GitHubで7時間超の大規模障害、Actionsなどに影響―認証系の連鎖障害が復旧を長期化
2026年8月20日 22:27
GitHubで2026年8月17日、GitHub Actionsを含む複数のサービスに影響する大規模な障害が発生した。影響は約7時間47分に及び、WebやAPIのエラー率はピーク時に約20%、アーカイブとrawコンテンツのダウンロードでは約50%に達した。
GitHubの事後報告によると、直接の原因は米中部リージョンのロードバランサーにおけるネットワーク飽和だった。自動スケーリング設定の不備を起点に認証経路へ障害が広がり、複数のリトライ処理がトラフィックを増幅したことで、GitHub ActionsやGitHub Copilotを含む広範なサービスの復旧が長引いた。
■約8時間にわたり複数のGitHubサービスへ影響
障害による顧客影響は、協定世界時の8月17日午後1時28分から午後9時15分までの7時間47分にわたった。日本時間では8月17日午後10時28分から18日午前6時15分にあたる。
影響を受けたのは、Issue、プルリクエスト、API、GitHub Actions、GitHub Copilotなどだ。SAMLおよびOIDC認証、SCIMプロビジョニング、Team Syncにも障害が及んだ。GitHub Enterprise Cloudのデータ所在地指定環境では、GitHub.com上の公開ワークフロー定義に依存するActionsワークフローも影響を受けた。
ピーク時にはWebおよびAPIリクエストの約20%でエラーが発生した。アーカイブとrawリポジトリコンテンツのダウンロードでは、エラー率が約50%に達した。rawコンテンツは依存ファイルやソースコードを直接取得する処理で使われることがあり、この経路に依存するビルドやインストール処理では失敗が発生する可能性が高まった。
大半のサービスは協定世界時午後4時36分までに回復したが、GitHub Actionsは午後6時3分ごろまでパフォーマンス低下が続いた。GitHub Copilotのトークンサービスが完全に回復したのは午後9時2分で、その後、GitHubは午後9時15分にインシデントの解決を記録した。
■負荷分散基盤の飽和から認証障害が連鎖
GitHubの事後報告によると、障害の直接の原因は、米中部リージョンにあるロードバランサーのネットワーク飽和だった。発端となったのは、サービスメッシュで使われるIstioのサイドカーPodが同時処理数の上限に達したことだった。
このPodは適切に自動スケールしなかった。スケーリングポリシーがホスト側サービスの状態を監視する一方、サイドカーの処理上限を監視するよう設定されていなかったためだ。最初の障害が別のコンポーネントへ波及し、最終的には4台のHAProxyノードがフロー上限に達した。
これにより、ゲートウェイの認証経路で遅延や失敗が広がった。GitHubは一部のトラフィックを米東部の北バージニアへ移し、米中部リージョンのネットワーク障害を調査した。
復旧を複雑にしたのがリトライ処理だった。内部ロードバランサーに対する再試行が負荷を増幅したため、GitHubはゲートウェイ側の認証リトライを一時的に減らした。一部のHAProxyノードを停止したところ、広範なサービスで直ちに回復が見られたという。
■Copilotではクライアント側のリトライがトラフィックを増幅
GitHub Copilotでは、トークン取得処理に失敗したクライアントが再試行を繰り返し、トラフィックをさらに増やした。GitHubによると、Copilotトークンサービスへのリクエストは通常の毎秒7000～9000件から、毎秒7万～10万件まで増加した。
特に、Visual Studio Codeから内部エンドポイントへの応答が遅れた際、潜在していたリトライ処理の不具合が表面化し、トラフィックを約10倍に増幅した。GitHubはリトライを誘発する応答をロードバランサーで一時的に遮断し、拠点ごとにトラフィックを段階的に戻すことでサービスを安定させた。
GitHub Copilotの障害は、外部のAIモデル基盤ではなく、GitHub側の認証とトークン発行を含むアクセス経路で発生した。GitHubのステータスページでは、モデルプロバイダーを独立したサービス項目として扱っており、今回の障害でもCopilot本体とモデル提供基盤の状態は区別されている。
■Actionsの90日稼働率は公開時点で99.33%
GitHubは2026年4月、ステータスページを改定し、サービス別の直近90日間の稼働率を公開する仕組みを導入した。障害の状態は「Degraded Performance」「Partial Outage」「Major Outage」の3段階で表示される。
記事公開時点のステータスページでは、GitHub Actionsの直近90日間の稼働率は99.33%、Git Operationsは99.99%だった。90日間の全時間を基準に単純換算すると、99.33%は約14時間半に相当する。
もっとも、この換算値は、個々の利用者やワークフローが実際に停止した時間をそのまま示すものではない。ステータスページの稼働率は、GitHubが記録したインシデントの件数、重大度、継続時間をサービスごとに集計した指標である。障害の影響範囲やエラー率は時間とともに変化し、利用者によっても異なる。
また、GitHubの契約上のSLAと、公開ステータスページの90日稼働率は同じ指標ではない。少なくとも従来のGitHub Enterprise向けSLAでは、99.9%の基準は暦年ではなく四半期単位で定められ、Actionsについては経過時間ではなく、実行が開始できなかったワークフローの割合を使う計算方法が示されていた。したがって、約8時間のインシデントを「Actionsが1年分の許容停止時間を消費した」と一律に評価することはできない。
■7月と8月に相次いだ可用性問題
GitHubは7月にも8件のインシデントを記録している。公式の可用性レポートでは、構成変更、自動運用、サービス間の依存関係、データセンターの容量不足など、複数の要因が報告された。
7月8日の障害では、データ所在地を指定したGitHub Enterprise Cloud環境で、仮想マシンの実行時設定が自動処理によって変更された。本来変更を防ぐはずの保護策が適用されず、サービスディスカバリーが機能しなくなった。顧客影響は7時間4分に及び、ピーク時にはアクティブなテナントの84%で、リクエストの過半数が失敗した。
7月19日には、データベース接続の問題により、自動DNS再構成処理が不完全な情報を基に設定を生成した。キャッシュされたDNSレコードが期限切れになるにつれて、サービスが内部アドレスを解決できなくなった。
7月25日のGitHub Actions障害では、重要なRedisクラスターに対する計画的な構成変更後、一つのリージョンが不安定な状態になった。その後、別の容量管理作業によってトラフィックが同リージョンへ送られ、ピーク時にはワークフロー実行の60%がインフラ関連のエラーで失敗した。
8月6日にもGitHub Actionsで長時間の障害が発生し、約9時間にわたって影響が続いた。ピーク時にはワークフロー実行の71%が失敗した。GitHubは、この障害について影響と継続時間の両面で受け入れられないものだったと説明している。
■ActionsのAzure移行とサービス分離を加速
GitHubによると、8月6日の障害で問題となったActionsの起動サービスは、モノリスとActionsを接続するコンポーネントで、当時はAzureではなくGitHubの自社データセンターで稼働していた。
Actionsの処理の多くはAzure上で動作しているが、この起動サービスは処理をキューに入れられる非同期性を理由に、移行の優先度が低く設定されていた。連鎖的な障害が発生した際、自社データセンター側の容量制約が復旧の遅れにつながったため、GitHubはActionsのAzure移行を加速するとしている。
GitHubはプラットフォーム全体でも、共有インフラへの依存を減らし、障害の影響範囲を限定する作業を進めている。7月には、米中部のAzureで処理するモノリスの読み取りトラフィックがピーク時に52.75%へ達した。専用化したユーザーサービスによって、最も古い共有データベースから毎秒100万件を超えるクエリを分離したほか、全リポジトリの29%について米中部に2個目のレプリカを配置した。
GitHubは、重要なサービスの分離、キャッシュの改善、単一障害点の削減、過剰なトラフィックを制限するロードシェディングなどにも取り組んでいる。今回の障害は、自動スケーリングの監視対象やリトライ制御といった個別の設計が、サービス間の依存を通じて広範な影響へ発展し得ることを示した。
■開発チームは依存経路と復旧手順の確認を
GitHub Actionsを本番環境への唯一のデリバリー経路としている組織では、GitHub側の障害がビルド、テスト、デプロイの停止へ直結する。可用性要件の高いシステムでは、別のCI/CDサービスや社内基盤から実行できる代替手順を整え、GitHubのコントロールプレーンに依存しない形で定期的に動作を確認することが重要になる。
セルフホストランナーは実行環境を自社で管理できるが、ワークフローの起動や制御にはGitHub Actionsのサービスを利用する。このため、セルフホストランナーを用意するだけでは、Actions自体の障害に対する完全な代替経路にはならない。
GitHubのrawコンテンツURLから依存ファイルを直接取得している場合は、管理下のアーティファクトリポジトリやパッケージレジストリへ必要なファイルを保存する方法も検討できる。外部サービスからの取得処理を減らすことで、ビルド時の依存経路を限定できる。
組織ごとに影響を把握するには、GitHubのステータス情報に加え、ワークフローの開始失敗率、待ち時間、途中失敗、デプロイの所要時間を自社側で記録する必要がある。契約上のSLAやサービスクレジットの条件は契約時期や契約内容によって異なるため、実際の適用条件はGitHubの現行契約とアカウント担当者を通じて確認することになる。
■注目ポイントQ&A
●8月17日のGitHub障害はどのくらい続きましたか？
顧客への影響は協定世界時の8月17日午後1時28分から午後9時15分までの7時間47分でした。日本時間では8月17日午後10時28分から18日午前6時15分にあたります。大半のサービスはこれより早く回復しましたが、GitHub Copilotの認証関連では影響が長く続きました。
●障害の原因は何でしたか？
米中部リージョンのロードバランサーで発生したネットワーク飽和です。IstioのサイドカーPodが処理上限に達しても適切に自動スケールせず、複数のHAProxyノードへ障害が連鎖しました。認証処理やクライアントのリトライがトラフィックを増幅し、復旧を遅らせました。
●GitHub Actionsの99.33%は、約14.5時間停止したという意味ですか？
90日間の全時間を基準に単純換算すると約14.5時間に相当しますが、すべての利用者が同じ時間だけ完全に利用できなかったことを意味するものではありません。公開稼働率は、各インシデントの重大度と継続時間を基に算出されたサービス全体の指標です。
●8月17日の障害で、年間SLAの停止枠を使い切ったのですか？
そのようには一律に判断できません。公開ステータスページの90日稼働率と契約上のSLAは計算方法が異なります。従来のEnterprise向けSLAでは99.9%の基準は四半期単位で、Actionsは停止時間ではなく、開始できなかった実行の割合を基に計算されていました。適用条件は各社の現行契約を確認する必要があります。
●GitHub Actionsへの依存リスクを減らすにはどうすればよいですか？
別のCI/CD基盤や手動のデリバリー手順を用意し、GitHub Actionsを経由せずに実行できるか確認する方法があります。依存ファイルを管理下のレジストリに保存することや、ワークフローの失敗率と待ち時間を自社で監視することも有効です。セルフホストランナーだけでは、Actionsの制御サービス自体が停止した場合の完全な代替にはなりません。
元記事: GitHub Actions Hit Three-Nines Failure; One August Outage Consumed Year’s Downtime Budget