クラウドコンピューティングとデータセンター

GitHub、2026年8月にActionsとCopilotに影響した5件の障害の詳細を公開

GitHubは2026年8月、GitHub Actions、Copilot、認証サービスを含む5件の性能劣化インシデントを記録し、容量上の圧力、スケーリングや再試行、リージョン復旧に関する問題が明らかになった。同社はサービスのAzureへの移行を加速し、監視、分離、復旧の仕組みを改善していると述べている。

2026-09-09
1 分で読めます
9 閲覧数
فريق تحرير certi.news
GitHub、2026年8月にActionsとCopilotに影響した5件の障害の詳細を公開

GitHubは2026年8月、サービスの可用性に影響した5件のインシデントの詳細を公開した。これにはGitHub Actionsの障害、Copilot Cloud Agentの結果遅延、Kimi K3モデルへのリクエスト失敗が含まれる。同社は、プラットフォームの成長と容量余力の縮小に加え、自動スケーリング、再試行ポリシー、復旧メカニズムの欠陥がインシデントの原因になったと説明している。

GitHubは、アーキテクチャの改善と、より多くのサービスのAzureへの移行に投資しており、可用性、容量、機能の順に優先すると述べている。また、容量監視、キュー管理、再試行ポリシー、基盤サービスのレジリエンスに関する改善も発表した。

原因の異なる5件のインシデント

  • 8月6日:インシデントは10時間42分続いた。Actionsの内部サービスに対する定期的なデプロイにより、あるサイトの容量が一時的に低下したことが発端だった。これによりサービスが飽和し、キャッシュ、DNS、APIの各インターフェースへエラーが波及した。その後、タスク割り当てパスの欠陥により復旧処理が遅れた。ワークフローの大部分が失敗または遅延し、一部のイベントでは手動での再実行が必要になった。
  • 8月17日:データセンターのロードバランサーが容量のピークに達したことに加え、サービスネットワークの補助コンポーネントが同時実行数の上限に達してもスケールしなかったため、劣化は7時間35分続いた。これにより共有認証パスで遅延と失敗が発生し、影響はIssues、Pull Requests、API、Actions、Copilotに及んだ。また、再試行処理の欠陥により、内部認証ポイントへのリクエスト量が倍増した。
  • 8月20日:インシデントは9時間54分続き、少なくとも54組織におけるCopilot Cloud Agentのタスク状態と結果に影響した。タスク状態を保存するクラウドデータベースプロバイダーのリージョンで障害が発生し、ストレージ設定のためリージョン切り替えも迅速に行えず、状態更新が蓄積した。タスク自体は失われなかったが、処理の復旧とキューの消化が完了するまで結果の表示が遅延した。
  • 8月26日:共有データベースが限界近くで稼働している状態で、イベントのバッチ処理によって飽和に至り、劣化は2時間50分続いた。これによりActionsの開始が遅れ、Copilot Code Reviewや一部のGitHub Pages処理など、同データベースに依存するサービスも影響を受けた。GitHubは受信負荷を段階的に抑制する必要があった。負荷の兆候が現れた際に保護を有効化する自動サーキットブレーカーが存在しなかったためである。
  • 8月27日:インシデントは2時間8分続き、外部モデルプロバイダーの劣化により、Copilot内でKimi K3モデルに向けられたリクエストだけが影響を受けた。インシデントのピーク時には、これらのリクエストの失敗率が半分を超えた一方、他のモデルとAuto設定は利用可能な状態を維持した。

実際に何が変わったのか

発表された対策からは、GitHubがインシデントを単独のデプロイエラーではなく、容量、分離、復旧に関する問題として扱っていることが分かる。同社はActionsのジョブの33%を、制約のある本番クラスターから予備容量へ移行した。これにより、ピーク時のキャッシュストレージのCPU使用率は98%から80%に低下し、同社の推定では約3か月分の余力が追加された。また、Azureへ移行したサービスの読み取りはピーク時に60.4%、単一システムの読み取りは64.3%、Gitの読み取りは54%に達した。

データベースについては、8月11日にAzure上で初の本番MySQLプライマリを稼働させたが、顧客から観測される書き込み処理への目立った影響はなかった。その後、8月27日には2つの基幹データベースでも同じパターンを繰り返した。また、GitHubは旧データベースのレプリカから毎秒約100万件のクエリを削減し、別の変更により毎秒12万件のクエリと、1時間あたり約5万9,000秒分の無駄な処理を削減した。

なぜこの報告が重要なのか

今回のインシデントは、サービスがデータベース、認証パス、Actions基盤を共有している場合、水平スケーリングだけでは不十分であることを示している。また、制御されていない再試行は部分的な劣化をより広範な負荷へ変える可能性がある。一方、リージョン間の切り替えが遅れると、元のタスクが失われていなくても状態が蓄積することがある。Azure計画、分離対策、負荷遮断機能は引き続き実施中であり、報告書はリスクが解消されたことを示すものではない。むしろ、GitHubが今後の取り組みを集中させる領域、すなわち追加の基幹データベースの移行、容量管理の自動化、依存関係の障害への対応強化を明らかにしている。

ニュースの出典
GitHub Blog
原文を開く ↗
ف
著者

فريق تحرير certi.news

同じカテゴリー

おすすめ記事

すべてのニュースを見る