パフォーマンスデータの収集に関するレコメンデーション
この Power Platform Well-Architected Performance Efficiencyチェックリストの推奨事項に適用されます:
| 体育:04 | パフォーマンス データを収集します。 ワークロード コンポーネントとフローは、自動的、継続的、かつ意味のあるメトリックとログを提供する必要があります。 アプリケーション、プラットフォーム、データ、オペレーティング システム レベルなど、ワークロードのさまざまなレベルでデータを収集します。 |
|---|
パフォーマンス データの収集は、ワークロードのパフォーマンスに関する情報を提供するメトリックとログを収集するプロセスです。 このデータには、メトリック と呼ばれる数値が含まれます。 メトリックは、特定の時点におけるシステムの状態を表します。 パフォーマンス データには、レコードに整理されたさまざまな種類のデータを含むログも含まれます。
パフォーマンス データを収集することで、ワークロードのパフォーマンスを監視および分析できます。 この情報を使用して、パフォーマンスのボトルネックを特定し、問題をトラブルシューティングし、データに基づいた意思決定を行ってワークロードの全体的なパフォーマンス効率を向上させることができます。
データに基づく洞察がなければ、根本的なパフォーマンスの問題や最適化の機会に気付かない可能性があります。 潜在的な結果として、応答 時間の遅延、スループットの低下、そして最終的には最適ではないユーザー エクスペリエンスが実現されます。 さらに、パフォーマンス データが不足すると、タイムリーに問題を診断してトラブルシューティングすることが困難になり、ダウンタイムが長引いて生産性が低下します。
定義
| 任期 | Definition |
|---|---|
| 活動ログ | リソースの削除など、リソースに対する管理操作を追跡するログ。 |
| アプリケーション ログ | アプリケーション イベント、エラー、サインインやデータベース接続の失敗などのその他のアクティビティに関する情報を追跡するログ。 |
| アプリケーション パフォーマンス監視 (APM) ツール | アプリケーションのパフォーマンスを監視して報告するツール。 |
| コード インストルメンテーション | アプリケーション コードの観点からパフォーマンス メトリックを直接的または間接的にキャプチャします。 キャプチャされたメトリックには、フロー メトリック、リソース使用量、言語またはランタイムに固有のメトリックが含まれます。 |
| 分散トレース | 分散ワークロード コンポーネント全体のメトリックを収集し、相関させます。 |
| メトリック シンク | 分析のために時系列データを相関させるメトリックの保存先。 |
| プラットフォーム ログ | リソース ログ、アクティビティ ログ、監査ログを含む診断および監査データ。 |
| プラットフォーム メトリック | 特定の時点におけるワークロードのパフォーマンスを記録する数値。 |
| リソース ログ | システムが生成するデータ。 システムの状態に関する情報を提供します。 |
| 構造化ログ | 通常はキーと値のペアとして、メッセージをログに記録するための意味のある形式を定義します。 |
主要な設計戦略
パフォーマンスの最適化には、パフォーマンス目標に対するワークロードまたはフローの現在のパフォーマンスを測定するためのデータが必要です。 コードとインフラストラクチャのパフォーマンスを測定するには、パフォーマンス目標 に対して適切な量と多様性のデータを収集する必要があります。 ワークロード内のすべてのコンポーネントとフローが継続的かつ意味のあるメトリックとログを自動的に生成することを確認します。 このデータは、アプリケーション、プラットフォーム、ストレージ、オペレーティング システムなどのさまざまなレベルから取得する必要があります。 包括的なパフォーマンス データの収集により、パフォーマンスを総合的に把握し、非効率性や改善の余地を正確に特定できるようになります。
パフォーマンス データの一元化
パフォーマンス メトリックとログの集中化とは、さまざまなソースからパフォーマンス メトリックとログを収集し、それらを中心的な場所に保存するプロセスです。 中央メトリック シンクと中央ログ シンクを作成します。 この集中化により、さまざまなシステムやコンポーネントにわたるパフォーマンス メトリックとログに簡単にアクセスし、分析および監視できるようになります。 メトリックとログを一元管理することで、ワークロードのパフォーマンスを可視化できます。 ワークロードのパフォーマンス メトリックとログを集約して保存できる適切なプラットフォームまたはツールを選択します。
トレードオフ: メトリックとログを収集するコストを理解します。 一般的に、収集するメトリックとログが増えるほど、コストが高くなります。
セグメント パフォーマンス データ
パフォーマンス データをセグメント化するには、メトリックとログをその発生元、目的、または ポイントする に基づいて整理および分類する必要があります。 たとえば、運用データと非運用データを分離したり、パフォーマンス目標とビジネス メトリックを区別したりする必要があります。 データをセグメント化すると、特定の環境を最適化し、トラブルシューティングを容易にし、パフォーマンス監視の不正確さを制限するのに役立ちます。 さまざまなデータ タイプを明確に区別することで、関連するメトリックをより効率的にキャプチャ、分析、対応し、ワークロード目標に合わせて 位置を合わせる ワークロードの健全性を向上させることができます。 パフォーマンス データをセグメント化するには、次のレコメンデーションに従ってください。
運用データと非運用データを分離します。 環境ごとにデータを分離することで、各環境を集中的に監視および最適化できます。 運用環境では、ユーザーやビジネス オペレーションに直接影響するパフォーマンスの問題をより適切に特定し、対処できます。 非運用環境では、データを分離することで、運用環境に展開する前のテスト段階での効果的なトラブルシューティングと微調整が容易になります。
各 接続 内で1セットのデータを使用します。 パフォーマンス ターゲットに 1 つのデータ セットを使用し、パフォーマンス ターゲットに関連するアラートに別のデータ セットを使用しないでください。 異なるデータセットを使用すると、アラートが不正確になり、パフォーマンス監視の有効性が損なわれます。
パフォーマンス目標とビジネス指標を分離します。 運用チームと開発チームは、パフォーマンス目標を使用してワークロードの健全性を監視し、ビジネス目標を達成します。 ビジネス メトリックは、ビジネス目標または顧客レポートに関連しています。 データが直接重複している場合でも、ビジネス メトリックを別のデータ ストリームでキャプチャします。 この分離により、適切なデータを柔軟に取得し、そのデータを個別に分析できるようになります。
保持ポリシーを定義する
保持ポリシーは、パフォーマンス データを保持する期間を指定します。 これらのポリシーを確立すると、ストレージを効率的に管理し、分析に必要なデータのみにアクセスできるようになります。 このようなポリシーは、パフォーマンスの向上をサポートし、コンプライアンス基準を満たします。 すべての環境で効果的なトラブルシューティングと監視を可能にするには、ログとメトリック データの保持ポリシーを構成する必要があります。 たとえば、ログとメトリックは、テストの 環境 よりも本番の 環境 でより長い時間保持する必要がある場合があります。 保持期間は、組織の要件とコンプライアンス規制に一致する必要があります。 分析および監査の目的でデータを保持する期間を決定します。 すぐに分析する必要のないデータをアーカイブします。
パフォーマンス データを収集する
データの収集には、主にインストルメンテーション コードを通じて収集された、スループット、レイテンシ、完了時間などのワークロードのパフォーマンス メトリックの監視と分析が含まれます。 ワークロード パフォーマンス データは、アプリケーションの健全性とパフォーマンスに関する貴重な洞察を提供します。 パフォーマンス データを監視および分析することで、問題を特定してトラブルシューティングし、パフォーマンスを最適化し、ワークロードに関する情報に基づいた意思決定を行うことができます。
インスツルメント コード
インストルメンテーションとは、コード スニペットまたはアクションをワークロード コードに埋め込むプロセスを指します。たとえば、キャンバス アプリで カスタム トレース イベント を作成します。 インストルメンテーションの目的は、ワークロードの実行中にパフォーマンス データをキャプチャすることです。 ワークロードの重要な操作を強調するメトリックを収集することが重要です。 スループット、レイテンシ、完了時間などの指標に注目します。 ビジネス関連の業務を他の業務と区別することが重要です。 ビジネス運営に関連するデータの場合、そのメタデータが明確に追跡および保存できるような構造になっていることを確認してください。 コード インストルメンテーション は次のような利点があります。
パフォーマンスのボトルネックの特定: 経過時間などのメトリックを追跡することで、ボトルネックを特定し、それに応じてコードを最適化できます。
負荷時のシステム動作の評価: さまざまなストレス シナリオでワークロードがどのように実行されるかを確認できます。 このデータは、スケーラビリティ、同時実行性、リソースの使用に関連する問題を特定するのに役立ちます。
ワークロードの健全性と可用性の追跡: 主要業績評価指標がリアルタイムで監視されるため、アプリケーションのパフォーマンスと可用性に影響する潜在的な問題に関するアラートを受け取ることができます。
ユーザー エクスペリエンスの向上: ユーザーがワークロードとどのように対話しているかについての洞察を得ることができます。 この情報を使用して、ユーザー エクスペリエンスを最適化し、改善すべき領域を特定します。
容量を計画し、リソースを割り当てる: インストルメンテーションによって収集されるパフォーマンス データは、ワークロードのリソース要件に関する貴重な洞察を提供します。 この情報は、容量の計画やリソースの割り当てに関する意思決定に役立ちます。
パフォーマンス監視のためにコードをインストルメント化する場合は、次の戦略を考慮してください。
APMツールを使用する: アプリケーション パフォーマンス監視 (APM) ツールは、メトリック、トレース、ログなどのパフォーマンス データを収集して分析します。 APM ツールは、コードレベルのインストルメンテーション、トランザクション トレース、パフォーマンス プロファイリングなどの機能を提供します。
カスタム インストルメンテーション: 開発者はカスタム コードを追加して、アプリケーションとワークロードに固有のパフォーマンス メトリックを収集できます。 カスタム インストルメンテーションを使用すると、実行時間を測定したり、リソースの使用状況を追跡したり、特定のイベントをキャプチャしたりできます。
トランザクション時間のキャプチャ。 トランザクション時間のキャプチャは、パフォーマンス監視の一環として、主要な技術機能のエンドツーエンドの時間を測定することに関連しています。 アプリケーション レベルのメトリックには、エンドツーエンドのトランザクション時間を含める必要があります。 これらのトランザクション時間には、データベース クエリ、外部 API 呼び出しの 応答 時間、処理手順の失敗率などの主要な技術機能がカバーされる必要があります。
テレメトリ標準を使用します。 OpenTelemetry などのテレメトリ標準に基づいて構築された APM ツール インストルメンテーション ライブラリとツールの使用を検討してください。
リソース パフォーマンス データを収集する
リソース パフォーマンス データを収集することで、ワークロードの健全性と動作に関する分析情報を得ることができます。 リソース パフォーマンス データは、容量計画の鍵となるリソースの使用状況に関する情報を提供します。 このデータはワークロードの健全性に関する分析情報も提供し、問題の検出とトラブルシューティングに役立ちます。 次のレコメンデーションを検討してください:
すべてのリソースのメトリックとログを収集します。 各サービスには、リソースの機能に固有のメトリックのセットがあります。 これらのメトリックは、リソースの健全性とパフォーマンスを理解するのに役立ちます。
プラットフォーム ツーリングの使用 Azure Monitor Insights などの組み込みおよび統合された監視ソリューションからインスピレーションを得ます。 このツールはパフォーマンス操作を効率化します。 プラットフォームを構築する際にはプラットフォーム ツールを検討し、カスタム ツールやレポートに投資してください。
ネットワーク トラフィックの監視 ネットワーク トラフィックを監視するということは、データがネットワーク経路を移動する際のフローとパターンを追跡および分析することを意味します。 トラフィック分析を収集し、サブネット境界を通過するトラフィックを監視します。 あなたの目標は、ネットワーク パフォーマンスを分析して最適化することです。
データベースとストレージデータを収集する
多くのデータベースおよびストレージ システムでは、独自の監視ツールが提供されています。 これらのツールは、それらのシステムに固有のパフォーマンス データを収集します。 データベースおよびストレージ システムでは、パフォーマンス関連のイベントやインジケーターを含むログが生成されることがよくあります。 データベース データとストレージ パフォーマンス データを収集して、ボトルネックを特定し、問題を診断し、情報に基づいた意思決定を行い、ワークロードの全体的なパフォーマンスと信頼性を向上させることができます。 次の種類のパフォーマンス データの収集を検討してください。
スループット: スループットは、一定期間にストレージ システムから読み取られたデータまたはストレージ システムに書き込まれたデータの量を測定します。 スループット データはデータ転送能力を示します。
レイテンシ: レイテンシは、ストレージ操作が続く時間を測定します。 レイテンシ データは、ストレージ システムの応答性を示します。
IOPS (1秒あたりのI/O操作): ストレージ システムが1秒間に実行できる読み取り操作または書き込み操作の数に関するデータ。 IOPS データは、ストレージ システムのスループットと応答性を示します。
容量使用量: 容量使用量は、使用されているストレージ容量の量と使用可能な量です。 キャパシティ使用データは、組織が将来のストレージ ニーズを計画するのに役立ちます。
コネクターのパフォーマンス データを収集する
統合サービス操作が完了するまでの待機時間は、ワークロードの全体的なパフォーマンスの低下につながる可能性があります。 ワークロードでコネクタを使用してサービスを統合する場合は、各コネクタ操作に費やされた時間を測定してその影響を評価し、ワークロード設計を最適化するかどうかを決定することを検討してください。 サービスに応じて、実行履歴またはカスタム ロジックを使用して、コネクタ操作に費やされた時間を取得できます。
データの検証と分析
パフォーマンス データは、パフォーマンス ターゲットと一致するように 位置を合わせる する必要があります。 データは、パフォーマンス目標に関連して、ワークロードまたはフローのパフォーマンスを完全かつ正確に表す必要があります。 たとえば、Web サービスの 応答 時間のパフォーマンス目標は 500 ミリ秒です。 頻繁に評価を行うことでパフォーマンスの問題を早期に検出し、軽減できるため、データの分析をルーチン化します。
通知の作成。 パフォーマンスの問題を迅速に特定して修正できる、実用的なアラートがあると便利です。 これらのアラートは、違反したパフォーマンスしきい値、潜在的なビジネスへの影響、および関連するコンポーネントを明確に示す必要があります。 まず、一般的なアラートと推奨アラートを設定します。 時間の経過とともに、特定のニーズに基づいてこれらの基準を変更できます。 これらのアラートの主な目的は、パフォーマンスの低下が重大な問題に発展する前に、潜在的なパフォーマンスの低下を予測することです。 外部依存関係に対してアラートを設定できない場合は、依存関係呼び出しの期間などの間接的な測定値を収集する方法を考案することを検討してください。
データ収集制限を設定する 収集するデータの量とその保持期間に論理的な制限を決定して設定します。 テレメトリでは、膨大な量のデータが生成されることがあります。 最も重要なパフォーマンス指標のみをキャプチャすることに重点を置くか、パフォーマンス データから有意義な分析情報を引き出すための効率的なシステムを導入することが重要です。
Power Platform 促進
アプリケーション パフォーマンス データの収集: Application Insights は、アプリケーションのパフォーマンスと可用性を監視するのに役立つAzure Monitorの機能です。 データは Application Insights Azure Monitor ログに保存され、パフォーマンスとエラー パネルで可視化されます。 データは、Application Insights によって定義された標準スキーマで、使用中の Application Insights 環境にエクスポートされます。 データをエクスポートして、キャンバス アプリをAzureで使用できるようにしたり、コパイロットからテレメトリ データをキャプチャしたり、Azureで使用したりすることができます。 Dataverse Power Automate Application Insights Application Insights Microsoft Copilot Studio Application Insights
Application Insights を使用すると、サーバー および ブラウザー データ ビュー を選択できるようになります。 期間が最も長い操作を特定することで、潜在的な問題を診断できます。
ネイティブ プラットフォーム機能を使用してパフォーマンスを分析します。の分析 Copilot Studio では、副操縦士のパフォーマンスの包括的な概要が提供されます。 人工知能 (AI) テクノロジーを使用して、エスカレーション率、放棄率、解決率に最も大きな影響を与えているトピックを特定します。 パフォーマンス分析情報は、実行時のユーザー データを分析し、モデル駆動型アプリのパフォーマンスを向上させるための優先順位付けされた推奨事項のリストを提供します。 Power Apps
パフォーマンス データの集中化、セグメント化、保持: Microsoft 、 Dataverse、 Power Automate クラウド フロー、モデル駆動型アプリに関する広範なテレメトリがすでに収集されています。 Application Insights 統合 では、環境またはテナント管理者が、Power Platform 管理センターでデータ エクスポート プロセスを設定する際に、Application Insights インストルメンテーション キーを提供します。 セットアップが完了するとすぐに、 Microsoft 環境 について収集されたテレメトリが Application Insights 環境 に送信されます。 Application Insights 統合を使用すると、Application Insights テレメトリ データ モデル に従った、標準化されたテレメトリのセットを受け取ります。 この統合に加えて、 接続 キャンバス アプリを使用して Application Insights 副操縦士からテレメトリ データをキャプチャし、 Microsoft Copilot Studio Azureで使用する こともできます Application Insights。
Azureリソースのパフォーマンス データの収集: ほとんどのAzureサービスは、診断および監査情報を提供するプラットフォーム ログとメトリックを生成します。 診断設定を有効にすると、収集して保存するプラットフォーム ログとメトリックを指定できます。相関関係を確認するには、サポートされているすべてのサービスの診断を有効にし、ログをアプリケーション ログと同じ送信先に送信します。
データベース パフォーマンス データの収集:Microsoft Dataverse と統合 Application Insights。 データ ストリームは現在、Dataverse API 着信呼び出し、Dataverse プラグイン実行呼び出し、および Dataverse SDK 呼び出しに関連するパフォーマンス データを提供しています。 問題を通知するには、パフォーマンスしきい値に基づいてアラートを設定します。
パフォーマンス データの検証と分析: Azure Monitor内では、Azure Monitorログを使用して、アプリケーションやシステムからのログ データを収集、分析、視覚化できます。 ログを集約することで、イベントをクロスクエリし、アプリケーションのパフォーマンスに関する分析情報を得ることができます。 詳細については、Azure Monitor ログのコスト計算とオプション** および Azure Monitor の価格 を参照してください。
Azure Monitor では、特定のパフォーマンス メトリックを監視し、事前定義された条件に基づいて トリガー アラートを生成するアラート ルールを定義できます。 たとえば、応答 時間が指定された制限を超えたときに通知するアラート ルールを作成できます。 アラート ルールを構成して、必要な受信者に通知を送信します。
通知ルールを作成する際は、通知をトリガーする前に満たす必要のある基準を定義することができます。 しきい値、集計方法、時間枠、評価の頻度を設定できます。 基準は、パフォーマンス監視要件に基づいて決定してください。 通知を送信するだけでなく、アラートがトリガーされたときに実行されるアクションを指定することもできます。 アクションには、メールの送信、Webhook の呼び出し、Azure 関数の実行などが含まれます。 特定のアラート シナリオに対応するために適切なアクションを選択します。
使用例
- Azure Monitorによるエンタープライズ監視
- キャンバス アプリでカスタム トレース イベントを作成する
- クラウドフローのカスタムアラートを作成する
- 副操縦士のパフォーマンスと使用状況を分析する Copilot Studio
パフォーマンス効率チェックリスト
完全なレコメンデーションのセットを参照してください。