GitHubは、8月17日に同社のプラットフォームを襲い、7時間47分続いた障害について、米国中部地域のデータセンター内でトラフィックが過去最高水準に達した際、重要なインフラストラクチャコンポーネントが拡張できなかったことが原因だったと明らかにした。容量への圧力が生じたことで複数のシステムに問題が広がり、github.com、認証、GitHub Actions、API、プルリクエスト、Issueに加え、Copilotも影響を受けた。また、障害の影響は世界中の開発者や組織に及んだ。
今回の障害は、GitHubが8月中に直面した2件目の大規模インシデントであり、これに先立ち8月6日にはActionsで障害が発生していた。同社は、いずれのインシデントもコードや設定の変更とは関連していないことが調査で判明したと説明した。両者の本質は容量不足にあり、需要が処理能力の限界を超える前に中核コンポーネントを拡張できていなかった。GitHubによると、月間のプッシュ数は4月の14億回から、それ以降は29億回に増加したが、同社は利用拡大を理由に障害防止の責任を免れることはないと認めた。
サービスはどのように復旧したのか？
復旧には、トラフィックの再ルーティング、影響を受けたインフラストラクチャの分離、サービスの段階的な再開が必要だった。GitHubの大半のサービスは同日中に復旧したが、一部のCopilotサービスにはより長い時間を要した。これらのサービスで発生したエラーにより、クライアント側で再試行ループが生じ、復旧中のトラフィックが増加したため、チームは安全にトラフィックを再ルーティングする前に、この動作を制限する必要があった。
GitHubによると、完全な根本原因分析報告書には詳細な技術的タイムラインが含まれており、同社は可用性と信頼性を向上させるため、以前に発表した取り組みを引き続き実施している。
実際に何が変わるのか？
GitHubの計画は、容量の増強、効率の向上、アーキテクチャ上のボトルネックの解消に重点を置いている。同社は、300万以上のCPUコアと120ペタバイトの高速ストレージに加え、追加のネットワーク容量を導入したと発表した。また、現在のデータセンターで利用可能な電力の範囲内で、可能な限り多くのハードウェアを設置すると同時に、Azureへの移行を加速している。
現在、AzureはGitHubプラットフォームのワークロードの約58%、Git操作の半分を担っており、5月時点のプラットフォームのワークロードに占める割合は12%だった。この拡張は、GitHub Actionsのジョブ実行数の増加を支えるうえでも役立っている。同社は、大規模なリポジトリにおける読み取り能力を読み取り者数に比例して線形に拡張する新たなアーキテクチャの開発に取り組んでいる。これにより理論上は無制限の読み取り操作が可能になり、最大規模のモノリポジトリから段階的に導入を開始する予定だ。
障害範囲の縮小と集中障害の防止
GitHubは、拡張だけでは十分ではないと考えている。同社は可用性のためにチームとリソースを追加で割り当て、より強力なテスト、安全性の高いロールアウト、改善された監視、より効果的なアラートに投資している。また、重要システムを分離し、それらの間の共有依存関係を取り除くことで、障害が発生する可能性を抑え、発生した場合の影響を縮小している。
8月6日と17日のインシデントを踏まえ、同社は統一された再試行制限と再試行予算を適用し、サービス間通信に可変タイムアウトも導入する。目的は、再試行の集中発生や連鎖的な負荷を防ぐことだ。また、トラフィックが突然急増した際に障害が発生する可能性のあるコンポーネントを検出するため、優先度の低いCPUおよびメモリのアラートも見直している。ソフトウェアの構築、出荷、運用をGitHubに依存する開発者や組織にとって、これらの対策は直接的な重要性を持つ。プラットフォームの復旧は、単にサービスを再開することだけでなく、障害の再発を防ぎ、発生時の範囲を限定することにもかかっている。