Az „availability” jelentése túl az uptime-on – jól skálázható rendszerek tervezése
DevOps és SRE poziciókban, gyakran esünk abba a hibába, hogy az „availability”-t, vagyis a rendelkezésre állást, egyszerűen az „uptime”-mal, a rendszer működési idejével azonosítjuk. „Minden zöld? Akkor minden rendben.” Pedig ez nagyon nem így van. Ez a leegyszerűsítő gondolkodás azonban nagyon veszélyes lehet, különösen a mai, komplex, microservices vagy monolithic alapú és folyamatosan skálázódó rendszerek korában. Egy tapasztalt SRE vagy DevOps szakember tudja, hogy a valódi hibátlan működés sokkal több, mint hogy nem csörög a pager duty. Az üzleti siker a felhasználói élményen és a szolgáltatás minőségén áll vagy bukik. Fontos tudás, hogy képesek vagyunk-e a metrikáinkat a maga teljességében mérni és értelmezni.
Long story short:
Elmúlt jó pár évem alatt megtanultam, hogy a „availability” tehát nem egy fix állapot, hanem egy folyamatosan változó cél, amelynek eléréséhez mindig szondáznunk és elemezni kell a rendszereinket tudatosan, skálázhatóságot és hibatűrést szem előtt tartva.
SLA, SLO, SLI – Az architektúra megbízhatóság mértékegységei
Triviális, de mégis fontos fogalmak: az SLA-t, SLO-t és SLI-t. Ezek azon oknál fogva kritikus fontosságú metrikák számunkra, mivel segítségével objektíven mérhetjük és javíthatjuk rendszereink teljesítményét.
- Service Level Agreement (SLA): Ez az a papír amit az ügyfél lobogtat, hogyha nem megy az alkalmazása. Gyakran tartalmaznak olyan általánosabb megfogalmazásokat, mint például a „a rendszernek 99,5%-os elérhetőséggel kell működnie, hogyha nem akkor KÖTBÉR”.
- Service Level Objective (SLO): Az SLO egy meghatározott és mérhető cél, amit a szolgáltatásunknak teljesíteni kell. Ezt általában a belső csapatok maguk tűzik ki, és szigorúbb, mint az SLA-ban foglalt ígéret. Például, ha az SLA 99,5%-os működést ír elő, a belső (fejlesztői/ops) SLO lehet 99,9%. Ez a puffer, az úgynevezett „hiba keret” (error budget), lehetővé teszi a csapat számára, hogy kockázatot vállaljon, új funkciókat vezessen be anélkül, hogy az SLA megsértését kockáztatná.
- Service Level Indicator (SLI): Az SLI-t a SLO teljesüléséből mérjük. Az SLI-nek közvetlenül a felhasználói élményt kell tükröznie. Például az alkalmazásunk esetében egy jó SLI lehet a sikeres HTTP kérések aránya, vagy a kérések 95%-ának 200 ms-on belül van a válaszideje, mivel egy felhasználó se szeret sokat várakozni
Miért is fontosak ezek a mértékek számunkra?
Az SLA, SLO és SLI hármasa egy objektív keretrendszert ad számunkra amivel mérhetjük a projektünk és az alkalmazásunk elérhetőségét. Segít abban, hogy teljesmértékben adatalapú döntéseket tudjunk meghozni, olyan technikai kérdésekben, hogy drága munkaidő most a architektúra stabilitására fókuszáljon, vagy pedig egy új feature implementálására.
Hogyan javítsunk a metrikákon? A skálázhatóság és a rendelkezésre állás kéz a kézben jár
A magas rendelkezésre állás és a szigorú SLO-k elérése nem a véletlen műve, hanem tudatos tervezés eredménye. Jól skálázható rendszereket ezen metrikák alapján lehet tervezni
- Redundancia és hibatűrés: A klub első szabálya: soha, de SOHA ne bízzunk egyetlen erőforrásban, hiába van alatta „megfelelő vas” akkor is tönkre mehet és ezzel rontja a felhasználói élményt. Legyen szó szerverekről amiken az alkalmazás fut vagy adatbázisokról, mindig tervezzünk redundanciával, legalább master-slave modellt használjunk az utóbbi eszköznél. A felhőszolgáltatók (mint az AWS, a GCP vagy az Azure) által kínált availability zones és régiók közötti replikáció kiváló eszköz erre. Mindenképp érdemes úgy tervezni az architektúrát, hogy a kritikus erőforrások, mint például adatbázisok AZ-ban legyenek, mivel ha az Azureben a West Europe region nem működik (és volt már olyan, hogy lehalt az a régió source: https://azure.status.microsoft/en-gb/status/history/) attól még a North Europe-ban lévő adatbázis képes kiszolgálni a felhasználókat.
- Horizontális skálázás és autoscaling: Ahelyett, hogy egyetlen, hatalmas és drága szerverre (vertikális skálázás) építenénk, a modern rendszerek a horizontális skálázást részesítik előnyben (microservicek esetében lehetséges), ahol a megnövekedett terheléssel újabb, kisebb szervereket (instance-okat) adunk a rendszerhez például availability sets-el Azureben. Az automatikus skálázás (autoscaling) segítségével a rendszer dinamikusan tud alkalmazkodni a terhelés változásaihoz, biztosítva a folyamatos működést anélkül, hogy bármiféle manuális beavatkozásra lenne szükség a megfelelő szabályok alkalmazásával, ezeket vagy Terraform-al vagy pedig Kubernetes deployment-ekkel tudjuk elérni.
- Load Balancing/Gateway: Az LB és Gateway szintén nélkülönözhetetlenek a skálázható architektúrákban mivel Layer 4 és Layer 7 tudják szétosztani a forgalmat így megakadályozva, hogy egyetlen szerver is túlterhelődjön. Ezenfelül a LB-k képesek érzékelni a nem megfelelően működő szervereket az általunk implementált healthcheck-ek segítségével, így kizárja őket a forgalomból, ezzel is növelve a rendszer általános elérhetőségét.
- Microservices: A monolitikus alkalmazásokkal szemben a microservice architektúra kisebb, egymástól függetlenebb szervizekre bontja a rendszert. Ez amiatt is ideálisabb, mivel az egyes szolgáltatásokat egymástól függetlenül fejlesztjük, telepítjük és skálázzuk. Egy microservice meghibásodása nem feltétlenül rántja magával az egész rendszert, így növelve a hibatűrést, mivel mindig úgy telepítjük őket, hogy LEGALÁBB 2 pod/instance működjön.
- Chaos Engineering: A nevéből adódóan, hogy szándékosan, kontrollált környezetben (természetesen nem PROD-on, hanem DEV-en vagy pedig TEST-en) idézünk elő hibákat a rendszerben (például egy adatbázis leállításával), hogy teszteljük annak ellenálló képességét és az automatikus hibajavító mechanizmusok működését. Ez a proaktív megközelítés segít feltárni a rejtett gyengeségeket, mielőtt azok éles környezetben okoznának problémát.
Nálatok hogy alakulnak a SLA/SLO metrikák? Kiszoktátok használni a puffer time-ot rendszer fejlesztésre vagy feature development az első? Következő részben a fault-toleranciában fogunk elmerülni, iratkozzatok fel, hogy a leghamarabb értesüljetek a cikkről!
