ワークロードの信頼性のトレードオフ Power Platform

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

信頼性の高いワークロードは、定義された信頼性目標を一貫して満たします。理想は、信頼性に影響を与えるイベントを回避することで、確立された回復力の目標を達成する必要があります。しかし現実的には、ワークロードはそのようなイベントの影響に耐える制御し、故障中に操作を所定のレベルで維持する必要があります。災害発生時でも、信頼性の高いワークロードは、一定の期間内に特定の状態に回復する必要があり、その両方が関係者間で合意されています。迅速な検出と復旧を可能にするインシデント対応計画が不可欠です。

ワークロードの設計フェーズでは、信頼性の設計原則と信頼性の設計レビューチェックリストのレコメンデーションに基づく決定が、目標と他の柱の最適化にどのように影響するかを考慮することが重要です。特定の決定は、一部の柱には利益をもたらすかもしれませんが、他の柱にとってはトレードオフとなる可能性があります。この記事では、信頼性のためにワークロードアーキテクチャと操作を設計するときに、ワークロードチームが遭遇する可能性のあるトレードオフの例について説明します。

信頼性とセキュリティのトレードオフ

トレードオフ: ワークロードのセキュリティ、外部からのアクセスの増加。セキュリティの柱では、攻撃ベクトルを最小化するためにセキュリティ、外部からのアクセスを縮小して封じ込め、セキュリティ制御の管理を軽減します。

信頼性は多くの場合、レプリケーションを使用して得ることができます。レプリケーションは、コンポーネントレベル、データレベル、さらには地理レベルでも実行できます。レプリカは、設計上、ワークロードの表面積を増やします。セキュリティの観点では、潜在的な攻撃ベクトルを最小化してセキュリティ制御の管理を軽減するには、表面領域を縮小して封じ込めることが推奨されています。
同様に、バックアップなどのディザスターリカバリーソリューションは、ワークロードのセキュリティ、外部からのアクセスを拡大します。ただし、多くの場合、ワークロードのランタイムからは分離されています。これには、ディザスターリカバリーソリューションに固有の追加のセキュリティ制御の実装が必要です。
信頼性の目標のために、アーキテクチャに追加のコンポーネントが必要になる場合があり、これによりセキュリティ、外部からのアクセスが増加します。この複雑さの増加により、おそらくシステムでまだ使用されていない方法で、保護する必要がある新しいコンポーネントが追加されるため、ワークロードのセキュリティ、外部からのアクセスが増加します。通常、これらのコンポーネントには、その使用や一般的な信頼性パターンをサポートするための追加コードが付随していることも理由で、アプリケーションのセキュリティ、外部からのアクセスが増加します。

トレードオフ: セキュリティ制御バイパス。セキュリティの柱では、通常のシステムとストレスのかかったシステムの両方で、すべての制御をアクティブなままにしておくことを推奨しています。

ワークロードで信頼性イベントが発生し、アクティブなインシデント応答によって対処されている場合、緊急性により、ワークロードチームに、日常的なアクセスに最適化されたセキュリティ制御をバイパスするよう圧力がかかる可能性があります。
トラブルシューティング活動により、チームはセキュリティプロトコルを一時的に無効にし、すでにストレスがかかっているシステムがさらなるセキュリティリスクにさらされる可能性があります。セキュリティプロトコルが速やかに再確立されないリスクもあります。
ロールベースのアクセス制御の割り当てやファイアウォール規則などのセキュリティ制御を細かく実装すると、構成が複雑さと機密性が増し、構成ミスの可能性が高まります。広範なルールを使用してこの潜在的な信頼性への影響を軽減すると、ゼロトラストアーキテクチャの 3 つの原則がすべて無効になります。

トレードオフ: ソフトウェアの旧バージョン。セキュリティの柱は、ベンダーのセキュリティパッチに対する "最新の情報を取得し、最新の状態を維持する" アプローチを奨励します。

リリースサイクルの更新や、サードパーティのコンポーネントやソリューションなどのベンダーライブラリへの更新を適用すると、ターゲットコンポーネントが中断され、変更中に使用できなくなる可能性があります。ファイルの部分置換を遅らせたり回避したりすると、潜在的な信頼性リスクを回避できる可能性がありますが、進化する脅威に対してシステムが保護されないままになります。
前述の考慮事項は、ワークロードのコードにも当てはまります。たとえば、古いライブラリやコンポーネントを使用するアプリケーションコードに適用されます。アプリケーションコードの更新と展開が、軽減されていない信頼性リスクと見なされる場合、アプリケーションは時間の経過とともに他のセキュリティリスクにさらされることになります。

