GitHub heeft meer details gegeven over een grote storing die op 17 augustus meerdere diensten trof. Een capaciteitsprobleem in een Amerikaans datacenter groeide door fout ingestelde autoscaling en agressieve retry-mechanismen uit tot een storing van bijna acht uur. Vooral bij Copilot liep het aantal verzoeken daardoor sterk op.
De problemen begonnen om 13.28 uur UTC in het Central US-datacenter van GitHub. Een verkeerspiek zorgde daar voor verzadiging van load balancers. De eerste problemen ontstonden bij een Istio-sidecar die zijn limiet voor gelijktijdige verbindingen bereikte. Deze component schaalde niet voldoende mee, omdat de ingestelde autoscaling-policy naar de capaciteit van de hoofdservice keek en niet naar de limieten van de sidecar.
Het probleem breidde zich vervolgens uit naar andere onderdelen van de infrastructuur. Uiteindelijk bereikten vier HAProxy-nodes hun maximale capaciteit. Omdat deze systemen onderdeel waren van het authenticatiepad, ontstonden vertragingen en fouten bij uiteenlopende GitHub-diensten.
Foutpercentages tot 50 procent
Issues, Pull Requests, API’s, Actions en Copilot werden getroffen. Op het hoogtepunt lag het foutpercentage voor web- en API-verkeer rond de 20 procent. Bij het downloaden van archives en raw content liep dit op tot ongeveer 50 procent. Ook SAML- en OIDC-authenticatie, SCIM en Team Sync ondervonden problemen.
GitHub verplaatste een deel van het verkeer van Central US naar Northern Virginia. Dat zorgde aanvankelijk voor verlichting, maar loste het onderliggende probleem niet op. Automatische retries bleken de belasting juist verder te verhogen. Verzoeken die niet of te langzaam werden afgehandeld, werden opnieuw verstuurd, waardoor de toch al overbelaste infrastructuur nog meer verkeer moest verwerken.
Het tijdelijk uitschakelen van de getroffen HAProxy-nodes zorgde uiteindelijk voor een snel herstel van een groot deel van de diensten. De meeste onderdelen functioneerden om 16.36 uur UTC weer normaal. GitHub Actions bleef tot ongeveer 18.03 uur hinder ondervinden.
Copilot-verkeer vertienvoudigt
Bij Copilot duurden de problemen langer. Een bestaande fout in het retrygedrag van VS Code versterkte het verkeer naar de Copilot Token Service met ongeveer een factor tien. Een mislukte aanvraag voor een token kon meerdere nieuwe verzoeken veroorzaken en vervolgens in een retry-loop terechtkomen.
Het verkeer naar de Token Service steeg daardoor van normaal 7.000 tot 9.000 requests per seconde naar 70.000 tot 100.000 requests per seconde. GitHub verminderde daarop het aantal retries binnen zijn gateway en blokkeerde tijdelijk bepaalde tokenrequests. Vervolgens werd het verkeer per locatie geleidelijk weer toegelaten. De Copilot Token Service was om 21.02 uur UTC volledig hersteld.
Volgens GitHub werd het herstel daarnaast bemoeilijkt door scrapingaanvallen op de codeload-endpoints.
GitHub gaat naar aanleiding van het incident de autoscaling van Istio-componenten aanpassen. Ook worden retry- en backoff-mechanismen in gateways en clients opnieuw bekeken. Daarnaast wil het bedrijf het retrygedrag van VS Code aanpakken en de monitoring van load-balancercapaciteit en regionale failover verbeteren.
Meer problemen met beschikbaarheid
De storing staat niet op zichzelf. The Register wijst erop dat GitHub de afgelopen maanden vaker met beschikbaarheidsproblemen kampte. Begin augustus werden onder meer Actions en Pages getroffen. In mei zorgde een storing bij Actions er zelfs voor dat sommige ontwikkelaars ten onrechte de melding kregen dat hun account was geschorst. GitHub erkende eerder al dat de betrouwbaarheid van het platform verbetering nodig heeft.
Die reeks incidenten valt samen met de komst van nieuwe alternatieven voor GitHub. CloudBees-CEO Moritz Plassnig verwacht dat de markt voor codehosting minder rond één platform zal draaien en wijst daarbij onder meer op Cursor en OpenAI. Cursor introduceerde deze week Origin Code Hosting, een eigen Git-gebaseerde hostingdienst die rechtstreeks met GitHub kan concurreren.