致命的な43秒。これにより、サービスが毎日低下します。



先週GitHubで、24時間11分間サービスを低下させるインシデントが発生しました。 インシデントはプラットフォーム全体に影響を与えるのではなく、少数の内部システムのみに影響を及ぼし、時代遅れで一貫性のない情報が表示されました。 最終的に、ユーザーデータは失われませんでしたが、データベースへの書き込みの数秒の手動調整はまだ進行中です。 クラッシュのほとんどについて、GitHubはwebhookの処理、GitHubページの作成と公開もできませんでした。



GitHubの皆さんは、皆さんが遭遇した問題について心から謝罪したいと思います。 GitHubに対するお客様の信頼を知っており、プラットフォームの高可用性をサポートする持続可能なシステムを作成できることを誇りに思っています。 私たちはあなたをこの事件に失望させ、深く後悔しています。 GitHubプラットフォームの長期的な劣化による問題を元に戻すことはできませんが、何が起こったのかを説明し、得られた教訓と、将来このような失敗から会社をより良く保護するための対策について話し合うことができます。

背景

ほとんどのGitHubユーザーサービスは、独自のデータセンターで機能します 。 データセンタートポロジは、コンピューティングおよびデータストレージシステムの作業を提供するいくつかの地域データセンターの前に、信頼性が高く拡張可能な境界ネットワークを提供するように設計されています。 プロジェクトの物理および論理コンポーネントに組み込まれた冗長性レベルにもかかわらず、サイトがしばらくの間相互にやり取りできない可能性があります。



10月21日午後10時52分（UTC）に、100Gの欠陥のある光学機器を交換するための定期修理により、東海岸（米国東海岸）のネットワークノードと東海岸のメインデータセンター間の通信が失われました。 それらの間の接続は43秒後に復元されましたが、この短時間の切断により一連のイベントが発生し、24時間11分でサービスが低下しました。





2つの物理データセンター、3つのPOP、およびピアリングを介して接続されたいくつかの地域のクラウドストレージを含むGitHubの高レベルネットワークアーキテクチャ



過去に、 MySQLを使用してGitHubメタデータを保存する方法と、 MySQLを高可用性にするアプローチについて説明しました。 GitHubは、数百ギガバイトからほぼ5テラバイトまでのサイズの複数のMySQLクラスターを管理します。 各クラスターには、Git以外のメタデータを格納するための多数のリードレプリカがあります。そのため、アプリケーションは、プールリクエスト、問題、認証、バックグラウンド処理、およびGitオブジェクトリポジトリ外の追加機能を提供します。 アプリケーションのさまざまな部分のさまざまなデータは、機能セグメンテーションを使用してさまざまなクラスターに格納されます。



大規模でパフォーマンスを向上させるために、アプリケーションは各クラスターの対応するプライマリサーバーに書き込みを指示しますが、ほとんどの場合、レプリカサーバーのサブセットに読み取り要求を委任します。 Orchestratorを使用してMySQLクラスタートポロジを管理し、自動的にフェールオーバーします。 このプロセス中、Orchestratorは多くの変数を考慮し、一貫性を保つためにRaftの上に組み立てられます。 Orchestratorは、アプリケーションがサポートしないトポロジを実装する可能性があるため、Orchestratorの構成がアプリケーションレベルの期待を満たしていることを確認する必要があります。





典型的なトポロジでは、すべてのアプリケーションが低遅延でローカルに読み取ります。

事件の記録

10.21.2018、22：52 UTC

前述のネットワーク分離の間、メインデータセンターのOrchestratorは、Raftコンセンサスアルゴリズムに従ってリーダーシップの選択を解除するプロセスを開始しました。 西海岸のデータセンターと東海岸のオーケストレーターパブリッククラウドノードは、コンセンサスに達することができました。そして、クラスターの障害を解決し、西部のデータセンターにレコードを転送し始めました。 Orchestratorは、西部でデータベースクラスタートポロジの作成を開始しました。 再接続後、アプリケーションはすぐに書き込みトラフィックを米国西部の新しいプライマリサーバーに送信しました。



東部のデータセンターのデータベースサーバーでは、西部のデータセンターに複製されていない短い期間のレコードがありました。 両方のデータセンターのデータベースクラスターには、他のデータセンターにないレコードが含まれているため、プライマリサーバーを安全に東部のデータセンターに戻すことができませんでした。

