適切なサービスと機能を選択するためのレコメンデーション
この Power Platform Well-Architected Performance Efficiencyチェックリストの推奨事項に適用されます:
| PE:03 | 適切なサービスを選択します。 サービスと機能は、ワークロードのパフォーマンス目標を達成し、予想される容量の変化に対応する能力をサポートする必要があります。 選択においては、プラットフォーム機能を使用するか、カスタム実装を構築するかの利点も考慮する必要があります。 |
|---|
このガイドでは、ワークロードに適したサービスを選択するためのレコメンデーションについて説明します。 次のレコメンデーションは、ワークロードの要件と要求に最適なサービスを選択するのに役立ちます。 ワークロードの要件を処理するように設計されたサービスを使用すると、ワークロードがパフォーマンス目標を満たすことが保証されます。 ワークロードに不適切なサービスを選択した場合、そのサービスがワークロードの要求に対応できない可能性があります。 サービスが不十分だと、応答時間が遅くなったり、ボトルネックが発生したり、ワークロード障害が発生したりする可能性があります。
定義
| 任期 | Definition |
|---|---|
| Region | 一連のデータセンターを含む地理的境界。 |
| リソース | クラウド サービス プロバイダー内で作成、構成、利用できる単一のエンティティまたはコンポーネント。 |
| サービス | クラウド サービス プロバイダーからの製品またはサービス。 |
| ストレージ サービス | オブジェクト、ブロック、およびファイルのストレージを提供するサービス。 |
主要な設計戦略
選択するサービスは、ワークロードのパフォーマンス目標と一致し、将来の容量ニーズに適応できるものでなければなりません。 ワークロードが拡大または進化するにつれて、使用するサービスは、大幅な調整を必要とせずにパフォーマンス基準に一致するようになります。 プラットフォーム機能とカスタム実装のバランスを考慮してください。 プラットフォーム機能は即時のソリューションを提供しますが、カスタムビルドのオプションは正確な調整を提供します。 全体的なソリューションでは、組み込みプラットフォーム機能の特定のギャップを埋めることを目的としたカスタムビルドのオプションを使用して、両方のオプションを組み合わせるのが一般的です。 サービスの選択は、利便性とカスタマイズのトレードオフを考慮し、将来を見据えて特定のニーズに合わせて調整する必要があります。
ワークロード要件を理解する
ワークロード要件を理解するということは、ワークロードの技術的および機能的な要求を把握することを指します。 この分析は、ワークロードを実行するために必要なリソース、ストレージ、ネットワーク、およびその他の仕様を決定するのに役立ちます。 サービスをワークロードの特定のニーズに合わせて調整すると、リソースの過剰プロビジョニングや使用不足を防ぐことができます。
ワークロードのニーズと特性を評価して要件を決定し、各層のワークロード要件をパフォーマンス目標に合わせます。 制約や依存関係を考慮する必要があります。 ワークロードの要件を理解すると、情報に基づいた意思決定を行うことができます。 適切なインフラストラクチャを決定し、ピーク負荷や需要の変動に対処するための戦略を実装できます。
パフォーマンス目標を達成します。 ワークロードのパフォーマンス目標を満たすことができるサービスを選択します。 サービスがパフォーマンスのニーズをサポートできること、およびそのパフォーマンスを監視できるよう徹底します。 重要なコンポーネントのパフォーマンス データを収集します。
組織の制限を考慮してください。 展開するサービスに対して組織が課す可能性のある制限について理解しておいてください。 ソリューションを設計するときは、これらの制限を考慮してください。
コンプライアンスとセキュリティの要件を考慮してください。 コンプライアンスとセキュリティの要件は、選択するサービスと構成に影響を与える可能性があります。 選択したサービスが、ストレージ、暗号化、アクセス制御、監査ログ、データの場所に関連する要件を満たしていることを確認します。
チームのスキルを考慮してください。 チームはワークロードを構築および維持します。 サービスによって必要なスキルは異なります。 チームが使い方を理解しているサービスを選択するか、サービスを選択する前にトレーニングを行うことを確約してください。 チーム メンバーがサービスを効果的に使用し、パフォーマンスを最適化するための専門知識と知識を備えていることを確認します。
トレードオフ: Power Platform サービスは特定の機能を提供しますが、カスタマイズが制限される可能性があります。 カスタムビルドコンポーネントを含むワークロードは、より柔軟性が高いかもしれませんが、Power Platform サービスのみを使用するワークロードと比較して、より多くの管理と構成が必要になる場合があります。
サービスを理解する
サービスを理解するには、プラットフォームのツールとサービスの能力、制限、機能を知ることが重要です。 サービスを理解することで、組み込み機能を使用できるようになるため、複雑なカスタム ソリューションの必要性が減り、パフォーマンス効率が向上します。
サービスを選択する前に、さまざまな要素を考慮し、サービスを総合的に理解してください。 プラットフォームが提供するサービスとツールを調査し、評価します。 ワークロード要件に最も適したサービスとツールを決定します。
サービス制限を理解する
サービス制限は、サービスが設定する事前定義されたしきい値または境界です。 サービス制限は、そのサービス内のリソースまたは機能の最大使用量を定義します。 サービスの制限を理解していれば、リソースの競合、パフォーマンスの低下、予期しないサービスの中断などの問題を回避できます。 ワークロードを適切に計画し、拡張できます。 計画では、データ量、処理能力、データ保存要件などの要素を考慮します。
プラットフォーム機能を優先する
プラットフォーム機能を優先するということは、プラットフォームによって提供される組み込み機能を使用して、カスタム コードなしで特定のタスクを処理することを意味します。 組み込み機能は、特定のタスクを大規模に効率的に処理するように設計されており、定期的にメンテナンスされます。 プラットフォーム機能により、クラウド インフラストラクチャ機能が抽象化されて処理されるため、その機能をより有効に活用できます。 独自のカスタム コードを作成して保守する代わりに、機能をプラットフォームにオフロードできるサービスを選択します。 多くの場合、PaaS (Platform-as-a-Service) ソリューションは、カスタム コードよりも優れたパフォーマンス効率を提供します。 カスタム コードを使うと複雑性が増すため、ワークロードでパフォーマンスの問題が発生しやすくなります。 サービス機能が不十分な場合にのみカスタム コードを開発します。
インフラストラクチャ要件を評価する
リソースのパフォーマンス効率は、リソースが存在するインフラストラクチャに関係します。 サービスのパフォーマンス効率を高めるには、適切なインフラストラクチャを選択することが重要になります。 インフラストラクチャ要件を評価するには、ワークロードをサポートするのに最適な地理的領域を特定する必要があります。
この意思決定における重要な考慮事項は次のとおりです。
リージョンを理解する 各リージョンは、異なる地理的位置に対応しています。 クラウドにソリューションを展開するには、ソリューションの物理サーバーとデータベースが配置されているデータセンターの場所を選択する必要があります。 この選択は、待ち時間によりパフォーマンスに影響を及ぼします。
単一リージョンと複数リージョンの展開モデル。 複数のリージョンに展開すると、エンドユーザーへの待機時間を削減できます。 ただし、コストとワークロードの複雑さが増加する可能性もあります。 データの使用要件を考慮してください。たとえば、単一のリージョンでは、複数の小さなデータ サイロの作成が妨げられる可能性があります。 ワークロードのニーズに合わせて展開モデルを選択してください
使用可能な機能を理解する リージョンによって提供される機能が異なる場合があります。 リージョンを選択する前に、そのリージョンで利用できる機能を理解してください。 リージョンがワークロードのパフォーマンスのニーズを満たしていることを確認します。
待機時間を考慮してください。 データが送信元から送信先まで移動するのにかかる時間である待機時間は、サービス間の距離が離れるほど長くなります。 リージョン間で通信するサービスでは、待機時間が増加する可能性があります。 頻繁に通信するサービスを特定し、同じリージョン内に配置することをお勧めします。 さらに、主要なユーザー ベースに近いリージョンを選択すると、待機時間が最小限に抑えられ、より優れたユーザー エクスペリエンスを提供できます。 世界中のさまざまな場所にユーザーがいる場合は、一部のユーザーに対する待機時間を妥協する必要があるかもしれません。 最適なバランスを見つけるには、ユーザー ペルソナとワークロードを分析する必要があります。 データセンターの場所を選択することは、環境戦略の一部です。
ネットワーク要件を評価する
ネットワークのニーズを評価して、適切なワークロード サービスと構成を決定します。 ネットワークがワークロードをサポートできることを確認します。
ネットワーク要件を評価するには、次の点を確認してください。
ネットワーク トラフィックを理解する ワークロードに予想されるネットワーク トラフィックを評価します。 データ転送のニーズとネットワーク要求の頻度を理解します。
帯域幅要件を理解する ワークロードの帯域幅要件を決定します。 ネットワーク経由で送受信されるデータの量を考慮してください。
ネットワーク待ち時間を理解する ワークロードに必要な待機時間を評価します。
スループットを理解します。 ワークロードに必要なスループットを考慮してください。 スループットとは、指定された期間内にネットワーク経由で送信できるデータの量を指します。 ネットワーク スループットの利点を活用するために、ネットワーク ルーティング オプションを構成します。
ネットワーク トラフィックとパフォーマンスに影響を与える構成を理解します。 ファイアウォール設定、オンプレミスの データ ゲートウェイ構成などは、ネットワーク トラフィックとパフォーマンスに影響を与える可能性があります。 影響を与える可能性のあるすべてのコンポーネントと構成を理解し、それらがパフォーマンス要件に対応するよう構成されていることを確認します。
カスタム コンポーネントのコンピューティング要件を評価する
プラットフォーム サービスは独自のコンピューティング要件を管理しますが、実装したカスタム クラウド コンポーネントのコンピューティング要件を評価する必要があります。 コンピューティング要件の評価には、インスタンス タイプ、スケーラビリティ、コンテナ化などの要素を含む、ワークロードの特定のコンピューティング ニーズを評価することが含まれます。 コンピューティング サービスによって機能や特性が異なり、ワークロードのパフォーマンスに影響を与える可能性があります。 ワークロードが効率的に実行されるように、最適なコンピューティング サービスを選択します。 カスタム コンポーネントのコンピューティング要件を評価するための詳細なレコメンデーションについては、Azure Well-Architected Framework の コンピューティング要件の評価 を参照してください。
負荷分散要件を評価する
プラットフォーム サービスは独自の負荷分散を管理しますが、追加の負荷分散オプションを評価して検討することが重要です。 選択は、サービス機能をどう使用するかに基づいて行う必要があります。 負荷分散により、作業が均等に分散され、単一のリソースが要求により圧倒されることがなくなります。 負荷分散はボトルネックを防ぎ、応答時間を短縮するのに役立ちます。 ソリューションに含まれるサービスで利用可能なさまざまな負荷分散オプションを評価します。 ドキュメントと比較ツールを確認して、機能について理解してください。
ワークロードに最適な負荷分散オプションを選択するには、次の点を考慮してください。
- ロボティック プロセス オートメーション (RPA) ホスト: 複数のRPAホスト間で負荷分散を行い、ワークロードを自動的にスケーリングして 非アテンド型 自動化を最適化するかどうかを評価します。
- オンプレミスの ゲートウェイ: オンプレミスの データ リソースにアクセスするときに、負荷分散オプションを使用して単一障害点を回避します。
データベース要件を評価する
データベースは、データの保存と取得、トランザクション処理、一貫性の保証、大規模データや急速に変化するデータの処理などの要素に影響を与える可能性があります。 データベースのニーズと基準を評価します。 これらの要件を満たすデータベース システムを選択します。 データベースを選択する前に、データベースの要件を評価します。
データベースの要件を評価し、適切なデータベースを選択するには、次の手順に従います。
ワークロードのニーズを特定します。 データ量、予想されるトランザクション レート、コンカレンシー、データの種類、予想される増加など、ワークロードの特定の要件を理解します。 ワークロードのニーズに基づいてさまざまなデータベース システムを評価します。 たとえば、ワークロードに高性能なリアルタイム データ処理が必要な場合は、高速なデータ取り込みと低レイテンシに最適化されたデータベース システムを選択できます。
データ モデルを検討します。 ワークロードのニーズに合ったデータ モデルを決定します。 データベース要件を評価して、選択したデータベースが必要なデータ構造、リレーションシップ、および整合性制約をサポートしていることを確認します。 たとえば、データが高度なリレーショナル構造を持っている場合は、トランザクションと参照整合性を強力にサポートするリレーショナル データベース管理システム (RDBMS) を選択できます。 データ モデルは、階層型、ネットワーク型、リレーショナル型、オブジェクト指向型、NoSQL 型のいずれかになります。 データ モデルの複雑性を評価します。 選択したデータベースが必要なデータ構造とリレーションシップをサポートしていることを確認します。
機能を評価します。 読み取り/書き込みパターン、クエリの複雑さ、待機時間要件、スケーラビリティのニーズなどの要素を考慮してください。 それに応じて、さまざまなデータベース システムのパフォーマンス機能を評価します。 一部のデータベースは読み取り中心のワークロードに優れていますが、他のデータベースは書き込み中心または分析ワークロード向けに最適化されています。
負荷を評価します。 データ量、トランザクション レート、読み取り/書き込み比率、予想される増加などの要素を考慮してください。 予想されるワークロードを処理できるデータベースを選択して、スムーズな操作を保証し、ワークロードの拡張時にパフォーマンスのボトルネックを防止します。 ワークロードのスケーラビリティ要件を考慮してください。 これらの要件には、予想されるデータの増加、同時ユーザー アクセス、水平または垂直スケーリングの必要性が含まれます。 さまざまなデータベース システムが提供するスケーラビリティ オプションと可用性機能を評価します。
ストレージ要件を評価する
データ アクセス パターン、耐久性要件、パフォーマンス ニーズに合ったストレージ サービスを選択します。 ほとんどのクラウド ワークロードでは、ストレージ テクノロジの組み合わせが使用されます。 この手法は、ポリグロット永続化アプローチとして知られています。 ワークロードに適したストレージ サービスの組み合わせを決定します。 汚染を避けるためにデータを分離することも必要です。 たとえば、監視データとビジネス データ用に別々のストレージ アカウントを用意する場合があります。 アプリケーションのパフォーマンスを最適化するには、適切な組み合わせと正しい実装を選択することが重要です。
キャッシュ要件を評価する
キャッシュには頻繁にアクセスされるデータが保存されます。 キャッシュにより、データ アクセスの待ち時間が短縮され、データ ストレージ コンポーネントの負荷が軽減されます。 これにより、ワークロードはスケーリングせずにより多くのリクエストを処理できるようになります。 ワークロード データと静的コンテンツをキャッシュすることは一般的です。 一部のプラットフォーム サービスでは、パフォーマンスを向上させるためにデータを自動的にキャッシュします。 パフォーマンスを向上させ、全体的な API リクエストの消費量を削減するために、追加のキャッシュを追加することを検討してください。
ビジネス ロジックの要件を評価する
機能、パフォーマンス、再利用性の要件に基づいて、ビジネス ロジックを実装する方法を選択します。 Power Platform ビジネス ロジックを実行するためのさまざまなオプションが提供されます。たとえば、 Power Automate クラウド フロー、ローコードまたはコード ファースト プラグイン、ビジネス ルールなどです。 ほとんどのワークロードでは、さまざまなオプションの組み合わせが使用されます。
ビジネス ロジックの実装方法を評価するには、次の点を考慮してください。
チーム スキル。 チームはワークロードを構築および維持します。 サービスによって必要なスキルは異なります。 チームが使い方を理解しているサービスを選択するか、サービスを選択する前にトレーニングを行うことを確約してください。 チーム メンバーがサービスを効果的に使用し、パフォーマンスを最適化するための専門知識と知識を備えていることを確認します。 たとえば、Dataverse プラグイン を開発するには、ワークロード チームが .NET または Power Fx コードを記述する必要があります。
論理的アプローチ。 承認プロセスやフォームの応答など、人間の介入を必要とするロジックのステップがあるかどうかを評価し、ある場合は、すべてのステップを人間の介入なしで実行できるかどうかを判断します。 たとえば、人間の介入が必要な場合は Power Automate 承認 を使用し、人間の介入が不要な場合は Dataverse プラグインを使用して、ロジックが Dataverse データ操作の一部としてシームレスに実行されるようにできます。
統合。 アーキテクチャ図を確認し、ワークロードをどのシステムと統合する必要があるかを検討します。 統合のオプションを評価し、パフォーマンスと信頼性への影響を考慮します。 リアルタイム統合はユーザーに即時のメリットをもたらしますが、パフォーマンスと信頼性に影響を与える可能性があります。 Power Automateのような非同期アプローチを使用したり、Dataverse イベント をキューに公開して後で処理したりすると、パフォーマンスと信頼性が向上します。 ただし、これらの方法ではユーザーに即時のフィードバックは提供されません。
複雑さ。 ロジックの複雑さを考慮し、個別のステップに分割できるかどうかを評価します。 たとえば、キャンバス アプリやカスタム スクリプトでロジックを実装する代わりに、ビジネス ルール を使用して、必須フィールド、データ形式、範囲を検証します。 既存の値に基づく単純な計算の場合は、計算 フィールドまたは ロールアップ フィールドを使用し、より複雑な計算の場合は Dataverse プラグインを使用します。
再利用性。 ロジックを識別して再利用し、一貫性とメンテナンス性を向上させます。 ワークロードのさまざまなポイントからビジネス ロジックを再利用する必要があるかどうかを検討します。 たとえば、Dataverse プラグイン ロジックはアプリや自動化から呼び出すことができますが、ビジネス ロジックをキャンバス アプリに配置した場合は再利用できません。
選択は、特定の要件、ワークロードの複雑性、および統合のニーズによって異なることに注意してください。 プロジェクトの目標と組織の状況に基づいて各オプションを評価します。 ロジックの使用が単一のプロジェクト以外にも役立つかどうかを検討します。 可能であれば、最大限の利益が得られるようにアプローチを調整してください。
応答性を評価する
ユーザーは客観的な基準ではなく、期待内容によってパフォーマンスを判断することを忘れないでください。 必ずしもプロセスを高速化するわけではないが、ユーザー エクスペリエンスをよりスムーズにするテクニックを使用することで、体感されるパフォーマンスを向上させることができます。 たとえば、非同期処理を使用するとタスクの完了が速くなるわけではありませんが、ユーザー インターフェイスの応答性が維持され、ユーザーが他の作業を実行できます。
応答性を評価するには:
- 同期、非同期、またはバックグラウンド (バッチ) 処理のいずれを設計するかを検討します。
- 時間の経過に伴うデータの増加を考慮してください。 より多くのデータがシステムを流れるようになると、同じ応答時間を維持するためにシステムを微調整する必要があるかもしれません。
- ページが読み込まれるたびにリアルタイムでデータを取得するのではなく、ページまたはアプリにキャッシュするデータを検討してください。
Power Platform の促進
要件を理解する: Azureモニター を使用して、ワークロードからデータを収集して分析します。 監視することで、ワークロードのパフォーマンスと正常性に関する分析情報を提供し、問題を特定してトラブルシューティングできるようになります。
サービスの理解と評価: プラットフォーム サービスを確認して、パフォーマンス要件を満たしているかどうかを判断します。 Power Platform は、同じ結果を達成する複数のサービスを提供します。 パフォーマンスのニーズ、チームのスキル セット、コスト要件に合わせてサービスの選択を柔軟に行うことができます。
関連情報
- クライアントのネットワーク容量とスループットを確認する
- 高度なモニターの概念
- パフォーマンスに関する考慮事項 Power Apps
- キャンバス アプリの実行フェーズ、データ呼び出しフロー、パフォーマンス監視を理解する
- ビジネスクリティカルなゲートウェイソリューションを計画、拡張、維持する
- ローコードプラグインを使用する Dataverse
- プラグインを使用してビジネスプロセスを拡張する
- Dataverse コードを使用した数式、計算、およびロールアップ列
- 数式列の操作 Dataverse
- ビジネスロジックを適用する Microsoft Dataverse
- Microsoft Dataverse ビジネスイベント
パフォーマンス効率チェックリスト
完全なレコメンデーションのセットを参照してください。