主要なユーザー フローに基づいてロード テストを定義する
ロード テストは、継続的な検証の重要な部分です。 開始するには、アプリケーション フローを識別する必要があります。 このユニットでは、ユーザーおよびシステム フロー、それらが重要な理由、テストの設計基準について説明します。
アプリケーション フローとは
フローは、タスクを完了するために必要なアプリケーション対話式操作で構成されます。
ユーザー フロー
これらのフローは、ユーザーがアプリケーションと対話する方法を示します。 Contoso Shoes のシナリオでは、品目を購入するためのチェックアウト プロセスがユーザー フローの例です。 次のコンポーネントが、在庫管理に関わります。
- フロント エンドの Web アプリケーション
- Azure Functions のチェックアウト ロジック
- Azure Cosmos DB のバックエンド データベース
ミッション クリティカルな観点から見ると、これらのコンポーネントは高い可用性と、障害に対する回復性が必要です。 たとえば、この組織は多数の同時ユーザーを想定しているため、フロントエンド Web ページを迅速に読み込む必要があります。
システム フロー
通常、これらのフローはユーザーに面しているわけではありませんが、システム フロー コンポーネントの停止や低下がユーザー エクスペリエンスに影響を与える場合があります。 たとえば、データベースから注文を取得し、出荷ラベルを生成する非同期アクティビティです。
注意
ほとんどのアプリケーションには複数のフローがあります。 各フローは、アーキテクチャのさまざまなコンポーネントに接することがあります。 また、1 つのコンポーネントが複数のフローに表示されることがあります。 コンポーネントに障害が発生したときに影響を受けるフローを理解することが重要です。
ロード テストとそのしきい値を定義する
ロード テストでは、実際のトラフィックをシミュレートして、アプリケーションのパフォーマンスをテストします。 ただし、その目標は、システムを壊すために大きな負荷を生成することではありません。 その目標は、ストレス テストを通じて達成できます。
ロード テストは、ユーザー フローのコンポーネントのパフォーマンス、パフォーマンス制限、リソース使用率、最適なスケーリング動作を特定するのに役立ちます。 ロード テストには、関連するすべてのユーザー フローとシステム フローが反映されている必要があります。 適切な設計には、アプリケーションに関する知識が必要です。 まず、次のような質問をします。
- "どの API 呼び出しを行う必要がありますか?"
- "API 呼び出しのシーケンスは何ですか?"
- "API 呼び出しで使用する必要があるテスト データは何ですか?"
回答に基づいて次の手順を行います。
主要なシナリオ、依存関係、予想される使用状況、可用性、パフォーマンス、スケーラビリティのターゲットを特定します。
一連の測定可能なしきい値を定義して、主要なシナリオの予想されるパフォーマンスを定量化します。 たとえば、アプリケーション コンポーネントの場合、予想されるユーザー ログイン数、API の 1 秒あたりの要求数、バックグラウンド プロセスの 1 秒あたりの操作数のしきい値を考慮することができます。
そのしきい値を使用して、アプリケーションのパフォーマンスのテスト、予想されるスケーリング操作の検証、関連するアクティビティのための現実的なトラフィックを生成するロード テストを定義します。 これらのしきい値を使用して、テストと運用の両方をカバーするアプリケーションの正常性モデルを開発します。
チェックアウト プロセス フローの例では、各ステップの平均ページ読み込み時間のしきい値を 500 ミリ秒未満に設定し、最大 100 人の同時ユーザーをサポートできます。
すべてのしきい値が定義されたので、ロード テストを実装する準備ができました。 このモジュールでは、Azure Load Testing を使用します。
Azure portal を使用して Azure Load Testing を構成してデプロイすることはできますが、プログラムによるアプローチを強くお勧めします。 API を使用して、自動化された方法でテストをデプロイ、構成、実行します。 この方法は、次のユニットで説明します。