先週、GitHubは障害に見舞われ、24時間11分間のサービス低下が発生しました。プラットフォームの一部には影響はありませんでしたが、複数の社内システムに影響が出たため、表示情報が古く不整合な状態になりました。最終的にユーザーデータの損失はありませんでしたが、データベースへの書き込み操作には数秒の手動調整が必要でした。また、インシデント発生中のほとんどの期間、GitHubはWebhookイベントの処理やGitHub Pagesウェブサイトの構築・公開ができませんでした。

[[248425]]

GitHubの社員一同、このインシデントが皆様に与えた影響を深く反省しております。皆様からGitHubに寄せられた信頼を大切にし、プラットフォームの高可用性を維持するための堅牢なシステムを構築してきたことを誇りに思っております。しかしながら、今回のインシデントで皆様にご期待に沿えなかったことを深くお詫び申し上げます。GitHubプラットフォームの長期にわたるダウンタイムによって生じた問題を完全に解消することはできませんが、今回のインシデントに至った経緯、そこから得られた教訓、そして再発防止のために当社が講じてきた対策についてご説明いたします。

背景

ユーザー向けのGitHubサービスのほとんどは、GitHubの自社データセンター施設内で運用されています。このデータセンタートポロジーは、複数の地域データセンターのフロントエンドで堅牢かつスケーラブルなエッジネットワークを構築し、コンピューティングおよびストレージワークロードの処理をサポートするように設計されています。この設計の物理コンポーネントと論理コンポーネントには多層的な冗長性が組み込まれていますが、サイト間の通信が一定期間途絶える可能性は依然として存在します。

10月21日22時52分（UTC）、100G光デバイス交換のための定期メンテナンス作業により、米国東海岸ネットワークセンターと米国東海岸メインデータセンター間の接続が切断されました。両拠点間の接続は43秒後に回復しましたが、この短時間の障害が一連の事象を引き起こし、24時間11分間のサービス品質低下を引き起こしました。

GitHub のネットワーク アーキテクチャの一般的な説明には、2 つの物理データ センター、3 つのアクセス ポイント (POP)、およびピアリングを介して相互接続された複数のリージョンのクラウド容量が含まれます。

以前、GitHub メタデータを MySQL に保存する方法と、MySQL の高可用性を確保するために採用している手法について説明しました。GitHub は、数百 GB から約 5 TB までのサイズに及ぶ複数の MySQL クラスタを運用しています。各クラスタには、Git 以外のメタデータを保存するための最大数十のリードレプリカがあり、これによりアプリケーションはプルリクエストの提供やチケットの発行、認証の管理、バックグラウンド処理の調整、そしてネイティブ Git オブジェクトストアを超える機能の提供が可能になります。アプリケーションのさまざまな部分の異なるデータは、機能的パーティショニングを使用して、複数のクラスタに保存されます。

パフォーマンスを大幅に向上させるため、アプリケーションは各クラスタ内の関連するマスターシステムに書き込みますが、ほとんどの場合、読み取りリクエストは少数のレプリカサーバに委任されます。MySQLクラスタのトポロジを管理し、自動フェイルオーバーを処理するためにOrchestratorを使用しています。Orchestratorは様々な変化要因を考慮し、コンセンサスを確保するためにRaft上に構築されています。Orchestratorはアプリケーションがサポートできないトポロジを実装できるため、Orchestratorの設定がアプリケーションレベルの期待値と一致するように注意する必要があります。

イベントタイムライン

10月21日 22:52 UTC:

東海岸データセンターのデータベースサーバーには、西海岸データセンターに複製できない一時的な書き込みデータが含まれています。現在、両データセンターのデータベースクラスターには、もう一方のデータセンターには存在しない書き込みデータが含まれているため、障害発生時にプライマリデータベースを東海岸データセンターに安全に切り替えることができません。

10月21日 22:54 UTC

社内監視システムが多数のシステム障害を示すアラートを発し始めました。エンジニアは、多くのデータベースクラスタのトポロジが予期せぬ状態にあると判断しました。Orchestrator APIへのクエリにより、データベースレプリケーショントポロジには西海岸のデータセンターのサーバーのみが含まれていることが判明しました。

10月21日 23:07 UTC

対応チームは、さらなる変更に備えてオンプレミスツールを手動でロックすることを決定しました。対応チームはウェブサイトをイエローアラートに設定しました。状況は自動的にアクティブイベントにエスカレーションされ、インシデントコーディネーターに通知されました。インシデントコーディネーターも対応にあたり、2分後にレッドアラートにアップグレードすることを決定しました。

10月21日 23:13 UTC

この時点で、この問題が複数のデータベースクラスタに影響を与えていることが判明しました。GitHubデータベースエンジニアリングチームのエンジニアは、東海岸のデータベースを各クラスタのマスターデータベースとして手動で設定し、レプリケーショントポロジを再構築するために必要な手順を特定するために、状況の調査を開始しました。東海岸のクラスタで数秒間書き込みデータが西海岸にレプリケーションされず、新しく書き込まれたデータが東海岸にレプリケーションされない状態になっていました。

