ワークロードのパフォーマンスを監視するためのアーキテクチャ戦略

この Azure Well-Architected Framework のパフォーマンス効率チェックリストの推奨事項に適用されます。

PE:04 一貫性のあるパフォーマンス測定を確立して、時間の経過と同時に動作を分析し、ベースラインと比較し、低下、非効率性、スケーリングのギャップを検出するために使用できるようにします。

パフォーマンス データがないと、基になる問題や最適化の機会に気付かれずに、ユーザー エクスペリエンスが低下します。

この記事では、待機時間、スループット、およびリソースの動作をキャプチャしてベースラインを確立し、ワークロード全体のパフォーマンス低下を特定する多層パフォーマンス測定を実装するための設計戦略について説明します。

この記事の重要な戦略は、 監視システムを設計するための OE:07 アーキテクチャ戦略で説明されている、可観測性の基本的な運用方法に基づいて構築されています。 監視プラクティスの実装に関するガイダンスについては、 監視設計ガイドを参照してください。 まず、これらのリソースを確認することをお勧めします。 このガイドの推奨事項は、パフォーマンスを対象とします。 信頼性の詳細については、信頼性の高い 監視とアラート戦略を設計するための RE:10 アーキテクチャ戦略に関するページを参照してください。

定義

任期 定義
アクティビティ ログ リソースの削除など、リソースに対する管理操作を追跡するログ。
アプリケーション ログ アプリケーション イベント、エラー、サインインやデータベース接続の失敗などのその他のアクティビティに関する情報を追跡するログ。
アプリケーション パフォーマンス監視 (APM) ツール アプリケーションのパフォーマンスを監視し、報告するツール。
Baselines 時間の経過に伴う誤差、回帰、改善を検出するための参照ポイントとして使用される予想されるシステム パフォーマンス メトリック。
コード計測 アプリケーション コードの観点による、パフォーマンス メトリックの直接的または間接的な取り込み。 取り込まれるメトリックには、フロー メトリック、リソース使用量、言語またはランタイムに固有のメトリックが含まれます。
分散トレース エンドツーエンドのトランザクション フローを理解するために、分散ワークロード コンポーネント間でメトリックを収集および関連付けます。
Latency 要求を開始してから応答を受信するまでの時間の遅延。システムの応答性を測定します。
Metrics 時間の経過に伴うワークロードのパフォーマンスの動作を記録する数値測定値。通常は、分析のために集計されます。
パーセンタイル (p50、p95、p99) パフォーマンス分布を示す統計メジャー。p50 は一般的なパフォーマンスを表し、p95 は負荷の最も高いユーザー エクスペリエンスを示し、p99 は最悪の場合のパフォーマンスをキャプチャします。
プラットフォームのメトリック 特定の時点におけるワークロードのパフォーマンスを記録する数値。

パーセンタイル ベースのメトリックを使用する

平均ではなくパーセンタイル (p50、p95、p99) を使用して、待機時間、応答時間、読み込み時間などのパフォーマンス メトリックを測定します。 平均は誤解を招く可能性があります。 ほとんどの要求は高速ですが、いくつかの要求が非常に遅い場合、平均は悪いエクスペリエンスを隠します。

パーセンタイルは、ユーザーエクスペリエンスを理解する上で重要な分布の端の挙動を示します。 p50 は一般的なパフォーマンスを表し、p95 は負荷がかかっているほとんどのユーザーエクスペリエンスを示し、p99 は最悪の場合のパフォーマンスまたは外れ値をキャプチャします。

監視ツールを使用してパフォーマンス データを収集し、定義された時間枠のパーセンタイルとして表します。 これらは、監視、アラート、パフォーマンス分析のベースラインとして使用します。

パフォーマンス向上の境界を定義する

測定に含まれる内容を正確に把握できるように、明確なパフォーマンス境界を定義します。 1 つの数値として扱うのではなく、システム全体の待機時間を分割します。 たとえば、エッジ サービス、ゲートウェイ、コンピューティング、依存関係である各レイヤーへの属性時間を使用して、遅延が実際に発生する場所を確認します。

