GitHub障害の原因は容量不足、対策を発表
詳細を読む
GitHubは8月20日、8月17日に発生した大規模障害の原因究明結果を公表しました。同社の主要サービスは7時間47分にわたり停止し、認証やGitHub Actions、Copilotなど広範な機能に影響が及びました。米中部データセンターでインフラの容量が急増するトラフィックに対応しきれなかったことが原因です。
障害はコードや設定変更が原因ではなく、需要拡大に設備増強が追いつかなかった容量問題でした。4月以降、月間コミット数は14億件から29億件へと倍増しており、急成長する開発需要がインフラに大きな圧力をかけていたことが背景にあります。ただし、成長は言い訳にならないと同社は述べています。
復旧にあたっては、トラフィックの再ルーティングや影響範囲の切り離しなど複数の対応を段階的に実施しました。多くのサービスは同日中に復旧した一方、Copilot関連の一部サービスは復旧に時間を要しました。エラーによりクライアント側で再試行ループが発生し、復旧中のトラフィックをさらに増加させたため、これを制御してから安全にトラフィックを戻す必要がありました。
GitHubは今年掲げた信頼性向上策として、容量追加・効率化・アーキテクチャ上のボトルネック解消の3点に注力してきました。これまでに300万個以上のCPUコアと120ペタバイトの高速ストレージ、大規模なネットワーク容量を追加し、既存データセンターに設置可能な限りのハードウェアを導入しつつ、Azureへの移行を加速させています。現在Azureはプラットフォーム負荷の約58%、Git操作の半分を担っており、5月の12%から大きく増加しました。
今回の2件の障害を受け、GitHubはサービス間通信全体で一貫したリトライ回数の上限や予算、可変タイムアウトを適用し、再試行の連鎖による負荷増大を防ぐ方針です。あわせて、急激なトラフィック増加時に見落とされやすい優先度の低いCPU・メモリのアラートを見直すほか、重要システムの分離や依存関係の削減も進めています。
GitHubは開発者コミュニティが同社基盤に依存して開発・運用を行っている以上、高可用性は単なる技術的な約束ではないと強調しました。8月17日には信頼に応えられなかったとして責任を認めた上で、今後の拡張性と信頼性の向上を通じて信頼回復を目指す考えを示しています。