データベース呼び出しの大部分において、西海岸のMySQLクラスタへの情報書き込みに依存する東海岸で稼働しているアプリケーションは、現在、全国規模の往復移動による遅延の増加を処理できません。その結果、多くのユーザーがサービスを利用できなくなっています。しかしながら、ユーザーデータの一貫性を確保するためには、サービス低下期間の延長が必要であると考えています。

10月21日 23:19 UTC

データベースクラスターのステータスを照会した結果、プッシュ通知などの操作に関するメタデータを書き込むタスクの実行を停止する必要があることが明らかになりました。そこで、Webフックの配信とGitHub Pagesのビルドを一時停止し、ユーザーから既に受信しているデータを危険にさらすよりも、ウェブサイトの可用性を部分的に低下させることにしました。つまり、ウェブサイトの可用性や復旧時間よりも、データの整合性の方が重要だったのです。

10月22日 00:05 UTC

インシデント対応チームのエンジニアは、データの不整合を解決するための計画の策定を開始し、MySQLのフェイルオーバー手順を実装しました。ステータスを更新し、内部データストレージシステムの制御されたフェイルオーバーを実行することをユーザーに通知しました。

MySQLデータは4時間ごとにバックアップされ、長年保持されますが、バックアップはリモートのパブリッククラウドストレージサービスに保存されます。数テラバイト規模のバックアップデータの復元には数時間を要し、その大部分はリモートバックアップサービスからのデータ転送に費やされました。膨大なバックアップファイルの解凍、チェックサム計算、準備、そして新しく構成されたMySQLサーバーへのロードに、ほとんどの時間が費やされました。

10月22日 00:41 UTC

影響を受けたすべてのMySQLクラスタのバックアップが開始されました。その間、複数のエンジニアリングチームが、ウェブサイトの可用性をさらに低下させたり、データ破損を引き起こしたりすることなく、転送と復旧時間を最小限に抑えるよう尽力しました。

10月22日 06:51 UTC

東海岸のデータセンターでは、複数のクラスタがバックアップからの復旧を完了し、西海岸からの新しいデータのレプリケーションを開始しました。これにより、全国規模のリンクを介して書き込み操作を実行するページのウェブサイトの読み込み速度が低下しましたが、これらのデータベースクラスタからデータを読み取るページは、新しく復旧したコピーに対して読み取り要求が発生した場合、最新の結果を返しました。その他の大規模なデータベースクラスタは現在も復旧中です。

10月22日 11:12 UTC

すべてのプライマリデータベースは東海岸で再構築されました。書き込みがアプリケーション層と同じ物理データセンター内のデータベースサーバーにルーティングされるようになったため、ウェブサイトの応答時間が非常に遅くなっています。多くのデータベースのリードレプリカは依然としてプライマリデータベースより数時間遅れており、ユーザーに提供するデータの整合性が取れていない状態です。読み取り負荷を大規模なリードレプリカプールに分散しているため、サービスへのリクエストはそれぞれ、数時間遅れているリードレプリカに「ヒット」する可能性が非常に高くなります。

10月22日 13:15 UTC

この時点で、GitHub.com のトラフィック負荷はピークに近づいていました。レプリケーションのレイテンシは徐々に減少するどころか、増加していました。そこで、東海岸のパブリッククラウド上に MySQL リードレプリカを追加設定し始めました。

10月22日 16:24 UTC

レプリカの同期が完了した後、レイテンシと可用性の問題を解決するために元のトポロジに戻しました。バックログデータの処理を開始する間、サービスを赤色アラート状態に保ちました。

10月22日 16:45 UTC

サービスの可用性をできるだけ早く100%に戻すには、データバックログの増加した負荷をより均等に分散する必要がありました。キューには500万件以上のフックイベントと8,000件以上のページが構築されていました。

このデータを再処理している際に、内部TTLの超過によりドロップされたWebフックペイロードが約20万件発生しました。この問題を発見したため、処理を一時停止し、TTLを一時的に増加しました。

状態更新の信頼性にさらなる影響を与えないようにするために、バックログ データがすべて処理され、サービスが明らかに通常のパフォーマンス レベルに戻るまで、パフォーマンス低下の状態が続きます。

10月22日 23:03 UTC

保留中のウェブフックとページビルドはすべて完了し、すべてのシステムの整合性と正常な動作が検証されました。ウェブサイトのステータスは緑色に更新され、正常に動作していることを示しています。

結論

皆様のプロジェクトや企業がGitHubをどれほど信頼しているか、私たちは理解しています。サービスの可用性とデータの正確性は、私たちにとって何よりも重要です。皆様により良いサービスを提供し、信頼にお応えできるよう、今回のインシデント分析を継続してまいります。