パフォーマンス ターゲットを定義するための推奨事項
この Azure Well-Architected Framework パフォーマンス効率チェックリストの推奨事項に適用されます。
| PE:01 | パフォーマンスターゲットを定義します。 パフォーマンス目標は、ワークロードの要件に関連付けられている数値である必要があります。 すべてのワークロード フローのパフォーマンス ターゲットを実装する必要があります。 |
|---|
このガイドでは、パフォーマンス ターゲットを確立して公開するための推奨事項について説明します。 パフォーマンス ターゲットは、パフォーマンス目標を定義するメトリックです。 これらのメトリックは、単一の数値または数値範囲として表されます。 これらは、継続的な改善を推進する明確で具体的なメトリックです。 パフォーマンス目標は、改善のための数値的基盤であり、チームが特定の目標に向けて取り組みを調整するのに役立ちます。 明確なパフォーマンス目標がない場合、チームはフォーカスがなく、パフォーマンスの問題に対する説明責任が不足している可能性があります。 パフォーマンス目標を設定することで、チームは特定の目標に向けて取り組み、継続的な改善を推進できます。
定義
| 期間 | 定義 |
|---|---|
| Data flow | システム内またはシステム間でのデータの移動。 |
| 依存関係 | ワークロードが依存するコンポーネント。 |
| Flow | ワークロードでは、特定の関数を実行する一連の操作。 これには、データの移動と、ワークロードのコンポーネント間でのプロセスの実行が含まれます。 |
| メトリック | 一定の間隔で収集される数値。 メトリックは、特定の時点でのシステムの一部の側面を記述します。 |
| パフォーマンスの目標 | パフォーマンス目標を定義するメトリック。 これらのメトリックは、単一の数値または数値範囲として表されます。 |
| ユーザー フロー | ユーザーがアプリケーションまたはシステム内で実行するアクションのパスまたはシーケンス。 |
| ワークフロー | タスクを実行するためにワークロードが実行する一連の手順。 |
主要な設計戦略
パフォーマンス目標の確立は、ワークロードのパフォーマンス効率を実現するために不可欠な手順です。 パフォーマンス目標は、ワークロードに必要なパフォーマンス レベルを定義し、それらの目標を達成する際の効果を測定するのに役立ちます。 パフォーマンス 目標は、ワークロードの効率を測定および比較するためのベンチマークを提供します。 このベンチマークは、改善点を強調するのに役立ちます。 また、目標はタスクをorganizationの目標に合わせ、ビジネス成果を向上させます。 さらに、パフォーマンス 目標はリソース割り当てのガイダンスを提供し、ワークロードが最適なパフォーマンスを維持しながら、さまざまな要求に確実に適応できるように支援します。
パフォーマンス目標を早期に設定する
ワークロードをデプロイする前に、パフォーマンス目標を設定します。 設計内のワークロードの場合、パフォーマンス目標には調査が必要です。 市場調査、競合分析、アンケートを実施して、パフォーマンス目標範囲を生成します。 パフォーマンス目標がない運用ワークロードの場合は、運用データと顧客フィードバックを使用してパフォーマンス目標を確立します。
パフォーマンス要件を決定する
パフォーマンス要件の決定は、アプリケーションにとって重要な応答時間、スループット、待機時間などの重要なパフォーマンス メトリックを特定することです。 これらのパフォーマンス目標をorganizationのビジネス目標に合わせることにより、クラス最高の製品でも平均的な製品であっても、ワークロードが目的の標準を満たすことができます。 たとえば、応答時間の短縮、スループット率の向上、リソースの使用の最適化を目指す場合があります。
パフォーマンス目標を設定するときは、organizationの目標をユーザー ベースの個別のニーズに合わせることが重要です。 ユーザーは最終的にパフォーマンスの成功を判断し、パフォーマンス目標を期待値に合わせる必要性を強調します。 このバランスにより、パフォーマンス 目標によって、意図したユーザー エクスペリエンスとワークロードの全体的な効率が確実にキャプチャされます。 ワークロードのパフォーマンスを包括的に測定して最適化するには、次の一覧のパフォーマンス目標を設定することを検討する必要があります。
個々のコンポーネント: 個々のコンポーネントはワークロードの個別のユニットまたはセグメントであり、それぞれが個別のパフォーマンス属性と需要を持つ可能性があります。
ユーザー フロー: これらの経路は、ユーザーがワークロードを操作する方法を示し、その流動性を確保することで、ユーザー エクスペリエンスを直接向上させます。
ワークフロー: ワークフロー定義の内部プロセスは、特定の結果を達成するために作成され、多くの場合、運用効率を決定します。
データ フロー: データ フローは、ワークロード内のデータの移動と相互作用を指し、潜在的な非効率性やボトルネックを特定するのに役立ちます。
外部依存関係: 外部依存関係は、パフォーマンスに大きな影響を与える可能性があるプライマリ ワークロード (統合されたサード パーティのサービスまたはツール) の外部の要素です。
スケール ユニット: スケール ユニットは、ワークロードのスケーラブルなセグメントに関連します。 負荷の増加に伴う堅牢なパフォーマンスの確保は、特に成長シナリオにおいて極めて重要です。
テクノロジ レベル: テクノロジ レベルは、API アクセスの速度、データベース操作の待機時間、潜在的なネットワーク遅延などの直接的なパフォーマンス インジケーターです。
ビジネス トランザクション: ビジネス トランザクションは、購入の完了やサービスの予約などのエンド ツー エンドのユーザー操作を表し、シームレスな実行はユーザーの満足度に直接関連付けられます。
ワークロード全体: この包括的なメトリックは、ワークロードのすべてのコンポーネントと側面を含む集合的なパフォーマンスの概要を示します。
主要なメトリックを特定する
主要なパフォーマンス メトリックを特定するには、ワークロードのパフォーマンス目標の達成に向けた進行状況を追跡する重要な測定値を決定する必要があります。 この識別により、パフォーマンス効率を測定および改善するための定量化可能な方法が提供されます。 重点を置く主要なメトリックを特定する場合は、可用性、容量、応答時間に関連するメトリックを検討します。
可用性: エラー率は可用性パフォーマンス メトリックです。 エラー率は、一定期間に失敗した要求の割合を表します。 エラー率の一般的なターゲットは、要求の 0.1% です。
容量: スループットとコンカレンシーは、容量メトリックのサンプルです。 スループットとは、特定の期間内に特定の数のトランザクションを処理する機能を指します。 たとえば、アプリケーションで 1 か月あたり 1 億件のトランザクションを維持する必要がある場合があります。 コンカレンシーは、同時ユーザーまたはアクションの尺度です。
応答時間: 待機時間と読み込み時間は、一般的な応答時間メトリックです。 待機時間は、要求への応答にかかる時間 (200 ミリ秒) です。 読み込み時間は、アプリケーションまたは Web ページが対話型になるのにかかる時間です。 一般的なターゲットは、1 秒未満で完了するサインイン要求の 99% です。
特定のターゲットを設定する
主要なメトリックを特定したら、各メトリックのパフォーマンス ターゲットまたはしきい値を指定する必要があります。 パフォーマンス目標は測定可能で現実的で、ワークロードの目標に合わせて調整する必要があります。 たとえば、ターゲット応答時間を 500 ミリ秒 (ms) 未満に設定したり、ターゲット エラー率を 1% 未満に設定したりできます。 高速や低速などのパフォーマンスの定性的評価を避けます。 数値ターゲットを使用すると、時間の経過と同時に客観的にパフォーマンスを評価できます。 特定のパフォーマンス目標を設定するときは、次の推奨事項を検討してください。
顧客を考慮する: パフォーマンス目標を設定するときは、顧客中心の視点を採用します。 パフォーマンスの最終的な判断者として顧客を認識することは、パフォーマンス目標が顧客の期待に合っていることを保証するのに役立ちます。 この調整には、組織の目標と顧客ベースの個別の要件の両方を考慮する必要があります。 これら 2 つの側面を統合すると、目的のカスタマー エクスペリエンスと全体的なワークロードの有効性を反映するようにパフォーマンス ターゲットを調整できます。 顧客の期待を考慮したパフォーマンス目標を定義することで、高品質のカスタマー エクスペリエンスを提供し、顧客のニーズを満たすように努めることができます。
パーセンタイルの使用: P99、P95、P50 などのパーセンタイルは、パフォーマンス評価の結果を表す業界標準です。 パーセンタイルは、数値に含まれるデータの量を示すメジャーです。 たとえば、P99 はデータの 99% をカバーします。 単純な平均ではなくパーセンタイルを使用して、ワークロードのパフォーマンスをより包括的に理解します。 パーセンタイルを測定するには、一定期間にわたってパフォーマンス データを収集します。通常は、監視ツールまたはログメカニズムを使用します。 次に、このデータを分析して、異なるパーセンタイルでの応答時間の値を決定します。
パフォーマンス ターゲットを文書化して公開する
パフォーマンス ターゲットの文書化と公開は、すべてのパフォーマンス ターゲットを一元的な場所に記録することです。 パフォーマンス目標の達成は、開発チームと運用チームの間で共有される責任です。 ワークロードが常にこれらのターゲットを満たすか、または超過していることを確認するには、アクションを実行するための情報とアクセス権をチームに提供します。 パフォーマンス目標を文書化して公開するには、次の推奨事項を検討してください。
パフォーマンス目標を文書化する: すべてのパフォーマンス目標を文書化します。 すべてのパフォーマンス目標が、開発チームと運用チームの両方から簡単にアクセスできる一元化された場所に文書化されていることを確認します。 これは、調整を促進し、リアルタイムの意思決定に役立ちます。
パフォーマンス目標を公開する: すべての責任あるチームは、パフォーマンス目標から実行可能なタスクを確認して作成できる必要があります。 ダッシュボードやレポートなどの情報ラジエーターを使用して、パフォーマンス目標にアクセスできるようにします。
アクション可能にする: ドキュメントと情報ラジエーターは、明確な次の手順を提案する必要があります。 たとえば、エラーが増加すると、すぐにチェックが求められる場合や、ターゲットを一貫して満たすと、そのベンチマークの再評価が提案される場合があります。
顧客からのフィードバックを評価する
顧客からのフィードバックを評価するには、顧客の応答と提案を積極的に探し、分析する必要があります。 顧客からのフィードバックを積極的に収集して分析することで、ニーズと期待に関する貴重な洞察が得られます。 定期的なコミュニケーションは、好みや技術動向の変化に合わせてパフォーマンス目標を調整するのに役立ちます。 顧客のニーズに焦点を当てることは、ワークロードが技術ベンチマークと一致するだけでなく、継続的な絞り込みを行っていることを意味します。 このアプローチでは、顧客満足度を重視することで、ワークロードが長期的に関連性があり、成功を収めることができます。
Azure ファシリテーション
パフォーマンス目標の設定: Azure Advisor には、パフォーマンス目標を通知できる パフォーマンスに関する推奨事項 が用意されています。
Azure Monitor は、Azure リソースを監視し、パフォーマンス目標を測定するための完全な機能セットを提供するフルスタック監視サービスです。 プラットフォームメトリックを収集し、すぐに使用できるダッシュボードを提供します。 これにより、メトリックに基づいてアラートを構成できます。 また、メトリックを格納して関連付け、単一の信頼できるソースを確保します。
関連リンク
パフォーマンス効率のチェックリスト
推奨事項の完全なセットを参照してください。