Ez a cikk összegyűjti azokat a közös sablonokat, amelyek segítik a mérnököket nagy léptékű szolgáltatásokkal dolgozni, amelyeket millió felhasználó keres.
A szerző tapasztalatai alapján ez nem egy kimerítő lista, de valóban hatékony tanácsok. Tehát kezdjük.
Fordította: .
Alapszint
Az alább felsorolt intézkedések viszonylag egyszerűek megvalósítani, de nagy hozadékot adnak. Ha korábban nem alkalmaztad őket, meglepődni fogsz a jelentős javulásokon.
Infrastruktúra mint kód
Az első tanács az, hogy a infrastrukturát kód formájában valósítsuk meg. Ez azt jelenti, hogy programozott módon kell telepítened az egész infrastruktúrát. Furcsán hangzik, de valójában a következő kódra gondolunk:
100 virtuális gép telepítése
- Ubuntu-val
- 2 GB RAM-mal mindegyik
- a következő kódot fogja tartalmazni
- ilyen paraméterekkel
Nyomon követheted az infrastruktúrában bekövetkezett változásokat, és gyorsan vissza tudsz térni hozzájuk a verziókezelő rendszer segítségével.
A modernizmus azt mondja nekem, hogy használhatsz Kubernetes/Docker-t, hogy mindezt megvalósítsd, és igaza van.
Ezenkívül az automatizálást valósíthatjuk meg Chef, Puppet vagy Terraform segítségével.
Folyamatos integráció és szállítás
Mérhető szolgáltatás létrehozásához fontos, hogy minden pull requesthez legyen egy építési és tesztelési folyamat. Még ha a teszt a legegyszerűbb is, akkor is garanciát ad arra, hogy a telepítendő kód lefordítható.
Minden alkalommal, ezen a ponton, megválaszolod a kérdést: lehet-e a build-em lefordítani és tesztelni, érvényes-e? Ez alacsony lécnek tűnhet, de sok problémát megold.
Nincs is szebb, mint látni ezeket a pipákat
Ehhez a technológiához nézd meg a Github-ot, CircleCI-t vagy Jenkins-t.
Terheléselosztók
Tehát terheléselosztót szeretnénk indítani, hogy átirányítsuk a forgalmat, és biztosítsuk az egyenlő terhelést az összes csomóponton vagy a szolgáltatás működését hiba esetén:
A terheléselosztó általában jól segít a forgalom eloszlásában. A legjobb gyakorlat a redundáns terheléselosztás, hogy ne legyen egyetlen hibapont.
A terheléselosztókat általában abban a felhőben állítják be, amelyet használsz.
RayID, korrelációs ID vagy UUID a kérésekhez
Találkoztál már olyan hibával az alkalmazásban, amelynek üzenete valami ilyesmi volt: „Valami hiba történt. Kérjük, mentsd el ezt az azonosítót, és küldd el támogatási szolgáltatásunknak”?
Az egyedi azonosító, korrelációs azonosító, RayID vagy bármely más hasonló változat egy egyedi azonosító, amely lehetővé teszi a kérés nyomon követését annak életciklusa során. Ez lehetővé teszi, hogy nyomon követhessük a kérés teljes útját a naplófájlokban.
A felhasználó kérdést intéz A rendszerhez, majd A kapcsolódik B-hez, B pedig C-hez, amely bejegyzést készít X-be, majd a kérés visszatér A-hoz.
Ha távolról csatlakoznál a virtuális gépekhez, és próbálnád nyomon követni a kérés útját (és manuálisan összevetni, hogy mely hívások történnek), akkor megőrülnél. Az egyedi azonosító megléte jelentősen megkönnyíti az életet. Ez az egyik legegyszerűbb dolog, amit tehetsz, hogy időt spórolj a szolgáltatás növekedése során.
Középszint
Itt a tanácsok nehezebbek, de a megfelelő eszközök megkönnyítik a feladatot, biztosítva a befektetés megtérülését még a kis- és középvállalkozások számára is.
Központosított naplózás
Gratulálok! 100 virtuális gépet indítottál el. Másnap a vezérigazgató megkeres, és panaszt tesz egy hibáról, amelyet a szolgáltatás tesztelése során tapasztalt. Megadja a megfelelő azonosítót, amiről korábban beszéltünk, de neked kell átnézned 100 gép naplóit, hogy megtaláld azt, amelyik hibát okozott. Ezt meg kell találnod a holnapi prezentáció előtt.
Bár ez egy vicces kalandnak hangzik, jobb biztosítani, hogy legyen lehetőséged egy helyről keresni az összes naplóban. A naplók központosításának kihívását az ELK stack beépített funkcióival oldottam meg: itt támogatott a naplók összegyűjtése keresési lehetőséggel. Ez tényleg segíteni fog a konkrét napló keresési problémájának megoldásában. Ráadásként diagramokat készíthetsz és hasonló szórakoztató dolgokat.
Az ELK stack funkciói
Felügyeleti ügynökök
Most, hogy a szolgáltatásod üzembe került, biztosítanod kell, hogy hibamentesen működjön. A legjobb módszer ezt elérni, ha elindítasz néhány ügynököt, amelyek párhuzamosan futnak, és ellenőrzik a működését és a alapvető műveletek végrehajtását.
Ebben a fázisban ellenőrzöd, hogy A futott build jól teljesít és normálisan működik.
Kis és közepes projektekhez a Postman ajánlott az API-k monitorozására és dokumentálására. De mindenekelőtt biztosítani kell, hogy legyen módunk arra, hogy megtudjuk, mikor történt hiba, és időben értesítést kapjunk.
Automatikus méretezés a terhelés függvényében
Ez nagyon egyszerű. Ha van egy virtuális géped, amely kiszolgálja a kéréseket, és az eléri a 80%-os memóriakapacitást, akkor vagy növelheted annak erőforrásait, vagy több virtuális gépet adhatsz a klaszterhez. Ezeknek a műveleteknek az automatikus végrehajtása kiválóan alkalmas a terheléshez igazodó rugalmas teljesítményváltoztatásra. De mindig vigyázni kell arra, hogy mennyit költesz, és ésszerű határokat kell megállapítani.
A legtöbb felhőszolgáltatásban beállítható az automatikus méretezés, akár több szerver, akár erősebb szerverek használatával.
Kísérleti rendszer
Jó módja a frissítések biztonságos telepítésének, ha egy órán keresztül a felhasználók 1%-án tesztelsz valamit. Természetesen láthattad az ilyen mechanizmusokat működés közben. Például a Facebook egyes közönségi tagoknak más színt mutat vagy módosítja a betűméretet, hogy lássa, hogyan reagálnak a felhasználók a változásokra. Ezt A/B tesztelésnek hívják.
Még egy új funkciót is kísérletként indíthatunk, és később meghatározhatjuk, hogyan kell azt kiadni. Emellett lehetőséged van „visszahívni” vagy módosítani a konfigurációt menet közben, figyelembe véve azt a funkciót, amely a szolgáltatásod romlását okozza.
Fejlett szint
Itt olyan tanácsok találhatók, amelyek megvalósítása meglehetősen nehéz. Valószínűleg több erőforrásra lesz szükséged, ezért egy kis vagy közepes cégnek nehézséget okozhat ezzel megbirkózni.
Kék-zöld telepítések
Ez az, amit „erlangi” telepítési módnak hívok. Az Erlangot széles körben használták, amikor a telefonszolgáltatók megjelentek. A telefonhívások irányításához szoftveres kapcsolókat alkalmaztak. Az ilyen kapcsolók szoftverének alapvető feladata az volt, hogy ne szakítsa meg a hívásokat a rendszer frissítése alatt. Az Erlang nagyszerű módja egy új modul behúzásának anélkül, hogy a korábbi leállna.
Ez a lépés a terheléselosztó elérhetőségétől függ. Tegyük fel, hogy Önnek van N verziója a szoftverének, majd szeretné telepíteni az N+1 verziót.
Ön tudnák egyszerűen leállítani a szolgáltatást, és telepíteni a következő verziót abban az időben, amelyet kényelmesnek tartanak a felhasználóik számára, ami némi leállást eredményez. De tegyük fel, hogy Önnek valóban szigorú SLA-követelményei vannak. Így a 99,99%-os SLA azt jelenti, hogy offline állapotban lehet a fő DB példányhoz éves szinten 52 percig.
Ha valóban ilyen mutatókat szeretne elérni, akkor két telepítésre lesz szüksége egyszerre:
- az éppen aktuális (N);
- a következő verzió (N+1).
Megkéri a terheléselosztót, hogy irányítson el egy százaléknyi forgalmat az új verzióra (N+1), miközben aktívan figyelemmel kíséri a visszaeséseket.
Itt van a zöld N telepítés, amely rendben működik. Megpróbálunk áttérni ennek a telepítésnek a következő verziójára.
Először is, valóban egy kicsi tesztet küldünk, hogy lássuk, működik-e az N+1 telepítésünk kis forgalom mellett:
Végül egy sor automatikus ellenőrzést futtatunk, amelyeket addig lefuttatunk, amíg a telepítésünk be nem fejeződik. Ha Ön nagyon-nagyon óvatos, akkor az N telepítését is örökre megőrizheti gyors visszatérés érdekében rossz regression esetén:
Ha egy még fejlettebb szintre szeretne lépni, hagyja, hogy minden a kék-zöld telepítésnél automatikusan történjen.
Anomáliák és automatikus hatáscsökkentés
Mivel központosított naplózással és jó naplógyűjtéssel rendelkezik, már magasabb célokat is kitűzhet. Például proaktívan előrejelezheti a kudarcokat. A monitorokon és naplókon nyomon követik a funkciókat, és különböző diagramokat készítenek – így előre megjósolható, hogy mi fog rosszul sikerülni:
Az anomáliák felfedezésével elkezdheti megérteni a szolgáltatás által kiadott nyomokat. Például a CPU terhelésének hirtelen növekedése jelezheti, hogy a merevlemez meghibásodik, míg a kérések számának hirtelen növekedése azt jelenti, hogy skálázni kell. Az ilyen típusú statisztikai adatok lehetővé teszik a szolgáltatás proaktívvá tételét.
Ezekkel az elemzési adatokkal bármilyen mértékben skálázhat, proaktívan és reakciószerűen módosíthatja a gépek, adatbázisok, kapcsolatok és egyéb erőforrások jellemzőit.
Ennyi volt!
Ez a prioritási lista sok problémától megszabadítja Önt, ha felhőszolgáltatást indít.
Az eredeti cikk szerzője arra ösztönzi az olvasókat, hogy hagyjanak megjegyzéseket és végezzenek módosításokat. A cikk nyílt forráskódú, a szerző a pull requesteket .
További olvasmányok a témában:
Forrás: habr.com
