次の方法で共有


Power Platform ワークロードのパフォーマンス効率のトレードオフ

オーバープロビジョニングなしでパフォーマンス目標を満たすワークロードは効率的です。 パフォーマンス効率のための主要な戦略には、コードの最適化、設計パターン、および容量計画の適切な使用が含まれます。 明確なパフォーマンス目標とテストが、この柱を支えています。

ワークロードの設計フェーズでは、パフォーマンス効率の設計原則に基づく決定や、パフォーマンス効率の設計レビュー チェックリストの推奨事項が、他の柱の目標や最適化の取り組みにどのような影響を与えるかを考慮することが重要です。 特定の決定は、一部の柱に利益をもたらす可能性がありますが、他の柱にとってはトレードオフを表します。 この記事では、パフォーマンス効率のためにワークロードのアーキテクチャと運用を設計するときにワークロード チームが遭遇する可能性のあるトレードオフの例を示します。

パフォーマンス効率と信頼性のトレードオフ

トレードオフ: 複製が減り、密度が増加する。 信頼性の基礎は、複製を使用し、誤動作の影響範囲を限定することによって弾力性を確保することです。

  • ワークロード リソースを統合すると、余剰容量を使用して効率を向上させることができます。 ただし、同じ場所に配置されたコンポーネントまたはアプリケーションプラットフォームでの誤動作の影響範囲が大きくなります。

トレードオフ: 複雑性が増す 信頼性はシンプルさを優先します。

  • データのパーティション分割とシャーディングは、大規模なデータセットや頻繁にアクセスされるデータセットのパフォーマンスの問題を回避するのに役立ちます。 ただし、これらのパターンを実装すると、追加のリソース間で (最終的な) 一貫性を維持する必要があるため、複雑さが増します。

  • 最適化されたアクセス パターンのためにデータを非正規化すると、パフォーマンスは向上しますが、データの複数の表現を同期させる必要があるため、複雑になります。

  • パフォーマンス中心のクラウド設計パターンでは、追加のコンポーネントの導入が必要になることがあります。 これらのコンポーネントを使用すると、ワークロードの表面積が増加します。 次に、ワークロード全体の信頼性を維持するために、コンポーネント自体を信頼できるものにする必要があります。

トレードオフ: アクティブな環境でのテストと観察 本番システムの不必要な使用を避けることは、信頼性のための自衛的なアプローチです。

  • アクティブな環境でのパフォーマンス テストには、テスト アクションまたは構成が原因で誤動作を引き起こすリスクが伴います。

  • ワークロードは、チームがアクティブな環境から学習できるようにするアプリケーション パフォーマンス監視 (APM) システムを使用してインストルメント化する必要があります。 APM ツールは、アプリケーション コードまたはホスティング環境にインストールされ、構成されます。 不適切な使用、制限の超過、または構成の誤りは、ツールの機能とメンテナンスを損ない、信頼性を損なう可能性があります。

パフォーマンス効率とセキュリティのトレードオフ

トレードオフ: セキュリティ管理の削減 セキュリティ管理は、深層における防御を提供するために、複数のレイヤーにわたって、時には冗長的に確立されます。

パフォーマンス最適化戦略の 1 つは、フローの遅延の原因となるコンポーネントまたはプロセスを削除またはバイパスすることです (特に処理時間が正当化されない場合)。 ただし、この戦略はセキュリティを危険にさらす可能性があるため、徹底的なリスク分析を伴う必要があります。 以下の例を参照してください:

  • 転送速度を向上させるために転送中または保存中に暗号化を削除すると、データが整合性または機密性の侵害にさらされる可能性があります。

  • 処理時間を短縮するためにセキュリティ スキャン ツールや検査ツールを削除または削減すると、それらのツールが保護する機密性、整合性、または可用性が損なわれる可能性があります。

  • ネットワーク フローからファイアウォール規則を削除してネットワーク待機時間を改善すると、望ましくない通信が許可される可能性があります。

  • データ処理を高速化するためにデータ検証を最小限に抑えると、特に入力に悪意がある場合、データの整合性が損なわれる可能性があります。

トレードオフ: ワークロードの対象領域の増加 セキュリティは、攻撃ベクトルを最小化し、セキュリティ制御の管理を軽減するために、表面積を縮小して封じ込めることを優先します。

パフォーマンス中心のクラウド設計パターンでは、追加のコンポーネントの導入が必要になることがあります。 これらのコンポーネントにより、ワークロードの表面積が増加します。 新しいコンポーネントは、システムでまだ使用されていない方法でセキュリティ保護する必要があり、多くの場合、コンプライアンスの範囲が広がります。 一般的に追加される次のコンポーネントを検討してください。

  • 各タスクのパフォーマンス要件に基づいて、クラウド フローやローコードプラグインなど、ビジネスロジックを処理する複数の異なる方法を導入します。

  • バックグラウンド ジョブやクライアント コンピューティングに処理をオフロードする。

