8月17日、GitHubでは7時間47分にわたる障害が発生しました。この障害により、github.com、認証、GitHub Actions、API、pull request、issue、Copilotが影響を受け、世界中の開発者や組織に支障が生じました。その日にソフトウェアをリリースしようとしていた皆さんを、私たちは失望させました。
これは、8月6日のActions障害に続く、8月に発生した2件目の重大なインシデントでした。3月と4月には、GitHubの信頼性を高めるために進めている取り組みについてお伝えしました。前進はしていますが、今回のインシデントによって、これらの取り組みを加速させる必要があることが明確になりました。
何が起きたのか
調査の結果、トラフィックが新たなピークに達した一方で、米国中部のデータセンターにある重要なインフラストラクチャーコンポーネントが、そのトラフィックに対応できる規模まで拡張できなかったことから、障害が始まったことが判明しました。その結果生じた容量への圧力がシステム全体に波及し、認証エラーを引き起こしたほか、複数のGitHubサービスに支障をきたしました。
復旧には、複数の協調した対応が必要でした。各チームはトラフィックを再ルーティングし、影響を受けたインフラストラクチャーを隔離したうえで、サービスを段階的に復旧させました。GitHubサービスの大半はその日の早い時間帯に復旧しましたが、一部のCopilotサービスではさらに時間がかかりました。これらのサービスで発生したエラーにより、復旧中にトラフィックを増加させるクライアント側の再試行ループが引き起こされました。トラフィックを安全に復旧させるには、まずこの動作を緩和する必要がありました。包括的な根本原因分析には、詳細な技術的タイムラインが含まれています。
どちらの障害も、コードや設定の変更によって発生したものではありません。いずれの事象の根底にも、容量不足がありました。需要が容量を上回る前に、重要なコンポーネントをスケールさせることができませんでした。4月以降、月間のコミット数は1.4ビリオンから2.9ビリオンに増加しました。この成長はシステムにかかる負荷の大きさを説明するものですが、今回の障害を正当化するものではありません。
実施したことと今後の取り組み
今年初めに掲げた信頼性に関する約束の一環として、私たちは3つの優先事項に注力しました。容量の追加、効率の向上、そしてアーキテクチャー上のボトルネックの解消です。それ以来、3ミリオンを超えるCPUコア、120ペタバイトの高速ストレージ、そして大幅なネットワーク容量を追加しました。既存のデータセンターでは、既存の電力容量が許す限りハードウェアを設置する一方で、Azureへの移行も加速させました。
現在、AzureはGitHubのプラットフォーム負荷のおよそ58%と、すべてのGit操作の半分を処理しています。この割合は、5月時点のプラットフォーム負荷の12%から上昇したものです。この拡張されたインフラストラクチャーは、以下に示すGitHub Actionsのジョブ実行数の増加も支えています。
Azureのインフラストラクチャーと容量によって、最大規模のモノレポをスケールさせる取り組みも加速しました。次のマイルストーンは、読み取り容量を読み取りを行うユーザー数に対して線形にスケールさせ、無制限の読み取り操作を可能にするアーキテクチャーです。
これを段階的に導入し、まずは最大規模のモノレポから開始します。
スケールだけが私たちが直面した課題ではありません。変化のスピードと複雑さが増すにつれて、既存の運用プラクティスは追いつけなくなりました。チームとリソースを可用性に振り向け、より強力なテスト、より安全なリリースプロセス、より優れた可観測性、そしてより効果的なアラート機構に投資しました。進展はありましたが、この取り組みはまだ完了していません。
これに加えて、重要なシステムを相互に分離し、それらの間に存在する共有依存関係を取り除いています。この取り組みは、障害が発生する可能性を低減し、障害が発生した場合の影響を抑えることを目的としています。
障害が発生するたびに教訓を得て、可用性に関する作業項目に新たな取り組みを追加しています。8月6日と8月17日の事象を受け、2つの緊急の変更を実施しました。
まず、リトライストームと連鎖的な負荷を防ぐため、サービス間のやり取りに一貫したリトライ上限、リトライ予算、可変のタイムアウト時間を導入しています。次に、急激なトラフィック増加時に障害が発生する可能性のあるコンポーネントを特定するため、低優先度のCPUおよびメモリーに関するアラートを見直しています。
高い可用性へのコミットメントは、単なる技術上の約束ではありません。