Fault Analysis Service の概要

  • [アーティクル]

Fault Analysis Service は、Microsoft Azure Service Fabric で構築されたサービスをテストするために設計されています。 Fault Analysis Service を使用すると、アプリケーションに対して意味のある障害を誘発させ、完全なテスト シナリオを実行することができます。 これらのエラーとシナリオでは、サービスがその有効期間中に経験する多数の状態と遷移を、完全に管理された安全で一貫性のある方法で実行して検証します。

アクションは、サービスをテストするための、そのサービスを対象にした個別のエラーです。 サービス開発者は、複雑なシナリオを記述するための構成要素としてアクションを使用できます。 次に例を示します。

  • ノードを再起動して、コンピューターまたは VM がリブートされる状況をシミュレートします。
  • ステートフル サービスのレプリカを移動して、負荷分散、フェールオーバー、またはアプリケーションのアップグレードをシミュレートします。
  • ステートフル サービスでのクォーラムの損失を発生させ、新しいデータを受け入れるための十分な "バックアップ" または "セカンダリ" レプリカがないことが原因で書き込み操作を続行できない、という状況を作ります。
  • ステートフル サービスでのデータ損失を発生させ、すべてのインメモリ状態が完全に消去された状況を作ります。

シナリオは、1 つまたは複数のアクションで構成される複雑な操作です。 Fault Analysis Service では、組み込みの完全なシナリオを 2 つ提供します。

  • 混乱のシナリオ
  • フェールオーバーのシナリオ

サービスとしてテストする

Fault Analysis Service は、Service Fabric クラスターで自動的に開始される Service Fabric システム サービスです。 これは、フォールト挿入、テスト シナリオの実行、正常性分析のホストとして動作するサービスです。

Fault Analysis Service

フォールト アクションまたはテスト シナリオが開始されると、コマンドが Fault Analysis Service に送信され、フォールト アクションまたはテスト シナリオが実行されます。 Fault Analysis Service が確実にフォールトとシナリオを実行し、結果を検証できるように、Fault Analysis Service はステートフルです。 たとえば、Fault Analysis Service を使用すると、実行時間の長いテスト シナリオを確実に実行できます。 また、テストはクラスター内で実行されているため、このサービスではクラスターと自分のサービスの状態を調べて、エラーに関する詳細情報を提供することができます。

分散システムをテストする

Service Fabric を使用すると、スケーラブルな分散アプリケーションを作成する作業が大幅に簡単になります。 同様に、Fault Analysis Service を使用すると、分散アプリケーションのテストが簡単になります。 テスト時に解決する必要がある 3 つの主な問題があります。

  1. 現実世界のシナリオで発生する可能性のある障害のシミュレート/生成: Service Fabric の重要な側面の 1 つに、分散アプリケーションをさまざまな障害から回復できることがあります。 しかし、アプリケーションがこれらの障害から回復できることをテストするためには、制御されたテスト環境で現実世界の障害をシミュレート/生成するメカニズムが必要です。
  2. 相互関係がある障害を生成する機能: ネットワーク障害やコンピューター エラー障害などのシステムの基本的な障害は、個別に生成することは簡単です。 個々のエラーの相互作業の結果として、実際に発生する可能性がある無数のシナリオを生成することは、容易ではありません。
  3. 開発とデプロイのさまざまなレベルでのエクスペリエンスの統合: さまざまな種類の障害を生成できるフォールト インジェクション システムはたくさんあります。 ただし、ワンボックス開発者シナリオを使用して運用環境でのテストを行うことを目的として、同じテストを大規模なテスト環境で実行するには、これらのシステムのエクスペリエンスでは不十分です。

これらの問題を解決するメカニズムはたくさんありますが、ワンボックス開発者環境から運用環境のクラスターでのテストに至るまで、必要な保証を常に提供しながら実行されるシステムはありません。 Fault Analysis Service を使用すると、アプリケーション開発者はビジネス ロジックのテストに集中できます。 Fault Analysis Service は、基盤となる分散システムでサービスの相互作用をテストするために必要なすべての機能を提供します。

現実世界の障害をシミュレート/生成するシナリオ

障害に対する分散システムの堅牢性をテストするには、障害を生成するメカニズムが必要です。 理論上、ノード停止のような障害の生成は簡単なように見えますが、Service Fabric が解決しようとするものと同じ一貫性の問題が発生し始めます。 たとえば、ノードをシャットダウンする場合は、次のようなワークフローが必要です。

  1. クライアントからノードのシャットダウン要求を発行します。

  2. 適切なノードに要求を送信します。

    a. ノードが見つからない場合、要求は失敗する必要があります。

    b. ノードが見つかった場合、要求は、ノードがシャットダウンされた場合にのみ返る必要があります。

