Röviden: A multi-region ára gyakran nagyobb, mint a kockázat, amit fedez. A helyes út nem a maximumból, hanem a valós rendelkezésre állási célból visszafejteni az architektúrát.
A rendelkezésre állás körüli beszélgetés hajlamos túlmérnökösödni. Amint valaki kimondja a „mi lesz, ha kiesik egy régió?” kérdést, a csapat elkezd multi-region aktív-aktív architektúrát tervezni — pedig a valós üzleti igény gyakran ennek töredéke. A kérdés nem az, hogy elméletileg milyen katasztrófát tudsz túlélni, hanem hogy mennyi kiesést enged meg az üzlet, és mennyit ér neked azt megelőzni.
Először a cél, aztán az architektúra
Mielőtt bármit terveznél, két számot kell tisztázni: mennyi kiesést tolerálsz (helyreállítási idő), és mennyi adatvesztést (helyreállítási pont). Ez a két érték határozza meg, milyen architektúra indokolt. Ha ezeket nem az üzlettel közösen rögzítitek, akkor mérnöki érzésre fogsz túlkölteni.
A rendelkezésre állás rétegei
| Szint | Mit véd | Tipikus költség |
|---|---|---|
| Egy AZ | Semmi extra | Alap |
| Multi-AZ | Egy adatközpont-zóna kiesése | Mérsékelt |
| Multi-region passzív | Egy teljes régió kiesése | Magas |
| Multi-region aktív-aktív | Régiókiesés, zéró átállás | Nagyon magas |
A legtöbb szolgáltatásnak a multi-AZ a helyes szint: megvéd a leggyakoribb hibától (egy zóna kiesése) mérsékelt költséggel és komplexitással.
Miért drága a multi-region?
A multi-region nem csak duplikált infrastruktúra. Vele jár az adatreplikáció késleltetése és költsége, a régiók közötti forgalom díja, a konzisztencia kezelésének nehézsége, és — talán a legnagyobb rejtett tétel — az üzemeltetési komplexitás. Egy aktív-aktív rendszert helyesen működtetni és tesztelni folyamatos mérnöki figyelmet igényel.
A multi-AZ, amit sokan félig csinálnak
Mielőtt a multi-regionön gondolkodnál, érdemes megnézni, hogy a multi-AZ tényleg rendben van-e. Gyakori hiba, hogy a compute több zónában fut, de az adatbázis vagy egy kritikus komponens egyetlen zónában lakik — így az egész rendszer rendelkezésre állása annak az egy komponensnek a szintjére esik. A lánc annyira erős, mint a leggyengébb, egyzónás eleme.
Mikor indokolt a multi-region?
Vannak valós esetek: jogszabályi előírás, amely földrajzi redundanciát követel; olyan üzleti kritikusság, ahol egy régiókiesés perceit sem engedheted meg; vagy globális felhasználói bázis, ahol a régiók közelsége teljesítménykérdés. Ha ezek közül egyik sem áll fenn, akkor a multi-region jó eséllyel a rossz problémára költött pénz.
Egy józan döntési sorrend
- Rögzítsd az üzlettel a tolerálható kiesést és adatvesztést.
- Ellenőrizd, hogy a multi-AZ tényleg teljes-e — nincs-e egyzónás gyenge pont.
- Csak ha az üzleti igény vagy a jogszabály valóban megköveteli, lépj a multi-region felé.
- Ha multi-regionre mész, tervezz rendszeres DR-gyakorlatot — enélkül nem ér semmit.
A rendelkezésre állási célok kiszámítása
A rendelkezésre állási döntés akkor válik józanná, ha számokra fordítjuk. Két kulcsértéket kell rögzíteni az üzlettel: mennyi kiesést tolerálsz (a helyreállítási idő), és mennyi adatvesztést (a helyreállítási pont). Ezek nem mérnöki, hanem üzleti döntések — a mérnök feladata megmutatni, milyen architektúra és milyen költség tartozik az egyes szintekhez, majd az üzlet dönt.
Gyakran kiderül, hogy az üzlet valós tűréshatára sokkal nagyobb, mint amit a mérnöki ösztön feltételezett. Egy néhány perces kiesés sok szolgáltatásnál teljesen elfogadható — és ez a felismerés rengeteg felesleges komplexitást és költséget takarít meg.
Az egyzónás gyenge pont vadászata
Mielőtt a multi-regionön gondolkodnál, vadászd le a rejtett egyzónás gyenge pontokat. Gyakori, hogy a compute szépen több zónában fut, de egy kritikus komponens — egy adatbázis-példány, egy cache, egy megosztott fájlrendszer — egyetlen zónában lakik. Ilyenkor a rendszer valós rendelkezésre állása annak az egy elemnek a szintjére esik, hiába multi-AZ minden más.
- Térképezd fel, minden réteg tényleg több zónában van-e.
- Keresd a megosztott, egyzónás komponenseket.
- Ellenőrizd, hogy egy zóna kiesése nem szakít-e meg egy kritikus utat.
A DR-gyakorlat elengedhetetlensége
Bármilyen szintű katasztrófa-helyreállítást is választasz, az csak akkor ér valamit, ha rendszeresen gyakorlod. Egy sosem tesztelt átállás a valós katasztrófa pillanatában majdnem biztosan elhasal — kiderül egy elavult konfiguráció, egy hiányzó jogosultság, egy senki által nem ismert függőség. A DR-gyakorlat nem luxus, hanem a terv érvényességének egyetlen bizonyítéka.
Mit jelent ez neked?
A rendelkezésre állást ne a legrosszabb elképzelhető forgatókönyvből, hanem a valós üzleti tűréshatárból tervezd. A legtöbb szolgáltatásnak a jól megcsinált multi-AZ a helyes válasz: megvéd a gyakori hibáktól arányos költséggel. A multi-regiont csak akkor vállald, ha jogszabály vagy tényleges üzleti kritikusság indokolja — és akkor is csak akkor, ha van kapacitásod rendszeresen tesztelni. A nem tesztelt DR nem terv, csak remény.