TakéLeaky bucket algorithm, algoritmus děravého kbelíkuPokročilý

Definice

Leaky bucket je algoritmus pro omezení nebo vyhlazení toku požadavků, paketů či událostí pomocí pomyslného kbelíku, který odtéká stálou rychlostí. Příchozí dávky se ukládají do fronty, přebytky při zaplnění propadnou a výstup zůstává předvídatelný i při nárazové zátěži v API, sítích i zpracování zpráv.

Kategorie: Sítě a protokolyAktualizováno

Jak leaky bucket funguje

Leaky bucket pracuje s představou nádoby s omezenou kapacitou. Nové požadavky, pakety nebo události do ní přitékají nepravidelně. Odtok je naopak pevně daný, například jeden požadavek za určitou dobu. Pokud je nádoba plná, další příchozí položka se odmítne, zahodí nebo označí jako nadlimitní podle konkrétní implementace.

Algoritmus se v praxi používá ve dvou blízkých významech. Varianta jako fronta vyhlazuje provoz: krátký náraz přijme do zásoby a ven pouští stabilní tempo. Varianta jako měřič pouze kontroluje, zda tok nepřekročil povolený profil, a přebytečné položky označí nebo zahodí bez skutečného čekání ve frontě.

Důležité parametry jsou kapacita kbelíku, rychlost odtoku a pravidlo pro přetečení. Kapacita určuje, jak velký výkyv systém snese. Rychlost odtoku určuje dlouhodobý limit. Pravidlo pro přetečení rozhoduje o uživatelské zkušenosti: klient může dostat chybu 429 Too Many Requests, paket může být zahozen nebo úloha může čekat na pozdější zpracování.

Kdy leaky bucket použít a kdy ne

Leaky bucket se hodí tam, kde je potřeba chránit službu před špičkami a zároveň držet předvídatelný výstup. Typickým místem je API gateway, příjem webhooků, odesílání e-mailů, síťové traffic shaping pravidlo nebo interní fronta před pomalejší závislostí. Výhodou je jednoduché chování: výstupní rychlost lze snadno vysvětlit, testovat i monitorovat.

Leaky bucket není ideální, pokud aplikace potřebuje občas povolit krátký legitimní burst bez umělého zpomalení. Pro takovou situaci často lépe sedí token bucket, protože nevyužité povolení může chvíli hromadit a později utratit. Leaky bucket také nemusí být vhodný pro požadavky s výrazně rozdílnou cenou, pokud všechny položky počítá stejně.

Na co si dát pozor

Leaky bucket může zvyšovat latenci, protože požadavky čekají, než na ně přijde řada. Příliš velká kapacita sice sníží počet odmítnutí, ale může vytvořit dlouhou frontu a uživatel stejně dostane odpověď pozdě. Příliš malá kapacita zase trestá i krátké běžné výkyvy.

Distribuovaná implementace potřebuje sdílený stav nebo pečlivé dělení limitu mezi instance. Pokud každá replika počítá vlastní kbelík, celkový limit se může násobit počtem replik. Systémy s více prioritami navíc potřebují rozhodnout, zda mají všechny požadavky čekat ve stejné frontě, nebo zda důležité operace dostanou samostatný limit.

Monitorování by mělo sledovat obsazení fronty, počet odmítnutých položek, dobu čekání a skutečnou výstupní rychlost. Samotný počet chyb nestačí, protože přetížený systém může nejdřív působit zdravě, zatímco fronta skrytě roste.

Příklady z praxe

  1. Ochrana HTTP API před nárazem požadavků

    API přijme během jedné sekundy dvacet požadavků od stejného klienta, ale backend bezpečně zvládá jen pět požadavků za sekundu. Leaky bucket uloží několik prvních požadavků do fronty, postupně je pouští dál a zbytek odmítne s odpovědí 429. Backend zůstane stabilní, ale klient musí počítat s limitem a opakováním později.

    const capacity = 5;
    const intervalMs = 200;
    const queue = [];
    
    function accept(req) {
      if (queue.length >= capacity) return false;
      queue.push(req);
      return true;
    }
    
    setInterval(() => {
      const req = queue.shift();
      if (req) handle(req);
    }, intervalMs);
  2. Vyhlazení provozu na síťové lince

    Router na hraně sítě přijímá krátké špičky paketů z aplikace pro zálohování. Leaky bucket nastaví stálou výstupní rychlost směrem do pomalejší linky, takže provoz nezahltí další zařízení. Pokud špička trvá příliš dlouho a kapacita se zaplní, nadbytečné pakety se zahodí nebo označí podle politiky sítě.

Časté omyly

MýtusLeaky bucket a token bucket jsou totéž.
Ve skutečnostiLeaky bucket a token bucket řeší podobný problém, ale mají jiné chování při nárazové zátěži. Leaky bucket typicky drží stálý odtok, zatímco token bucket může krátkodobě povolit burst z nastřádaných tokenů.
MýtusLeaky bucket vždycky jen zpomalí klienta, nikdy nic nezahodí.
Ve skutečnostiLeaky bucket má omezenou kapacitu. Pokud příchozí tok překročí kapacitu fronty nebo měřiče, implementace může další požadavky odmítnout, pakety zahodit nebo je označit jako nadlimitní.
MýtusStačí nastavit velký bucket a problém se špičkami zmizí.
Ve skutečnostiVelká kapacita pouze přesune problém do čekání ve frontě. Uživatelé mohou dostávat odpovědi pozdě a systém může spotřebovat mnoho paměti, i když počet odmítnutí vypadá nízko.

Časté dotazy

Kdy se leaky bucket používá v API?
Leaky bucket se v API používá hlavně jako rate limiter nebo jako fronta před částí systému, která nesmí dostat příliš mnoho práce najednou. API gateway může přijímat krátké špičky, pouštět požadavky do aplikace stabilním tempem a po zaplnění kapacity vracet chybu 429. Takové chování chrání databázi, externí integrace i aplikační servery.
Zahazuje leaky bucket požadavky?
Leaky bucket může požadavky zahazovat, odmítat nebo pouze zdržovat, záleží na zvolené implementaci. Frontová varianta drží položky do naplnění kapacity a poté další položky odmítne. Měřicí varianta žádnou reálnou frontu mít nemusí a pouze rozhodne, zda je příchozí provoz ještě v povoleném profilu.
Je leaky bucket vhodný pro distribuovaný rate limiting?
Leaky bucket je pro distribuovaný rate limiting použitelný, ale vyžaduje opatrnost. Více aplikačních instancí musí sdílet stav kbelíku, nebo musí mít limit rozdělený tak, aby součet nepřekročil zamýšlenou hodnotu. Bez společného počítání může každá instance povolit vlastní dávku požadavků a celkový limit se nechtěně znásobí.

Zdroje

  1. Leaky bucket(otevře se v novém okně)Wikipedia
  2. An Informal Management Model for Diffserv Routers(otevře se v novém okně)RFC Editor, 2002
  3. A Single Rate Three Color Marker(otevře se v novém okně)RFC Editor, 1999
  4. A Two Rate Three Color Marker(otevře se v novém okně)RFC Editor, 1999

Související pojmy

Potřebujete to vyřešit v praxi?

Poradíme, jak na to ve vašem projektu

Vysvětlit pojem je jedna věc, navrhnout kolem něj funkční řešení druhá. Ozvěte se a probereme, co dává smysl u vás.