主要ネットワーク接続の43秒間の停止により、GitHubのサービスが1日間停止した経緯
トム・クレイジット著
GitHub が新しいオーナーの下でこの 1 週間に最初に行ったことの 1 つは、これまでで最も詳細な障害レポートの 1 つに最後の仕上げを施すことでした。
世界中の何百万人もの開発者が日々ソフトウェア開発に利用しているGitHubは、先週、定期メンテナンスの不具合により、日曜の夕方から月曜の朝にかけてかなりの時間、利用不能状態になったと、技術担当シニアバイスプレジデントのジェイソン・ワーナー氏が詳細な障害報告書の中で述べています。この接続の途絶はすぐに回復しましたが、GitHubのエンジニアは、この障害によってユーザーデータの一貫性が失われていることにすぐに気づき、連鎖的な問題を引き起こしました。
「今回の件で皆様のご期待に応えられず、深くお詫び申し上げます」とワーナー氏は、マイクロソフトによる75億ドルの買収完了から数日後に記した。「GitHubのプラットフォームが長期間利用できなくなったことで生じた問題を帳消しにすることはできませんが、今回の件に至った経緯、そこから得た教訓、そしてこのような事態が二度と起こらないよう企業として講じている対策についてご説明することはできます。」
ワーナー氏が分刻みで説明する状況の展開とGitHubのエンジニアたちが復旧に奔走した経緯を理解するのに、運用やデータベースの専門家である必要はありませんが、ある程度の知識があれば理解できるでしょう。ワーナー氏によると、GitHubは基本的に、ユーザーデータの一部が破壊される可能性もある迅速な復旧か、時間はかかるものの全てのデータを守る復旧プロセスのどちらかを選ばざるを得なかったとのことです。
GitHubの東海岸ネットワークハブと東海岸のプライマリデータセンター間の接続が43秒間途絶えた際、コンピューターとスタッフは迅速に対応し、GitHubユーザーが作成中の新規データが西海岸のデータセンターにフェイルオーバーされるようにしました。しかし、東海岸のデータセンターに書き込まれていた少量のデータが西海岸のデータセンターに複製されていませんでした。つまり、ユーザーデータは異なるデータセンター間で異なる状態に存在し、どちらのデータセンターも完全な正確な状況を把握できていなかったのです。
これは問題です。データ損失を防ぐ唯一の解決策は、バックアップからユーザーデータを再構築することでしたが、これには非常に時間がかかり、東海岸で実行されているアプリケーションはデータベースに情報を書き込むために太平洋岸まで移動しなければならなくなったため、そのプロセス中にサイトのパフォーマンスが低下するのは避けられませんでした。
これによりユーザーは不満を抱き、修正にどのくらいの時間がかかるのかを何度も曖昧に伝えようとしたことで、事態はさらに悪化しました。
「インシデント発生中、皆様に有益な情報をお伝えしたいという思いから、バックログデータの処理速度に基づいて、復旧までの所要時間について複数の公開見積もりを行いました。振り返ってみると、その見積もりはすべての変数を考慮していませんでした」とワーナー氏は述べています。
GitHubは、今回のインシデントを検証し、インフラの意思決定プロセスとインシデント対応手順について何が学べるかを検討しています。ワーナー氏は、今回のような長時間の障害が再び発生しないように、カオスエンジニアリングなどの新たなレジリエンス（回復力）コンセプトの導入に投資する予定だと述べました。
ワーナー氏とGitHubの透明性は称賛に値します。これはクラウドエンジニアリングに関わるすべての人にとって有益です。また、これはGitHubがMicrosoft傘下の初期段階において、顧客と開発者の関係構築に非常に慎重になる兆候でもあります。Microsoftは最近までソフトウェアコミュニティでかなり嫌われていました。
