Hedged Request Menekan Tail Latency dengan Biaya Terkendali

Sebuah service dapat memiliki median latency yang baik tetapi tetap menghasilkan sebagian kecil response yang sangat lambat. Antrean, jeda runtime, contention pada storage, packet loss, atau replica yang sedang sibuk dapat membuat request tertentu jauh lebih lambat daripada kasus umum.

Hedged request menangani ekor distribusi tersebut dengan mengirim salinan kedua setelah request pertama tertahan selama jeda tertentu. Caller menerima response valid pertama lalu membatalkan attempt yang tersisa. Teknik ini menukar sejumlah pekerjaan tambahan yang dibatasi dengan peluang untuk keluar dari jalur eksekusi yang kebetulan lambat.

Pertukaran tersebut berguna hanya ketika eksekusi duplikat aman dan traffic tambahan tetap terkendali.

Hedge dikirim setelah jeda, bukan langsung diduplikasi

Mengirim dua salinan setiap request pada saat yang sama dapat menurunkan latency, tetapi juga menggandakan traffic sebelum sistem memiliki indikasi bahwa suatu attempt lambat. Hedge memberi kesempatan bagi request biasa untuk selesai terlebih dahulu.

t0              t0 + hedge delay
|---------------------|
request A ------------|-------------------->
                      request B -------->
                              |
                              +-- response valid pertama

Delay dapat dikaitkan dengan percentile latency terbaru untuk operasi tersebut. Sebagai contoh, caller dapat mempertimbangkan hedge hanya setelah attempt utama melewati percentile tinggi dari observation window yang sesuai. Percentile yang dipilih merupakan kebijakan sistem, bukan angka universal.

Delay yang terlalu pendek menghasilkan banyak pekerjaan duplikat yang tidak perlu. Delay yang terlalu panjang menyisakan sedikit waktu bagi attempt kedua untuk memperbaiki deadline caller. Rentang yang berguna bergantung pada distribusi latency, sisa deadline, dan biaya setiap attempt.

Keragaman replica merupakan bagian dari mekanisme

Hedge hanya memberi sedikit manfaat jika kedua attempt masuk ke antrean yang sama atau bergantung pada resource bermasalah yang sama. Jika topology memungkinkan, attempt kedua sebaiknya diarahkan ke replica sehat atau jalur eksekusi lain.

Hal ini tidak berarti routing dilakukan secara acak tanpa batasan. Aturan eligibility normal tetap berlaku: locality, kepemilikan shard, kebutuhan consistency, capacity, dan health state masih relevan. Hedge hanya menghindari penempatan yang sama persis ketika penempatan itu mungkin menjadi sumber jalur lambat.

Failure yang berkorelasi membatasi manfaat. Jika semua replica menunggu satu partition database yang jenuh, menduplikasi request frontend hanya menambah pekerjaan tanpa keluar dari bottleneck. Mitigasi tail paling efektif ketika bagian yang berarti dari variasi latency bersifat independen antar-attempt yang memenuhi syarat.

Eksekusi duplikat harus aman secara semantik

Operasi read-only sering menjadi kandidat, tetapi label “read” saja belum cukup. Sebuah request dapat memicu accounting, access logging yang memiliki side effect, cache fill, perpanjangan lease, atau transisi state lain.

Untuk operasi yang dapat mengubah state, eksekusi duplikat memerlukan mekanisme keamanan yang eksplisit. Idempotency key dapat membantu service otoritatif mengenali command berulang, tetapi scope dan masa retensinya harus mencakup kedua attempt. Caller tidak dapat berasumsi bahwa cancellation mencegah request yang lebih lambat mencapai server.

attempt A ---- accepted ---- commit
attempt B ---- same key ---- existing result

Jika sebuah operasi tidak dapat menerima duplikat concurrent, operasi tersebut tidak layak diberi hedge hanya untuk memperbaiki latency.

Cancellation membatasi pemborosan tetapi tidak menghapusnya

Setelah satu attempt mengembalikan hasil yang dapat dipakai, caller sebaiknya segera membatalkan attempt lain. Cancellation melepaskan resource pada client dan dapat menghentikan pekerjaan server jika transport, framework, dan aplikasi meneruskannya dengan benar.

