要約

  • GitHubによると、8月17日の障害は7時間47分続いた。WebとAPIのエラー率はピーク時に約20%、アーカイブとリポジトリのrawコンテンツ取得は約50%に達し、Issues、Pull Requests、Actions、企業向け認証、Copilotが影響を受けた。
  • Istio sidecarが同時処理上限に達したにもかかわらず、ホスト側だけを監視する設定のため適切にスケールしなかった。4台のHAProxyノードがflow limitを使い切り、再試行によってCopilot Token Serviceの負荷は通常の毎秒7,000～9,000件から7万～10万件に増えた。

別リージョンにトラフィックを移せば、それだけで復旧するとは限らない。今回のGitHub障害では、遅い応答を受けたクライアントが新たな負荷を作り続けた。

GitHubはインシデント zkxwbgr0cnmx の詳細更新で、影響時間を8月17日13時28分から21時15分（UTC）までの7時間47分としている。Issues、Pull Requests、API、Actions、Copilotでエラーや遅延が発生した。WebとAPIのエラー率は約20%、アーカイブとrawコンテンツのダウンロードは約50%まで上昇したという。

企業の管理機能も影響範囲に入った。SAML/OIDC認証、SCIM、Team Syncに加え、データレジデンシーを利用するGitHub Enterprise Cloud上のActionsでも、GitHub.comにある公開ステップ定義に依存するワークフローが影響を受けた。これは保存データが選択リージョンの外へ出たという説明ではない。実行時の依存先が別のサービス面に残っていたという範囲の事実である。

直接の起点について、GitHubはCentral USデータセンターのロードバランサーが新たなトラフィックピークでネットワーク飽和したと説明する。Istioのsidecar podが同時処理上限に達した一方、オートスケーリングのポリシーはホストサービスを監視し、sidecarの上限を見ていなかった。実際に詰まった場所へ容量が追加されなかった。

制約は連鎖し、最終的に4台のHAProxyノードがflow limitを使い切った。共通のgateway認証経路で遅延と失敗が広がった。GitHubはこれらのノードでHAProxyを同時に停止したところ、広範な回復が直ちに見られたとしている。

失敗していたトラフィックの一部はNorthern Virginiaへ移され、Central US側を調査している間もそこで正常に処理された。多くのサービスは16時36分までに回復したが、Actionsの劣化は18時03分ごろまで残った。

Copilotはさらに長引いた。単一の内部エンドポイントからの応答遅延が、VS Codeに潜んでいた再試行の不具合を引き起こした。失敗したtoken操作が追加リクエストを生み、ループに入る場合があった。Copilot Token Serviceは通常の毎秒7,000～9,000リクエストから7万～10万リクエストへ跳ね上がった。

GitHubは受け皿を増やすだけでなく、増幅そのものを止める必要があった。gatewayの再試行を一時的に減らし、ロードバランサーで一部のCopilot tokenリクエストにHTTP 403を返した。その後、サイト単位でトラフィックを段階的に戻した。Token Serviceは21時02分ごろに完全復旧し、インシデントは21時15分にクローズされた。

codeloadエンドポイントを狙う複数のスクレイピング攻撃も復旧を難しくしたとGitHubは述べている。ただし、その寄与量は公開されておらず、最初の原因とも位置づけられていない。公表された主な連鎖は、sidecarの上限、監視対象を欠いたスケーリング設定、HAProxyのflow枯渇、再試行による増幅である。

公式ドキュメントを見ると、複数機能が同じ境界をまたぐ理由が分かる。再利用可能なワークフローは、設定が許可すれば公開リポジトリに置かれた定義を企業ワークフローから呼び出せる。GitHub-hosted runnerは、ジョブ実行やactionの取得にGitHub.com、API、Actionsの各ドメイン、codeload.github.comへの接続を必要とする。

認証も独立した付属機能ではない。GitHubはSAML SSOとSCIMを企業のアクセス制御とアカウント管理に使う。データレジデンシーの説明では専用GHE.comサブドメインと複数の保存地域を示している。データの保存場所と、認証やワークフロー取得が通る経路は別々に確認しなければならない。

再発防止策としてGitHubは、sidecarの同時処理能力を反映したオートスケーリング、Istioのリクエスト・同時処理・スケール上限の監査、gatewayとクライアントの再試行およびbackoffの見直し、VS Codeの挙動修正、ロードバランサー監視とリージョン切り替えの強化を挙げる。現時点では実施予定であり、完了を示す証拠ではない。

利用者側では、復旧確認を機能別に分けられる。リポジトリの読み取り、API、SSO、チーム同期、公開ワークフロー定義の取得、runner起動、Copilot token発行は同じ結果になるとは限らない。Web画面が戻ったことだけでデリバリー経路全体の復旧を判断するのは情報不足である。

GitHubのREST APIベストプラクティスは、Retry-Afterやrate-limit resetに従い、失敗が続く場合は待機時間を指数的に延ばすよう求める。これは外部連携向けの指針で、社内障害の実装説明ではない。それでも、無制限の再試行が待ち時間を新しい需要へ変えるという運用上の原則は共通する。

出典