月曜日に発生した7時間にも及ぶ障害について、GitHub自身が下した説明は率直だった。プログラムのバグでも設定ミスでもなく、トラフィックが過去最高水準に達し、米国中部のデータセンターにある重要なインフラコンポーネントがその急成長に追いつけなかったというのだ。
今回の障害で本当に注目すべきは数字だ。GitHubによると、4月以降プラットフォーム上の月間コミット数は14億回から29億回へと成長し、わずか4カ月でほぼ倍増したという。公式声明では「この成長がシステムにかかった負荷を説明するものではあるが、今回の障害の言い訳にはならない」と述べられている。つまりGitHubは、問題の原因はトラフィックそのものではなく、自社インフラがユーザー行動の変化速度に追いついていなかったことにあると明確に認識しているのだ。
今回露呈した脆弱性に対し、GitHubがステータスレポートで挙げた修正の方向性は、同時並行処理のメカニズムに集中している。チームはサーバーのCPUおよびメモリ警告設定を見直し、高トラフィック時に機能しなくなる可能性のあるコンポーネントを特定している。同時に、一貫したリトライ回数の上限、リトライ予算、サービス間連携における可変タイムアウト設定を導入し、「リトライの嵐」が連鎖的なシステム過負荷を引き起こすのを防ぐことを目指している。
今回のコミット数急増の原因については、GitHubは数字そのものを示すにとどまり、具体的な要因には触れていない。この時期は、AnthropicやOpenAIなどの企業がAI支援コーディングツールを拡充し続けている時期と重なるが、これはあくまで時期的な一致にすぎず、GitHub公式は両者を直接結びつけているわけではない。多くのプロフェッショナルおよびアマチュア開発者がコードを保存するデフォルトのプラットフォームとして、GitHubが今後直面するのは、こうした成長曲線にインフラの拡張速度をいかに追いつかせるかという課題だ。