信頼性と運用の効率化のトレードオフ

トレードオフ: 運用の複雑さの増大。運用の効率化は、信頼性自体と同様に、シンプルさを優先します。

ワークロードに対する包括的な監視戦略を持つことは、運用の効率化にとって重要な要素です。信頼性設計パターンを実装するために追加のコンポーネントをアーキテクチャに導入すると、管理するデータソースが増加し、分散トレースと監視の実装が複雑になります。
複数のリージョンを使用して 1 つのリージョンのリソース容量制約を克服したり、アクティブ/アクティブアーキテクチャを実装したりすると、ワークロードの運用管理の複雑さが増します。この複雑さは、複数のリージョンを管理する必要性と、そのリージョン間のデータ複製を管理する必要性によって生じます。

トレードオフ: チームの知識と認識を生み出す努力の向上。運用の効率性の柱では、手順とトポロジのドキュメントリポジトリを保持および管理することを推奨しています。

信頼性コンポーネントとパターンの追加によりワークロードの安定性が増すにつれて、運用手順と成果物のドキュメントの維持にかかる時間が増えます。
ワークロード内のコンポーネントの数が増加するにつれて、トレーニングはより複雑になります。この複雑さはオンボーディングに必要な時間に影響し、製品のロードマップとサービスレベルのガイダンスを追跡するために必要な知識を増やします。

信頼性とエクスペリエンスの最適化のトレードオフ

トレードオフ: 俊敏性の低下。エクスペリエンス最適化の柱は、ユーザーの効率性を優先します。

厳格なテストを強調すると、導入に不可欠なエクスペリエンス機能のリリースが遅れる可能性があります。
信頼性を最適化すると、複雑さの最小化に重点が置かれる可能性があり、カスタムコンポーネントや統合など、より魅力的なユーザーエクスペリエンスを実現する機能の優先順位が低くなります。

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

トレードオフ: レイテンシが増加します。パフォーマンス効率を実現するには、ユーザーとデータフローのパフォーマンス目標を達成するシステムが必要です。

信頼性パターンには、レプリカの故障に耐えるためにデータレプリケーションが組み込まれることがよくあります。レプリケーションにより、信頼性の高いデータ書き込み操作に追加の遅延が発生し、特定のユーザーまたはデータフローのパフォーマンスバジェットの一部が消費されます。
信頼性では、正常なレプリカに負荷を分散または再分散するために、さまざまな形式のリソースバランシングが採用されることがあります。バランス調整に使用される専用コンポーネントは、通常、バランス調整対象の要求またはプロセスのパフォーマンスに影響します。
範囲を限定した影響に耐えるためにコンポーネントを地理的境界または可用性ゾーンに分散すると、それらの可用性境界にまたがるコンポーネント間の通信にネットワーク遅延が発生します。
ワークロードの健全性を監視するために、広範なプロセスが使用されます。監視は信頼性にとって重要ですが、計測機器はシステムのパフォーマンスに影響を及ぼす可能性があります。可観測性が高まると、パフォーマンスが低下する可能性があります。

トレードオフ: オーバープロビジョニングの増加。パフォーマンス効率の柱では、過剰なプロビジョニングを推奨せず、代わりに需要を満たすのに十分なリソースのみを使用することを推奨します。

自動スケーリング操作は瞬時に行われないため、形を整えたり平滑化したりできない突然の劇的な需要の急増に確実に対応することはできません。したがって、より大きなインスタンスまたはより多くのインスタンスを介してオーバープロビジョニングすることは、需要シグナルと供給の作成間の遅延を考慮するための重要な信頼性戦術です。未使用の容量はパフォーマンス効率の目標に反します。
場合によっては、需要に応じてコンポーネントを拡張できず、その需要が完全に予測できないことがあります。最悪のケースをカバーするために大規模なインスタンスを使用すると、そのユースケース以外の状況で過剰なプロビジョニングによる無駄が生じます。

次の方法で共有