Jegyzet. ford.: augusztus elején a Red Hat nyilvánosan beszélt az akadálymentesítési problémák megoldásáról, amelyekkel a szolgáltatás felhasználói az előző hónapokban találkoztak. (a konténerképek nyilvántartásán alapul, amelyet a vállalat a CoreOS megvásárlásával együtt kapott). Függetlenül attól, hogy érdeklődik e szolgáltatás iránt, tanulságos az az út, amelyet a cég SRE mérnökei bejártak a baleset okainak diagnosztizálására és megszüntetésére.
Május 19-én, kora reggel (Eastern Daylight Time, EDT) a quay.io szolgáltatás összeomlott. A baleset mind a quay.io fogyasztóit, mind a quay.io-t szoftverkészítési és -terjesztési platformként használó nyílt forráskódú projekteket érintett. A Red Hat értékeli mindkettőjük bizalmát.
Az SRE mérnökeiből álló csapat azonnal bekapcsolódott, és megpróbálta mielőbb stabilizálni a Quay szolgáltatást. Azonban miközben ezt tették, az ügyfelek elvesztették a képességüket, hogy új képeket küldjenek, és csak alkalmanként tudták a meglévőket lehúzni. Ismeretlen okból a quay.io adatbázis blokkolva lett, miután a szolgáltatást teljes kapacitásra méretezték.
«Mi változott?" - ez az első kérdés, amit ilyenkor fel szoktak tenni. Észrevettük, hogy nem sokkal a probléma előtt az OpenShift Dedicated fürt (amely a quay.io-t futtatja) megkezdte a frissítést a 4.3.19-es verzióra. Mivel a quay.io a Red Hat OpenShift Dedicated-en (OSD) fut, a rendszeres frissítések rutinszerűek voltak, és soha nem okoztak problémát. Sőt, az elmúlt hat hónap során többször frissítettük a Quay-klasztereket, anélkül, hogy a szolgáltatás megszakadt volna.
Miközben megpróbáltuk visszaállítani a szolgáltatást, más mérnökök elkezdtek egy új OSD-klasztert készíteni a szoftver előző verziójával, hogy ha valami történne, mindent telepíthessenek rajta.
Kiváltó okok elemzése
A hiba fő tünete az adatbázis-kapcsolatok tízezreiből álló lavina volt, amely gyakorlatilag működésképtelenné tette a MySQL-példányt. Ez megnehezítette a probléma diagnosztizálását. Korlátoztuk az ügyfelektől érkező kapcsolatok maximális számát, hogy segítsük az SRE csapatának a probléma értékelését. Nem észleltünk szokatlan forgalmat az adatbázisban: a legtöbb kérést elolvasták, és csak néhányat írtak.
Megpróbáltunk azonosítani egy olyan mintát az adatbázis-forgalomban, amely ezt a lavinát okozhatja. A naplókban azonban nem találtunk mintákat. Amíg arra vártunk, hogy az új fürt OSD 4.3.18-as verzióval elkészüljön, folytattuk a quay.io podok elindítását. Minden alkalommal, amikor a fürt elérte a teljes kapacitást, az adatbázis lefagy. Ez azt jelentette, hogy az összes quay.io pod mellett újra kellett indítani az RDS-példányt.
Estére stabilizáltuk a szolgáltatást írásvédett módban, és a lehető legtöbb nem alapvető funkciót (például névtér szemétgyűjtését) letiltottuk, hogy csökkentsük az adatbázis terhelését. A fagyások megálltak de az okot sosem találták meg. Az új OSD-fürt elkészült, és áttelepítettük a szolgáltatást, a csatlakoztatott forgalmat és folytattuk a figyelést.
A Quay.io stabilan működött az új OSD-fürtön, így visszatértünk az adatbázisnaplókhoz, de nem találtunk olyan összefüggést, amely megmagyarázná az elakadásokat. Az OpenShift mérnökei együttműködtek velünk annak megértésében, hogy a Red Hat OpenShift 4.3.19-es verziójában bekövetkezett változások okozhatnak-e problémákat a Quay-nél. Azonban nem találtak semmit, és Laboratóriumi körülmények között nem lehetett reprodukálni a problémát.
Második kudarc
Május 28-án, nem sokkal az EDT dél előtt, a quay.io ismét összeomlott, ugyanazzal a tünettel: az adatbázis blokkolva volt. És ismét minden erőnket a nyomozásra fordítottuk. Mindenekelőtt a szolgáltatás visszaállítására volt szükség. azonban ezúttal az RDS újraindítása és a quay.io podok újraindítása nem hozott semmit: újabb kapcsolatok lavina lepte el a bázist. De miért?
A Quay Python nyelven íródott, és mindegyik pod egyetlen monolit konténerként működik. A tároló futtatókörnyezete sok párhuzamos feladatot futtat egyszerre. Használjuk a könyvtárat gevent alatt gunicorn webes kérések feldolgozásához. Amikor egy kérés érkezik a Quay-be (a saját API-n keresztül vagy a Docker API-ján keresztül), akkor hozzárendelődik egy gevent worker. Ennek a dolgozónak általában fel kell vennie a kapcsolatot az adatbázissal. Az első hiba után azt tapasztaltuk, hogy az eseménykezelők alapértelmezett beállításokkal csatlakoznak az adatbázishoz.
Tekintettel a Quay podok jelentős számára és a másodpercenkénti több ezer bejövő kérésre, nagyszámú adatbázis-kapcsolat elméletileg túlterhelheti a MySQL-példányt. A monitorozásnak köszönhetően ismert volt, hogy a Quay átlagosan 5 ezer kérést dolgoz fel másodpercenként. Az adatbázishoz való csatlakozások száma megközelítőleg ugyanannyi volt. 5 ezer kapcsolat bőven belefért RDS példányunk lehetőségeibe (ami nem mondható el több tízezerről). Valamilyen oknál fogva váratlan kiugrások voltak a kapcsolatok számában, azonban nem észleltünk összefüggést a beérkező kérésekkel.
Ezúttal elhatároztuk, hogy megtaláljuk és megszüntetjük a probléma forrását, és nem korlátozzuk magunkat az újraindításra. A Quay kódbázisba módosítások történtek, hogy korlátozzák az adatbázishoz való csatlakozások számát az egyes dolgozók számára gevent. Ez a szám paraméter lett a konfigurációban: lehetővé vált, hogy menet közben megváltoztassuk anélkül, hogy új konténerképet építettünk volna. Annak érdekében, hogy megtudjuk, hány kapcsolat kezelhető reálisan, több tesztet futtattunk egy átmeneti környezetben, különböző értékeket állítva be, hogy megnézzük, ez hogyan befolyásolja a terheléses tesztelési forgatókönyveket. Ennek eredményeként kiderült, hogy A Quay 502 hibát kezd el dobni, ha a kapcsolatok száma meghaladja a 10 ezret.
Azonnal üzembe helyeztük ezt az új verziót az éles környezetben, és elkezdtük figyelni az adatbázis csatlakozási ütemezését. A múltban a bázist körülbelül 20 perc után lezárták. 30 problémamentes perc után reménykedtünk, egy órával később pedig bizalommal. Visszaállítottuk a helyszín forgalmát, és megkezdtük a postmortem elemzést.
Miután sikerült megkerülni a blokkoláshoz vezető problémát, nem tudtuk meg valódi okait. Megerősítést nyert, hogy nincs összefüggésben az OpenShift 4.3.19-es változásaival, mivel ugyanez történt a 4.3.18-as verzióval is, amely korábban gond nélkül működött a Quay-vel.
Nyilvánvalóan valami más lapult a fürtben.
Részletes tanulmány
A Quay.io az alapértelmezett beállításokkal csatlakozott az adatbázishoz hat évig minden probléma nélkül. Mi változott? Egyértelmű, hogy a quay.io forgalom ez idő alatt folyamatosan nőtt. Esetünkben úgy nézett ki, mintha elértek volna valamilyen küszöbértéket, ami kiváltóként szolgált a kapcsolatok lavinájához. A második hiba után is folytattuk az adatbázis-naplók tanulmányozását, de nem találtunk semmiféle mintát vagy nyilvánvaló összefüggést.
Időközben az SRE csapata a Quay kérésének megfigyelhetőségének és általános szolgáltatási állapotának javításán dolgozik. Új mérőszámok és irányítópultok kerültek bevezetésre, amely bemutatja, hogy a rakpart mely részeire van a legnagyobb kereslet az ügyfelek körében.
A Quay.io június 9-ig jól működött. Ma reggel (EDT) ismét jelentős növekedést tapasztaltunk az adatbázis-kapcsolatok számában. Ezúttal nem volt állásidő, mivel az új paraméter korlátozta a számukat, és nem tette lehetővé a MySQL átviteli sebesség túllépését. Azonban körülbelül fél órán keresztül sok felhasználó észlelte a quay.io lassú teljesítményét. Gyorsan összegyűjtöttünk minden lehetséges adatot a hozzáadott felügyeleti eszközök segítségével. Hirtelen egy minta rajzolódott ki.
Közvetlenül a kapcsolatok megugrása előtt nagyszámú kérés érkezett az App Registry API-hoz. Az App Registry a quay.io egy kevéssé ismert funkciója. Lehetővé teszi olyan dolgok tárolását, mint például a Helm diagramok és a gazdag metaadatokkal rendelkező konténerek. A legtöbb quay.io felhasználó nem használja ezt a funkciót, de a Red Hat OpenShift aktívan használja. Az OpenShift részeként az OperatorHub az összes operátort az App Registry-ben tárolja. Ezek az operátorok képezik az OpenShift munkaterhelési ökoszisztéma és a partnerközpontú működési modell alapját (2. napi műveletek).
Minden OpenShift 4-fürt a beépített OperatorHub operátorait használja a telepíthető operátorok katalógusának közzétételéhez, és frissítések biztosításához a már telepítettekhez. Az OpenShift 4 növekvő népszerűségével a rajta lévő fürtök száma is nőtt világszerte. Ezen fürtök mindegyike letölti az operátori tartalmat a beépített OperatorHub futtatásához, háttérként a quay.io fájlban található alkalmazás-nyilvántartást használva. A probléma forrását kutatva figyelmen kívül hagytuk, hogy az OpenShift fokozatos népszerűségének növekedésével az egyik ritkán használt quay.io funkció terhelése is megnőtt..
Elemeztük az App Registry kérésforgalmát, és megnéztük a rendszerleíró adatbázis kódját. Azonnal kiderültek azok a hiányosságok, amelyek miatt az adatbázis lekérdezései nem alakultak ki optimálisan. Ha alacsony volt a terhelés, akkor nem okoztak gondot, de a terhelés növekedésével problémaforrássá váltak. Kiderült, hogy az App Registry két problémás végponttal rendelkezik, amelyek nem reagáltak megfelelően a növekvő terhelésre: az első a lerakatban lévő összes csomag listáját adta meg, a második pedig visszaadta a csomag összes blobot.
Az okok megszüntetése
A következő héten magának az App Registry-nek és környezetének optimalizálásával töltöttük a kódot. Az egyértelműen hatástalan SQL-lekérdezéseket átdolgozták, és a szükségtelen parancshívásokat kiküszöbölték tar (a blobok lekérésekor minden alkalommal lefutott), a gyorsítótárazás hozzáadásra került, ahol csak lehetséges. Ezt követően kiterjedt teljesítménytesztet végeztünk, és összehasonlítottuk az App Registry sebességét a változtatások előtt és után.
A korábban legfeljebb fél percig tartó API-kérések most ezredmásodpercek alatt fejeződnek be. A következő héten bevezettük a változtatásokat a termelésbe, és azóta a quay.io stabilan működik. Ezalatt az idő alatt több éles kiugrás is volt az App Registry végpontján, de az elvégzett fejlesztések megakadályozták az adatbázis-kimaradásokat.
Mit tanultunk?
Nyilvánvaló, hogy minden szolgáltatás megpróbálja elkerülni az állásidőt. Esetünkben úgy gondoljuk, hogy a közelmúltbeli kiesések hozzájárultak a quay.io jobbá tételéhez. Megtanultunk néhány kulcsfontosságú tanulságot, amelyeket szeretnénk megosztani:
- Az adatok arról, hogy ki és hogyan veszik igénybe a szolgáltatást, soha nem feleslegesek. Mivel a Quay „csak működött”, soha nem kellett időt töltenünk a forgalom optimalizálásával és a terhelés kezelésével. Mindez hamis biztonságérzetet keltett, amelyet a szolgáltatás a végtelenségig skálázhatott.
- Amikor megszűnik a szolgáltatás, az újbóli üzembe helyezése kiemelt prioritás.. Mivel a Quay továbbra is szenvedett egy zárolt adatbázistól az első leállás során, szabványos eljárásaink nem hozták meg a kívánt hatást, és nem tudtuk visszaállítani a szolgáltatást ezek segítségével. Ez ahhoz a helyzethez vezetett, hogy időt kellett tölteni az adatok elemzésével és gyűjtésével annak reményében, hogy megtalálják a kiváltó okot – ahelyett, hogy minden erőfeszítést a funkcionalitás helyreállítására összpontosítottak volna.
- Értékelje az egyes szolgáltatási funkciók hatását. Az ügyfelek ritkán használták az App Registry-t, így csapatunk számára ez nem volt prioritás. Amikor néhány termékfunkciót alig használnak, a hibák ritkán jelennek meg, és a fejlesztők nem figyelik a kódot. Könnyű áldozatává válni annak a tévhitnek, hogy ennek így kell lennie – egészen addig, amíg hirtelen ez a funkció egy nagyobb esemény középpontjában nem találja magát.
Mi a következő lépés?
A szolgáltatás stabilitását biztosító munka soha nem áll meg, folyamatosan fejlesztjük. Mivel a forgalom folyamatosan növekszik a quay.io oldalon, elismerjük, hogy felelősségünk van mindent megtenni, hogy eleget tegyünk ügyfeleink bizalmának. Ezért jelenleg az alábbi feladatokon dolgozunk:
- Telepítsen írásvédett adatbázis-replikákat, hogy segítse a szolgáltatást a megfelelő forgalom kezelésében az elsődleges RDS-példánnyal kapcsolatos problémák esetén.
- RDS-példány frissítése. Maga a jelenlegi verzió nem probléma. Inkább egyszerűen el akarjuk távolítani a hamis nyomot (amit a kudarc során követtünk); A szoftver naprakészen tartása egy másik tényezőt is kiküszöböl a jövőbeni leállások esetén.
- További gyorsítótár a teljes fürtben. Továbbra is keressük azokat a területeket, ahol a gyorsítótárazás csökkentheti az adatbázis terhelését.
- Webalkalmazás-tűzfal (WAF) hozzáadása, hogy megtudja, ki és miért csatlakozik a quay.io webhelyhez.
- A következő kiadástól kezdődően a Red Hat OpenShift-fürtök felhagynak az App Registry-vel, és a quay.io webhelyen elérhető konténerképek alapján az operátori katalógusokat helyezik el.
- Az App Registry hosszú távú helyettesítője az Open Container Initiative (OCI) termékspecifikációinak támogatása lehet. Jelenleg natív Quay-funkcióként valósítják meg, és a specifikáció véglegesítése után lesz elérhető a felhasználók számára.
A fentiek mindegyike a Red Hat folyamatban lévő quay.io-ba történő befektetésének részét képezi, miközben egy kis „startup stílusú” csapatból egy kiforrott SRE-vezérelt platform felé haladunk. Tudjuk, hogy sok ügyfelünk támaszkodik a quay.io-ra mindennapi munkája során (beleértve a Red Hat-et is), és igyekszünk a lehető legátláthatóbban közölni a közelmúltbeli kieséseket és a folyamatos fejlesztési erőfeszítéseket.
PS a fordítótól
Olvassa el blogunkon is:
- «";
- «";
- «".
Forrás: will.com