🥇Post Mortem par Quay.io pieejamības trūkumu

Piezīme:: augusta sākumā Red Hat publiski paziņoja par pieejamības problēmu risināšanu, kas radās iepriekšējā mēnešos tās pakalpojuma lietotājiem. Quay.io (tā pamatā ir konteineru attēlu reģistrs, kas uzņēmuma īpašumā nonāca kopā ar CoreOS iegādi). Neatkarīgi no jūsu ieinteresētības šajā pakalpojumā, ir mācīšanās vērts ceļš, pa kuru uzņēmuma SRE inženieri devās, lai diagnosticētu un novērstu avārijas cēloņus.

19. maijā, agrā rītā (pēc vasaras ziemeļamerikāņu austrumu laika, EDT), serviss quay.io piedzīvoja kritumu. Avārija skāra gan quay.io klientus, gan Open Source projektus, kas izmanto quay.io kā platformu programmatūras izstrādei un izplatīšanai. Red Hat novērtē uzticību gan vieniem, gan otriem.

SRE inženieru komanda uzreiz ķērās pie darba un centās pēc iespējas ātrāk stabilizēt Quay pakalpojuma darbību. Tomēr kamēr viņi to darīja, klienti zaudēja iespēju pārsūtīt jaunus attēlus un tikai periodiski varēja lejupielādēt esošos. Nezināmu iemeslu dēļ quay.io datu bāze tika bloķēta pēc pakalpojuma paplašināšanas līdz pilnai jaudai.

«Kas mainījās?» — tas ir pirmais jautājums, ko parasti uzdod šādos gadījumos. Mēs pamanījām, ka neilgi pirms problēmas OpenShift Dedicated klasteris (uz kura darbojas quay.io) sāka atjaunināšanu uz versiju 4.3.19. Tā kā quay.io darbojas uz Red Hat OpenShift Dedicated (OSD), regulārie atjauninājumi bija ikdienišķa operācija un nekad nevienu neapturēja. Turklāt iepriekšējā pusgadā mēs vairākas reizes atjauninājām Quay klasterus bez jebkādām apkalpošanas pārtraukumiem.

Kamēr mēs centāmies atjaunot pakalpojuma darbību, citi inženieri sāka gatavot jaunu OSD klasteri ar iepriekšējo programmatūras versiju, lai, ja nepieciešams, visu izvietotu uz tā.

Sakņu cēloņu analīze

Galvenais avārijas simptoms bija desmitiem tūkstošu savienojumu uz DB lavīna, dēļ kuras MySQL instants faktiski kļuva nedarbspējīgs. Tā rezultātā bija grūti diagnosticēt problēmu. Mēs ieviesām ierobežojumu uz maksimālo klientu savienojumu skaitu, lai palīdzētu SRE komandai novērtēt problēmu. Nekādu neparastu datu bāzes satiksmi nepamanījām: patiesībā vairums pieprasījumu bija uz lasīšanu, bet tikai neliels skaits – uz rakstīšanu.

Mēs arī mēģinājām noteikt datu bāzes satiksmes modeli, kas varētu izraisīt šo lavīnu. Tomēr loģiskajās datnēs nebija iespējams atrast nekādas likumsakarības. Gaidot jauna klastera ar OSD 4.3.18 gatavību, mēs turpinājām mēģinājumus palaist pod’us quay.io. Katru reizi, kad klasteris sasniedza pilnu jaudu, datu bāze iesaldējās. Tas nozīmēja, ka bija nepieciešams restartēt RDS instanci, papildus visiem pod’iem quay.io.

Vakara beigās mēs stabilizējām servisu lasīšanas režīmā un atslēdzām maksimālo skaitu nesvarīgu funkciju (piemēram, atkritumu vākšana nosaukumu telpā), lai samazinātu slodzi uz datu bāzi. Iestrēgumi apstājās, bet iemesls tā arī netika atrasts. Jaunais OSD klasteris bija gatavs, un mēs pārcēlām servisu, pieslēdzām trafiku un turpinājām uzraudzību.

