エンタープライズITチームがGoogleCloudの6月の停止から何を学ぶことができるか：ガイド

2019年6月初旬、Google Cloud 一連のカスケード障害に苦しんだこれにより、複数のサービスリージョンが数時間利用できなくなりました。

これ自体はまったく前例のないことではありません。それを重要なものにしたのは、それを含むように設計されたソフトウェアそのものを介して伝播する方法でした。さらに、この問題を修正するためのエンジニアの最初の試みは、同じソフトウェアアーキテクチャの失敗によって妨げられました。停止の原因となったのは、Googleの管理コンポーネントの相互接続性と相互依存性でした。

停止

この状況をより完全に理解するために、以下は何が起こったかの簡単な要約です。通常はそれほど大したことではないメンテナンスの「イベント」がGCPのネットワークコントロールプレーンで反応を引き起こし、そのコードの障害によってさらに悪化し、Googleのインフラストラクチャの他の場所で他のジョブを停止できるようになりました。

クラウドプラットフォームの分散性は、あるエリアのクラスターが別のエリアのクラスターから独立して維持されるように設計されているにもかかわらず、それらの管理プロセスがリージョン間でリークすると、障害がウイルスのように広がることを意味します。また、これらのコントローラーはクラウド全体にトラフィックをルーティングする役割を果たしているため、多くのコントローラーがオフになると、ネットワークトラフィックがさらに制限され、さらに多くの障害が発生します。技術用語で：

ネットワークコントロールプレーンジョブは、複数のリージョンにまたがる複数のクラスターで同時に停止されました
複数の地域で同時にパケット損失とエラー率が増加
その結果、主要なネットワークルートが利用できなくなり、特定のサービスのネットワーク遅延が増加しました
ツールトラフィックがサービストラフィックと競合したため、問題をトラブルシューティングするためのツールが使用できなくなりました

根本原因が特定されたら、障害を修正するには、管理パスを解明して、適切なプロセスを適切な順序でオフラインにし、必要な修正を適用する必要がありました。

Googleのエンジニアは、最初にメンテナンスジョブの実行を担当する自動化ツールを無効にしました
サーバークラスター管理ソフトウェアが更新され、他のクラスターに影響を与える可能性のあるリスクの高いリクエストを受け付けなくなりました。
構成をローカルに保存するための更新が行われ、システムを自動的に再構築することによって発生する遅延を回避することで、リカバリ時間を短縮しました
ネットワーク障害-静的条件が拡張され、エンジニアがエラーを軽減するためのより多くの時間を確保できるようになりました
ネットワークが混雑している場合でも、影響を受ける顧客にステータスを伝えるためのツールが改善されました

最終的には、問題に対処するGoogleの意欲や能力に問題があるのではなく、プラットフォームが予期しないイベントにどのように反応するかという体系的な問題に問題がありました。リアルタイムコンピューティング環境では、最初のシステムに修正を適用するために使用される他のシステムにある別の問題を修正するために、管理システムをオフラインにできる余裕はありません。

では、これは現代のITについて何を教えてくれるのでしょうか。これは、ポイントツールよりもプラットフォームに偏って、フットプリントとインフラストラクチャ全体で運用を一元化する必要があるという理論を証明しています。最新のIT運用戦略に必要な3つの特定の機能は次のとおりです。

ローカルアクションのグローバルビュー。分散インフラストラクチャのグローバルビューを持つことは重要です。問題に単独で対処することは、現在テストされていない領域に障害を伝播する可能性があります。管理データを集約するには、すべての地域に同時に観測点を作成する必要があります。これにより、統合された分析が可能になり、異種のイベントが複雑になるのを防ぐことができます。これは、インフラストラクチャ全体のアクティビティを理解することにより、グローバルサービスパフォーマンスモデルを構築するのにも役立ちます。また、システムが応答しなくなったときに管理タスクがどのように実行されるかを考慮する必要があります。ツールトラフィックをサービストラフィックから保護し、運用データとシステムステータス/イベントの間でネットワーク容量を共有しないでください。
インパクトをインパクトよく見る能力。企業は、グローバルな影響モデルを設計する必要があります。 IT運用担当者は、変更を加える前に、トポロジ主導の影響を理解する必要があります。自動化された変更であってもです。 Googleの自動化は影響モデルを考慮せず、代わりに、間違いを自動的にスケーリングする、ポリシー主導の直接的な自動化でした。トポロジマッピングを介してサービスの依存関係を理解することも同様に重要です。これにより、影響分析でポリシー主導の自動化のカスケード効果を考慮に入れることができます。
信頼できる構成ストア。 最後に、分散階層に依存するのではなく、構成データをローカルに保存することで「バックアップをバックアップ」することで、サービスの復元時間を短縮できます。障害時に競合するネットワークトラフィックによって管理タスクに使用できる帯域幅が制限されるため、このデータを地域ごとに取得すると、回復の待ち時間が長くなります。

この停止は、本質的に、避けられないサービスの中断に備えていると考えているあらゆる場所のエンタープライズクラスのIT運用チームへの贈り物でした。依存関係と影響の単一のグローバルビューを含むIT運用管理戦略を構築することのすべての価値を教えてくれました。すべての企業は、Googleになりたいと考えています。しかし、これはあなたがしない1つの方法です。