75. Kapacitní plánování a předpověď růstu infrastruktury

Úvod a kontext

Modul 12 ukázal, jak monitorovat aktuální stav systému (metriky,
logy, trasování) a modul 11 popsal, jak funguje cloudové škálování
a jeho náklady. Kapacitní plánování spojuje obojí do jedné otázky
směřující do budoucnosti: "kolik zdrojů (CPU, paměť, disk, síťová
propustnost, databázové připojení) budeme potřebovat za tři, šest
nebo dvanáct měsíců, a kdy přesně dojdou ty současné?" Bez
kapacitního plánování se firma dozví odpověď nepříjemným způsobem —
výpadkem ve chvíli špičky (typicky Černý pátek, konec kvartálu,
virální článek) — nebo platí zbytečně za kapacitu, kterou nikdy
nevyužije.

Teorie

Proč nestačí škálovat reaktivně

Autoscaling z modulu 8 (horizontální škálování podů) a elastické
cloudové zdroje z modulu 11 řeší škálování v horizontu minut —
zvládnou reagovat na krátkodobý nárůst zátěže. Kapacitní plánování
řeší jiný, delší horizont: zdroje, které nelze navýšit v
řádu minut. Typické příklady:

• Databázový server — vertikální navýšení (větší instance)
  často vyžaduje odstávku nebo komplexní migraci (modul 6), ne
  jen příkaz navíc.
• Síťová kapacita datacentra nebo peering — objednání dalšího
  pásma u poskytovatele má dodací lhůtu v týdnech.
• Kvóty u cloudového poskytovatele — AWS/Azure/GCP mají výchozí
  limity (modul 11) na počet instancí, IP adres apod., jejichž
  navýšení vyžaduje žádost s několikadenní až týdenní odezvou.
• Licence a smluvní kapacita u komerčního softwaru nebo
  managed služeb.
• Lidská kapacita — i tým, který danou infrastrukturu provozuje,
  má limit na to, kolik dalších systémů dokáže spravovat.

U těchto zdrojů reaktivní přístup ("navýšíme, až to dojde") přijde
buď pozdě (výpadek), nebo draze (urgentní řešení za prémiovou cenu).

Z čeho se předpověď dělá

Základem je pravidelně sbíraná historie využití z monitoringu
(Prometheus/Grafana, modul 12) — typicky za posledních 6–12 měsíců,
s dostatečnou granularitou, aby byly vidět jak dlouhodobý trend, tak
sezónní vzory (denní špička, týdenní vzor pracovní dny/víkend,
roční sezónnost jako Vánoce v e-commerce). Ze surových dat se
odvozují dvě odlišné věci:

