ワークロードの信頼性のトレードオフ Power Platform
信頼性の高いワークロードは、定義された信頼性目標を一貫して満たします。 理想は、信頼性に影響を与えるイベントを回避することで、確立された回復力の目標を達成する必要があります。 しかし現実的には、ワークロードはそのようなイベントの影響に耐える制御し、故障中に操作を所定のレベルで維持する必要があります。 災害発生時でも、信頼性の高いワークロードは、一定の期間内に特定の状態に回復する必要があり、その両方が関係者間で合意されています。 迅速な検出と復旧を可能にするインシデント対応計画が不可欠です。
ワークロードの設計フェーズでは、信頼性の設計原則 と 信頼性の設計レビュー チェックリスト のレコメンデーションに基づく決定が、目標と他の柱の最適化にどのように影響するかを考慮することが重要です。 特定の決定は、一部の柱には利益をもたらすかもしれませんが、他の柱にとってはトレードオフとなる可能性があります。 この記事では、信頼性のためにワークロード アーキテクチャと操作を設計するときに、ワークロード チームが遭遇する可能性のあるトレードオフの例について説明します。
信頼性とセキュリティのトレードオフ
トレードオフ: 作業負荷の表面積が増加します。 セキュリティの柱では、攻撃ベクトルを最小化するためにセキュリティ、外部からのアクセスを縮小して封じ込め、セキュリティ制御の管理を軽減します。
信頼性は多くの場合、レプリケーションを使用して得ることができます。 レプリケーションは、コンポーネント レベル、データ レベル、さらには地理レベルでも実行できます。 レプリカは、設計上、ワークロードの表面積を増やします。 セキュリティの観点では、潜在的な攻撃ベクトルを最小化してセキュリティ制御の管理を軽減するには、表面領域を縮小して封じ込めることが推奨されています。
同様に、バックアップなどのディザスター リカバリー ソリューションは、ワークロードのセキュリティ、外部からのアクセスを拡大します。 ただし、多くの場合、ワークロードのランタイムからは分離されています。 これには、ディザスター リカバリー ソリューションに固有の追加のセキュリティ制御の実装が必要です。
信頼性の目標のために、アーキテクチャに追加のコンポーネントが必要になる場合があり、これによりセキュリティ、外部からのアクセスが増加します。 この複雑さの増加により、おそらくシステムでまだ使用されていない方法で、保護する必要がある新しいコンポーネントが追加されるため、ワークロードのセキュリティ、外部からのアクセスが増加します。 通常、これらのコンポーネントには、その使用や一般的な信頼性パターンをサポートするための追加コードが付随していることも理由で、アプリケーションのセキュリティ、外部からのアクセスが増加します。
ワークロードで信頼性イベントが発生し、アクティブなインシデント応答によって対処されている場合、緊急性により、ワークロード チームに、日常的なアクセスに最適化されたセキュリティ制御をバイパスするよう圧力がかかる可能性があります。
トラブルシューティング活動により、チームはセキュリティ プロトコルを一時的に無効にし、すでにストレスがかかっているシステムがさらなるセキュリティ リスクにさらされる可能性があります。 セキュリティ プロトコルが速やかに再確立されないリスクもあります。
ロールベースのアクセス制御の割り当てやファイアウォール規則などのセキュリティ制御を細かく実装すると、構成が複雑さと機密性が増し、構成ミスの可能性が高まります。 広範なルールを使用してこの潜在的な信頼性への影響を軽減すると、ゼロ トラスト アーキテクチャの 3 つの原則がすべて無効になります。
リリース サイクルの更新や、サードパーティのコンポーネントやソリューションなどのベンダー ライブラリへの更新を適用すると、ターゲット コンポーネントが中断され、変更中に使用できなくなる可能性があります。 ファイルの部分置換を遅らせたり回避したりすると、潜在的な信頼性リスクを回避できる可能性がありますが、進化する脅威に対してシステムが保護されないままになります。
前述の考慮事項は、ワークロードのコードにも当てはまります。 たとえば、古いライブラリやコンポーネントを使用するアプリケーション コードに適用されます。 アプリケーション コードの更新と展開が、軽減されていない信頼性リスクと見なされる場合、アプリケーションは時間の経過とともに他のセキュリティ リスクにさらされることになります。
信頼性と運用の効率化のトレードオフ
ワークロードに対する包括的な監視戦略を持つことは、運用の効率化にとって重要な要素です。 信頼性設計パターンを実装するために追加のコンポーネントをアーキテクチャに導入すると、管理するデータ ソースが増加し、分散トレースと監視の実装が複雑になります。
複数のリージョンを使用して 1 つのリージョンのリソース容量制約を克服したり、アクティブ/アクティブ アーキテクチャを実装したりすると、ワークロードの運用管理の複雑さが増します。 この複雑さは、複数のリージョンを管理する必要性と、そのリージョン間のデータ複製を管理する必要性によって生じます。
信頼性コンポーネントとパターンの追加によりワークロードの安定性が増すにつれて、運用手順と成果物のドキュメントの維持にかかる時間が増えます。
ワークロード内のコンポーネントの数が増加するにつれて、トレーニングはより複雑になります。 この複雑さはオンボーディングに必要な時間に影響し、製品のロードマップとサービス レベルのガイダンスを追跡するために必要な知識を増やします。
信頼性とエクスペリエンスの最適化のトレードオフ
厳格なテストを強調すると、導入に不可欠なエクスペリエンス機能のリリースが遅れる可能性があります。
信頼性を最適化すると、複雑さの最小化に重点が置かれる可能性があり、カスタム コンポーネントや統合など、より魅力的なユーザー エクスペリエンスを実現する機能の優先順位が低くなります。
信頼性とパフォーマンス効率のトレードオフ
信頼性パターンには、レプリカの故障に耐えるためにデータ レプリケーションが組み込まれることがよくあります。 レプリケーションにより、信頼性の高いデータ書き込み操作に追加の遅延が発生し、特定のユーザーまたはデータ フローのパフォーマンス バジェットの一部が消費されます。
信頼性では、正常なレプリカに負荷を分散または再分散するために、さまざまな形式のリソース バランシングが採用されることがあります。 バランス調整に使用される専用コンポーネントは、通常、バランス調整対象の要求またはプロセスのパフォーマンスに影響します。
特定の範囲の影響に耐えるためにコンポーネントを地理的境界または可用性ゾーンに分散すると、それらの可用性境界にまたがるコンポーネント間の通信にネットワーク遅延が発生します。
ワークロードの健全性を監視するために、広範なプロセスが使用されます。 監視は信頼性にとって重要ですが、計測機器はシステムのパフォーマンスに影響を及ぼす可能性があります。 観測性が高まると、パフォーマンスが低下する可能性があります。
自動スケーリング操作は瞬時に行われないため、形を整えたり平滑化したりできない突然の劇的な需要の急増に確実に対応することはできません。 したがって、より大きなインスタンスまたはより多くのインスタンスを介してオーバープロビジョニングすることは、需要シグナルと供給の作成間の遅延を考慮するための重要な信頼性戦術です。 未使用の容量はパフォーマンス効率の目標に反します。
場合によっては、需要に応じてコンポーネントを拡張できず、その需要は完全に予測できないことがあります。 最悪のケースをカバーするために大規模なインスタンスを使用すると、そのユースケース以外の状況で過剰なプロビジョニングの無駄が発生します。