記事

GitHub、7時間47分におよんだ8月17日の大規模障害の原因を公表——月間コミット29億件への急増が引き金に

GitHubが8月17日に発生した大規模障害の調査結果を公表しました。原因はトラフィック急増に対する容量不足で、Azureへの移行加速や再試行制御の導入など再発防止策も明らかにしています。

GitHubは2026年8月20日、8月17日に発生した大規模障害についての調査結果と今後の対策を公式ブログで公表しました。執筆者はGitHubのCTOを務めるVlad Fedorov氏です。障害は7時間47分におよび、github.com本体、認証、GitHub Actions、API、プルリクエスト、Issues、GitHub Copilotまで、開発者が日常的に使う主要機能のほぼすべてが影響を受けました。

GitHubにとって8月の重大インシデントはこれが2件目です。8月6日にはGitHub Actionsの障害が発生しており、立て続けのトラブルを受けて、同社はかねてから進めていた信頼性改善の取り組みを加速させると表明しました。

障害の原因はコード変更ではなく「容量不足」

調査によると、障害はトラフィックが過去最高のピークに達した際、米国中部データセンターの重要なインフラコンポーネントがスケールに追従できなかったことから始まりました。そこで生じた容量逼迫がシステム全体に波及し、認証の失敗と複数サービスの停止を引き起こしています。

注目すべきは、8月6日と17日のどちらの障害も、コードや設定の変更が原因ではなかったという点です。GitHubは両者を本質的に「容量の障害」と総括し、需要が容量を超える前に重要コンポーネントをスケールできなかったことを率直に認めました。背景にあるのは利用量の爆発的な伸びで、月間コミット数は4月の14億件から29億件へと、わずか4か月で倍増しています。

復旧作業では、トラフィックの再ルーティング、影響を受けたインフラの隔離、段階的なサービス復旧が実施されました。大半のサービスは当日中に回復しましたが、Copilot関連サービスは復旧が長引きました。エラーがクライアント側の再試行ループを誘発し、復旧中のトラフィックをさらに増加させたため、この挙動を抑え込むまで安全にトラフィックを戻せなかったと説明されています。

Azure移行を加速、プラットフォーム負荷の58%まで拡大

GitHubは今年3月と4月に公表した信頼性改善のコミットメントに沿って、容量の追加、効率の改善、アーキテクチャ上のボトルネック除去という3つの優先課題に取り組んできました。これまでに300万CPUコア以上、120ペタバイトの高速ストレージ、大幅なネットワーク容量を追加し、既存データセンターには電力の許す限りハードウェアを増設したとしています。

並行してMicrosoft Azureへの移行も加速しており、現在はプラットフォーム負荷の約58%、Git操作の半分をAzureが担っています。5月時点の負荷比率は12%だったため、3か月で大きく比重が移った計算になります。

Git fetch操作のスループット推移を示す2つのグラフ

画像引用元: The GitHub Blog

次のマイルストーンとして掲げるのは、読み取り容量がリーダー数に比例して線形にスケールするアーキテクチャです。実質的に無制限の読み取り操作を可能にするもので、最大規模のモノレポから段階的に展開していく計画です。

再試行ストームを防ぐ2つの即時対策

今回の2つのインシデントからは、即時の変更が2点導入されました。1つ目は、サービス間通信全体への一貫した再試行制限、再試行バジェット、可変タイムアウトの適用です。復旧を妨げた再試行ストームや連鎖的な負荷増大を防ぐ狙いがあります。2つ目は、優先度の低いCPU・メモリアラートの見直しで、突発的なトラフィック急増時に破綻しうるコンポーネントを洗い出すとしています。

このほか、重要システムの分離や共有依存関係の除去も進めており、障害の発生確率を下げると同時に、発生時の影響範囲を限定する設計を目指しています。

開発チームへの影響

GitHubに依存する開発チームにとって、今回のポストモーテムは自社のCI/CDや開発フローの耐障害性を見直すきっかけになります。特に、クライアント側の再試行ループが復旧を遅らせたという教訓は、GitHub APIやActionsを呼び出す自動化を組んでいるチームにそのまま当てはまります。指数バックオフや再試行上限の設定を確認しておくと、次の障害時に自社システムが「加害者」になる事態を避けられます。月間コミット29億件という規模の伸びが続く以上、同種の容量起因の障害リスクは今後もゼロにはならないと考えて備えておきたいところです。