Quay.io stabila darbojās jaunajā OSD klasterī, tāpēc mēs atgriezāmies pie datu bāzes žurnāliem, bet tā arī neizdevās atrast korelāciju, kas izskaidrotu bloķējumus. OpenShift inženieri strādāja kopā ar mums, cenšoties saprast, vai izmaiņas Red Hat OpenShift 4.3.19 varēja izraisīt problēmas ar Quay. Tomēr neko neatklājām, un problemu laboratorijas apstākļos reproducēt neizdevās.

Otrais traucējums

28. maijā, neilgi pirms pusdienlaika EDT, quay.io atkal sabruka ar tiem pašiem simptomiem: datu bāzes darbība tika bloķēta. Atkal mēs veltījām visus spēkus izmeklēšanai. Vispirms bija nepieciešams atjaunot servisa darbību. Tomēr šoreiz RDS restartēšana un pod’u quay.io restartēšana novedusi pie nekā: nākamā lavīna savienojumu pārplūdināja datu bāzi. Bet kāpēc?

Quay ir uzrakstīts Python valodā un katrs pods darbojas kā vienots monolīts konteiners. Konteinera izpildes vidē vienlaikus tiek izpildītas daudzas paralēlas operācijas. Mēs izmantojam bibliotēku gevent Roskomnadzora. gunicorn lai apstrādātu tīmekļa pieprasījumus. Kad Quay saņem pieprasījumu (caur mūsu pašu API vai caur Docker API), tam tiek piešķirts gevent darbinieks. Parasti šis darbinieks sazinās ar datu bāzi. Pēc pirmā kļūmes mēs atklājām, ka gevent darbinieki pieslēdzās datu bāzei, izmantojot noklusējuma iestatījumus.

Ņemot vērā ievērojamo pod’u skaitu Quay un tūkstošiem pieprasījumu sekundē, lielais pieslēgumu skaits teorētiski varēja pārslogot MySQL instanci. Pateicoties uzraudzībai, mēs zinājām, ka Quay vidēji apstrādā 5000 pieprasījumu sekundē. Aptuveni tikpat liels bija arī pieslēgumu skaits datu bāzei. 5000 pieslēgumu ar rezervi derēja mūsu RDS instancēm (ām nē runājot par desmitiem tūkstošu). Kādu iemeslu dēļ notika negaidīti pieprasījumu savienojumu uzplaiksnījumi., tomēr mēs nepamanījām nekādu korelāciju ar ienākošajiem pieprasījumiem.

Šoreiz mēs stingri izlēmām atrast un novērst problēmas avotu, nevis apmierināties ar restartēšanu. Quay kodu bāzē tika veikti grozījumi, ierobežojot pieslēgumu skaitu datu bāzei katram darbiniekam . Šis skaits kļuvis par parametru konfigurācijā: to varēja mainīt “lidojuma laikā”, neizveidojot jaunu konteineru attēlu. Lai noskaidrotu, cik daudz savienojumu patiesi var apstrādāt, tika veikti daži testi ar staging vidēm, nosakot dažādas vērtības, lai redzētu, kā tas ietekmē slodzes testēšanas scenārijus. Galu galā izrādījās, ka Quay sāk izdot 502 kļūdas, kad savienojumu skaits pārsniedz 10 tūkstošus.

Mēs nekavējoties izvēršam šo jauno versiju ražošanā un sākām uzraudzīt datu bāzes savienojumu grafiku. Agrāk bāze tika bloķēta aptuveni pēc 20 minūtēm. Pusstundas bez problēmām mums radās cerība, un pēc stundas — pārliecība. Mēs atjaunojām rakstīšanas trafiku vietnē un uzsākām postmortem analīzi.

Mums izdevās apiet bloķēšanas problēmu, mēs nenoskaidrojām tās īstās cēloņus. Apstiprinājās, ka tā nav saistīta ar kādiem izmaiņām OpenShift 4.3.19, jo tas pats notika arī 4.3.18 versijā, kas iepriekš darbojās ar Quay bez jebkādām problēmām.

Klāsterī acīmredzot slēpās vēl kaut kas.

Detalizēta izpēte

Quay.io seši gadus izmantoja noklusējuma iestatījumus datubāzes savienojumam bez jebkādām problēmām. Kas mainījās? Ir skaidrs, ka visu šo laiku satiksme uz quay.io nepārtraukti pieauga. Mūsu gadījumā viss izskatījās tā, it kā tiktu sasniegta kāda sliekšņa vērtība, kas kalpoja par trigeri savienojumu lavīnai. Mēs turpinājām izpētīt datubāzes žurnālus pēc otrā sabrukuma, bet neatzinām nekādas likumsakarības vai acīmredzamas saiknes.

