GitHubで8月に相次いだ5件のサービス障害

GitHubは9月10日、8月にサービスへ影響した障害が5件あったとする可用性レポートを公開しました。同社によると、対応はAzureへの移行と容量確保に加え、再試行、オートスケーリング、フェイルオーバーの改善にも及び、優先順位は可用性、次にキャパシティ、その次に機能です。

負荷の移動と再試行が障害を広げた

8月6日のGitHub Actions障害は10時間42分続きました。GitHubによると、通常のデプロイで1拠点の容量が一時的に減り、別拠点へ流れたトラフィックによってサービスメッシュのサイドカーがCPUとメモリの上限に達しました。キャッシュ、DNS、APIのエラーが連鎖し、ジョブ割り当ての潜在的な再試行バグが復旧を長引かせました。

8月17日にはピークトラフィックが1データセンターのロードバランサーを過負荷にし、サイドカーも十分にスケールしませんでした。共有認証の性能が低下してIssue、プルリクエスト、API、Actions、Copilotなどへ影響が波及し、認証エンドポイントへの通信を増幅するクライアント側の再試行バグも重なったとGitHubは説明しています。

Actionsは遅延しCopilotは結果表示が追いつかなかった

8月20日のCopilot Cloud Agentでは、プロバイダー側のリージョン障害により、タスク状態と結果を保持するマネージドデータベースが影響を受けました。GitHubによるとタスク自体は完了し、作業の消失はなかったものの、状態と結果の反映が遅延。少なくとも54組織で通常より大きな遅れが生じ、1分単位で計測したタスク状態アクティビティへの顧客影響は最大37.5％でした。

8月26日のActionsでは、限界に近い共有データベースへイベントが集中し、自動サーキットブレーカーがなかったため、GitHubが手動でスロットリングを調整しました。遅れた実行の大半はバックログ解消後に始まりましたが、初期の少数は新しく開始し直す必要がありました。翌日のKimi K3障害では、上流モデルプロバイダーの性能低下によりピーク時にリクエストの半数超が失敗しましたが、他のモデルとAutoルーティングには影響せず、当時は再試行やモデル切り替えで成功する場合があったとGitHubは報告しています。

Azure移行と容量対策を同時に進める

GitHubは「可用性、次にキャパシティ、その次に機能」を掲げ、アーキテクチャへの投資とAzureへの基盤移行を進めています。8月11日には初めて本番MySQLプライマリをAzure上で稼働させ、GitHubによれば移行中の顧客影響はなく、クライアントから見た書き込みへの影響も最小限でした。8月27日にはさらに2基で同じ手順を実施。移行済みサービスの読み取りトラフィックは最大60.4％、モノリスからの読み取りは64.3％、Gitの読み取りは54％がAzureに達したとしています。

容量面では、Actionsジョブの33％を余裕のあるクラスターへ振り分け、キャッシュCPUのピークを98％から80％へ下げ、約3カ月の余裕を確保したとGitHubは説明しています。ただし、同社はこれを最終的な解決ではなく短期的な封じ込め策と位置づけています。再試行、オートスケーリング、サーキットブレーカー、フェイルオーバーを含む仕組みも改善対象です。