GitHubのインシデント分析がサービスの信頼性を改善する方法を示す

2018年10月21日、GitHubユーザは、GitHubのメタデータの保存に使われるMySQLトポロジに影響を与えたインシデントが原因で、24時間のサービス低下を経験した。日常のメンテナンス作業が原因のインシデントにより、古くて一貫性のない情報が表示され、24時間、ウェブフックと他の内部サービスが利用できなくなった。GitHubの事後インシデントレポートは、どこで問題が起きたかを示し、サイト信頼性を改善する解決策を述べている。

インシデントの原因は、GitHubエンジニアのJason Warner氏が書いた通り、故障した100GB光学装置の置き換えだった。この時に、GitHub US東海岸ハブとプライマリUS東海岸データセンタ間の接続が、短時間、切断された。43秒間の切断により、US東海岸データセンタは、US西海岸へ複製されていない書き込みを受け取った。同時に、GitHubがMySQLクラスタトポロジを管理し、自動フェイルオーバを扱うために使うOrchestratorが、ネートワークパーティションを検出し、ネットワークトポロジを再編成した。そのためすべての書き込みトラフィックは、US西海岸データセンタにリダイレクトされた。

GitHubエンジニアたちが起きていることを理解した時には、2つのデータセンタは分裂し、通常のオペレーションを復元するために同期するのは簡単ではなかった。

このがんばりは困難なものでした。この時点で、西海岸のデータベースクラスタは、ほぼ40分間、アプリケーション層からの書き込みを受け入れていました。さらに、東海岸クラスタに存在する書き込みが数秒間ありました。この書き込みは、西海岸へ複製されず、東海岸に新たに書き込みを返す複製を妨げていました。

さらに問題を複雑にしたのは、GitHubサービスが正確に動かず、国をまたがる待ち時間が増加したために、多くのアプリケーションが動かなくなったことだ。この時点で、GitHubエンジニアたちは、サービスの可用性よりも、データの機密性と完全性を優先することを決めた。そのため、ウェブホックデリバリとPagesを一時停止して、データリカバリに向けて、長い道のりを進んだ。これらは、バックアップからの復元、レプリカの同期、そして、最後には、キューに入ったジョブの再開という3つのステップで実行された。

バックアップからの復元は、数時間かかった。ほとんどは、データの解凍、チェックサム、そして、数テラバイトのデータをロードするためだ。約8時間後に復元が完了し、ネットワークトポロジが安定すると、GitHubのパフォーマンスが改善し始めた。しかし、まだ古いデータを持った数十のレプリカがあり、多くのユーザは、一貫性のないデータを見ていた。

私たちは、大きな読み込みレプリカへ読み込みのロードを分散しました。サービスに対するそれぞれのリクエストは、数時間遅れている読み込みレプリカに当たる可能性がありました。

レプリカが最新データに追いつくようにスピードをあげるため、GitHubエンジニアたちはレプリカの数を増加させた。そのため、集まった読み込みトラフィックは、レプリカ間でより等しく分離することができた。

GitHubエンジニアたちがリカバリフェーズで取り組まなければならない、さらなる問題は、キューに入ったウェブフックとPagesのバックログによって現れる増加したロードを処理することだった。それらは、5百万フックイベントと8万Pagesのビルドに達していた。結局、GitHubの状態は、インシデントが発生してから24時間をわずかに過ぎて、問題がなくなった。

このプロセス全体を通して、GitHubエンジニアたちは、実施しなければならない技術的な新提案を多数特定した。

• リージョンの境界間でOrchestratorがデータベースプライマリを促進することを防ぐ。

  リージョン内のリーダーの選択は、通常、安全ですが、突然入り込んだ、国にまたがる待ち時間が、このインシデントの間の主な要因でした。

• ファシリティレベルで、N+1の冗長性をサポートするために、アクティブ/アクティブ/アクティブ設計で、GitHubデータセンタをリエンジニアリングする。ユーザに影響を与えずに、データセンタの完全な停止に耐えられるようにすべきだ。

• フォルトインジェンクションとカオスエンジニアリングツールにさらに投資する。

最後に、この記事を書いている時点において、データは完全に復旧していない。US西海岸データセンタと同期しなかったUS東海岸の2、3秒のために、GitHubは、どの書き込みを一致させられるか、また、影響を受けたどのユーザに連絡を取る必要があるかを理解するために、現在、MySQLのログを解析している。