Google App Engineデータセンターの停電のタイムライン

お住まいの場所で電気が切れた場合、コンピューターに重大な影響はほとんどありません。 もちろん、電源が切れたり、ドライブが覆われたりする可能性があります-これは不快ですが、致命的ではありません。 しかし、数十万人のユーザーにサービスを提供する大規模なデータセンターで電力が遮断された場合はどうなりますか？







2月24日に、 Google App Engineが稼働していたデータセンターの電源が切れました。 2時間以上、App Engineは使用できませんでした。 この事件の完全な報告はメーリングリストで見つけることができ、失敗履歴の翻訳といくつかの結論は以下で見つけることができます。



早朝



午前7時48分 モニタリングチャートは、メインデータセンターにいくつかの問題があり、エラーの数が着実に増加していることを示し始めています。 ほぼ同時に、App Engineへのアクセスに関する問題に関するユーザーからのメッセージがメーリングリストに表示されます。



7:53 サイト信頼性エンジニアは、メインデータセンターの電源が失われたことを担当する多数のエンジニアにメッセージを送信します。 この場合のデータセンターにはバックアップジェネレーターがありますが、この場合、データセンター内のマシンの約25％が時間通りにバックアップ電源を受け取らず、低下しました。 この時点で、当直のエンジニアがポケットベルへの信号を受信しました。



8:01 この時点で、勤務中のエンジニアは障害の量を判断し、App Engineが機能していないと判断しました。 この手順に従って、彼はユーザーに障害を通知する必要性について製品管理者とエンジニアリング管理者に警告しました。 数分後、App Engineチームからの最初のメッセージ（「この問題を調査中です」）がメーリングリストに表示されます。



8:22 分析後、データセンターの電源は復旧しましたが、多くのマシンはシャットダウン後も存続せず、トラフィックを処理できません。 特に、GFSおよびBigtableクラスターは、多数のマシンが失われたために誤動作状態にあるため、データストア（Datastore）はメインデータセンターで使用できません。 デューティエンジニアのチームが、代替データセンターへの緊急移動について話し合います。 突然の停止の手順に従って緊急操作を実行することが決定されます。



8:36 App Engineチームは、追加の停止メッセージをappengine-downtime-notifyグループとApp Engineステータスサイトに送信します。



8:40 メインデューティエンジニアは、2つの矛盾する手順を発見します。 これは、データストアの再配置による運用プロセスの最近の変更の結果です。 勤務中の他のエンジニアとの議論はコンセンサスに至らず、エンジニアは手順を変更する責任者と状況を解決しようとしています。



8:44 a.m. 誰もがどの緊急手順が正しいかを把握しようとしている間、勤務中のエンジニアは読み取り専用モードのトラフィックを代替データセンターに転送しようとしています。 トラフィックは変換されますが、この手順での予期しない構成の問題により、正しく機能しません。



9:08 。 さまざまなエンジニアが、代替データセンターの読み取り専用トラフィックの問題の診断に関与しています。 ただし、その間、メインデューティエンジニアは、メインデータセンターが回復し、作業を続行できると考えるようになるデータを受け取ります。 しかし、エンジニアはこの決定を行うための明確な指示を持っていなかったため、この時点で回復する可能性は低いと考えられます。 サービスを復元しようとして、トラフィックはメインデータセンターに戻されますが、他のエンジニアは代替データセンターの読み取り専用トラフィックの問題を調査し続けます。



9:18 a.m. メインデューティエンジニアは、メインデータセンターが復旧せず、トラフィックを処理できないことを確認します。 この時点で、信号が偽であり、メインデータセンターがまだ動作していないこと、および代替手順および緊急時の手順に集中する必要があることは、勤務エンジニアにとって明らかでした。



9:35 a.m. 緊急時の手順に精通したエンジニアと連絡を取り、プロセスを主導し始めます。 トラフィックは代替DCに転送されます。最初は読み取り専用モードです



9:48 a.m. 読み取り専用モードで代替DCから外部ユーザーへのサービスを開始します。 読み取り専用期間で正しく動作するアプリケーションは、機能が切り捨てられていても、この時点で正しく動作するはずです。



9:53 現在、オンラインで適切なエンジニアと相談した後、緊急時手順の正しい文書が明確化および確認され、勤務エンジニアが使用できるようになりました。 読み書きの緊急転送の実際の手順が開始されます。



10:09 a.m. 緊急手順は問題なく終了します。 サービストラフィックは、読み取りと書き込みのために、通常モードで復元されます。 この時点で、App Engineは動作していると見なされます。



10:19 a.m. AppEngineが正常に動作していることを示すメッセージがappengine-downtime-notifyリストに送信されます。



息を吐くことができます。



偉大なジョエルが遺贈したように、 バックアップについて話すのはやめて 、復元について話しましょう。 迷惑が発生した場合、スムーズに連携するには多くのギアが必要です。 まず、監視システム（何ですか？監視システムとは何かわかりませんか？残りのギアについてはおそらく考えられないでしょう）は、トラブルの発生から数分後に通知します。 第二に、予備の容量が必要です。 第三に、これらの予備能力の使用方法を正確に知っているか、正確な指示が必要です。 App Engineチームが1つの（正しい）ドキュメントセットを持っている場合、停止は2時間ではなく20分しか続きません。



しかし、私の意見では、App Engineは問題を悪くなく処理しました。 「おはよう、友人！」というメッセージがポケットベルに表示されるエンジニアの場所にいると想像してください。 今、あなたの会社は数百ドルのお金を失い、神はどれだけの評判を知っています。 そして、これはあなたの問題です。 頑張って！」