GitHubが障害を総括、43秒間のネットワーク断が1日のサービス障害につながった：データベースの不整合解消に時間
GitHubは2018年10月30日（米国時間）、2018年10月21日16時頃（米国太平洋時）から約24時間にわたって発生した障害に関する分析報告を、同社のブログに掲載した。これによると、ネットワーク機器の部品交換で生じた43秒のネットワーク接続断が、GitHubのメタデータ管理データベースの不整合を引き起こし、復旧に時間を要したという。
GitHubは2018年10月30日（米国時間）、2018年10月21日16時頃（米国太平洋時）から約24時間にわたって発生した障害に関する分析報告を、同社のブログに掲載した。これによると、ネットワーク機器の部品交換で生じた43秒のネットワーク接続断が、GitHubのメタデータを管理するデータベースの不整合を引き起こし、復旧に時間を要したという。
GitHubはGitのリポジトリデータ以外のメタデータ、すなわちイシュー、プルリクエスト、コメント、通知、認証情報などの管理に、MySQLを使っている。
このMySQLデータベースは下図の通り、米国東部、米国西部の2つのデータセンターにまたがって展開されている。github.comおよびアプリケーションは、米国東部のデータセンターにある。このため平常時は、MySQLについても米国東部のデータセンターで複数のマスターが動いており、同データセンターおよび米国西部データセンターにおける多数のインスタンスが、スレーブ／リードレプリカとして動いている。
障害の発端は、10月21日に通常作業の一環として、米国東部のネットワークPOPを米国東部データセンターに接続するネットワーク機器の100Gbps光モジュールを交換したことだった。これで43秒間、接続が途切れた。
短い接続断を受け、GitHubの運用しているデータベースオーケストレータ―機能が、米国西部データセンターのMySQLデータベースインスタンスを、新たなリーダーに昇格させた。これに基づき、接続が復旧後、アプリケーションは全てのMySQLアクセストラフィックを、米国西部データセンターに転送し始めた。
また、オーケストレータ―機能は米国東部の接続が復旧しているにもかかわらず、同データセンターのMySQLデータベースインスタンスをスレーブ／リードレプリカとして認識せず、米国西部データセンターで完結したデータベーストポロジーを構成した。
米国東部の旧マスターデータベースには、米国西部のMySQLが新たなマスターになるまでに複製ができなかった少量のデータが残っていた。逆に、米国西部のマスターおよびリードレプリカには、米国東部のMySQLデータベースインスタンスにはない、新しいデータが蓄積されていった。この時点で、米国東部への安全なフェイルバックが簡単にはできない状況になっていた。
これに関連して、GitHubは今回、事後分析の結論の1つとして、地理的に離れた2つのデータセンターにまたがってマスターセレクションを行う設定をやめると表明した。
「オーケストレータ―の振る舞いは、設定の通りだった。ただし、アプリケーション層がこのトポロジー変更に対応できなかった。リージョン内でリーダーセレクションを行うのが一般的には安全だ。だが、今回のインシデントで大きな影響をもたらしたのは、突然に、国をまたがる遅延が発生したことだった。私たちがこれまでに経験したことのないネットワーク上の不整合が生じたことからすると、これはシステムの緊急的な振る舞い（として当然）だった」
ユーザーデータの整合性を確保するために、復旧が長引いた
データベースの不整合が発覚した後、復旧に約1日近くを要したのは、ユーザーのデータを失うことなく、秘匿性を保ちながら完全に復旧することを最優先したからだという。
GitHubの復旧に向けてのアプローチは、まず米国東部のマスターデータベースをバックアップからリストアし、次に2データセンターにおける全てのデータベースを同期させる。その上でフェイルバック、すなわち米国東部にマスターを戻すことだった。
ところがまず、クラウドサービスにバックアップしていた数テラバイトのデータを転送し、リストアのために準備するだけでも、数時間が掛かったという。
「リストアの手順は日常的に検証してきた。従ってリカバリに要する時間についてもよく知っていた。しかし、これまで、データベースクラスタをバックアップから完全に再構築する必要が生じたことはなかった。遅延レプリカのような、他の方法で対処できていた」
次に米国西部のマスターから、リストアしたばかりの米国東部マスターに対し、新たなデータの差分を同期する作業を行った。このプロセスも、WANを介しているため、相応の時間が掛かった。
米国東部マスターの同期作業が完了した後、サービスのパフォーマンスは全般的に改善したが、米国東部の全リードレプリカが最新の情報に追い付くまでに、その後数時間が掛かった。これにより、ユーザーに古い情報が示される事象が発生した。
全リードレプリカの同期が完了した後、マスターを米国東部に戻すフェイルバックの作業を実施。これを踏まえて、GitHubと連携しているパートナーからのAPIアクセス受け付けを再開。さらに確認作業の後、サービスのステータスを正常に戻したという。
結果としてデータはほとんど失われなかったが、前述の、米国東部から米国西部への複製が行われていなかった954の書き込みについては、同社が取得しているログから自動的に復旧が可能か、ユーザーに通知する必要があるかについて、検討しているという。
今回の障害で、サイトリライアビリティに関する考えが変わった
GitHubは今回のサービス障害を受け、次のような対策を講じるとしている。
- 地理的に離れた2つのデータセンターにまたがってマスターセレクションを行う設定をやめる
- サービスステータス表示の方法を改める。「緑」「黄」「赤」だけでなく、サービスの種類に応じ、より詳細な情報を表示するようにする
- GitHubは障害発生の数週間前から、データセンターを1カ所失っても問題がないように、N+1の新たなサービスデリバリアーキテクチャを構築する取り組みを始めている。この取り組みを加速する
- サービスに関する同社の数々の前提をあらためて検証すべく、自律的に動いていく
今回の障害により、サイトリライアビリティについての考え方が変わったと、GitHubは述べている。意図的な障害発生、あるいはChaos Engineeringを通じて、障害が発生する前に、発生する可能性のあるシナリオを検証する、システマチックな手法を確立していきたいという。
Copyright © ITmedia, Inc. All Rights Reserved.