GitHubは、2026年9月の可用性レポートで、サービスのパフォーマンスに影響を与えた2件の障害を明らかにしました。同時に、インフラの再分散とデータベースの負荷耐性向上も進展しました。同社によると、負荷が高まった場合や共有コンポーネントの1つが故障した場合の障害リスクを低減する変更を実施したものの、対策作業はまだ完了していません。
10月7日時点で、160の本番サービスのうち120サービスがCentral USリージョンにデプロイされ、51台の主要MySQLデータベースのうち13台が移行されていました。Azureは、GitHubの主要アプリケーションの読み取りトラフィックの65.4%、Gitの読み取りトラフィックの48.3%、ストリーム処理トラフィックの80.2%を処理しました。同社は、これらの割合は異なるワークロードに関するものであり、合算すべきではないと強調しています。
インフラ移行は進展するも、予定より遅延
GitHubは、可用性ゾーン間のキャパシティの不均衡を理由に、9月11日にCentral USでのデプロイとトラフィック増加を停止しました。9月18日には一時的なキャパシティの確保後、恒常的な増加を再開しましたが、長期的なキャパシティ作業はなお継続しており、利用可能な全キャパシティを10月末までに提供することを目標としています。同社は、9月30日までにすべての本番サービスを同地域へデプロイするという意欲的な目標を達成できませんでした。
データベースの計画的な切り替え中に、自動化された緊急手順がCentral USのデータベースレプリカを切り離し、同地域の顧客に障害を引き起こしました。GitHubは、復旧メカニズムを改善するまで、計画的な引き渡しの際にこの手順を無効化しました。
データベース負荷の軽減と障害の封じ込め
GitHubは、主要な認証システムの24個のテーブルを、同社で最も古い共有データベースから切り離しました。これにより、レプリカから毎秒約100万件のクエリが削減されました。また、IssuesとPull Requestsを支えるクラスターから変更履歴に含まれていた不要なレコード約9億8,000万件を削除し、復旧可能なストレージ約1.8テラバイトを確保しました。トランザクション間の競合は、6月のピーク時と比べて週次で約77%減少しました。
サンプルの対象となったPull Requestsのトラフィックの半分は、共有依存関係が停止した場合でも、機能を限定して継続できるようになりました。また、データベーストラフィックのルーティングにより、急増時にキャパシティを自動的に追加できます。9月23日にPull Requestsの活動が増加した際、あるクラスターは14レプリカから19レプリカへ拡張されました。GitHubは、サービスが広範囲に飽和する前に優先度の低いリクエストを拒否できる負荷制御メカニズムも追加しました。
9月の2件の障害
9月13日、バックグラウンドで実行されたデータクリーンアップ作業により、共有データベースへの負荷が増加しました。保護メカニズムはレプリカの遅延を監視していましたが、利用可能な接続数の上限に達したプライマリサーバーに蓄積する負荷は監視していませんでした。クエリに短いタイムアウトが設定されていなかったため、リクエスト処理が待機し続け、さらに再試行ループが失敗した書き込み処理を送り続けました。障害は1時間28分続き、内部負荷を下げてタスクを停止した後に収束しました。
9月28日、Copilotコードレビューを実行するサービスへの変更により、一部の顧客へ、コメントを含む完全版ではなく、レビュー結果の限定版が送信されました。そのため、プルリクエストにレビューが表示されていないにもかかわらず、タスクは完了したように見えました。障害は52分続き、GitHubは変更をロールバックして対処するとともに、影響を受けたレビューを顧客に再リクエストするよう求めました。
実際には何が変わるのか
この2件の障害は、キャパシティの改善だけでは十分でないことを示しています。信頼性は、障害を早期に検知し、効果のない再試行を停止し、出力が実際に引き渡される前にタスクの成功を宣言しないことにも左右されます。GitHubは、バックグラウンド処理の制御を追加し、サービス起動時の挙動を改善し、Copilot code reviewの結果の監視と配信を強化する取り組みを進めています。
GitHub Actionsのインフラにも改善が見られました。測定されたRedis操作は約28%、相対的なCPU使用率は約30%減少しました。独立したキャッシュ層により、Redisが使用する帯域幅は84%、平均応答時間は66%、主要な在庫リクエストの中央値の応答時間は96%、待機中のリクエストは95%削減されました。今後も残る未解決の問題は、実際の本番環境下でキャパシティ作業を完了し、共有依存関係の障害が再発するのを防げるかどうかに関係しています。