{"id":92073,"date":"2020-08-22T19:41:56","date_gmt":"2020-08-22T17:41:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io"},"modified":"2020-08-22T19:41:56","modified_gmt":"2020-08-22T17:41:56","slug":"post-mortem-po-nedostupnosti-quay-io","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io","title":{"rendered":"Post Mortem o nedostupnosti Quay.io","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Napomena za prijevod.<\/b>: po\u010detkom kolovoza Red Hat je javno objavio rje\u0161enje za probleme dostupnosti koji su se pojavili tijekom prethodnih mjeseci kod korisnika njihove usluge Quay.io<\/a><\/noindex> (temeljen na registru za slike kontejnera, koji je tvrtka dobila s kupnjom CoreOS-a). Neovisno o va\u0161em interesu za ovu uslugu kao takvu, pou\u010dan je put koji su pro\u0161li SRE in\u017eenjeri tvrtke kako bi dijagnosticirali i uklonili uzroke incidenta.<\/i><\/p>\n

\"Post
\n
\n19. svibnja, rano ujutro (prema ljetnom sjevernoameri\u010dkom isto\u010dnom vremenu, EDT), usluga quay.io je pala. Incident je utjecao na potro\u0161a\u010de quay.io, kao i na open source projekte koji koriste quay.io kao platformu za izgradnju i distribuciju softvera. Red Hat cijeni povjerenje i jednih i drugih.<\/p>\n

Tim SRE in\u017eenjera odmah se uklju\u010dio u rad i nastojao \u0161to prije stabilizirati rad usluge Quay. Me\u0111utim, dok su radili na tome, klijenti su izgubili mogu\u0107nost slanja novih slika, a samo su povremeno mogli povu\u0107i postoje\u0107e. Iz nepoznatih razloga, baza podataka quay.io je bila blokirana nakon skaliranja usluge na punu snagu.<\/a><\/noindex><\/p>\n

\u00ab\u0160to se promijenilo?<\/b>\u2014 to je prvo pitanje koje se postavlja u sli\u010dnim slu\u010dajevima. Primijetili smo da je nedugo prije problema klaster OpenShift Dedicated (na kojem radi quay.io) po\u010deo s a\u017euriranjem na verziju 4.3.19. Budu\u0107i da quay.io radi na Red Hat OpenShift Dedicated (OSD), redovita a\u017euriranja su bila uobi\u010dajena operacija i nikada nisu uzrokovala probleme. \u0160tovi\u0161e, u proteklih \u0161est mjeseci nekoliko smo puta a\u017eurirali klastere Quay bez ikakvih prekida u radu.<\/p>\n

Dok smo poku\u0161avali ponovno pokrenuti uslugu, drugi in\u017eenjeri su po\u010deli pripremati novi OSD klaster s prethodnom verzijom softvera, kako bi sve u slu\u010daju nu\u017ede mogli implementirati na njemu.<\/p>\n

Analiza uzroka<\/h2>\n

\nGlavni simptom kvara bila je lavina od desetaka tisu\u0107a veza na bazu podataka, zbog \u010dega je instanca MySQL-a postala prakti\u010dki neupotrebljiva. Zbog toga je bilo te\u0161ko dijagnosticirati problem. Postavili smo ograni\u010denje na maksimalni broj veza od klijenata kako bismo pomogli SRE timu da procijeni problem. Nismo primijetili neuobi\u010dajen promet prema bazi podataka: zapravo, ve\u0107ina zahtjeva bila je za \u010ditanje, dok su samo neki bili za pisanje.<\/p>\n

Poku\u0161ali smo tako\u0111er otkriti obrazac u prometu DB-a koji bi mogao izazvati ovu lavinu. Me\u0111utim, nismo uspjeli prona\u0107i nikakve obrasce u zapisima. O\u010dekuju\u0107i dovr\u0161enje novog klastera s OSD 4.3.18, nastavili smo s poku\u0161ajima pokretanja podova quay.io. Svaki put kada je klaster dostigao punu snagu, baza podataka bi se smrzavala. To je zna\u010dilo da je bilo potrebno ponovno pokrenuti RDS instancu uz sve podove quay.io.<\/p>\n

Do ve\u010deri smo stabilizirali uslugu u read-only re\u017eimu i isklju\u010dili maksimalni broj nebitnih funkcija (na primjer, sakupljanje sme\u0107a u prostoru imena) kako bismo smanjili optere\u0107enje na bazi podataka. Zale\u0111ivanja su prestala, ali uzrok nije prona\u0111en<\/b>. Novi OSD klaster je bio spreman, i prebacili smo uslugu, povezali promet i nastavili s pra\u0107enjem.<\/p>\n

Quay.io je stabilno radio na novom OSD klasteru, stoga smo se vratili logovima baze podataka, no nismo uspjeli otkriti korelaciju koja bi objasnila blokade. In\u017eenjeri OpenShifta radili su zajedno s nama, poku\u0161avaju\u0107i razumjeti mogu li promjene u Red Hat OpenShift 4.3.19 uzrokovati probleme s Quay. Me\u0111utim, ni\u0161ta nije otkriveno, a nije uspjelo reproducirati problem u laboratorijskim uvjetima<\/b>.<\/p>\n

Drugi kvar<\/h2>\n

\n28. svibnja, nedugo prije podneva po EDT-u, quay.io se ponovno sru\u0161io s istim simptomima: funkcionalnost baze podataka bila je blokirana. I ponovo smo mobilizirali sve snage za istragu. Prvo \u0161to je trebalo u\u010diniti bilo je ponovno pokrenuti uslugu. Me\u0111utim, Ovaj put ponovno pokretanje RDS-a i ponovno pokretanje podova quay.io nisu urodili plodom.<\/b>Quay je napisan na Pythonu, a svaki pod radi kao jedinstveni monolitni kontejner. U radnom okru\u017eenju kontejnera izvr\u0161ava se mnogo paralelnih zadataka. Koristimo biblioteku<\/p>\n

gevent za obradu web zahtjeva. Kada Quay primi zahtjev (putem na\u0161eg API-ja ili preko Dockerovog API-ja), dodijeljuje se gevent radnik. Obi\u010dno taj radnik treba uspostaviti vezu s bazom podataka. Nakon prvog kvara otkrili smo da su se gevent radnici koristili podacima o vezi prema zadanim postavkama.<\/code> pod gunicorn<\/code> za obradu web zahtjeva. Kada Quay primi zahtjev (putem na\u0161eg API-ja ili putem Docker API-ja), dodijeljuje mu gevent worker. Obi\u010dno bi taj worker trebao komunicirati s bazom podataka. Nakon prvog pada otkrili smo da se gevent worker-i povezivali s bazom koriste\u0107i zadane postavke.<\/p>\n

S obzirom na zna\u010dajan broj podova Quay i tisu\u0107e pristiglih zahtjeva u sekundi, veliki broj veza s bazom podataka teoretski bi mogao preopteretiti MySQL instancu. Monitoring je pokazao da Quay prosje\u010dno obra\u0111uje 5 tisu\u0107a zahtjeva u sekundi. Otprilike toliko je bilo i veza s bazom podataka. 5 tisu\u0107a veza bez problema se uklapalo u mogu\u0107nosti na\u0161e RDS instance (\u0161to se ne mo\u017ee re\u0107i za desetke tisu\u0107a). Iz nekog razloga doga\u0111ali su se neo\u010dekivani skokovi u broju veza.<\/b>, me\u0111utim, nismo primijetili nikakvu korelaciju s dolaznim zahtjevima.<\/p>\n

Ovaj put \u010dvrsto smo odlu\u010dili prona\u0107i i otkloniti izvor problema, a ne ograni\u010diti se na ponovno pokretanje. U kodnoj bazi Quay napravljene su promjene koje ograni\u010davaju broj veza s DB-om za svakog workera.<\/b> gevent. Taj broj postao je parametar u konfiguraciji: bilo je mogu\u0107e mijenjati ga 'u hodu', bez potrebe za ponovno sastavljanjem novog kontejnerskog identiteta. Kako bismo saznali koji broj veza se zapravo mo\u017ee obraditi, provedeni su brojne probe sa staging okru\u017eenjem, u kojima su postavljene razli\u010dite vrijednosti kako bi se vidjelo kako \u0107e to utjecati na scenarije testiranja optere\u0107enja. Na kraju je otkriveno da Quay po\u010dinje isporu\u010divati gre\u0161ke 502 kada broj veza prema\u0161i 10 tisu\u0107a.<\/b><\/p>\n

Odmah smo implementirali ovu novu verziju u produkciji i po\u010deli pratiti grafikon veza na bazu podataka. U pro\u0161losti se baza zaklju\u010davala otprilike nakon 20 minuta. Nakon 30 minuta bez problema stekli smo nadu, a nakon sat vremena \u2014 sigurnost. Vratili smo promet za pisanje na stranici i zapo\u010deli postmortem analizu.<\/p>\n

Uspijev\u0161i zaobi\u0107i problem koji je vodio do zaklju\u010davanja, nismo otkrili njene prave uzroke<\/b>. Potvr\u0111eno je da to nije povezano s bilo kakvim promjenama u OpenShift-u 4.3.19, budu\u0107i da se isto dogodilo i na verziji 4.3.18, koja je ranije radila s Quay bez ikakvih problema.<\/p>\n

U klasteru se o\u010dito skrivala ne\u0161to drugo.<\/p>\n

Detaljna ispitivanja<\/h2>\n

\nQuay.io \u0161est godina koristio je zadane postavke za povezivanje s bazom podataka bez problema. \u0160to se promijenilo? Jasno je da je u me\u0111uvremenu promet na quay.io neprekidno rastao. U na\u0161em slu\u010daju \u010dini se kao da je postignuta odre\u0111ena prag vrijednost koja je poslu\u017eila kao okida\u010d za lavinu veza. Nastavili smo prou\u010davati logove baze podataka nakon drugog kvara, ali nismo prona\u0161li nikakvih obrazaca ili o\u010ditih povezanosti.<\/p>\n

U me\u0111uvremenu, SRE tim radio je na pobolj\u0161anju vidljivosti zahtjeva u Quayu i op\u0107em zdravlju usluge. Postavljene su nove metrike i nadzorne plo\u010de<\/b>, pokazuju\u0107i koji dijelovi Quaya imaju najve\u0107i promet me\u0111u korisnicima.<\/p>\n

Quay.io normalno je radio do 9. lipnja. Ujutro (po EDT-u) ponovno smo svjedo\u010dili zna\u010dajnom porastu broja veza s bazom podataka. Ovaj put do\u0161lo je do zastoja<\/b>, jer je nova postavka ograni\u010dila njihov broj i onemogu\u0107ila prekora\u010denje propusnosti MySQL-a. Me\u0111utim, tijekom otprilike pola sata mnogi korisnici su primijetili usporen rad quay.io. Brzo smo prikupili sve dostupne podatke, koriste\u0107i dodane alate za nadzor. Iznenada se pokazala povezanost.<\/p>\n

Prije samog skoka u broju veza, veliki broj zahtjeva stigao je na App Registry API<\/b>. App Registry je malo poznata funkcija quay.io. Omogu\u0107uje pohranu stvari poput Helm dijagrama i kontejnera s bogatim metapodacima. Ve\u0107ina korisnika quay.io ne koristi ovu funkciju, me\u0111utim, aktivno je koristi Red Hat OpenShift. OperatorHub unutar OpenShifta pohranjuje sve operatore u App Registry. Ti operatori \u010dine osnovu ekosustava radnih optere\u0107enja OpenShifta i operativnog modela (u okviru operacija 'drugog dana', Day 2) orijentiranog na partnere.<\/p>\n

Svaki OpenShift 4 klaster koristi operatore iz ugra\u0111enog OperatorHub-a za publikaciju kataloga operatora dostupnih za instalaciju i pru\u017eanje a\u017euriranja za ve\u0107 instalirane. S porastom popularnosti OpenShift 4 pove\u0107ao se i broj klastera na njemu \u0161irom svijeta. Svaki od tih klastera preuzima sadr\u017eaj operatora kako bi pokrenuo ugra\u0111eni OperatorHub, koriste\u0107i App Registry unutar quay.io kao backend. U potrazi za izvorom problema, propustili smo da primijetimo da je s postepenim porastom popularnosti OpenShift pove\u0107an i pritisak na jednu od rijetko kori\u0161tenih funkcija quay.io.<\/b>.<\/p>\n

Proveli smo analizu prometa zahtjeva App Registry i zavirili u kod registra. Odmah su se pojavili nedostaci koji su uzrokovali neoptimalno formiranje zahtjeva prema bazi podataka. U uvjetima male optere\u0107enosti nisu stvarali nikakve probleme, no kada je optere\u0107enje raslo, postajali su izvor problema. App Registry imao je dva problemati\u010dna endpoint-a koja su lo\u0161e reagirala na pove\u0107ano optere\u0107enje: prvi je vra\u0107ao popis svih paketa u repozitoriju, a drugi je vra\u0107ao sve blob-ove za paket.<\/p>\n

Uklanjanje uzroka<\/h2>\n

\nCijeli sljede\u0107i tjedan posvetili smo optimizaciji koda App Registry i njegovog okru\u017eenja. Preina\u010deni su o\u010digledno neu\u010dinkoviti SQL upiti, uklonjeni su suvi\u0161ni pozivi komandi (koji su se pokretali pri svakom va\u0111enju blobova), i dodano je ke\u0161iranje gdje god je to bilo mogu\u0107e. Nakon toga provedeno je opse\u017eno testiranje performansi i uspore\u0111ena je brzina rada App Registry prije i nakon promjena. tar<\/code> (pokretala se pri svakom izdavanju blobova), dodano ke\u0161iranje gdje god je to mogu\u0107e. Zatim je provedeno opse\u017eno testiranje performansi i uspore\u0111ena brzina rada App Registry-a prije i nakon promjena.<\/p>\n

. Sljede\u0107eg tjedna implementirali smo promjene u produkciju, i od tada quay.io radi stabilno. U to vrijeme zabilje\u017eeni su nekoliko naglih porasta prometa na endpointu App Registry, ali u\u010dinjene nadogradnje sprije\u010dile su prekide u radu baze podataka.<\/b>. Sljede\u0107i tjedan implementirali smo promjene u produkciji, i od tada quay.io radi stabilno. Tijekom tog vremena zabilje\u017eeni su nekoliko naglih skokova prometa na endpointu App Registry-a, ali napravljena pobolj\u0161anja sprije\u010dila su prekide rada baze podataka.<\/p>\n

Jasno je da svaka usluga nastoji izbje\u0107i zastoje. U na\u0161em slu\u010daju, vjerujemo da su nedavni problemi pomogli da quay.io postane bolji. Za sebe smo izvukli nekoliko klju\u010dnih lekcija koje \u017eelimo podijeliti:<\/h2>\n

\nPodaci o tome tko i kako koristi va\u0161u uslugu nikada nisu suvi\u0161ni.<\/p>\n

    \n
  1. Kako je Quay \u00absamo radio\u00bb, nikada nismo imali potrebu tro\u0161iti vrijeme na optimizaciju prometa i upravljanje optere\u0107enjem. Sve to stvorilo je la\u017eni osje\u0107aj sigurnosti da se usluga mo\u017ee skalirati neograni\u010deno.<\/b>Kada usluga padne,<\/li>\n
  2. obnova njenog rada je glavni prioritet. obnova njegovog rada je na\u0161 glavni prioritet<\/b>. Budu\u0107i da je Quay nastavio trpjeti od blokirane baze podataka tijekom prvog kvara, na\u0161i standardni postupci nisu imali planirani u\u010dinak i nismo uspjeli obnoviti rad usluge njihovom pomo\u0107i. To je dovelo do situacije u kojoj je bilo potrebno provesti vrijeme analiziraju\u0107i i prikupljaju\u0107i podatke u nadi da \u0107emo prona\u0107i uzrok \u2014 umjesto da usmjerimo sve napore na obnavljanje funkcionalnosti.<\/li>\n
  3. Procijenite utjecaj svake funkcije usluge<\/b>. Klijenti rijetko koriste App Registry, stoga nije bio prioritet za na\u0161 tim. Kada se neke funkcije proizvoda gotovo uop\u0107e ne koriste, njihovi bugovi se rje\u0111e 'otkrivaju', a programeri prestaju pratiti kod. Lako je postati \u017ertva zablude da to tako treba biti \u2014 dok iznenada ta funkcija ne postane u sredi\u0161tu velikog incidenta.<\/li>\n<\/ol>\n

    <\/p>\n

    \u0160to dalje?<\/h2>\n

    \nRad na osiguranju stabilnosti usluge nikada ne prestaje i stalno je pobolj\u0161avamo. Obujmi prometa na quay.io i dalje rastu, a mi smo svjesni da moramo u\u010diniti sve \u0161to je mogu\u0107e kako bismo opravdali povjerenje klijenata. Stoga trenutno radimo na sljede\u0107im zadacima:<\/p>\n

      \n
    1. Implementacija replikacija baza podataka samo za \u010ditanje, kako bi se pomoglo usluzi da obradi odgovaraju\u0107i promet u slu\u010daju problema s glavnim primjerkom RDS-a.<\/li>\n
    2. A\u017euriranje primjerka RDS-a. Trenutna verzija sama po sebi nije problem. Umjesto toga, jednostavno \u017eelimo ukloniti la\u017eni trag (koji smo slijedili tijekom kvara); odr\u017eavanje softvera a\u017eurnim omogu\u0107it \u0107e uklanjanje jo\u0161 jednog faktora za budu\u0107a isklju\u010denja.<\/li>\n
    3. Dodatno cacheiranje u cijelom klasteru. Nastavljamo tra\u017eiti podru\u010dja u kojima cacheiranje mo\u017ee smanjiti optere\u0107enje na bazi podataka.<\/li>\n
    4. Dodavanje vatrozida aplikacija (WAF), kako bismo vidjeli tko i za\u0161to pristupa quay.io.<\/li>\n
    5. Po\u010dev\u0161i od sljede\u0107e verzije, klasteri Red Hat OpenShift odustaju od App Registry u korist kataloga operatora (Operator Catalogs), koji se temelje na slikama kontejnera dostupnim na quay.io.<\/li>\n
    6. Dugoro\u010dna zamjena za App Registry mogla bi biti podr\u0161ka specifikacijama artefakata Open Container Initiative (OCI). Trenutno je implementirana kao izvorna funkcionalnost Quay i bit \u0107e dostupna korisnicima kada se sama specifikacija kona\u010dno usuglasi.<\/li>\n<\/ol>\n

      \nSve navedeno dio je kontinuiranih ulaganja Red Hata u quay.io dok prelazimo iz male \"startupa\" ekipe u zrelu platformu koju upravlja SRE. Svjesni smo da mnogi na\u0161i klijenti ovise o quay.io u svom svakodnevnom radu (uklju\u010duju\u0107i i Red Hat!) i trudimo se biti \u0161to otvoreniji u vezi s nedavnim neuspjesima i stalnim naporima da postanemo bolji.<\/p>\n

      P.S. od prevodioca<\/h2>\n

      \nPro\u010ditajte i na na\u0161em blogu:<\/p>\n