Üdvözlök mindenkit, a nevem Alexander, a CIAN-nál dolgozom mérnökként, és rendszeradminisztrációval és infrastrukturális folyamatok automatizálásával foglalkozom. Az egyik korábbi cikkhez fűzött kommentben megkértük, hogy mondjuk el, honnan kapunk napi 4 TB naplót, és mit csinálunk vele. Igen, sok naplónk van, ezek feldolgozására külön infrastruktúra-fürt jött létre, amely lehetővé teszi a problémák gyors megoldását. Ebben a cikkben arról fogok beszélni, hogyan alakítottuk át egy év leforgása alatt, hogy az egyre növekvő adatáramlással működjön.
Hol kezdtük?
Az elmúlt néhány évben a cian.ru terhelése nagyon gyorsan nőtt, és 2018 harmadik negyedévére az erőforrásforgalom elérte a 11.2 millió egyedi felhasználót havonta. Akkoriban a kritikus pillanatokban a naplók 40%-át veszítettük el, ezért nem tudtuk gyorsan kezelni az incidenseket, és sok időt és erőfeszítést fordítottunk azok megoldására. Gyakran nem tudtuk megtalálni a probléma okát, és egy idő után kiújul. Pokol volt, és valamit tenni kellett ellene.
Akkoriban egy 10 adatcsomópontból álló klasztert használtunk az ElasticSearch 5.5.2-es verziójával, szabványos indexbeállításokkal a naplók tárolására. Több mint egy éve vezették be népszerű és megfizethető megoldásként: akkor még nem volt olyan nagy a rönkök áramlása, nem volt értelme nem szabványos konfigurációkkal előállni.
A bejövő naplók feldolgozását a Logstash biztosította öt ElasticSearch koordinátor különböző portjain. Egy index, mérettől függetlenül, öt szilánkból állt. Óránkénti és napi rotációt szerveztek, ennek eredményeként óránként körülbelül 100 új szilánk jelent meg a klaszterben. Bár nem volt túl sok napló, a klaszter jól megbirkózott, és senki sem figyelt a beállításaira.
A gyors növekedés kihívásai
A generált naplók mennyisége nagyon gyorsan nőtt, mivel két folyamat átfedte egymást. Egyrészt nőtt a szolgáltatást igénybe vevők száma. Másrészt elkezdtünk aktívan áttérni a mikroszolgáltatási architektúrára, felfűrészelve régi monolitjainkat C# és Python nyelven. A monolit részeit felváltó több tucat új mikroszolgáltatás lényegesen több naplót generált az infrastruktúra klaszter számára.
A méretezés vezetett oda, hogy a klaszter gyakorlatilag kezelhetetlenné vált. Amikor a naplók 20 ezer üzenet/másodperc sebességgel kezdtek érkezni, a gyakori haszontalan forgatás 6 ezerre növelte a szilánkok számát, és csomópontonként több mint 600 szilánk volt.
Ez problémákhoz vezetett a RAM kiosztásában, és amikor egy csomópont összeomlott, az összes szilánk egyszerre kezdett mozogni, megsokszorozva a forgalmat és más csomópontokat terhelve, ami szinte lehetetlenné tette az adatok írását a fürtbe. És ebben az időszakban rönk nélkül maradtunk. És ha probléma volt a szerverrel, akkor gyakorlatilag elvesztettük a fürt 1/10-ét. A nagyszámú kis index bonyolultabbá tette.
Naplók nélkül nem értettük meg az incidens okait, és előbb-utóbb újra ráléphettünk ugyanarra a gereblyére, és ez csapatunk ideológiájában elfogadhatatlan volt, hiszen minden munkamechanizmusunk az ellenkezőjét hivatott megvalósítani – soha ne ismétlődjön meg. ugyanazok a problémák. Ehhez a naplók teljes mennyiségére és azok szinte valós idejű kiszállítására volt szükségünk, hiszen egy ügyeletes mérnökcsapat nemcsak mérőszámokból, hanem naplókból is figyelte a riasztásokat. A probléma mértékének megértéséhez a naplók teljes mennyisége akkoriban körülbelül napi 2 TB volt.
Célul tűztük ki, hogy a rönkök elvesztését teljes mértékben kiküszöböljük, és vis maior esetén maximum 15 percre csökkentjük az ELK klaszterbe való eljuttatásuk idejét (később erre a számra mint belső KPI-re támaszkodtunk).
Új forgási mechanizmus és meleg-meleg csomópontok
A fürt átalakítást az ElasticSearch verzió 5.5.2-ről 6.4.3-ra való frissítésével kezdtük. Az 5-ös verziójú fürt ismét meghalt, és úgy döntöttünk, hogy kikapcsoljuk, és teljesen frissítjük – még mindig nincsenek naplók. Így néhány óra alatt megtettük ezt az átállást.
A legnagyobb léptékű átalakítás ebben a szakaszban az Apache Kafka megvalósítása volt három csomóponton, közbenső pufferként egy koordinátorral. Az üzenetközvetítő megmentett minket attól, hogy elveszítsük a naplókat az ElasticSearch problémái során. Ezzel egy időben 2 csomópontot adtunk a fürthöz, és átváltottunk egy meleg-meleg architektúrára, amelyben három „forró” csomópont található az adatközpont különböző rackeiben. Átirányítottuk hozzájuk a naplókat egy olyan maszk segítségével, amelyet semmilyen körülmények között nem szabad elveszíteni - nginx, valamint az alkalmazási hibanaplókat. Kisebb naplókat küldtek a fennmaradó csomópontokba - hibakeresés, figyelmeztetés stb., majd 24 óra elteltével a „fontos” naplókat a „forró” csomópontokból továbbították.
Annak érdekében, hogy ne növekedjen a kis indexek száma, az időforgatásról áttértünk a rollover mechanizmusra. A fórumokon sok információ jelent meg arról, hogy az indexméret szerinti rotáció nagyon megbízhatatlan, ezért úgy döntöttünk, hogy az indexben szereplő dokumentumok száma szerint rotációt alkalmazunk. Elemeztük az egyes indexeket, és rögzítettük, hogy hány dokumentumot követően működjön a rotáció. Így elértük az optimális szilánkméretet - nem több, mint 50 GB.
Klaszter optimalizálás
Teljesen azonban nem szabadultunk meg a problémáktól. Sajnos továbbra is megjelentek a kis indexek: nem érték el a megadott mennyiséget, nem voltak elforgatva, és a három napnál régebbi indexek globális tisztításával törölték őket, mivel eltávolítottuk a dátum szerinti rotációt. Ez adatvesztéshez vezetett, mivel az index teljesen eltűnt a klaszterből, és egy nem létező indexre való írási kísérlet megtörte a kurátor logikáját, amelyet a kezeléshez használtunk. Az írási álnevet indexké alakították, és megtörték az átváltási logikát, ami egyes indexek ellenőrizetlen növekedését okozta 600 GB-ig.
Például a forgatás konfigurációjához:
сurator-elk-rollover.yaml
---
actions:
1:
action: rollover
options:
name: "nginx_write"
conditions:
max_docs: 100000000
2:
action: rollover
options:
name: "python_error_write"
conditions:
max_docs: 10000000
Ha nem volt átgörgetési álnév, hiba történt:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
A probléma megoldását a következő iterációra hagytuk, és felvettünk egy másik problémát: áttértünk a Logstash pull logikájára, amely feldolgozza a bejövő naplókat (eltávolítja a felesleges információkat és gazdagítja). Elhelyeztük a docker-ben, amit a docker-compose-on keresztül indítunk el, és ott elhelyeztük a logstash-exportert is, amely metrikákat küld a Prometheusnak a naplófolyam működési megfigyelésére. Így lehetőséget adtunk magunknak arra, hogy zökkenőmentesen módosítsuk az egyes naplótípusok feldolgozásáért felelős logstash példányok számát.
Miközben javítottuk a klasztert, a cian.ru forgalma havi 12,8 millió egyedi felhasználóra nőtt. Ennek eredményeként kiderült, hogy átalakításaink egy kicsit elmaradtak a termelésben bekövetkezett változásoktól, és szembesültünk azzal, hogy a „meleg” csomópontok nem bírták a terhelést, és lelassították a teljes rönkszállítást. Hibamentesen kaptunk „forró” adatokat, de a többi szállításába be kellett avatkoznunk, és kézi görgetést kellett végeznünk az indexek egyenletes elosztása érdekében.
Ugyanakkor a fürt logstash-példányainak méretezését és beállításainak megváltoztatását nehezítette, hogy helyi docker-compose volt, és minden műveletet manuálisan hajtottak végre (új végek hozzáadásához manuálisan kellett végigmenni az összes a szerverek és a docker-compose up -d mindenhol).
Napló újraelosztás
Idén szeptemberben még a monolit darabolását végeztük, a klaszter terhelése nőtt, a naplók áramlása megközelítette a másodpercenkénti 30 ezer üzenetet.
A következő iterációt hardverfrissítéssel kezdtük. Öt koordinátorról háromra váltottunk, lecseréltük az adatcsomópontokat, és nyertünk pénzben és tárhelyben. A csomópontokhoz két konfigurációt használunk:
- A „forró” csomópontokhoz: E3-1270 v6 / 960 Gb SSD / 32 Gb x 3 x 2 (3 a Hot1-hez és 3 a Hot2-hez).
- „Meleg” csomópontokhoz: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Ennél az iterációnál áthelyeztük a mikroszolgáltatások hozzáférési naplóit tartalmazó indexet, amely ugyanazt a helyet foglalja el, mint az első vonalbeli nginx naplók, a három „forró” csomópontból álló második csoportba. Mostantól 20 órán át tároljuk az adatokat a „forró” csomópontokon, majd a „meleg” csomópontokra továbbítjuk a többi naplóba.
A kis indexek eltűnésének problémáját rotációjuk újrakonfigurálásával oldottuk meg. Most minden esetben 23 óránként forgatják az indexeket, még akkor is, ha kevés adat van ott. Ez némileg növelte a szilánkok számát (kb. 800 db volt), de a klaszterteljesítmény szempontjából ez tűrhető.
Ennek eredményeként hat „forró” és csak négy „meleg” csomópont volt a klaszterben. Ez enyhe késleltetést okoz a hosszú időintervallumokra vonatkozó kérésekben, de a csomópontok számának jövőbeni növelése megoldja ezt a problémát.
Ez az iteráció megoldotta a félautomata méretezés hiányának problémáját is. Ehhez egy infrastrukturális Nomad-fürtöt telepítettünk – hasonlóan ahhoz, amit a termelésben már telepítettünk. Egyelőre nem változik automatikusan a Logstash mennyisége a terhelés függvényében, de erre majd rátérünk.
Tervek a jövőre
A megvalósított konfiguráció tökéletesen skálázódik, és most 13,3 TB adatot tárolunk - minden naplót 4 napig, ami a riasztások vészhelyzeti elemzéséhez szükséges. A naplók egy részét metrikákká alakítjuk, amelyeket hozzáadunk a Graphite-hoz. A mérnökök munkájának megkönnyítése érdekében mérőszámaink vannak az infrastruktúra-fürthöz és szkriptjeink a gyakori problémák félautomata javításához. Az adatcsomópontok számának jövőre tervezett növelése után 4-ről 7 napra térünk át az adattárolásra. Ez elég lesz az operatív munkához, hiszen mindig igyekszünk minél előbb kivizsgálni az incidenseket, a hosszú távú vizsgálatokhoz pedig telemetriai adatok állnak rendelkezésre.
2019 októberében a cian.ru webhely forgalma már havi 15,3 millió egyedi felhasználóra nőtt. Ez a rönkszállítás építészeti megoldásának komoly próbája lett.
Most az ElasticSearch 7-es verzióra való frissítésére készülünk. Ehhez azonban frissítenünk kell számos index leképezését az ElasticSearch-ben, mivel ezek az 5.5-ös verzióból kerültek át, és a 6-os verzióban elavultnak nyilvánították (a verzióban egyszerűen nem léteznek 7). Ez azt jelenti, hogy a frissítési folyamat során minden bizonnyal lesz valamilyen vis maior, amely naplózás nélkül hagy minket, amíg a probléma megoldódik. A 7-es verzió közül a Kibanát várjuk a legjobban továbbfejlesztett felülettel és új szűrőkkel.
Fő célunkat elértük: megszüntettük a naplózást, és az infrastruktúra klaszter leállását heti 2-3 összeomlásról havi pár órás karbantartási munkára csökkentettük. Mindez a termelési munka szinte láthatatlan. Most azonban pontosan meg tudjuk határozni, hogy mi történik a szolgáltatásunkkal, gyorsan megtehetjük csendes üzemmódban, és nem kell attól tartani, hogy a naplók elvesznek. Általánosságban elmondható, hogy elégedettek, boldogok vagyunk, és készülünk az új zsákmányokra, amelyekről később fogunk beszélni.
Forrás: will.com