99,99% rendelkezésre állás egy kritikus rádióplatformhoz

A kihívás

Egy médiatechnológiai vállalat rádiós streaming platformot épített, amit több országban, milliós hallgatóság mellett kellett stabilan működtetni. A rendszer élő adásokat, on-demand tartalmakat és valós idejű hirdetésbeszúrást kezelt, miközben a leállás gyakorlatilag nem fért bele.

A tét nagyon is kézzelfogható volt:

• Az élő adás nem akadhat meg. Ha egy műsor közben megszakad a stream, a hallgató gyorsan továbbáll, és nem biztos, hogy visszajön
• A szabályozói elvárások dokumentált rendelkezésre állási garanciákat kértek számon
• A csúcsforgalom kiszámíthatatlan volt. Egy friss hír pár perc alatt a 10-szeresére tudta húzni a terhelést
• A meglévő infrastruktúra egyetlen régióban futott, redundancia nélkül, a monitoring pedig nagyjából annyit jelentett, hogy „valaki majd ránéz”. Néha ránéztek, néha kevésbé

Olyan architektúrára volt szükség, ami akkor is megy tovább, amikor több dolog egyszerre romlik el.

A megközelítés

A rendszert geo-redundánsra terveztem és az alapoktól így is építettem fel. A monitoring és az incidenskezelés nem utólagos toldás lett, hanem az első naptól a design része.

Geo-redundáns architektúra

Két AWS régióba telepítettem active-active konfigurációban:

• Route 53 health checkek latenciaalapú routinggal. A hallgatók automatikusan a legközelebbi, egészséges végpontra kerültek
• Azonos infrastruktúra stackek mindkét régióban, teljesen Terraformban definiálva. Nincsenek „helyi varázslatok”
• Régiók közötti adatreplikáció a tartalommetaadatokhoz és a felhasználói állapotokhoz
• CDN réteg CloudFronttal a statikus elemekhez és az előre felvett tartalmakhoz, ami 70%-kal csökkentette az origin terhelését

A legfontosabb tervezési elv: bármelyik régió önállóan is el tudja vinni a teljes forgalmat. Ezt rendszeresen teszteltem úgy, hogy az egyik régiót teljesen leürítettem. A bizalom jó, a próba még jobb.

Monitoring és megfigyelhetőség

Teljes körű megfigyelhetőségi stacket építettem:

• Prometheus metrikagyűjtésre, Thanos hosszú távú tárolással
• Grafana dashboardok, amelyek valódi operatív kérdésekre adtak választ, nem csak szépek voltak. Például: „Egészséges a platform?” „Hol szűkül be?” „Most kell valakit felébreszteni?”
• Egyedi metrikák a stream állapotához: hallgatószám, buffering arány, stream késleltetés, hirdetésbeszúrási sikerráta
• Előre definiált SLO-k: 99,99% rendelkezésre állás, <200ms streamindítási idő, <1% hirdetésbeszúrási hibaarány
• Többcsatornás riasztás. PagerDuty a kritikus eseményekre, Slack figyelmeztetésre, email tájékoztatásra. Sok idő ment el a küszöbök finomhangolására, mert a riasztásfáradtság csendben teszi tönkre a megbízhatóságot

Incidenskezelés

A monitoring önmagában csak fél megoldás, ezért komplett incidenskezelési keretrendszer is készült:

• Runbookok minden riasztáshoz. Nem az, hogy „nézd meg, mi van”, hanem konkrét lépések, amiket ügyeletben, hajnali 3-kor is végig lehet vinni
• Automatizált javítások a tipikus problémákra: pod-újraindítás, forgalomátterelés, cache ürítés
• Incidens súlyossági szintek egyértelmű eszkalációs útvonallal
• Incidens utáni értékelés hibáztatás helyett rendszerfejlesztési fókuszban
• Káosztesztek. Havi game day gyakorlatok, amikor szándékosan elrontottunk dolgokat productionben. Meglepően nyugodt érzés, amikor tudod, hogy vissza is tudod hozni

Az eredmények

Három hónap építés és keményítés után:

A platform több nagy hírhelyzetet is gond nélkül kezelt 10-szeres forgalmi csúcs mellett, érdemi degradáció nélkül. A monitoring rendszer többször még azelőtt jelezte a problémát, hogy abból felhasználói kiesés lett volna. Egy esetben például az adatbázis connection pool kimerülését 15 perccel a felhasználói hatás előtt sikerült észlelni és kezelni.

Az ügyfél platformba vetett bizalma látványosan megerősödött. A korábbi óvatos bővítés helyett magabiztosabb terjeszkedésre váltottak, mert az infrastruktúra ezt már valóban elbírta.