10.21.2018、22：54 UTC

当社の内部監視システムは、多数のシステムの誤動作を示すアラートを生成し始めました。 この時点で、数人のエンジニアが応答し、着信通知のソートに取り組みました。 23:02までに、最初の応答グループのエンジニアは、多数のデータベースクラスターのトポロジが予期しない状態にあると判断しました。 Orchestrator APIを照会すると、データベースレプリケーショントポロジが表示され、ウエスタンデータセンターのサーバーのみが含まれていました。

10.21.2018、23：07 UTC

この時点で、対応チームは、追加の変更を防ぐために内部展開ツールを手動でブロックすることにしました。 23:09に、グループはサイトを黄色に設定しました。 このアクションにより、状況にアクティブなインシデントのステータスが自動的に割り当てられ、インシデントコーディネーターに警告が送信されました。 23:11にコーディネーターが作業に参加し、2分後にステータスをredに変更することにしました。

10.21.2018、23：13 UTC

当時、この問題がいくつかのデータベースクラスターに影響を与えていることは明らかでした。 データベースのエンジニアリンググループの追加の開発者が作業に関与しました。 彼らは、米国東海岸のデータベースを各クラスターのプライマリとして手動で構成し、レプリケーショントポロジを再構築するために実行する必要があるアクションを決定するために、現在の状態を調べ始めました。 この時点では、ウエスタンデータベースクラスターがほぼ40分間アプリケーション層からレコードを受信して​​いたため、これは簡単ではありませんでした。 さらに、東のクラスターでは、西に複製されず、新しいレコードを東に複製することを許可しなかった数秒のレコードがありました。



ユーザーデータのプライバシーと整合性を保護することは、GitHubの最優先事項です。 したがって、西部のデータセンターに記録された30分以上のデータにより、このデータを保存するための状況に対する解決策は1つだけであると判断しました。 ただし、西部のMySQLクラスターへの情報の書き込みに依存している東部のアプリケーションは、現在、ほとんどのデータベース呼び出しのやり取りによる追加の遅延を処理できません。 この決定は、私たちのサービスが多くのユーザーにとって不適切になるという事実につながります。 サービス品質の長期的な低下は、ユーザーのデータの一貫性を確保するための努力に値すると考えています。





間違ったトポロジでは、西から東へのレプリケーションに違反し、トランザクションパフォーマンスを維持するために低レイテンシに依存しているため、アプリケーションは現在のレプリカからデータを読み取ることができません

10.21.2018、23：19 UTC

データベースクラスターの状態に関する問い合わせから、プッシュリクエストなどのメタデータを書き込むタスクの実行を停止する必要があることがわかりました。 ユーザーから既に受け取ったデータを危険にさらさないように、選択を行い、意図的にサービスの部分的な低下、ウェブフックおよびGitHubページのアセンブリの中断を行いました。 言い換えれば、戦略は優先順位を付けることでした：サイトの使いやすさと迅速な回復の代わりにデータの整合性。

10/22 / 2018、00：05 UTC

応答チームのエンジニアは、データの不整合を解決する計画の開発を開始し、MySQLのフェイルオーバー手順を開始しました。 計画では、バックアップからファイルを復元し、両方のサイトでレプリカを同期し、安定したサービストポロジに戻り、キュー内のジョブの処理を再開しました。 ステータスを更新して、内部ストレージシステムの管理されたフェールオーバーを実行することをユーザーに通知します。





回復計画には、前進、バックアップからの復元、同期、ロールバック、グリーンステータスに戻る前の遅延の解消が含まれます。



MySQLのバックアップは4時間ごとに作成され、長年にわたって保存されますが、Blobオブジェクトのリモートクラウドストレージに保存されます。 バックアップから数テラバイトのリカバリには数時間かかりました。 リモートバックアップサービスからデータを転送するのに長い時間がかかりました。 ほとんどの時間は、アンパック、チェックサムのチェック、大きなバックアップファイルの準備、新たに準備されたMySQLサーバーへのアップロードのプロセスに費やされました。 この手順は毎日テストされるので、誰もが回復にどれくらいの時間がかかるかをよく知っていました。 ただし、このインシデントの前に、バックアップからクラスター全体を完全に再構築する必要はありませんでした。 遅延レプリカなど、他の戦略は常に機能しています。