• Trend růstu — dlouhodobý směr (např. "využití disku roste
  lineárně o 8 % měsíčně" nebo "počet aktivních uživatelů roste
  exponenciálně s obchodním růstem firmy").
• Špička vs. průměr — kapacita musí pokrýt špičku, ne průměr;
  poměr špička/průměr (tzv. peak-to-average ratio) se u stabilního
  provozu obvykle drží konstantní, takže z předpovědi průměrného
  růstu lze odvodit i budoucí špičku.

Vstupem do předpovědi by měl být i byznysový kontext mimo čistě
technická data — plánovaná marketingová kampaň, otevření nového trhu,
sezónní akce — protože čistě technická extrapolace minulého trendu
takové skokové změny nezachytí.

Metody předpovědi (od jednoduché po pokročilejší)

1. Lineární extrapolace — nejjednodušší, vhodná pro krátký
   horizont a stabilní růst: proložit historická data přímkou a
   odečíst, kdy protne kapacitní limit.
2. Extrapolace s ohledem na sezónnost — u dat s výrazným
   sezónním vzorem (denním/týdenním/ročním) se od trendu odečítá
   sezónní složka zvlášť, aby krátkodobý výkyv nezkreslil
   dlouhodobý odhad (např. metody typu STL dekompozice nebo
   jednoduše porovnání "stejné období loni").
3. Odvození z byznys metrik — namísto přímé extrapolace
   technické metriky (např. CPU) se predikuje byznys metrika
   (počet uživatelů, počet objednávek) z byznys plánu a k ní se
   dopočítá technický nárok podle známého poměru (např. "1000
   aktivních uživatelů = přibližně 2 vCPU navíc" na základě
   měření zátěžovým testem, modul 5).
4. Zátěžové testování pro ověření limitů — simulace očekávané
   budoucí zátěže na testovacím prostředí, aby se zjistilo, kde
   systém skutečně selže, ne jen kde extrapolace předpokládá limit.

Kapacitní rezerva (headroom)

Kapacita by se nikdy neměla plánovat "na doraz" — je běžné držet
rezervu (headroom), typicky 20–40 % nad předpovězenou špičkou,
z několika důvodů: nepřesnost samotné předpovědi, prostor pro
neočekávaný nárazový provoz, čas potřebný na reakci (objednání
další kapacity trvá, viz výše), a prostor pro operace navíc jako
rolling update nasazení (modul 9), který dočasně potřebuje běžet
staré i nové verze současně. Příliš malá rezerva vede k výpadkům
při špičce; příliš velká rezerva znamená zbytečné náklady (modul 11)
— kapacitní plánování je vždy kompromis mezi spolehlivostí a cenou,
podobně jako volba SLO a error budgetu z modulu 14.

Praktický příklad

Ukázka jednoduchého kapacitního výpočtu pro databázové úložiště na
základě historických dat z monitoringu:

Vstupní data (z Prometheus dashboardu, posledních 6 měsíců):
  - Využití disku databáze dnes:         420 GB z celkových 500 GB (84 %)
  - Využití před 6 měsíci:               300 GB
  - Měsíční růst (lineárně):             (420 - 300) / 6 = 20 GB/měsíc

Predikce bez zásahu:
  - Volná kapacita dnes:                 500 - 420 = 80 GB
  - Čas do vyčerpání při 20 GB/měsíc:    80 / 20 = 4 měsíce

Rozhodnutí:
  - Objednávka většího disku má dodací/migrační lhůtu ~3 týdny.
  - Cílová rezerva (headroom): 30 % nad předpovězenou špičkou za
    12 měsíců od teď.
  - Předpověď za 12 měsíců: 420 + 12 * 20 = 660 GB
  - Cílová kapacita s rezervou: 660 * 1.3 ≈ 860 GB

Akce: navýšit disk na alespoň 900 GB (zaokrouhleno na dostupnou
velikost instance) nejpozději za 2 měsíce od teď (4 měsíce do
vyčerpání minus 3 týdny na realizaci minus bezpečnostní rezerva
na schválení a naplánování odstávky).

Stejný postup se dá zapsat jako jednoduchý PromQL dotaz, který
odhadne čas do vyčerpání přímo z aktuálního trendu (lineární
extrapolace pomocí funkce predict_linear, viz modul 12):

# Odhad, za kolik sekund dosáhne využití disku 100 %,
# extrapolací lineárního trendu za posledních 6 hodin
predict_linear(node_filesystem_avail_bytes{mountpoint="/data"}[6h], 4 * 7 * 24 * 3600) < 0

Shrnutí

Kapacitní plánování předpovídá budoucí nároky na zdroje, které
nejde navýšit v řádu minut (databáze, síťová kapacita, cloudové
kvóty, lidská kapacita), na rozdíl od autoscalingu, který řeší
krátkodobé výkyvy. Předpověď vychází z historických dat monitoringu
kombinovaných s byznysovým kontextem, používá metody od jednoduché
lineární extrapolace po odvození z byznys metrik a zátěžové testy,
a vždy počítá s rezervou (headroom), protože plánování "na doraz"
vede k výpadkům při první odchylce od odhadu.

Kontrolní otázky

1. Proč nestačí spoléhat na autoscaling a proč je i tak potřeba
   samostatné kapacitní plánování?
2. Jaký je rozdíl mezi predikcí založenou na čistě technické
   extrapolaci trendu a predikcí odvozenou z byznys metrik? Kdy je
   vhodnější druhý přístup?
3. Proč se kapacita neplánuje přesně na předpovězenou špičku, ale
   s rezervou (headroom), a co určuje, jak velká rezerva je vhodná?
4. Mini cvičení: databáze dnes využívá 600 GB z 800 GB kapacity a
   před 4 měsíci využívala 500 GB. Za jak dlouho dojde kapacita při
   lineárním trendu, a jakou minimální kapacitu byste objednali,
   pokud chcete pokrýt špičku za 9 měsíců s 25% rezervou?