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.
A 100%-os rendelkezésre állás mítosz. A felhasználóknak nem tökéletességre van szükségük, hanem következetességre és megbízhatóságra. Az SRE alapelvei az egyensúly megtalálására tanítanak: adatvezérelt döntéshozatal SLO-k és SLI-k segítségével, és okos kockázatvállalás error budgetek révén.
Elmúlt jó pár évem alatt megtanultam, hogy az „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, az SLO és az SLI. Ezek azért kritikus fontosságú metrikák számunkra, mert a segítségükkel 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 teljes mé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 Azure-ben 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 Azure-ben. 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 Terraformmal vagy pedig Kubernetes deployment-ekkel tudjuk elérni.
- Load Balancing/Gateway: Az LB és Gateway szintén nélkülö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!