InfoQ: DDSketch lovi spore mikroservise prije nego što p99 izgori

InfoQ-ov tekst “Adaptive Hedged Requests for Reducing p99 Latency”, koji potpisuje Prathamesh Bhope, polazi upravo od te točke. Hedged request nije nova ideja: pošalje se rezervni zahtjev ako prvi predugo traje, a prvi uspješni odgovor pobjeđuje. Problem je što naivna verzija lako stvara dodatno opterećenje. Ako sustav svaku sumnjivo sporu operaciju duplira bez kontrole, p99 se može popraviti na grafikonu, ali infrastruktura dobije novi val rada koji pogoršava sljedeći incident.

Ovdje je važan pridjev “adaptivni”. Umjesto statičnog timeouta, mehanizam koristi DDSketch za procjenu kvantila latencije u stvarnom vremenu. To znači da prag za hedging ne mora biti ručno pogođena brojka, nego se može vezati uz aktualnu distribuciju odgovora. Kada se sustav ubrza ili uspori, prag se pomiče zajedno s njim. To je bitno u produkciji, gdje latencija ne živi u urednoj laboratorijskoj krivulji nego se mijenja zbog prometa, cache hit ratea, deploymenta, regionalnih problema i vanjskih ovisnosti.

Drugi dio dizajna su rotirajući vremenski prozori. Oni sprječavaju da se odluke donose na temelju prestarih uzoraka. Ako se distribucija latencije pomakne, sustav mora brzo zaboraviti jučerašnju sliku i reagirati na sadašnju. U suprotnom hedging postaje trom: ili prekasno šalje rezervni zahtjev pa ne pomaže p99, ili ga šalje prerano pa gomila rad.

Treći osigurač je token-bucket budžet. To je praktična kontrola štete: hedging dobiva ograničen broj “žetona”, odnosno pravo na dodatne zahtjeve samo dok je potrošnja unutar budžeta. Slična logika token bucketa dobro je poznata iz rate limitinga i prometnog oblikovanja, primjerice u RFC 2697. U ovom kontekstu služi urednički jasnoj svrsi: optimizacija repne latencije ne smije postati skriveni DDoS protiv vlastitih servisa.

Signal iz članka je snažan jer navodi smanjenje p99 latencije za 74 posto. Ta brojka nije samo kozmetička metrika. P99 je mjesto gdje se skupljaju korisnici koji imaju najgore iskustvo, transakcije koje probijaju SLA i zahtjevi koji u lancu pozivaju nove timeout strategije. Googleov klasični rad “The Tail at Scale” godinama je referenca za isti problem: kada sustav raste, rep distribucije postaje proizvodni problem, ne statistička fusnota.

Najzanimljiviji dio nije samo slanje rezervnog zahtjeva, nego kombinacija triju ograničenja: mjeri se aktualni rep, zaboravlja se zastarjela distribucija i troši se strogo ograničen budžet. To adaptivni hedging čini operativnom tehnikom, a ne samo optimističnim trikom. Za velike distribuirane sustave poruka je prilično izravna: ne treba svaki spor zahtjev tretirati kao kvar, ali ga ne treba ni pasivno čekati dok p99 izgara.