次の方法で共有

Azure でのミッション クリティカルなワークロードのデプロイとテスト

  • [アーティクル]

ミッション クリティカルな環境のデプロイとテストは、参照アーキテクチャ全体の重要な部分です。 個々のアプリケーション スタンプは、ソース コード リポジトリのコードとしてインフラストラクチャを使用してデプロイされます。 インフラストラクチャと上部のアプリケーションの更新プログラムは、アプリケーションのダウンタイムをゼロにしてデプロイする必要があります。 リポジトリからソース コードを取得し、個々のスタンプを Azure にデプロイするには、DevOps 継続的インテグレーション パイプラインをお勧めします。

デプロイと更新が、アーキテクチャの中心的なプロセスになります。 インフラストラクチャとアプリケーション関連の更新プログラムは、完全に独立したスタンプにデプロイする必要があります。 アーキテクチャ内のグローバル インフラストラクチャ コンポーネントのみがスタンプ間で共有されます。 インフラストラクチャ内の既存のスタンプは操作しません。 インフラストラクチャの更新プログラムは、これらの新しいスタンプにのみデプロイされます。 同様に、新しいアプリケーション バージョンも、これらの新しいスタンプにのみデプロイされます。

新しいスタンプが Azure Front Door に追加されます。 トラフィックは徐々に新しいスタンプに移動されます。 新しいスタンプから問題なくトラフィックが提供されていると判断されると、前のスタンプは削除されます。

デプロイされた環境には、侵入、混乱、ストレス テストをお勧めします。 インフラストラクチャの事前テストでは、弱点が検出されるほか、エラーが発生した場合にデプロイされたアプリケーションがどのように動作するかが検出されます。

デプロイ

参照アーキテクチャでのインフラストラクチャのデプロイは、次のプロセスとコンポーネントによって異なります。

  • DevOps - GitHub のソース コードとインフラストラクチャのパイプライン。

  • ダウンタイムなしの更新 - 更新とアップグレードは、デプロイされたアプリケーションのダウンタイムなしで、環境にデプロイされます。

  • 環境 - アーキテクチャに使用される短命の環境と永続的な環境。

  • 共有リソースと専用リソース - スタンプとインフラストラクチャ全体に専用の Azure リソースと共有の Azure リソース。

デプロイ プロセスのフローチャート図。

詳細については、「Azure でのミッション クリティカルなワークロードのデプロイとテスト: デザインに関する考慮事項」を参照してください

デプロイ: DevOps

DevOps コンポーネントでは、インフラストラクチャと更新プログラムをデプロイするためのソース コード リポジトリと CI/CD パイプラインを提供します。 GitHub と Azure Pipelines がコンポーネントとして選択されました。

  • GitHub - アプリケーションとインフラストラクチャのソース コード リポジトリが含まれています。

  • Azure Pipelines - ビルド、テスト、リリースのすべてのタスクにアーキテクチャで使用されるパイプライン。

デプロイに使用される設計の追加コンポーネントが、ビルド エージェントです。 Microsoft Hosted ビルド エージェントは、インフラストラクチャと更新プログラムをデプロイするために Azure Pipelines の一部として使用されます。 Microsoft Hosted ビルド エージェントを使用すると、開発者がビルド エージェントを保守および更新するための管理上の負担が軽減されます。

Azure Pipelines の詳細については、「Azure DevOps とは」を参照してください。

DevOps パイプラインのフローチャートの図。

詳細については、「Azure でのミッション クリティカルなワークロードのデプロイとテスト: コードとしてのインフラストラクチャのデプロイ」を参照してください

デプロイ: ダウンタイムなしの更新プログラム

参照アーキテクチャのダウンタイムなしの更新戦略が、ミッション クリティカルなアプリケーション全体の中心になります。 スタンプをアップグレードする代わりに置き換える方法により、インフラストラクチャ スタンプへのアプリケーションの新規インストールが確実になります。 参照アーキテクチャでは、ブルー/グリーン アプローチを利用し、個別のテスト環境と開発環境を実現しています。