10/22 / 2018、00：41 UTC

この時点で、影響を受けるすべてのMySQLクラスターのバックアッププロセスが開始され、エンジニアは進捗状況を追跡しました。 同時に、複数のエンジニアグループが、サイトのさらなる劣化やデータ破損のリスクなしに転送と復旧を高速化する方法を研究しました。

10/22 / 2018、06：51 UTC

東部データセンターのいくつかのクラスターは、バックアップからの復元を完了し、西海岸からの新しいデータの複製を開始しました。 これにより、国全体で書き込み操作を実行したページの読み込みが遅くなりましたが、これらのデータベースクラスターからの読み取りページは、読み取り要求が新しく復元されたレプリカに届いた場合、実際の結果を返しました。 他の大規模なデータベースクラスターは引き続き回復しました。



私たちのチームは、外部ストレージからの起動に起因する帯域幅の制限を克服するために、西海岸から直接復旧方法を特定しました。 回復が正常に完了することはほぼ100％明らかになり、正常なレプリケーショントポロジを作成する時間は、キャッチアップレプリケーションの所要時間によって異なります。 この推定値は、利用可能なテレメトリレプリケーションに基づいて線形補間され、ステータスページが更新されて、2時間の待機が推定回復時間として設定されました。

10/22 / 2018、07：46 UTC

GitHubが有益なブログ投稿を投稿しました 。 私たちはGitHub Pagesを使用しており、すべてのアセンブリは数時間前に一時停止されたため、追加の作業が必要になりました。 遅延をおaび申し上げます。 私たちはこのメッセージをもっと早く送信するつもりでしたが、将来的にはそのような制限の条件で更新の公開を提供します。

10/22 / 2018、11：12 UTC

すべてのプライマリデータベースが再び東に転送されます。 これにより、アプリケーションレイヤーと同じ物理データセンターにあるデータベースサーバーにレコードがルーティングされるようになり、サイトの応答性が大幅に向上しました。 これによりパフォーマンスは大幅に向上しましたが、メインコピーから数時間遅れてデータベースを読み取るレプリカがまだ何十もありました。 これらの遅延レプリカにより、ユーザーはサービスとやり取りするときに一貫性のないデータを見ることになります。 読み込みレプリカの大きなプールに読み込み負荷を分散します。サービスへの各リクエストには、数時間の遅延で読み込みレプリカに入る可能性が高くなります。



実際、遅延レプリカのキャッチアップ時間は、線形ではなく指数関数的に短縮されます。 データベースクラスター内のレコードの負荷が増加したために、アメリカとヨーロッパのユーザーが目覚めたとき、回復プロセスは予想よりも長くかかりました。

10/22 / 2018、13：15 UTC

GitHub.comのピーク負荷に近づいていました。 対応チームは次のステップについて議論しました。 一貫性のある状態へのレプリケーションラグが減少するのではなく増加することは明らかでした。 以前、東海岸のパブリッククラウドで追加のMySQLリードレプリカの準備を開始しました。 それらが利用可能になると、複数のサーバー間で読み取り要求のフローを分散することが容易になりました。 リードレプリカの平均負荷を減らすと、レプリケーションのキャッチアップが加速しました。

10/22 / 2018、16：24 UTC

レプリカを同期した後、元のトポロジに戻り、遅延と可用性の問題を解消しました。 状況の迅速な修正よりもデータの整合性の優先順位に関する意識的な決定の一環として、蓄積されたデータの処理を開始したとき、サイトの赤い状態を維持しました 。

10/22 / 2018、16：45 UTC

回復段階では、ラグに関連する増加した負荷のバランスをとる必要があり、エコシステムパートナーに通知が過剰になり、可能な限り迅速に100％の効率に戻る可能性がありました。 500万を超えるフックイベントと80,000のWebページ構築リクエストがキューに残りました。



このデータの処理を再度有効にすると、内部TTLを超えてドロップされたWebhookで約200,000の有用なタスクを処理しました。 これについて知ると、処理を停止し、TTLの増加を開始しました。