トレードオフ: セグメンテーションの削除 セキュリティの柱は、きめ細かなセキュリティ管理を可能にし、強力なセグメンテーションを優先して、影響範囲を縮小します。

リソースの共有は、効率を向上させるためのアプローチです。 密度を高めて、容量の使用を最適化します。 たとえば、複数の キャンバス アプリや クラウド フロー でローコード プラグインを再利用します。 密度が高くなると、次のようなセキュリティ上の懸念が生じる可能性があります。

  • 最小特権の原則に違反し、アクセス ログ内の個々の監査証跡を不明瞭にする共有ワークロード ID。

  • ネットワーク ルールなどの境界セキュリティ制御は、同じ場所にあるすべてのコンポーネントをカバーするように縮小され、個々のコンポーネントに必要以上のアクセスを提供します。

パフォーマンス効率とオペレーショナルエクセレンスのトレードオフ

トレードオフ: 監視能力の低下 意味のあるアラートをワークロードに提供し、インシデント対応を確実に成功させるためには、監視が必要です。

  • 他のタスクの代わりにテレメトリの収集に費やす処理時間を減らすために、ログとメトリックの量を減らすことで、システムの全体的な観測可能性が低下します。 結果として生じる可観測性の低下の例には、次のようなものがあります。

    • これにより、意味のあるアラートの作成に使用されるデータ ポイントが制限されます。
    • これは、インシデント対応活動のカバレッジにギャップをもたらします。
    • これにより、セキュリティ上またはコンプライアンス上重要な対話と境界の可観測性が制限されます。
  • パフォーマンス設計パターンを実装すると、多くの場合、ワークロードの複雑さが増します。 コンポーネントがクリティカル フローに追加されます。 ワークロード監視戦略とパフォーマンス監視には、これらのコンポーネントを含める必要があります。 フローが複数のコンポーネントまたはアプリケーションの境界にまたがっている場合、そのフローのパフォーマンスを監視する複雑さが増します。 流量性能は、相互接続されたすべてのコンポーネント間で相関させる必要があります。

トレードオフ: 運用の複雑性が増す 複雑な環境では、相互作用がより複雑になり、日常業務、臨時業務、緊急業務から悪影響を受ける可能性が高くなります。

  • 密度を高めてパフォーマンス効率を向上させると、運用タスクのリスクが高まります。 1 つのプロセスのエラーは、大きな爆発半径を持つ可能性があります。

  • パフォーマンス設計パターンを実装すると、バックアップ、キーのローテーション、回復戦略などの運用手順に影響を与えます。 たとえば、データのパーティション分割とシャーディングは、チームが日常的なタスクがデータの一貫性に影響を与えないようにしようとすると、それらのタスクを複雑にする可能性があります。

トレードオフ: 文化的なストレス オペレーショナル エクセレンスは、無責任、尊重、継続的改善の文化に根ざしています。

  • パフォーマンス問題の根本原因分析を実施することで、修正が必要なプロセスまたは実装の欠陥を特定できます。 チームは、演習を学習の機会と見なす必要があります。 チームメンバーが問題で非難されると、士気に影響を与える可能性があります。

  • 日常的なプロセスやアドホックなプロセスは、ワークロードのパフォーマンスに影響を与える可能性があります。 多くの場合、これらのアクティビティはオフピーク時に実行することが望ましいと考えられています。 ただし、オフピーク時間は、これらのタスクを担当する、または熟練したチーム メンバーにとって不便であったり、通常の時間外であったりする可能性があります。

パフォーマンス効率とエクスペリエンス最適化のトレードオフ

トレードオフ: ユーザー エンゲージメントの低下 エクスペリエンス最適化の柱は、より魅力的なユーザー エクスペリエンスを優先します。

  • パフォーマンスの最適化では、カスタマイズよりもプラットフォーム機能の使用が優先されるため、より魅力的なユーザーエクスペリエンスにつながる可能性のあるカスタムコンポーネントの優先順位が下がります。

  • パフォーマンスの最適化では、複雑さの最小化に重点が置かれすぎて、カスタムコンポーネントや統合など、より魅力的なユーザーエクスペリエンスのための機能の優先順位が下がる可能性があります。

  • ユーザーインターフェースの開発は、より速いイテレーションや出荷サイクルで行われることが多く、パフォーマンスを継続的に向上させることが難しくなる可能性があります。