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

[アーティクル]
06/12/2024

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

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

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

トレードオフ: レプリケーションの削減と密度の向上。 信頼性の基礎は、レプリケーションを使用して回復力を確保し、障害の影響範囲を制限することです。

ワークロードリソースを統合すると、余剰容量が活用され、効率が向上します。ただし、同じ場所にあるコンポーネントまたはアプリケーションプラットフォームの障害による影響範囲は拡大します。

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

データのパーティション分割とシャーディングは、大規模なデータセットや頻繁にアクセスされるデータセットでのパフォーマンスの問題を回避するのに役立ちます。ただし、これらのパターンを実装すると、追加のリソース間で (最終的な) 一貫性を維持する必要があるため、複雑さが増します。
最適化されたアクセスパターンのためにデータを非正規化するとパフォーマンスが向上しますが、データの複数の表現を同期させる必要があるため、複雑さが生じます。
パフォーマンス中心のクラウド設計パターンでは、追加のコンポーネントの導入が必要になる場合があります。これらのコンポーネントを使用すると、ワークロードの表面積が増加します。全体のワークロードの信頼性を維持するには、コンポーネント自体の信頼性を高める必要があります。

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

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

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

トレードオフ: セキュリティ制御の削減。 多層防御を実現するために、セキュリティ制御は複数のレイヤーにわたって、場合によっては冗長的に確立されます。

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

転送速度を向上させるために転送中または保存中の暗号化を削除すると、データの整合性または機密性が侵害される可能性があります。
処理時間を短縮するためにセキュリティスキャンまたは検査ツールを削除または削減すると、それらのツールによって保護される機密性、整合性、または可用性が損なわれる可能性があります。
ネットワーク遅延を改善するためにネットワークフローからファイアウォールルールを削除すると、望ましくない通信が発生する可能性があります。
データ処理を高速化するためにデータ検証を最小限に抑えると、特に入力が悪意のあるものである場合には、データの整合性が損なわれる可能性があります。

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

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

各タスクのパフォーマンス要件に基づいて、クラウドフローやローコードプラグインなどのビジネスロジックを処理する複数の異なる方法を導入します。
処理をバックグラウンドジョブまたはクライアントコンピューティングにオフロードします。

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

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

最小権限の原則に違反し、アクセスログ内の個々の監査証跡を不明瞭にする共有ワークロードID。
ネットワークルールなどの境界セキュリティ制御は、同じ場所にあるすべてのコンポーネントをカバーするように縮小され、個々のコンポーネントに必要以上のアクセス権が与えられます。

パフォーマンス効率と運用の卓越性のトレードオフ

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

ログとメトリックの量を減らして、他のタスクではなくテレメトリの収集に費やされる処理時間を短縮すると、システム全体の可観測性が低下します。結果として観測性が低下する例としては、次のようなものがあります。
- 意味のあるアラートを作成するために使用されるデータポイントを制限します。
- これにより、インシデント対応活動の範囲にギャップが生じます。
- セキュリティやコンプライアンスに敏感なやり取りや境界における観測可能性を制限します。
パフォーマンス設計パターンを実装すると、ワークロードの複雑さが増すことがよくあります。重要なフローにコンポーネントが追加されます。ワークロード監視戦略とパフォーマンス監視には、これらのコンポーネントを含める必要があります。フローが複数のコンポーネントまたはアプリケーション境界にまたがる場合、そのフローのパフォーマンスを監視する複雑さが増します。フローのパフォーマンスは、相互接続されたすべてのコンポーネント間で相関させる必要があります。

トレードオフ: 操作の複雑さが増します。 複雑な環境では、相互作用がより複雑になり、日常的な操作、アドホックな操作、緊急操作による悪影響が生じる可能性が高くなります。

密度を高めることでパフォーマンス効率を向上させると、運用タスクのリスクが高まります。単一のプロセスでエラーが発生すると、影響範囲が大きくなる可能性があります。
パフォーマンス設計パターンが実装されると、バックアップ、キーのローテーション、回復戦略などの運用手順に影響します。たとえば、データのパーティショニングとシャーディングにより、チームが日常的なタスクがデータの一貫性に影響を与えないようにしようとすると、日常的なタスクが複雑になる可能性があります。

トレードオフ: 文化的なストレス。 運用上の卓越性は、非難を許さない、尊重する、継続的な改善の文化に根ざしています。

パフォーマンスの問題の根本原因分析を実行すると、修正が必要なプロセスまたは実装の欠陥が特定されます。チームはこの演習を学習の機会とみなすべきです。チームメンバーが問題の原因だと責められると、士気に影響が出る可能性があります。
ルーチンプロセスとアドホックプロセスはワークロードのパフォーマンスに影響を及ぼす可能性があります。これらのアクティビティは、オフピーク時に実行することが望ましいとよく考えられます。ただし、これらのタスクを担当または熟練したチームメンバーにとって、オフピーク時間は不便であったり、通常の時間外であったりする可能性があります。

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

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

パフォーマンスを最適化すると、カスタマイズよりもプラットフォーム機能の使用が優先され、より魅力的なユーザーエクスペリエンスにつながるカスタムコンポーネントの優先順位が低くなります。
パフォーマンスを最適化すると、複雑さを最小限に抑えることに重点が置かれすぎて、カスタムコンポーネントや統合など、より魅力的なユーザーエクスペリエンスを実現する機能が優先されなくなる可能性があります。
ユーザーインターフェイスの開発は、より高速な反復と出荷サイクルで行われることが多く、パフォーマンスを継続的に向上させることが難しくなる可能性があります。

次の方法で共有