ステータス更新の信頼性がさらに低下するのを避けるため、蓄積されたデータ全体の処理が完了するまで劣化のステータスを残し、サービスが明らかに通常のパフォーマンスレベルに戻ったことを確認します。

10/22 / 2018、11：03 p.m. UTC

すべての不完全なWebhookイベントとPagesアセンブリが処理され、すべてのシステムの整合性と正しい動作が確認されます。 サイトのステータスが緑に更新されました 。

さらなるアクション

データの不一致の解決

リカバリ中、主にデータセンターのエントリを含むバイナリMySQLログを記録しましたが、これは西側のものには複製されませんでした。 このようなエントリの総数は比較的少ないです。 たとえば、最も忙しいクラスタの1つでは、これらの秒に954レコードしかありません。 現在、これらのログを分析し、どのエントリを自動的に調整でき、どのエントリがユーザーの支援を必要とするかを判断しています。 いくつかのチームがこの作業に参加しており、私たちの分析ではすでにユーザーが繰り返したレコードのカテゴリを特定しており、それらは正常に保存されました。 この分析で述べたように、私たちの主な目標は、GitHubに保存するデータの整合性と正確性を維持することです。

コミュニケーション

インシデント中に重要な情報をお客様に伝えようとして、蓄積されたデータの処理速度に基づいて、復旧時間のいくつかの公的な推定を行いました。 振り返ってみると、推定値はすべての変数を考慮していませんでした。 混乱をおかけして申し訳ありません。今後、より正確な情報の提供を目指します。

技術的対策

この分析の過程で、いくつかの技術的対策が特定されました。 分析が続行され、リストを補足できます。

• Orchestratorの構成を調整して、プライマリデータベースが領域外に移動しないようにします。 Orchestratorは設定に従って機能しましたが、アプリケーションレイヤーはこのようなトポロジ変更をサポートしていませんでした。 通常、地域内のリーダーを選択することは安全ですが、大陸を横断する交通の流れによる突然の遅延の出現が、この事件の主な原因となっています。 これは、この規模のネットワークの内部セクションに遭遇しなかったため、システムの新しい、新しい動作です。
• 新しいステータスレポートシステムへの移行を加速しました。これにより、アクティブインシデントをより明確な言語で議論するためのより適切なプラットフォームが提供されます。 GitHubの多くの部分がインシデント全体で利用可能でしたが、サイト全体の緑、黄、赤のステータスのみを選択できました。 私たちはこれが正確な絵を与えていないことを認めます：何が機能し、何が機能しないか。 新しいシステムには、プラットフォームのさまざまなコンポーネントが表示されるため、各サービスのステータスを把握できます。
• このインシデントの数週間前に、アクティブ/アクティブ/アクティブアーキテクチャを使用して複数のデータセンターからのGitHubトラフィックをサポートするために、企業全体のエンジニアリングイニシアチブを開始しました。 このプロジェクトの目標は、データセンターレベルでN + 1の冗長性をサポートし、外部の干渉なしで1つのデータセンターの障害に耐えることです。 これには多くの作業が必要であり、しばらく時間がかかりますが、さまざまな地域のいくつかの適切に接続されたデータセンターが適切な妥協点を提供すると考えています。 最新の事件はこのイニシアチブをさらに推進しました。
• 前提を確認する際に、より積極的な立場を取ります。 GitHubは急速に成長し、過去10年間でかなりの量の複雑さを蓄積してきました。 妥協や意思決定の歴史的背景を把握し、新世代の従業員に引き継ぐことはますます難しくなっています。

組織的措置

この事件は、サイトの信頼性の理解に大きく影響しました。 運用管理の強化や応答時間の改善は、当社のような複雑なサービスシステムの信頼性を十分に保証するものではないことを学びました。 これらの取り組みをサポートするために、障害シナリオを実際に発生する前にテストする体系的なプラクティスも開始します。 この作業には、意図的に障害を導入し、カオスエンジニアリングツールを使用することが含まれます。

おわりに

プロジェクトやビジネスでGitHubにどのように依存しているかを知っています。 私たちは、サービスの可用性とデータの安全性を誰よりも大切にしています。 この事件の分析は、あなたにより良いサービスを提供し、あなたの信頼を正当化する機会を見つけ続けます。