Tikmēr SRE komanda strādāja pie uzlabojumiem saistībā ar pieprasījumu novērojamību Quay un vispārējo pakalpojuma veselību. Tika ieviestas jaunas metriskās un uzraudzības paneli, kas rāda, kuras Quay daļas iegūst vislielāko pieprasījumu no klientiem.

Quay.io parasti darbojās līdz 9. jūnijam. No rīta (pēc EDT) mēs atkal kļuvām par lieciniekiem ievērojamam savienojumu skaita pieaugumam ar datubāzi. Šoreiz dīkstāves nenotika, jo jauns parametrs ierobežoja to skaitu un neļāva pārsniegt MySQL caurlaidspēju. Tomēr apmēram pusstundas laikā daudzi lietotāji ziņoja par quay.io lēnu darbību. Mēs ātri apkopojuši visus iespējamos datus, izmantojām pievienotos uzraudzības rīkus. Pēkšņi parādījās likumsakarība.

Pirms paaugstinājuma savienojumu skaita liela daļa pieprasījumu tika saņemta uz App Registry API. App Registry ir maz zina funkcija quay.io. Tā ļauj uzglabāt tādas lietas kā Helm chartus un konteinerus ar bagātīgu (rich) metadatu. Lielākā daļa quay.io lietotāju neizmanto šo funkciju, tomēr to aktīvi izmanto Red Hat OpenShift. OperatorHub, kas ir daļa no OpenShift, uzglabā visus operatorus App Registry. Šie operatori veido pamatu OpenShift darba slodzes ekosistēmai un operāciju modelim (Dienas 2 operāciju ietvaros), kas orientēts uz partneriem.

Katrs OpenShift 4 klasteris izmanto operatorus no iebūvētā OperatorHub, lai publicētu pieejamo operatoru katalogu instalēšanai un sniegtu atjauninājumus jau instalētajiem. Pieaugot OpenShift 4 popularitātei, pieauga arī klasteru skaits visā pasaulē. Katrs no šiem klasteriem ielādē operatoru saturu, lai palaistu iebūvēto OperatorHub, izmantojot App Registry iekš quay.io kā backend. Problēmas avota meklējumos mēs nepamanījām, ka ar OpenShift popularitātes pieaugumu pieauga arī slodze uz vienu no reti izmantotajām quay.io funkcijām..

Mēs veicām dažus pieprasījumu App Registry trafika analīzes un ieskatījāmies reģistra kodā. Uzreiz atklājās trūkumi, kas radīja neoptimālus pieprasījumus datu bāzei. Nelielas slodzes laikā tie neradīja nekādas problēmas, taču palielinoties slodzei, kļuva par problēmu avotu. App Registry bija divi problemātiski endpoint’i, kas slikti reaģēja uz slodzes palielināšanos: pirmais izdeva visu iepakojumu sarakstu krātuvē, otrais - atgrieza visus blob’us iepakojumam.

Problēmu novēršana.

