カオス実験を設計する
ミッション クリティカルなアプリケーションは回復力があり、障害に対応する準備ができている必要があります。 しかし、クラウド内の潜在的な障害シナリオを予測することは困難です。 カオス エンジニアリングを使用すると、制御された環境で障害実験を実行して、開発とデプロイ中に発生する可能性のある問題を特定できます。 現実的なエラーを意図的に注入し、システムがどのように反応するかを観察します。
このユニットでは、Azure Chaos Studio を使用します。 このサービスは、クラウド アプリケーションとサービスの回復性を測定し、理解し、改善するのに役立ちます。 悪条件の運用環境でこの障害が発生した場合に、迅速に対応する準備が整います。
障害モード分析を実行する
カオス実験を設計するときは、最初のステップとして、アプリケーション コンポーネントの障害モード分析 (FMA) を実行して、潜在的な障害シナリオを特定します。
使用可能で機能する必要があるユーザー フローに関連するすべてのコンポーネントを一覧表示します。 たとえば、チェックアウト ユーザー フローでは、Azure App Services、Functions、Cosmos DB データベースが使用されます。
コンポーネントごとに、考えられる障害ケース、その影響、および潜在的な軽減策を一覧表示します。
Contoso Shoes のチェックアウト ユーザー フローの例のコンポーネントに対して行われた FMA の結果を見てみましょう。
フロントエンド アプリケーションをホストするための Azure App Service
| リスク | 影響 | 考えられる軽減策 |
|---|---|---|
| 可用性ゾーンの停止 | そのゾーン内のインスタンスが使用できなくなる可能性があります。 App Service プランでゾーン冗長が有効になっているため、完全な停止は想定されません。 |
残りのインスタンスに追加の負荷を許容し、パフォーマンス目標を達成しながら、このシナリオに十分なヘッド ルームを提供します。 |
| SNAT ポートの枯渇 | 送信接続を作成できません。 その結果、データベースへの呼び出しなどのダウンストリーム呼び出しは失敗します。 | ダウンストリーム コンポーネントに接続するには、プライベート エンドポイントを使用します。 |
| 個々のインスタンスが異常になる | 異常なインスタンスにルーティングされたユーザー トラフィックでは、パフォーマンスが低下したり、完全に失敗したりする可能性があります。 | App Service 正常性チェック機能により、異常なインスタンスが自動的に識別され、新しい正常なインスタンスに置き換えられます。 |
チェックアウト ロジックの Azure Functions
| リスク | 影響 | 考えられる軽減策 |
|---|---|---|
| 開始パフォーマンスが低速 (コールド) | Azure Functions 従量課金プランが使用されるため、新しいインスタンスではパフォーマンスが保証されません。 ("うるさい隣人" からの) サービスに対する需要が高い場合、チェックアウト関数の起動時間が長くなり、パフォーマンス目標に影響を与える可能性があります。 |
Azure Functions Premium プランにアップグレードします。 |
| 基になるストレージの停止 | 基になるストレージ アカウントが使用できなくなった場合、関数は動作を停止します。 | リージョン ストレージでの負荷分散コンピューティング、またはGRS 共有ストレージでの負荷分散コンピューティングを使用します。 |
Azure Cosmos DB データベース
| リスク | 影響 | 考えられる軽減策 |
|---|---|---|
| データベースまたはコレクションの名前変更 | 構成が一致しないため、データが失われる可能性があります。 構成が更新され、そのコンポーネントが再起動されるまで、アプリケーションはデータにアクセスできません。 | データベースとコレクション レベルのロックを使用して、この状況を回避します。 |
| 書き込みリージョンの停止 | プライマリ リージョン (または書き込みリージョン) で停止が発生した場合、Azure Cosmos DB アカウントで自動 (サービスマネージド) フェールオーバーが構成されていると、Azure Cosmos DB アカウントによってセカンダリ リージョンが自動的に新しいプライマリ書き込みリージョンに昇格します。 指定したリージョンの優先順位に従って別のリージョンにフェールオーバーが発生します。 | 複数のリージョンと自動フェールオーバーを含むデータベース アカウントを構成します。 障害が発生した場合、サービスは自動的にフェールオーバーされ、アプリケーションで持続的な問題が発生しないようになります。 |
| 要求ユニット (RU) の不足による広範な調整 | 特定のスタンプが Azure Cosmos DB の使用に対してホットに実行され、他のスタンプは引き続き要求を処理できます。 | より多くのスタンプに対してより適切な負荷分散を使用するか、RU を追加します。 |
カオス実験を設計する
カオス実験を設計するには、いくつかの失敗事例を選択します。 障害が発生する可能性、または可能性のある影響に基づいて選択できます。
実験の目的は、アプリケーションに実装した回復性対策を検証することです。 仮説の例として、ゾーン冗長が有効になっている App Service でアプリケーションを実行するとします。 ゾーン内のすべての基になるインスタンスがダウンした場合でも、アプリケーションが実行されると想定しています。
Chaos Studio を使用して、関連するコンポーネントにエラーを注入します。 Chaos Studio には、選択できる障害のライブラリが用意されています。 ただし、障害ライブラリにはすべてが含まれているわけではないため、シナリオの調整が必要になる場合があります。 または、エラーの注入に役立つ他のツールを見つけなければならない場合もあります。
重要
実験では非運用環境のみをターゲットにします。 運用環境にエラーを注入することは危険な場合があり、経験と計画が必要です。
例: Azure Cosmos DB の停止とフェールオーバー
表に示す Azure Cosmos DB の "書き込みリージョンの停止" 障害シナリオを選択したとします。 "サービスによって開始されるフェールオーバーが、アプリケーションに持続的な影響を与えることはない" が仮説です。 この仮説が正しいと証明された場合、複数のリージョンにレプリケートする回復性対策が、アプリケーションの信頼性に望ましいプラスの影響を与えることが検証されます。
この障害をシミュレートするには、Chaos Studio 障害ライブラリの Azure Cosmos DB エラーを使用します。
この例は、10 分間 (PT10M) 実行され、新しい書き込みリージョンとして West US 2 を使用する Azure Cosmos DB フェールオーバーの場合です。 West US 2 が既に読み取りレプリケーション リージョンの 1 つとして設定されていることを前提としています。
{
"name": "branchOne",
"actions": [
{
"type": "continuous",
"name": "urn:csci:microsoft:cosmosDB:failover/1.0",
"parameters": [
{
"key": "readRegion",
"value": "West US 2"
}
],
"duration": "PT10M",
"selectorid": "myCosmosDbResource"
}
]
}
実験が終了すると、Chaos Studio は書き込みリージョンを元の値に戻します。
Azure リソースに対してエラーを注入する前に、そのリソースに対応するターゲットと機能の設定を有効にする必要があります。 この設定では、フォールト インジェクションが有効になっているリソースに対して実行できる障害が制御されます。 ターゲットと機能を他のセキュリティ対策と共に使用することで、偶発的な事故や悪意のあるフォールト インジェクションを避けることができます。
ロード テストとカオス実験の両方を設計したので、それらをパイプラインに自動化して、一貫して定期的に実行されるようにする必要があります。 次のユニットでは、CI/CD パイプラインへのテストの追加について学習します。