演習 - 正常性状態、メトリック、しきい値を定義する
この演習では、前に作成した正常性モデルの構造を引き継ぎます。 タスクでは、サンプル アプリケーション用の個々のコンポーネントの正常性状態を定量化します。
正常性モデル構造では、まず、ユーザー フローを使用して上部からレイヤーを評価し、下位レイヤーに進んでいきます。
ユーザー フローの正常性状態
これまでに、2 つのユーザー フローカタログ項目のリストとコメントの追加を特定しました。 各フローの正常性状態を確認するには、次のような質問をします。
- ユーザー フローが正常と見なされるのは、どんなときですか?
- 低下状態で動作可能ですか?
実装および機能の要件に基づいて、ユーザー フローに参加するアプリケーション コンポーネントを特定します。 これらのコンポーネントについては、アーキテクチャ コンポーネントの例に関するセクションを参照してください。
| ユーザー フロー | コンポーネント |
|---|---|
| カタログ項目のリスト | フロントエンド内部 Web アプリケーション、Catalog API |
| コメントの追加 | フロントエンド内部 Web アプリケーション、Catalog API、バックグラウンド プロセッサ |
これらのコンポーネントのいずれかが異常になった場合、ユーザー フローは異常になると予想されます。
注意
アプリケーションによっては、特別な "低下" モードで動作可能です。 たとえば、Contoso Shoes でローカル ブラウザー キャッシュが実装されている場合、Web アプリケーションを使用している従業員はコメントを作成できますが、ブラウザーで継続的にチェックできる Catalog API が正常になるまで、コメントを送信することはできず、顧客ビューは更新されません。
アプリケーション コンポーネントの正常性状態
コンポーネントの正常性状態に寄与するメトリックを決定します。 この手順では、コンポーネントの機能を知る必要があります。 次のような質問をします。
- 優れたユーザー エクスペリエンスを維持するために許容できる API の処理時間はどれくらいですか?
- 予期されるエラーがありますか? "通常" のエラー率はどれくらいですか?
- "通常の" 処理時間はどれくらいですか? 処理時間が通常よりも長い場合、それは何を意味しますか?
- Azure Cosmos DB に到達できない場合、書き込み操作はどうなりますか?
これらの質問をすることで、主要なメトリックについて特定の測定可能なしきい値が得られます。 たとえば、Catalog API コンポーネントについて、これらのしきい値を検討できます。
| メトリックとしきい値 | 正常性の状態 |
|---|---|
| 応答時間 < 150 ミリ秒 失敗要求数 < 10 | Healthy |
| 応答時間 < 300 ミリ秒 失敗要求数 < 50 | 低下しています |
| 応答時間 > 300 ミリ秒 失敗要求数 > 50 | 異常 |
Application Insights などのアプリケーション監視ソリューションから値を取得できます。
Azure リソースの正常性状態
Azure サービスの正常性状態は、特定のリソースに基づいています。 たとえば、Azure Cosmos DB はデータベース トランザクション ユニット (DTU) 使用率を報告し、Azure App Services は CPU 使用率に関する情報を提供します。
リソースの種類別のメトリックについては、「Azure Monitor のサポートされるメトリック」を参照してください。
正常性状態としきい値
アプリケーションのすべてのレイヤーを評価したら、この例のようなコンポーネントおよびその正常性状態の定義を掲載したリストが得られます。
| コンポーネント | インジケーター、メトリック | Healthy | 低下しています | 異常 |
|---|---|---|---|---|
| "カタログ項目のリスト" ユーザー フロー | 基になる正常性状態 | フロントエンドが正常、Catalog API が正常 | ||
| "コメントの追加" ユーザー フロー | 基になる正常性状態 | フロントエンドが正常、Catalog API が正常、バックグラウンド プロセッサが正常 | ||
| フロント エンドの Web アプリケーション | 20x 以外の HTTP 応答数/分 | 0 | 1 ～ 10 | > 10 |
| Catalog API | 例外の数/秒 | < 10 | 10-50 | > 10 |
| 平均処理時間 (ミリ秒) | < 150 | 150 - 500 | > 500 | |
| バックグラウンド プロセッサ | キューでの平均時間 (ミリ秒) | < 200 | 200 - 1,000 | > 1,000 |
| 平均処理時間 (ミリ秒) | < 100 | 100 - 200 | > 200 | |
| 失敗数 | < 3 | 3 ～ 10 | > 10 | |
| Azure Cosmos DB | DTU 使用率 | < 70% | 70% - 90% | > 90% |
| Azure Key Vault | 失敗数 | < 3 | 3 ～ 10 | > 10 |
| Azure Event Hubs | 処理中のバックログの長さ (送信/受信メッセージ) | < 3 | 3 - 20 | > 20 |
| Azure Blob Storage | 平均待機時間 (ミリ秒) | < 100 | 100 - 200 | > 200 |
この例では、フロントエンド Web アプリケーションと Catalog API のエラー許容度が異なります。 この違いは、アプリケーションの技術的な解釈に関連しています。 すべてのフロントエンド エラーはクライアント側で処理する必要があるため、しきい値は 0 です。 ただし、API レイヤーでは、ユーザーが原因で発生したエラーを考慮するために 10 個の例外が許可されます。 たとえば、404 - Not Found などのエラーは、必ずしも正常性の問題を示しているわけではありません。