参照アーキテクチャには、次の 2 つの主要コンポーネントがあります。

  • インフラストラクチャ - Azure サービスとリソース。 Terraform およびその関連する構成と共にデプロイされます。

  • アプリケーション - ユーザーにサービスを提供するホステッド サービスまたはアプリケーション。 シングルページ アプリケーション (SPA) UI 用の HTML および JavaScript の Docker コンテナーと npm ビルド アーティファクトに基づきます。

多くのシステムでは、アプリケーションの更新がインフラストラクチャの更新よりも頻繁に行われることを前提にしています。 その結果、異なる更新手順がそれぞれに対して開発されています。 パブリック クラウド インフラストラクチャでは、さらに速いペースで変更が起きることがあります。 アプリケーション更新プログラムとインフラストラクチャ更新プログラムのデプロイ プロセスが 1 つ選択されました。 1 つのアプローチでは、インフラストラクチャとアプリケーションの更新が常に同期されます。このアプローチでは、次のことができます。

  • 1 つの一貫したプロセス - インフラストラクチャとアプリケーションの更新プログラムがリリース内で混在している場合に、意図的な間違いも意図しない間違いも起きる可能性が低くなります。

  • ブルー/グリーン デプロイを有効にする - すべての更新プログラムは、新しいリリースへのトラフィックの段階的な移行を使用してデプロイされます。

  • アプリケーションのより簡単なデプロイとデバッグ - スタンプ全体で複数のバージョンのアプリケーションが並行してホストされることはありません。

  • 簡単なロールバック - エラーや問題が発生した場合は、以前のバージョンを実行するスタンプにトラフィックを切り替えることができます。

  • 手動による変更と構成の誤差の解消 - すべての環境は新規デプロイです。

詳細については、「Azure でのミッション クリティカルなワークロードのデプロイとテスト: エフェメラル ブルー/グリーン デプロイ」を参照してください

ブランチ戦略

更新方法の基本は、Git リポジトリ内でブランチを使用することです。 参照アーキテクチャでは、次の 3 種類のブランチを使用します。