Cancellation bukan rollback. Attempt yang kalah mungkin sudah memakai CPU, mengirim storage I/O, mengambil lock, atau melakukan side effect sebelum sinyal cancellation tiba. Capacity planning karena itu harus menghitung pekerjaan hedge sebagai pekerjaan nyata, walaupun sebagian besar attempt yang kalah dibatalkan dengan cepat.

Caller juga memerlukan aturan mengenai response yang dapat diterima. Transport error yang datang cepat tidak selalu patut mengalahkan response sukses yang sedikit lebih lambat. Implementasi dapat membedakan hasil yang dapat dipakai dari kegagalan attempt dan tetap menunggu selama attempt lain masih dapat berhasil di dalam deadline.

Deadline request tetap menjadi batas terluar

Hedging tidak menjadi alasan untuk memperpanjang deadline caller. Semua attempt berada di dalam budget waktu end-to-end yang sama.

Sebelum meluncurkan hedge, caller perlu memeriksa apakah waktu yang tersisa cukup bagi attempt kedua untuk menghasilkan response yang berguna. Memulai duplikat beberapa milidetik sebelum deadline terluar dapat menambah beban dengan peluang manfaat yang sangat kecil.

outer deadline
|----------------------------------------|
primary  ---------------------------->
                 hedge  ----------->

Timeout per attempt dapat lebih pendek daripada deadline terluar, tetapi tidak boleh menciptakan jalur yang hidup melewatinya. Cancellation dari upstream caller harus menghentikan attempt utama dan hedge.

Dengan batas ini, kebijakan latency tetap dapat disusun lintas service boundary. Optimasi downstream tunduk pada budget request yang sama dan tidak diam-diam membuat budget baru.

Budget mencegah hedge memperbesar overload

Tail latency sering meningkat saat overload, tepat ketika duplikasi tanpa batas paling berbahaya. Jika setiap request lambat meluncurkan request tambahan, pekerjaan ekstra dapat memperpanjang antrean dan menghasilkan lebih banyak hedge.

Policy produksi memerlukan budget yang tegas. Sistem dapat membatasi hedge melalui token bucket, rasio hedge maksimum, concurrency cap, atau gabungan beberapa kontrol tersebut. Ketika budget habis, request berjalan tanpa duplikat.

Policy juga sebaiknya mempertimbangkan sinyal capacity. Replica pool yang mendekati saturasi bukan tempat yang tepat untuk traffic hedge agresif. Menahan hedge selama overload dapat menjaga throughput walaupun tail latency individual sementara meningkat.

Perbedaannya penting: hedging merupakan optimasi latency, bukan pengganti admission control, capacity, atau backpressure.

Pengukuran perlu memisahkan pekerjaan utama dan hedge

Satu histogram latency tidak dapat menunjukkan efisiensi hedging. Telemetry perlu membedakan attempt utama, hedged attempt, pemenang, cancellation, dan attempt yang tetap berjalan setelah cancellation.

Pengukuran yang berguna mencakup hedge launch rate, proporsi hedge yang menang, tambahan volume request, cancellation latency, latency per attempt, latency end-to-end, serta pekerjaan server dari attempt yang kalah. Sinyal tersebut dapat menunjukkan policy yang memperbaiki satu percentile dengan menghabiskan capacity terlalu besar.

Hedge delay juga perlu dikalibrasi ulang secara berkala jika nilainya berasal dari latency yang diamati. Threshold tetap yang dipilih saat traffic ringan dapat berperilaku sangat berbeda setelah workload, topology, atau distribusi service time berubah.

Penurunan tail harus tetap menjaga stabilitas sistem

Hedged request efektif ketika attempt lambat sering merupakan kejadian terisolasi dan jalur lain yang memenuhi syarat dapat selesai lebih cepat. Mekanisme yang sama menjadi mahal ketika pekerjaan duplikat tidak aman, failure sangat berkorelasi, atau service sudah kekurangan capacity.

Implementasi yang kuat memberi jeda sebelum duplikat, mengarahkannya melalui jalur alternatif yang memenuhi syarat, memakai deadline asli yang sama, membatalkan pekerjaan yang kalah, dan menerapkan budget hedge yang ketat. Dengan batas tersebut, tail latency dapat ditekan tanpa mengubah setiap request lambat menjadi beban yang tidak terkendali.