Aplikace eDoklady umožňuje prokazovat se digitální podobou občanského průkazu v telefonu. Při otevření a aktualizaci dokladu však klient komunikuje přes vstupní bránu s aplikačními servery a navazujícími státními systémy. DIA proto před podzimními volbami připravila veřejný zátěžový test, který měl prověřit celý tento řetězec ve chvíli, kdy aplikaci otevřou tisíce lidí současně.

Ve čtvrtek 13. srpna měli účastníci otevřít eDoklady přesně ve 13:00. Aplikační servery podle závěrečné analýzy zpracovaly 95 procent přihlášení do 20 milisekund. Při měření z telefonu však odezva u 95 procent požadavků nepřesáhla 22,2 sekundy. Obě metriky zachycovaly jinou část cesty: první zahrnovala jen práci aplikačních serverů, druhá i čas strávený před nimi. Právě tam podle DIA některá spojení čekala ve frontě.

Medián vypadal dobře, vyšší percentily už ne

V intervalu od 13:00 do 13:10 činil medián celkové odezvy z telefonu 267 milisekund, před testem 28 milisekund. U 99 procent požadavků odezva nepřesáhla 33,5 sekundy, zatímco před špičkou to bylo 3,6 sekundy. Nejméně polovina požadavků tedy skončila do 267 milisekund, ale u nejpomalejšího procenta trvala odezva déle než 33,5 sekundy.

Odezvu z pohledu uživatele proto nelze spolehlivě shrnout ani průměrem, ani jediným číslem z backendu. Vyšší percentily ukazují pomalé požadavky, které v souhrnné hodnotě zaniknou. V tomto případě navíc ukázaly, že rychlé zpracování uvnitř aplikace nevylučuje dlouhé čekání před ní.

Požadavky čekaly před aplikačními servery

Během prvních dvou minut vzrostl počet souběžných spojení na vstupní bráně téměř dvanáctkrát a v nejvytíženější sekundě přišlo 1 712 požadavků. Vstupní vrstva pak musí téměř okamžitě obsloužit mnohonásobně více spojení a automatické škálování přidat kapacitu. Pokud se nová kapacita nezapojí včas, začne se tvořit fronta.

Aplikační servery za bránou přitom zůstaly rychlé: 95 procent požadavků na vydání dokladu zpracovaly do 179 milisekund a stabilní byly také odezvy navazujících registrů. Za hlavní omezení označila závěrečná analýza vstupní bránu Application Gateway. Automatické škálování po skokovém nárůstu spojení nezvýšilo její kapacitu dost rychle, takže některé požadavky čekaly ve frontě a u části z nich vypršel časový limit při načítání statických dat potřebných k otevření aplikace.

DIA následně oznámila zvýšení předem připravené kapacity brány a změnu distribuce statického obsahu. Přidat další aplikační servery by frontu vznikající před nimi samo o sobě neodstranilo.

Druhá vlna dala automatickému škálování čas

Večer téhož dne přišla během televizního zpravodajství neplánovaná druhá vlna. Za přibližně půl hodiny prošlo systémem přes 14 tisíc přihlášení a přeneslo se 19,7 GB dat, podle DIA podobné množství jako odpoledne. Medián odezvy tentokrát činil 29 milisekund a 99. percentil 4,3 sekundy.

Odpoledne přišli lidé na pokyn téměř současně, večer provoz rostl plynuleji. DIA lepší výsledek připsala tomuto pozvolnějšímu náběhu. Vysvětlení odpovídá obecnému chování služby: podle dokumentace Microsoftu trvá u Application Gateway v2 přidání instancí schopných přijímat provoz obvykle tři až pět minut. Přesný čas škálování konkrétní konfigurace eDokladů veřejné podklady neuvádějí.

Application Gateway večer využila až 65 kapacitních jednotek, odpoledne nejvýše 50. Kapacitní jednotka není server, ale složená míra výpočetního zatížení, trvalých spojení a datové propustnosti. Z rozdílu mezi 50 a 65 proto nelze odvodit počet běžících instancí ani to, která ze tří složek výslednou hodnotu určila.

Obě vlny nebyly kontrolovaným experimentem. Lišil se počet přihlášení i průběh provozu a rozdílný mohl být také stav mezipamětí nebo skladba operací. Plynulejší náběh je proto věrohodným, nikoli jediným prokázaným vysvětlením. Další testy by měly oddělit náhlý skok od postupného náběhu a studený stav od zahřátého.

Generátor zátěže vytvoří provoz, ne testovací identitu

Takovou špičku lze vytvořit i synteticky. V uzavřeném modelu však virtuální uživatel zahájí další iteraci až po dokončení předchozí. Když systém zpomalí, test začne posílat méně nových požadavků právě ve chvíli, kdy by měl tlak udržet. Dokumentace k6 tento jev označuje jako coordinated omission. Otevřený model zahajuje nové iterace nezávisle na době odezvy. Zamýšlenou frekvenci však udrží jen tehdy, má-li generátor dost prostředků.

Ani správně nastavený otevřený model ale nevytvoří platnou identitu v několika propojených státních systémech. DIA uměla izolované komponenty zatěžovat virtuálními uživateli a některé závislosti nahrazovat. Pro produkční průchod službou jí však chyběla dostatečná populace testovacích identit použitelných v základních registrech a navazujících systémech. Generátor sám nevytvoří desetitisíce identit, které by ve všech zapojených systémech byly v potřebném stavu.

Hlavní vlna ve 13 hodin zároveň nebyla souběžnou registrací všech 30 tisíc účastníků. Noví uživatelé se měli zaregistrovat předem; během špičky měli lidé aplikaci otevřít, odemknout PINem nebo biometrií a počkat na aktualizaci dokladu. Test tak prověřoval především otevření aplikace, přihlášení a aktualizaci dokladu, nikoli hromadnou registraci přes Identitu občana.

Skutečný provoz předepsaný scénář přesto přesahoval. Od rána do 13:15 DIA zaznamenala 6 600 nových registrací a nejnovější verzi aplikace měla jen přibližně polovina účastníků. Interval je širší než hlavní špička, takže registrace nelze přičíst pouze jejím prvním minutám.

Veřejný test doplňuje syntetický, nenahrazuje ho

Zapojení veřejnosti je náročné na koordinaci a špatně se opakuje. Pro pravidelné ověřování změn proto zůstávají vhodnější automatizované testy s řízeným náběhem a známými daty. Nestačí přitom zatížit jediný endpoint: scénáře musejí oddělit náhlý náběh od postupného a telemetrie musí zachytit latenci v jednotlivých vrstvách, čekání ve frontě, okamžiky škálování i celkovou odezvu z klienta.

Veřejný test nebyl užitečný proto, že by lidé dokázali vytvořit větší nápor než generátor. Přinesli do něj to, co syntetickému scénáři chybělo: použitelné identity, skutečná zařízení a méně předvídatelný průběh provozu. Fronta před rychlým backendem pak ukázala, že věrnost testu neurčuje samotný objem zátěže, ale to, zda požadavky projdou stejnou cestou jako uživatel.