[Branch]\(ブランチ) 説明
feature/* と fix/* すべての変更のエントリ ポイント。 これらのブランチは開発者によって作成され、 feature/catalog-update や fix/worker-timeout-bug などのわかりやすい名前を付ける必要があります。 変更をマージする準備ができたら、 main ブランチに対するプル要求 (PR) が作成されます。 すべての PR は、少なくとも 1 人のレビュー担当者によって承認される必要があります。 例外が限られている場合、PR で提案されるすべての変更は、エンド ツー エンド (E2E) 検証パイプラインを介して実行する必要があります。 E2E パイプラインは、開発者が完全な環境に対する変更をテストおよびデバッグするために使用する必要があります。
main 継続的に前進し、安定したブランチ。 主に統合テストに使用されます。 main への変更は、プル要求によってのみ行われます。 ブランチ ポリシーでは、直接書き込みが禁止されています。 永続的な integration (int) 環境に対する夜間リリースは、 main ブランチから自動的に実行されます。 main ブランチは安定していると見なされます。 いつでもそこからリリースを作成できると考えて間違いありません。
release/* リリース ブランチは、 main ブランチからのみ作成されます。 ブランチは、 release/2021.7.Xという形式に従います。 ブランチ ポリシーは、リポジトリ管理者のみが release/* ブランチを作成できるように使用されます。 これらのブランチのみが prod 環境へのデプロイに使用されます。

詳細については、「Azure でのミッション クリティカルなワークロードのデプロイとテスト: 分岐戦略」を参照してください

修正プログラム

バグまたはその他の問題のために修正プログラムが緊急に必要であり、通常のリリース プロセスを実行できない場合は、修正プログラム パスを使用できます。 初期テスト中に検出されなかったユーザー エクスペリエンスに対する重要なセキュリティ更新プログラムおよび修正プログラムが、修正プログラムの有効な例と考えられます。

修正プログラムは、新しい fix ブランチに作成してから、通常の PR を使用して main にマージする必要があります。 新しいリリース ブランチを作成する代わりに、修正プログラムは既存のリリース ブランチに "厳選" されます。 このブランチは既に prod 環境にデプロイされています。 最初すべてのテストを行ってリリース ブランチをデプロイした CI/CD パイプラインが再度実行され、パイプラインの一部として修正プログラムがデプロイされます。

主要問題を回避するには、簡単に厳選し、リリース ブランチに統合できる、分離されたいくつかのコミットが修正プログラムに含まれていることが重要です。 分離されたコミットを厳選してリリース ブランチに統合できない場合、変更が修正プログラムとして適格と認められないことを示しています。 変更は完全な新しいリリースとしてデプロイし、新しいリリースをデプロイできるようになるまで、以前の安定版へのロールバックと組み合わせる必要があります。

デプロイ: 環境

参照アーキテクチャでは、インフラストラクチャに次の 2 種類の環境が使用されます。

  • 短命 - 短命の環境のデプロイには、E2E 検証パイプラインが使用されます。 短命の環境は、開発者向けの純粋な検証環境またはデバッグ環境に使用されます。 検証環境は feature/* ブランチから作成でき、テストを受け、すべてのテストが成功した場合は破棄できます。 デバッグ環境は検証環境と同じ方法でデプロイされますが、すぐには破棄されません。 これらの環境は、数日を超えて存在するべきでなく、機能ブランチの対応する PR がマージされたときに削除する必要があります。

  • 永続的 - 永続的環境には、 integration (int) と production (prod) のバージョンがあります。 これらの環境は継続的に稼働し、破棄されません。 この環境では、 int.mission-critical.app のような固定ドメイン名が使用されます。 参照アーキテクチャの実際の実装では、 staging (運用前) 環境を追加する必要があります。 staging 環境は、 prod (ブルー/グリーン デプロイ) と同じ更新プロセスで、 release ブランチをデプロイおよび検証するために使用されます。

    • 統合 (int) - int バージョンは、 prodと同じプロセスで main ブランチから夜間にデプロイされます。 トラフィックの切り替えは、以前のリリース ユニットよりも高速です。 prod でのように、トラフィックを数日にわたって徐々に切り替える代わりに、 int のプロセスは、数分以内または数時間で完了します。 この高速な切り替えにより、更新された環境は翌朝までに準備が整います。 パイプライン内のすべてのテストが成功した場合、古いスタンプは自動的に削除されます。

    • 運用 (prod) - prod バージョンは release/* ブランチからのみデプロイされます。 トラフィックの切り替えでは、より細かい手順が使用されます。 手動承認ゲートが各ステップ間に置かれます。 各リリースでは、新しいリージョン スタンプが作成され、新しいアプリケーション バージョンがスタンプにデプロイされます。 プロセスでは既存のスタンプを操作しません。 prod に関する最も重要な考慮事項は、 "常にオン"である必要があるということです。 計画的なダウンタイムや計画外のダウンタイムが起こらないようにする必要があります。 唯一の例外は、データベース レイヤーに対する根本的な変更です。 計画メンテナンス期間が必要になる場合があります。

デプロイ: 共有リソースと専用リソース

参照アーキテクチャ内の永続的環境 (int および prod) には、インフラストラクチャ全体で共有されているか、個々のスタンプ専用であるかに応じて、さまざまな種類のリソースがあります。 リソースは特定のリリース専用にすることができ、次のリリース ユニットが引き継ぐまでしか存在しません。

リリース ユニット

リリース ユニットは、特定のリリース バージョンごとの複数のリージョン スタンプです。 スタンプには、他のスタンプと共有されていないすべてのリソースが含まれます。 これらのリソースは、仮想ネットワーク、Azure Kubernetes Service クラスター、Event Hubs、Azure Key Vault です。 Azure Cosmos DB と ACR は、Terraform データ ソースで構成されます。

グローバルに共有されるリソース

リリース ユニット間で共有されるすべてのリソースは、独立した Terraform テンプレートで定義されます。 これらのリソースは、Front Door、Azure Cosmos DB、Container Registry (ACR)、Log Analytics ワークスペース、およびその他の監視関連リソースです。 これらのリソースは、リリース ユニットの最初のリージョン スタンプがデプロイされる前にデプロイされます。 リソースは、スタンプの Terraform テンプレートで参照されます。

Front Door

Front Door はスタンプ間でグローバルに共有されるリソースですが、その構成は他のグローバル リソースとは若干異なります。 Front Door は、新しいスタンプをデプロイした後に再構成する必要があります。 Front Door は、トラフィックを新しいスタンプに徐々に切り替えるように再構成する必要があります。

Front Door のバックエンド構成を Terraform テンプレートで直接定義することはできません。 この構成は Terraform 変数で挿入されます。 変数の値は、Terraform デプロイが開始される前に構築されます。

Front Door デプロイの個々のコンポーネント構成は、次のように定義されます。

  • フロントエンド - セッション アフィニティは、ユーザーが 1 つのセッション中に異なる UI バージョンを切り替えないように構成されています。

  • 配信元 - Front Door は、次の 2 種類の配信元グループで構成されます。

    1. UI を提供する静的ストレージの配信元グループ。 グループには、現在アクティブなすべてのリリース ユニットの Web サイト ストレージ アカウントが含まれます。 異なるリリース ユニットの配信元に異なる重みを割り当てて、トラフィックを新しいユニットに徐々に移動できます。 リリース ユニットからの各配信元には、同じ重みが割り当てる必要があります。

    2. AKS でホストされる API の配信元グループ。 異なる API バージョンのリリース ユニットがある場合は、リリース ユニットごとの API 配信元グループが存在します。 すべてのリリース ユニットで互換性が同じ API が提供されている場合は、すべての配信元が同じグループに追加され、異なる重みが割り当てられます。

  • ルーティング規則 - 次の 2 種類のルーティング規則があります。

    1. UI ストレージの配信元グループにリンクされている UI のルーティング規則。

    2. 配信元で現在サポートされている各 API のルーティング規則。 たとえば、 /api/1.0/* と /api/2.0/* などです。

    リリースでバックエンド API の新しいバージョンが導入された場合、この変更はリリースの一部としてデプロイされる UI に反映されます。 UI の特定のリリースでは、常に特定のバージョンの API URL が呼び出されます。 UI バージョンでサービスを提供されるユーザーは、それぞれのバックエンド API を自動的に使用します。 API バージョンの異なるインスタンスには、特定のルーティング規則が必要です。 これらのルールは、対応する配信元グループにリンクされます。 新しい API が導入されていない場合は、API 関連のすべてのルーティング規則が単一の配信元グループにリンクされます。 この場合、ユーザーが API とは異なるリリースから UI を提供されているかどうかは関係ありません。

デプロイ: デプロイ プロセス

ブルー/グリーン デプロイがデプロイ プロセスの目標になります。 release/* ブランチからの新しいリリースが prod 環境にデプロイされます。 ユーザー トラフィックは、新しいリリースのスタンプに徐々に移されます。

新しいバージョンのデプロイ プロセスの最初の手順として、新しいリリース ユニットのインフラストラクチャが Terraform と共にデプロイされます。 インフラストラクチャ デプロイ パイプラインを実行すると、選択したリリース ブランチからの新しいインフラストラクチャがデプロイされます。 インフラストラクチャ のプロビジョニングと並行して、コンテナー イメージはビルドまたはインポートされ、グローバル共有コンテナー レジストリ (ACR) にプッシュされます。 前のプロセスが完了すると、アプリケーションはスタンプにデプロイされます。 実装の観点からは、複数の依存ステージを持つ 1 つのパイプラインです。 修正プログラムのデプロイに対して同じパイプラインを再実行できます。

新しいリリース ユニットがデプロイされて検証されると、Front Door に追加され、ユーザー トラフィックを受信します。

新しい API バージョンが導入されているリリースと導入されていないリリースを区別するスイッチ/パラメーターを、計画する必要があります。 リリースで新しい API バージョンが導入されているかどうかに基づいて、API バックエンドを含む新しい配信元グループを作成する必要があります。 または、新しい API バックエンドを既存の配信元グループに追加することもできます。 新しい UI ストレージ アカウントが、対応する既存の配信元グループに追加されます。 目的のトラフィック分割に従って、新しい配信元の重みを設定する必要があります。 前述のように、適切な配信元グループに対応する新しいルーティング規則を作成する必要があります。

新しいリリース ユニットの追加の一環として、新しい配信元の重みを、目的の最小ユーザー トラフィックに設定する必要があります。 問題が検出されない場合は、一定期間にわたって新しい配信元グループへのユーザー トラフィックの量を増やす必要があります。 重みパラメーターを調整するには、目的の値で同じデプロイ手順を再度実行する必要があります。

リリース ユニットの破棄

リリース ユニットのデプロイ パイプラインの一部として、リリース ユニットが不要になったときにすべてのスタンプを削除する破棄ステージがあります。 すべてのトラフィックは、新しいリリース バージョンに移動されます。 このステージでは、リリース ユニット参照が Front Door から削除されます。 この削除は、新しいバージョンのリリースを後日有効にするために重要です。 Front Door では、将来の次のリリースに備えるために、単一のリリース ユニットを指している必要があります。

Checklists

リリースの周期の一環として、リリース前とリリース後のチェックリストを使用する必要があります。 次に、どのチェックリストにも少なくとも含める必要のある項目の例を示します。

  • リリース前チェックリスト - リリースを開始する前に、次の点を確認してください。

    • main ブランチの最新の状態が int 環境に正常にデプロイされ、テストされたことを確認します。

    • main ブランチに対して PR を使用して変更ログ ファイルを更新します。

    • main ブランチから release/ ブランチを作成します。

  • リリース後のチェックリスト - 古いスタンプが破棄され、その参照が Front Door から削除される前に、次の点を確認してください。

    • クラスターが受信トラフィックを受信しなくなっています。

    • Event Hubs やその他のメッセージ キューには、未処理のメッセージが含まれていません。

デプロイ: 更新戦略の制限事項とリスク

この参照アーキテクチャで説明している更新戦略には、触れておく必要のある制限事項とリスクがいくつかあります。

  • コストの増加 - 更新プログラムをリリースするときに、多くのインフラストラクチャ コンポーネントがリリース期間中に 2 回アクティブになります。

  • Front Door の複雑さ - Front Door の更新プロセスでは実装と保守が複雑です。 ダウンタイムなしに効果的なブルー/グリーン デプロイを実行できるかどうかは、正常に動作できるかどうかによります。

  • 小さな変更に時間がかかる - 更新プロセスの結果、小さな変更のリリース プロセスが長くなります。 この制限は、前のセクションで説明した修正プログラム プロセスで一部軽減できます。

デプロイ: アプリケーション データ転送の互換性に関する考慮事項

更新戦略では、同時に実行している複数バージョンの API と作業コンポーネントをサポートできます。 Azure Cosmos DB は 2 つ以上のバージョン間で共有されるため、あるバージョンによって変更されたデータ要素が、それを使用する API またはワーカーのバージョンと必ずしも一致しない可能性があります。 API レイヤーとワーカーは、上位互換性設計を実装する必要があります。 以前のバージョンの API またはワーカー コンポーネントでは、新しいバージョンの API またはワーカー コンポーネントによって挿入されたデータを処理します。 理解できない部分は無視されます。

テスト

参照アーキテクチャには、テスト実装内のさまざまな段階で使用されるさまざまなテストが含まれています。

テストの内容には以下が含まれます。

  • 単体テスト - これらのテストは、アプリケーションのビジネス ロジックが期待どおりに動作することを検証します。 この参照アーキテクチャには、Azure Pipelines によってすべてのコンテナーがビルドされる前に自動的に実行される単体テストのサンプル スイートが含まれています。 いずれかのテストが失敗した場合、パイプラインは停止します。 ビルドとデプロイは続行されません。

  • ロード テスト - これらのテストは、特定のワークロードまたはスタックの容量、スケーラビリティ、潜在的なボトルネックを評価するのに役立ちます。 参照実装には、実際のトラフィックをシミュレートするために使用できる合成ロード パターンを作成するためのユーザー ロード ジェネレーターが含まれています。 ロード ジェネレーターは、参照実装とは別に使用することもできます。

  • スモーク テスト - これらのテストは、インフラストラクチャとワークロードが使用可能で、期待どおりに機能するかどうかを識別します。 スモーク テストは、すべてのデプロイの一部として実行されます。

  • UI テスト - これらのテストは、ユーザー インターフェイスがデプロイされており、期待どおりに動作することを検証します。 現在の実装では、実際のテストを行わないデプロイ後のいくつかのページのスクリーンショットのみがキャプチャされます。

  • エラー インジェクション テスト - これらのテストは自動化することも、手動で実行することもできます。 アーキテクチャの自動テストでは、デプロイ パイプラインの一部として Azure Chaos Studio が統合されます。

詳細については、「Azure でのミッション クリティカルなワークロードのデプロイとテスト: 継続的な検証とテスト」を参照してください

テスト: フレームワーク

可能な限りのオンライン参照実装の既存のテスト機能とフレームワーク。

フレームワーク Server1 説明
NUnit ユニット このフレームワークは、実装の .NET Core 部分を単体テストするために使用されます。 単体テストは、コンテナーのビルド前に Azure Pipelines によって自動的に実行されます。
Azure Load Testing を使用した JMeter [読み込み] Azure Load Testing は、 Apache JMeter ロード テストの定義を実行するために使用されるマネージド サービスです。
Locust [読み込み] Locust は、Python で記述されたオープンソースのロード テストフレームワークです。
Playwright UI とスモーク Playwright は、1 つの API で Chromium、Firefox、WebKit を自動化するためのオープン ソースの Node.js ライブラリです。 Playwright テスト定義は、参照実装とは別に使用することもできます。
Azure Chaos Studio エラー インジェクション 参照実装では、E2E 検証パイプラインの省略可能な手順として Azure Chaos Studio を使用して、回復性検証のエラーを挿入します。

テスト: エラー インジェクション テストとカオス エンジニアリング

分散アプリケーションには、サービスとコンポーネントの停止に対する回復性が必要です。 エラー インジェクション テスト (フォールト インジェクションまたはカオス エンジニアリングとも呼ばれます) は、アプリケーションとサービスを実際のストレスとエラーに適用する方法です。

回復性はシステム全体のプロパティであり、障害を挿入すると、アプリケーションでの問題を見つけるのに役立ちます。 これらの問題に対処することで、信頼性の低い条件、依存関係の欠落、その他のエラーに対するアプリケーションの回復性の検証に役立ちます。

手動テストと自動テストをインフラストラクチャに対して実行することで、実装での障害と問題を見つけられます。

自動

参照アーキテクチャは、 Azure Chaos Studio を統合して、一連の Azure Chaos Studio 実験をデプロイして実行し、スタンプ レベルでさまざまな障害を挿入します。 カオス実験は、E2E デプロイ パイプラインの省略可能な部分として実行できます。 テストが実行されると、省略可能なロード テストが常に並列で実行されます。 ロード テストは、クラスターに負荷を作成して、挿入された障害の影響を検証するために使用されます。

マニュアル

手動のエラー インジェクション テストは、E2E 検証環境で行う必要があります。 この環境では、他の環境から干渉されるリスクのない、完全な代表的なテストが保証されます。 テストで生成されたほとんどのエラーは、Application Insights Live metrics ビューで直接観察できます。 残りのエラーは、[エラー] ビューと対応するログ テーブルで確認できます。 その他のエラーについては、 kubectl を使用して AKS 内の動作を監視するなど、さらに詳細なデバッグが必要です。

参照アーキテクチャに対して実行されるエラー インジェクション テストの 2 つの例を次に示します。

  • DNS ベースのエラー インジェクション - 複数の問題をシミュレートできるテスト ケース。 DNS サーバーまたは Azure DNS のエラーによる DNS 解決エラー。 DNS ベースのテストは、たとえば BackgroundProcessor が Event Hubs に接続できない場合など、クライアントとサービスの間の一般的な接続の問題をシミュレートするのに役立ちます。

    単一ホストのシナリオでは、ローカル hosts ファイルを変更して DNS 解決を上書きできます。 AKS などの複数の動的サーバーがある大規模な環境では、 hosts ファイルは実現できません。 Azure プライベート DNS ゾーン は、テスト エラー シナリオの代替手段として使用できます。

    Azure Event Hubs と Azure Cosmos DB は、参照実装内で使用される 2 つの Azure サービスであり、DNS ベースのエラーを挿入するために使用できます。 Event Hubs DNS 解決は、いずれかのスタンプの仮想ネットワークに関連付けられた Azure プライベート DNS ゾーンで操作できます。 Azure Cosmos DB は、特定のリージョン エンドポイントを持つグローバルにレプリケートされたサービスです。 これらのエンドポイントの DNS レコードの操作で、特定のリージョンのエラーをシミュレートし、クライアントのフェールオーバーをテストできます。

  • ファイアウォールのブロック - ほとんどの Azure サービスでは、仮想ネットワークや IP アドレスに基づくファイアウォール アクセス制限がサポートされています。 参照インフラストラクチャでは、Azure Cosmos DB または Event Hubs へのアクセスを制限するために、これらの制限が使用されます。 簡単な手順としては、既存の 許可 ルールを削除するか、新しい ブロック ルールを追加します。 この手順では、ファイアウォールの構成ミスやサービスの停止をシミュレートできます。

    参照実装での次のサンプル サービスを、ファイアウォール テストでテストできます。

    サービス 結果
    Key Vault Key Vault へのアクセスがブロックされている場合、最も直接的な影響は、新しいポッドの生成エラーでした。 ポッドの起動時にシークレットをフェッチする Key Vault CSI ドライバーが、そのタスクを実行できず、ポッドの起動が妨げられます。 kubectl describe po CatalogService-deploy-my-new-pod -n workload で、対応するエラー メッセージを確認できます。 既存のポッドは引き続き動作しますが、同じエラー メッセージが表示されます。 エラー メッセージは、シークレットの定期的な更新チェックの結果によって生成されます。 テストは行われませんが、Key Vault にアクセスできない間は、デプロイの実行は機能しないと想定されています。 パイプライン実行内の Terraform タスクと Azure CLI タスクにより、Key Vault への要求が行われます。
    Event Hubs Event Hubs へのアクセスがブロックされると、 CatalogService と HealthService によって送信された新しいメッセージは失敗します。 BackgroundProcess によるメッセージの取得は失敗に時間がかかり、エラー全体で数分以内になります。
    Azure Cosmos DB 仮想ネットワークの既存のファイアウォール ポリシーを削除すると、ヘルス サービスが最小ラグで失敗し始めます。 この手順では、特定のケース (全体的な Azure Cosmos DB の停止) のみをシミュレートします。 リージョン レベルで発生するほとんどのエラー ケースは、クライアントを別の Azure Cosmos DB リージョンに透過的にフェールオーバーすることで自動的に軽減する必要があります。 前に説明した DNS ベースのエラー インジェクション テストは、Azure Cosmos DB のより有意義なテストです。
    Container Registry (ACR) ACR へのアクセスがブロックされたときに、AKS ノードで以前にプルおよびキャッシュされた新しいポッドの作成は引き続き実行されます。 k8s デプロイ フラグ pullPolicy=IfNotPresentにより、作成は引き続き行われます。 ブロックの前にイメージをプルしてキャッシュしていないノードは、新しいポッドを生成できず、 ErrImagePull のエラーですぐに失敗します。 kubectl describe pod には、対応する 403 Forbidden メッセージが表示されます。
    AKS イングレス Load Balancer AKS マネージド ネットワーク セキュリティ グループ (NSG) の HTTP(S)(ポート 80 および 443) の受信規則を Deny に変更すると、ユーザーまたは正常性プローブのトラフィックがクラスターに到達できなくなります。 このエラーのテストでは、Front Door のネットワーク パスとリージョン スタンプの間の障害物としてシミュレートされた根本原因を特定することは困難です。 Front Door はすぐにこのエラーを検出し、スタンプをローテーションから取り出します。