Neowinは8月19日(米国時間)、GitHubが8月17日に発生した大規模障害について根本原因分析(RCA: Root Cause Analysis)を公開したと報じた。この事案では数時間にわたりサービス品質が低下し、世界中の数百万人の開発者に影響した。ピーク時にはGitHubのWebとAPIで約20%のエラー率を記録し、アーカイブやRawコンテンツのダウンロードでは約50%に達した。

多くのサービスは約3時間で復旧したものの、GitHub ActionsとCopilot Token Serviceは長時間にわたり障害が続いた。GitHub.com、Issues、プルリクエスト、API、Actions、Copilot、複数の認証サービスなどが影響を受け、完全復旧までには7時間47分を要したという。

  • GitHubは8月17日に発生した大規模障害の根本原因分析を公開した　引用：GitHub

    GitHubは8月17日に発生した大規模障害の根本原因分析を公開した　引用：GitHub

設定ミスとリトライで障害が連鎖、Copilotにも波及

障害の発端は、米国中部のデータセンターにて発生した過大なトラフィックによるロードバランサーのネットワーク飽和とされる。サービスメッシュ基盤のIstioを利用していたが、Podのサイドカーが同時実行数の上限に達したにもかかわらず、ポリシーの設定ミスにより自動スケールが行われず障害が連鎖した。

最終的に4台のHAProxyノードがフロー制限に到達。これらのノードはGitHubのゲートウェイ認証経路に関係していたため、認証要求の処理が遅延または失敗した。加えて、GitHubのリトライ処理が過負荷状態の内部ロードバランサーへ追加のトラフィックを送ったことで、障害が拡大した。

GitHubは一部のトラフィックを北バージニアへ移したが、そこでも別の問題が発生した。内部エンドポイントの応答遅延をきっかけに、VS Codeに存在していたリトライ処理の不具合が表面化し、Copilotの認証トラフィックが急増した。

通常、毎秒7000～9000件の要求を処理するが、障害中は再試行が繰り返されたことで、約10倍となる毎秒7万～10万件まで急増した。GitHubはゲートウェイの再試行回数を減らし、一部のトークン要求をHTTP 403エラー(処理の拒否)で一時的に遮断することで、サイトごとのトラフィックを段階的に回復させ、サービスを復旧させた。

再発防止策を発表、Azure移行まで「綱渡り」続くか

GitHubは今年4月、AIコーディングによる負荷の増大を理由に、課金モデルの変更を発表している。これら高まる需要に対応するため、6月にはAmazon Web Services(AWS)のの活用を検討していると報じられた。それでも今回、ピーク負荷が大規模な障害を引き起こすに至った(参考：「AI需要急増でGitHubの処理能力が限界に、MicrosoftがAWS活用を模索か | TECH+（テックプラス）」)。

今回の分析を受け、同社は自動スケーリングポリシーの修正、Istioの同時実行性およびスケーリング制限の監査、再試行とバックオフ動作の見直し、VS Codeの不具合対応、ロードバランサーの容量監視と地域間フェイルオーバー保護機能といった改善計画を実施すると発表した。

GitHubではAI関連サービスを含めて需要が拡大しており、安定したサービス提供に向けたインフラ強化が引き続き重要となる。同社はMicrosoft Azureへの移行も進めており、今回発表した再発防止策とあわせ、今後の対応が注目される。