制御できるもの、つまりコード、サービス、インフラストラクチャ、直接の依存関係と、クライアント側の条件、DNS 解決、ISP 待機時間、デバイスの制約など、制御できない外部要因とを分離します。 この区別により、誤った属性の発生を防ぎ、完全なエンド ツー エンドのユーザー エクスペリエンスを反映しながら、変更を加えることができる領域に最適化が集中し続けます。

パフォーマンスの問題がユーザー エクスペリエンスに影響するタイミングと場所を評価します。 システムの制御可能な部分の改善を通じて、設計または軽減によってその劣化を補正します。

環境と目的別に信号をセグメント化する

各シグナルが明確なコンテキストを反映するようにパフォーマンス データをセグメント化します。 動作が異なる信号や異なる決定に役立つシグナルの混在を避けるために、環境と目的によって分離します。

運用環境と非運用環境のデータを分離します。 運用データは実際のユーザーへの影響を反映しており、監視とアラートを促進する必要があります。 非運用環境のデータはテストとチューニングに役立ちますが、運用環境と組み合わせて使用すると結果が歪み、実際の問題が隠されます。

ビジネス メトリックからパフォーマンス メトリックを分離します。 パフォーマンス メトリックはシステムの動作とワークロードの正常性を追跡し、ビジネス メトリックは結果を追跡します。 重複する場合でも、それぞれを個別に分析して使用できるように、個別のストリームに保持します。

スコープ付きアクション可能なパフォーマンス アラートを作成する

アラートの目的は、ユーザーに表示される、またはビジネスに影響を与える状態になる前に、パフォーマンスの低下を早期に検出することです。 エンドツーエンドのユーザー エクスペリエンスと、負荷がかかっている重要なシステム パスを表すコア内部トランザクションという 2 つのレベルでアラートを作成します。

ターゲットとアラートの両方に対して、各環境内で一貫性のある単一のデータセットを使用します。 アラートがパフォーマンス 目標とは異なるデータに基づいている場合、信頼できなくなり、信頼しにくくなります。

アクション可能で、パフォーマンスの結果に明確に関連付けられたアラートを作成します。 各アラートは、どのしきい値に持続的な侵害があったか、潜在的な影響を受け、関連するコンポーネントを示す必要があるため、調査する場所と影響を明確にします。 標準の既知のしきい値から始めて、観察されたシステムの動作とワークロードの特性に基づいて、時間の経過と共にそれらを調整します。

外部依存関係に対する直接アラートが不可能な場合は、依存関係呼び出しの期間、エラー率、タイムアウト動作などの間接的なシグナルを使用して、システムのパフォーマンスへの影響を概算します。

弾力性を監視する

需要イベントとスケーリング イベントの変化にシステムがどのように対応するかを測定します。

コールド スタートと初期化の待機時間を追跡して、起動時のオーバーヘッドが応答性に与える影響 (特にスケールアウト イベント中) を把握します。 スケールアウトとスケールインの動作を監視して、システムが負荷の変化にどの程度迅速に適応するか、スケーリング アクションが需要に合わせて進むかどうかを評価します。

時間の経過に伴うパフォーマンスの追跡

設計と外部要因の変化に伴い、パフォーマンスがどのように進化するかを追跡します。

予想されるシステム パフォーマンスを表すベースラインを確立し、現在の動作を比較して、回帰や改善を含む誤差を検出します。

パフォーマンスの変更を、デプロイ、構成の更新、スケーリング アクションなどの運用イベントに接続します。 これらのイベントを使用してタイムラインに注釈を付けて、動作のシフトが明確なコンテキストを持ち、原因の可能性が高いまでトレースできるようにします。

この継続的な可視性は、エンジニアリング上の意思決定のためのフィードバック ループとして使用します。 計画と優先順位付けに関するパフォーマンスの分析情報を提供し、インシデント対応だけでなく、通常の作業への入力として扱います。