Nākamo nedēļu mēs veltījām App Registry koda un tā apkārtējo vides optimizācijai. Tika pārstrādāti acīmredzami neefektīvi SQL pieprasījumi, novērsti liekie komandu izsaukumi (tie tika aktivizēti, katru reizi iegūstot blob'us), kur iespējams, tika ieviesta kešatmiņa. Pēc tam tika veikts plašs veiktspējas tests un salīdzināta App Registry darbība pirms un pēc izmaiņām. tar (tā tika palaista katru reizi, kad tika izsaukti blob’ji), visur, kur bija iespējams, tika pievienota kešatmiņa. Pēc tam tika veikta apjomīga veiktspējas testēšana, salīdzinot App Registry ātrumu pirms un pēc izmaiņām.

. Nākamajā nedēļā mēs ieviesām izmaiņas ražošanā, un kopš tā laika quay.io darbojas stabilā režīmā. Šajā laikā mēs novērojām vairākus straujus datu plūsmas pieaugumus App Registry endpoint'ā, taču veiktie uzlabojumi novērsa datu bāzes darbības pārtraukumus.. Nākamnedēļ mēs ieviesām izmaiņas ražošanā, un kopš tā laika quay.io darbojas stabilā režīmā. Šajā laikā bija novērojami vairāki strauji satiksmes pieaugumi App Registry galapunktā, taču veiktie uzlabojumi novērsa datu bāzes darbības traucējumus.

Ko mēs esam mācījušies?

Dati par to, kas un kā izmanto jūsu pakalpojumu, nekad nav lieki.

. Kamēr Quay "vienkārši strādāja", mums nebija nepieciešamības tērēt laiku datu plūsmas optimizācijai un slodzes pārvaldībai. Tas radīja maldīgu drošības sajūtu, ka pakalpojums var tikt paplašināts bezgalīgi.Kad pakalpojums pārtrūkst,
atjaunošanas process ir galvenā prioritāte. tās atjaunošana — galvenā prioritāte. Kamēr Quay turpināja ciest no bloķētās datu bāzes pirmajā avārijā, mūsu standarta procedūras neizrādījās paredzētajā efektā, un mēs nevarējām atjaunot pakalpojuma darbību, izmantojot tās. Tas noveda pie situācijas, kad bija jālaiko dati un jāanalizē, lai cerētu atrast pamata cēloni – vietā, lai visus spēkus veltītu atjaunošanas darbībām.
Novērtējiet katras pakalpojuma funkcijas ietekmi.. Klienti reti izmantoja App Registry, tāpēc tas nebija mūsu komandas prioritāte. Kad dažas produkta funkcijas tiek gandrīz nelietotas, to kļūdas „parādās” reti, un izstrādātāji pārstāj sekot kodeksam. Ir viegli kļūt par maldinošo priekšstatu, ka tā tam jābūt – līdz brīdim, kad šī funkcija neizsist pārvērtēšanas dēļ lielā incidenta centrā.

Kas tālāk?

Darbs pie pakalpojuma stabilitātes nodrošināšanas nekad neapstājas, un mēs pastāvīgi to uzlabojam. Trafika apjomi uz quay.io turpina pieaugt, un mēs apzināmies, ka mums jādara viss iespējamais, lai attaisnotu klientu uzticēšanos. Tāpēc pašlaik strādājam pie šādiem uzdevumiem:

Lasāmās datu bāzes repliku izvietošana, lai palīdzētu pakalpojumam apstrādāt attiecīgo trafiku problēmu gadījumā ar galveno RDS instanci.
RDS instances atjaunināšana. Esošā versija pati par sevi nav problēma. Drīzāk mēs vienkārši vēlamies novērst nepatiesu pavedienu (kura virzienā mēs devāmies avārijas laikā); programmatūras uzturēšana aktuālā stāvoklī ļaus novērst vēl vienu faktoru nākotnes traucējumiem.
Papildu kešatmiņa visā klasterī. Mēs turpinām meklēt jomas, kur kešatmiņa varētu samazināt noslodzi uz datu bāzi.
Web aplikāciju ugunsmūra (WAF) pievienošana, lai redzētu, kas un kāpēc pieslēdzas pie quay.io.
Sākot ar nākamo laidienu, Red Hat OpenShift klasteri atteiksies no App Registry par labu operatoru katalogiem (Operator Catalogs), kas balstīti uz konteineru attēliem, kas pieejami uz quay.io.
Ilgtermiņa aizvietotājs App Registry varētu būt atbalsts Open Container Initiative (OCI) artefaktu specifikācijām. Patlaban tas tiek īstenots kā Quay dzimtais funkcionalitāte un būs pieejams lietotājiem, kad specifikācija tiks noteikti apstiprināta.

Viss iepriekš minētais ir daļa no turpinājumiem, ko Red Hat iegulda quay.io, pārejot no nelielas "sākuma komandas" uz nobriedušu platformu, ko pārvalda SRE. Mēs apzināmies, ka daudzi mūsu klienti paļaujas uz quay.io savā ikdienas darbībā (tai skaitā Red Hat!) un cenšamies būt maksimāli atklāti par nesenajiem traucējumiem un nepārtrauktajiem centieniem kļūt labākiem.