GitHub 7 stundas 47 minūtes atgriež kļūdas: autoskalēšana neredzēja Istio sidecar noslogojumu

GitHub 17. augustā 7 stundas un 47 minūtes strādāja ar kļūdām. Aptuveni 20 % tīmekļa un API pieprasījumu beidzās ar kļūdu. Arhīvu un neapstrādāta repozitoriju satura lejupielādēm kļūdu īpatsvars sasniedza 50 %. Pārstāja strādāt autentifikācija, Actions, Copilot, biļetes un izmaiņu pieprasījumi.

Ne koda, ne konfigurācijas izmaiņas te nav vainīgas. GitHub tehnoloģiju direktors Vlads Fjodorovs uzņēmuma blogā raksta, ka slodze sasniedza jaunu maksimumu un viens infrastruktūras komponents ASV centrālajā datu centrā tai līdzi neizauga. Tālāk gāja ķēdes reakcija, kas nogāza autentifikāciju visai platformai.

Autoskalēšana mērīja nepareizo procesu

Komponents, kas nepadevās, ir Istio sidecar starpniekserveris. Istio liek blakus katram servisa podam atsevišķu starpniekserveri, kas pārņem visu ienākošo un izejošo tīkla trafiku. Serviss pats par tīklu vairs nedomā. Šis sidecar 17. augustā sasniedza vienlaicīgi apstrādājamo savienojumu robežu.

Automātiskā mērogošana to nepamanīja. Tā skatījās uz galvenā servisa konteinera procesora un atmiņas patēriņu. Sidecar noslogojums šajos rādītājos neparādījās, tāpēc jaunas kopijas netika palaistas tajā brīdī, kad tās visvairāk vajadzēja. Serviss pēc saviem paša mērītājiem izskatījās mierīgs, kamēr tīkla slānis blakus tam jau bija pilns.

Šo kļūdu var atkārtot jebkurš, kas darbina Istio uz Kubernetes. Horizontal Pod Autoscaler pēc noklusējuma rēķina podā deklarētos resursu pieprasījumus. Komanda tos parasti uzstāda tikai galvenajam konteineram. Sidecar konteineram bieži nav ne pieprasījumu, ne atsevišķa slieksni. Envoy vienlaicīgo savienojumu skaitītājs ir pavisam cits rādītājs, kas mērogošanas lēmumā neienāk vispār. Kamēr slodze aug pakāpeniski, tas neizpaužas. Trafika maksimumā process pie griestiem stāv klusi, bez procesora pieauguma un bez brīdinājuma.

Kad sidecar pārstāja tikt līdzi, slodze pārgāja uz četriem HAProxy slodzes balansētājiem. Arī tie aizgāja līdz griestiem. Pēc tam salūza iekšējā autentifikācija, tātad arī visi servisi, kas gaida no tās atbildi. Tā viena poda līmeņa robeža izauga par platformas mēroga pārtraukumu.

VS Code atkārtoja pieprasījumus bez griestiem

Atgūšanos aizkavēja kļūda Visual Studio Code. Kad Copilot autentifikācija neizdevās, redaktors mēģināja vēlreiz un vēlreiz, bez jebkāda atkārtošanas ierobežojuma. Žetonu servisa slodze uzlēca no 7000 līdz 9000 pieprasījumiem sekundē uz 70 000 līdz 100 000 pieprasījumiem sekundē. Tas ir desmitkārtīgs pieaugums, ko saģenerēja paši redaktori lietotāju datoros.

Atkārtošanas budžets pret to strādā vienkārši. Klients drīkst atkārtot tikai fiksētu daļu no saviem pieprasījumiem, teiksim, desmit procentus. Pārējās neveiksmes tas atdod lietotājam kā kļūdu. Kad serveris krīt, atkārtojumu apjoms tad aug lineāri, nevis eksponenciāli. GitHub tagad apņēmies šādus budžetus uzlikt visiem saviem servisiem. Visual Studio Code puses labojums iet pa atsevišķu ceļu, jo redaktora versijas lietotāju datoros nomainās nedēļās.

Iznākumu pazīst katrs, kas licis kopā izkliedētu sistēmu. Klienti uzturēja avāriju dzīvu arī tad, kad servera pusē problēma jau bija atrasta. Fjodorovs to min kā iemeslu, kāpēc Copilot atgriezās vēlāk par pārējiem servisiem.

Ja tajā dienā mēģināji izlaist programmatūru, mēs tevi pievīlām. — Vlads Fjodorovs, GitHub tehnoloģiju direktors

Revīziju skaits četros mēnešos dubultojies

Slodzes skaitļi paskaidro, kāpēc griesti pienāca tagad. Aprīlī GitHub apstrādāja 1,4 miljardus revīziju mēnesī. Augustā tie ir 2,9 miljardi. Mēnesī tiek sapludināti 130 miljoni izmaiņu pieprasījumu. Jaunu repozitoriju skaits ir 24 miljoni mēnesī, Actions izpilžu skaits sasniedzis 115,4 miljonus.

Jauda arī ir augusi. Kopš pagājušā rudens pievienoti vairāk nekā 3 miljoni procesoru kodolu un 120 petabaiti ātrās krātuves. Azure apkalpo 58 % platformas slodzes, maijā tie bija 12 %. Puse no visām Git operācijām jau iet caur Azure. Ar to nepietika, jo problēma sēdēja vienā mērogošanas nosacījumā.

Ko GitHub apņēmies mainīt

Saraksts ir tehnisks un īss. Visos servisos tiks ieviesti vienoti atkārtošanas ierobežojumi ar budžetiem, lai klients viens pats nespēj uzsist serveri. Tiks pārskatīti procesora un atmiņas brīdinājumi tiem komponentiem, kuri cieš no pēkšņiem slodzes viļņiem. Kritiskās sistēmas tiks nodalītas cita no citas tā, lai starp tām nepaliek kopīgu atkarību.

Atsevišķi apsolīta arhitektūra, kurā lasīšanas jauda aug lineāri ar lasītāju skaitu. To sāks ieviest lielākajos monorepozitorijos. Aprīļa ierakstā GitHub jau bija nosaucis prioritāšu secību: vispirms pieejamība, tad jauda, tad jaunas funkcijas. Tolaik plānoja desmitkārtīgu jaudas pieaugumu, februārī pārrēķināja uz trīsdesmitkārtīgu.

Augusts nebija pirmā reize

6. augustā bija vēl viens pārtraukums, arī tas bez koda vai konfigurācijas izmaiņām. Aprīlī sapludināšanas rinda salūza 658 repozitorijos un ietekmēja 2092 izmaiņu pieprasījumus. Četras dienas vēlāk pārslogojās Elasticsearch. Meklēšana pārstāja strādāt kopā ar tām funkcijām biļetēs un projektos, kas paļaujas uz meklēšanu. Datu zudumu nevienā no gadījumiem nebija.

The Register apraksta reakciju sociālajos tīklos kā sadalījušos starp saprašanu par mērogu un neapmierinātību no maksājošiem klientiem. Statusa lapā GitHub turpmāk apņēmies rādīt pieejamības skaitļus arī par mazākiem traucējumiem.

Avoti

• The August 17 outage, and the work ahead, GitHub Blog
• An update on GitHub availability, GitHub Blog
• ‘We let you down’: GitHub pledges to scale up before developers give up, The Register
• The reason for GitHub’s approximately 8-hour downtime has been identified, GIGAZINE
• GitHub’s ~8-Hour Outage Caused by “Capacity Shortage”, BigGo