システムの進化に伴い、パフォーマンス目標を継続的に改善します。 ターゲットが現実的で実際のユーザー エクスペリエンスと一致するように、観察された動作と使用パターンに基づいて SLO、しきい値、および期待値を調整します。

アプリケーションのパフォーマンス データを収集する

スループット、待機時間、完了時間などのアプリケーションのパフォーマンス メトリックを、主にインストルメント化コードを使用して収集する必要があります。

パフォーマンスが最も高い重要な実行パスをインストルメント化します。主要な要求フロー、リソースを集中的に使用する操作、外部の依存関係や再試行が発生するポイントなどです。 トランザクションの可視性をエンドツーエンドで確保し、実行時間とその関連する手順の合計を測定できるようにします。

次の 3 種類のパフォーマンス 信号をキャプチャします。

  • 集計されたパフォーマンス動作のメトリック (待機時間の分布、スループット、エラー率)
  • 要求パスとシステム コンポーネント間で時間がどのように分散されるかを理解するためのトレース
  • 特定の手順またはイベントでの詳細な実行コンテキストのログ

これらのシグナル間で一貫性のあるメタデータを使用して、パフォーマンス データをシステムのレイヤー間およびサービス間で関連付けることができます。

ワークロード固有の動作やボトルネックを説明するために追加の細分性が必要な場合を除き、プラットフォームによって既に公開されている低レベルのパフォーマンスシグナルを複製しないでください。

リソース パフォーマンス データを収集する

リソース レベルのパフォーマンス データを収集して、負荷の下でのインフラストラクチャ コンポーネントの動作と、それらがワークロード全体のパフォーマンスにどのように影響するかを理解します。

各サービスは、正常性とパフォーマンスの特性を反映するプラットフォーム固有のメトリックを公開します。 診断設定を使用してこのデータをエクスポートし、短期間のプラットフォーム保有期間を超えてアラート、ダッシュボード、長期的な分析にアクセスできるようにします。

すべてのリソースのメトリックとログを収集します。 予想される範囲に対するコンピューティングとストレージの使用率を追跡して、プロビジョニング不足によって待機時間が発生せず、負荷がかかっているパフォーマンスが低下していないことを確認します。 また、P99 の使用状況を確認し、リソースの残りのヘッドルームと比較することで、このデータを使用してオーバープロビジョニングを検出することもできます。

リソース パフォーマンスの一部としてネットワーク トラフィックを監視します。 サブネットとサービス境界を越えたトラフィック フローを分析して、ワークロードのパフォーマンスに影響を与える可能性がある待機時間、輻輳、データ転送パターンを理解します。

データベースとストレージのデータを収集する

データベース システムとストレージ システムでは、ボトルネックの特定、容量の検証、ワークロードの動作の理解のための特殊なパフォーマンス シグナルが生成されます。 これらの信号は、通常、組み込みの監視ツールとシステムによって生成されたログから取得されます。

主要なパフォーマンス ディメンションに焦点を当てます。

Area 測定対象 それがあなたに伝えるもの
Throughput 時間の経過に伴う読み取り/書き込みボリューム データ転送容量
Latency ストレージ操作あたりの時間 ストレージの応答性
IOPS 1 秒あたりの読み取り/書き込み操作 トランザクション処理機能
容量の使用 使用済みストレージと使用可能なストレージ スケーリングと容量計画のニーズ

データベースの場合は、監視をワークロード固有の動作に拡張します。

Area 測定対象 それがあなたに伝えるもの
検索性能 実行時間、頻度、リソース使用量 データ アクセス パターンの効率
トランザクションのパフォーマンス 期間、同時実行、ロックの競合 競合とトランザクションの効率
インデックスのパフォーマンス 断片化、使用、最適化への影響 クエリアクセラレーション構造の有効性
リソースの使用 CPU、メモリ、ディスク、ネットワーク システム レベルの制約
接続のメトリック アクティブ、失敗、中止された接続 安定性と接続圧力
トランザクションレート 1 秒あたりのトランザクション数 ワークロードの強度と時間の経過に伴う変化
エラー率 データベースエラーと障害 信頼性とパフォーマンスの低下信号