この障害をテストの観点から検証するには、障害が誘発されたときに障害が実際に発生したことをテストで知る必要があります。 Service Fabric が提供する保証は、コマンドがアクセスした時点のノードの状態 (ノードはこれから停止されるか、既に停止されていた) です。 どちらにしても、テストでは、状態を正しく判断し、成功か失敗かを正しく検証する必要があります。 Service Fabric の外部で実装される、同様の障害を処理するシステムでは、ネットワーク、ハードウェア、ソフトウェアの問題が多数発生する可能性があり、その結果、前述の保証を提供できないことがあります。 前述の問題が存在する中で、Service Fabric は、クラスターの状態を再構成してこれらの問題を回避します。そのため、Fault Analysis Service は正しい保証を提供できます。

必要なイベントとシナリオの生成

現実世界の障害を常にシミュレートすることは容易ではありませんが、相互関係がある障害を生成することは、さらに難しい処理です。 たとえば、次のような場合、永続化されたステートフル サービスでデータの損失が発生します。

  1. レプリカの書き込みクォーラムだけがレプリケーションで同期された場合。 すべてのセカンダリ レプリカでプライマリに対する遅延が発生している場合。
  2. (コード パッケージまたはノードの停止が原因で) レプリカが停止し、そのために書き込みクォーラムが停止した場合。
  3. (ディスクの破損またはコンピューターの再イメージ化が原因で) レプリカのデータが失われ、そのために書き込みクォーラムを回復できない場合。

これらの相互関係がある障害は、現実の世界で (個別エラーほど頻繁ではないにしろ) 確かに発生します。 このようなシナリオを運用環境で発生する前にテストすることが重要です。 さらに重要なのは、(すべてのエンジニアが勤務している日中の) 制御された状況の中で、これらのシナリオを運用環境のワークロードでシミュレートする能力です。 これにより、運用環境で障害が午前 2 時に初めて発生するような状況を避けることができます。

異なる環境にまたがる統合されたエクスペリエンス

従来は、開発環境、テスト環境、運用環境用に 3 つの異なるエクスペリエンスのセットを作成するのが普通でした。 モデルは次のようなものでした。

  1. 開発環境では、個々のメソッドの単体テストを可能にする状態遷移を生成します。
  2. テスト環境では、障害を生成し、さまざまな障害シナリオを適用してエンド ツー エンドのテストを実行します。
  3. 運用環境を不自然な障害が発生しない状態に保ち、障害に対してきわめて迅速に人間が対応できるようにします。

Service Fabric では、Fault Analysis Service を通して、開発者環境から運用環境まで同じ方法を使用するように変える提案をしています。 これを実現する方法は 2 つあります。

  1. 制御された障害を誘発させるために、1 台のコンピューターの環境から運用環境のクラスターに至るまで、すべての環境で Fault Analysis Service API を使用します。
  2. クラスターで障害を自動的に誘発させるために、Fault Analysis Service を使用して自動障害を生成します。 構成を通して障害の割合を制御すると、同じサービスを異なる環境で異なる方法でテストすることができます。

Service Fabric では、異なる環境で障害の規模が異なっても、実際のメカニズムは同一になります。 これにより、コーディングからデプロイまでのパイプラインが大幅に短縮され、現実世界の負荷でサービスをテストすることができます。

Fault Analysis Service を使用する

C#

Fault Analysis Service 機能は、Microsoft.ServiceFabric NuGet パッケージの System.Fabric 名前空間にあります。 Fault Analysis Service 機能を使用するには、この NuGet パッケージを参照先としてプロジェクトに含める必要があります。

PowerShell

PowerShell を使用するには、Service Fabric SDK をインストールする必要があります。 SDK がインストールされると、ServiceFabric PowerShell モジュールが使用できるように自動的に読み込まれます。

次のステップ

真のクラウド スケール サービスを作成するには、デプロイの前と後の両方で、サービスが現実世界の障害に耐えることができることを保証することが不可欠です。 サービスが主流の今日の世界において、短期間でコードを刷新し実稼働に移すことはきわめて重要です。 Fault Analysis Service は、まさにそれをサービス開発者が実現するために役立ちます。

組み込みのテスト シナリオを使用して、アプリケーションとサービスのテストを開始するか、または、Fault Analysis Service から提供されるフォールト アクションを使用して、独自のテスト シナリオを作成します。