これらのシグナルを一緒に使用して、低速なクエリ、リソースの飽和、および構造的な非効率性を区別します。 これにより、ストレージ システムとデータベース ワークロードの両方で、ターゲットを絞った最適化が可能になります。

オペレーティング システムのパフォーマンス データを収集する

インフラストラクチャ ベースのワークロードの場合は、オペレーティング システム レベルのメトリックを収集して、コンピューティング リソースがどのように利用されているか、およびリソースの制約が発生する可能性がある場所を把握します。

負荷が発生しているシステムの時間ベースの動作をキャプチャするために、一定の間隔で OS パフォーマンス カウンターをサンプルします。

Area 測定対象 それが示す内容
CPU CPU 使用率 (ユーザー/特権)、CPU キューの長さ コンピューティングの飽和とスケジューリングの負荷
Processes スレッド数、ハンドル数 アプリケーションと OS レベルのプロセス負荷
メモリ コミット済みメモリ、使用可能なメモリ、ページング率、スワップ使用量 メモリ プレッシャーとページング アクティビティ
Disk 読み取り/書き込み速度、スループット、ディスク使用率 ストレージ I/O のパフォーマンスとボトルネック
Network インターフェイス スループット、RX/TX エラー ネットワークの容量と伝送に関する問題

これらのシグナルを使用して、オペレーティング システム レベルでリソースの飽和状態を特定し、アプリケーション レベルの非効率性とインフラストラクチャの制約を区別します。

必要に応じて合成データを生成する

システムが一貫して使用されていない場合、トラフィックが戻ったときにパフォーマンスが良いかどうかを判断するのは困難です。

これに対処するには、システムを通じて自動リクエストを送信するシンセティックトランザクションを使用します。 これらは、実際のユーザーやデータに影響を与えることなく、実際の使用状況をシミュレートします。 これは、システムの一部をアクティブに保ち、一貫したパフォーマンス メトリックを生成し、不規則な使用が隠れる可能性のあるパターン (時間帯の問題など) を明らかにするのに役立ちます。

Azureファシリテーション

Azure Monitor は、ワークロード全体のパフォーマンス データを収集、分析、および応答するための統合プラットフォームを提供します。 アプリケーション、インフラストラクチャ、外部ソースのデータを共通のデータ プラットフォームに集約します。

データ収集とストレージ: Log Analytics ワークスペース を使用して、構成可能な 保持ポリシーを使用してパフォーマンス データを一元化します。 複数のワークスペースを作成して、環境またはコンプライアンス要件別にデータをセグメント化します。

アプリケーションの監視: Application Insights は、 要求率、応答時間、例外など、アプリケーション レベルのテレメトリを収集します。 分散トレースを有効にして、分散コンポーネント間でパフォーマンスを関連付ける。

インフラストラクチャの監視: すべての Azure サービスで 診断設定 を有効にして、プラットフォームのログとメトリックを収集します。 詳細な VM パフォーマンス データには 、Azure Diagnostics 拡張機能 を使用します。 特定のプラットフォームのテレメトリ オプションについて説明します。 たとえば、Kubernetes クラスターは Prometheus 統合を通じて豊富なパフォーマンス テレメトリを出力します。

データベースとストレージ: Azure Monitor は、Azure SQL Database、MySQL、PostgreSQL、およびストレージ サービスの組み込みの監視を提供します。 Azure Storage Analytics は、BLOB、テーブル、キュー ストレージ全体のスループットや待機時間などの主要なパフォーマンス インジケーターを追跡します。

アラートと分析: カスタマイズ可能なしきい値、時間枠、アクション (電子メール、Webhook、Azure Functions) を使用してアラート ルールを作成します。 Azure Monitor ログを使用して、パフォーマンス データをクエリをクロスして関連づける。 価格の詳細については、 Azure Monitor の価格に関するページを参照してください。

例示

パフォーマンス効率チェックリスト

推奨事項の完全なセットを参照してください。

パフォーマンス効率チェックリスト

  • Last updated on