信頼性のトレードオフ
信頼性の高いワークロードは、定義された信頼性の目標を一貫して満たしています。 理想的には信頼性に影響を与えるイベントを回避することで、確立された回復性の目標に到達する必要があります。 しかし、現実的には、ワークロードで、そのようなイベントの影響を許容して制御し、不具合が実際に発生したときに、事前に決定されたレベルで運用を維持する必要があります。 障害が発生した場合でも、信頼性の高いワークロードを一定期間内に特定の状態に復旧する必要があります。この期間と状態は両方とも、利害関係者間で合意されたものです。 これには、迅速な検出と復旧を実現できるインシデント対応計画が不可欠です。
ワークロードの設計フェーズ中は、信頼性の設計原則と、信頼性の設計レビュー チェックリストの推奨事項に基づく決定が、その他の重要な要素の目標と最適化にどのように影響するかを検討する必要があります。 特定の決定が一部の重要な要素に利益をもたらす一方で、その他の重要な要素とのトレードオフとなる場合があります。 この記事では、ワークロード チームが信頼性を高めるためにワークロードのアーキテクチャと運用を設計するときに遭遇する可能性があるトレードオフの例について説明します。
信頼性のセキュリティとのトレードオフ
トレードオフ: ワークロードの攻撃可能領域の増加。セキュリティの重要な要素は、攻撃ベクトルを最小限に抑え、セキュリティ制御の管理を軽減するために、縮小して封じ込める攻撃可能領域に優先順位を付けます。
多くの場合、信頼性はレプリケーションを介して取得されます。 レプリケーションは、コンポーネント レベルやデータ レベルで、または地理的レベルでも行われる場合があります。 レプリカにより、設計上、ワークロードの攻撃可能な領域が増えます。 セキュリティの観点からは、潜在的な攻撃ベクトルを最小限に抑え、セキュリティ制御の管理を効率化するために、攻撃可能な領域を減らし、封じ込めることが推奨されます。
同様に、バックアップなどのディザスター リカバリー ソリューションにより、ワークロードの攻撃可能な領域が増えます。 ただし、多くの場合、これらソリューションはワークロードのランタイムから分離されています。 これらのソリューションでは、追加のセキュリティ制御を実装する必要がありますが、これらの制御はディザスター リカバリーアプローチに固有である可能性があります。
信頼性の目標のために、アーキテクチャに追加のコンポーネントが必要になる場合があり、これにより、攻撃可能な領域が増えます。 たとえば、切り離しを介して要求に回復性を持たせるためにメッセージ バスを追加できる場合があります。 これによって複雑さが増すと、おそらくはシステムでまだ使用されていない方法で保護する必要がある新しいコンポーネントが追加され、ワークロードの攻撃可能な領域が増えます。 通常、これらのコンポーネントには、その使用や一般的な信頼性パターンをサポートするための追加のコードとライブラリが伴います。これにより、アプリケーションの攻撃可能な領域も増えます。
アクティブなインシデント対応下で対処されている信頼性イベントがワークロードで発生した場合、その緊急度のため、日常的なアクセスのために最適化されたセキュリティ制御を回避するよう求める圧力がワークロード チームにかかる場合があります。
トラブルシューティング アクティビティが原因で、チームがセキュリティ プロトコルを一時的に無効にし、既にストレスを受けているシステムが別のセキュリティ リスクにさらされる可能性があります。 また、セキュリティ プロトコルがすぐに再確立されないリスクもあります。
カスタム ロールベースのアクセス制御の割り当てや狭いファイアウォール ルールなど、セキュリティ制御の細かい実装により、構成の複雑さと機密度が生じ、構成の誤りが起きる可能性が高まります。 広範なルールを使用してこの潜在的な信頼性への影響を軽減すると、ゼロ トラスト アーキテクチャの 3 つの原則がすべて損なわれます。
セキュリティ パッチまたはソフトウェア更新プログラムを適用すると、ターゲット コンポーネントが中断され、ソフトウェアの変更時に使用できなくなる可能性があります。 修正プログラムの適用を遅らせるか回避すると、潜在的な信頼性リスクを回避できる可能性がありますが、システムは進化する脅威から保護されないままになります。
上記の考慮事項は、ワークロードのコードにも当てはまります。 たとえば、古いライブラリを使用するアプリケーション コードや古い基本イメージを使用するコンテナーに当てはまります。 アプリケーション コードの更新とデプロイが、軽減されていない信頼性リスクであると見なされる場合、アプリケーションは時間の経過とともに別のセキュリティ リスクにさらされます。
コスト最適化による信頼性のトレードオフ
レプリケーションは、信頼性の重要な戦略です。 この戦略では具体的に、一定数の同時ノード障害を処理するのに十分なレプリケーションを用意します。 同時ノード障害に対する許容度を高めるには、レプリカ数を増やす必要がありますが、その結果、コストの増加につながります。
過剰プロビジョニングは、フェールオーバー イベント時など、システムに対する予期しない負荷を吸収するもう 1 つの手法ですが、これは、別の形で信頼性の問題につながる可能性があります。 使用されていない余分な能力は、無駄であると見なされます。
ワークロードで、ワークロードの復旧ポイントと時間の目標を過度に満たすディザスター リカバリー ソリューションが使用されている場合、この過剰により、無駄が原因でコストが高くなります。
ワークロードのデプロイ自体は信頼性への影響の潜在的な発生源であり、その影響は多くの場合、ブルー/グリーンなどのデプロイ戦略を介してデプロイ時の冗長性によって軽減されます。 安全なデプロイ時にリソースが一時的に重複すると、通常、それらの期間中のワークロードの全体的なコストが増加します。 コストは、デプロイの頻度に応じて増加します。
信頼性を実現するには、システムの監視が必要です。 システムの監視には、監視データの転送と収集が必要です。 監視機能が増加すると、データの頻度と量が増加し、その結果としてコストが増加します。
ワークロードの信頼性アフォーダンスには、テストと訓練が必要です。 テストの設計と実行には時間がかかり、場合によっては特殊化されたツールが必要になり、そのコストが発生します。
信頼性の高いターゲットを持つワークロードには多くの場合、技術的なチーム メンバーを正式なオンコール ローテーションの一部にする必要がある迅速な応答プロセスがあります。 このプロセスにより、他の場所に注意が向けられる可能性があるため、追加の人員コストや機会損失コストが発生します。 また、このプロセスの管理のための潜在的なツールのコストも発生します。
テクノロジー プロバイダーとのサポート契約は、信頼性の高いワークロードの重要なコンポーネントです。 サポート レベルが過剰にプロビジョニングされているために使用されないサポート 契約では、無駄が生じます。
オペレーショナル エクセレンスによる信頼性のトレードオフ
信頼性により、通常、ワークロードの複雑さが増します。 ワークロードの複雑さが増すにつれて、デプロイの調整と構成の攻撃可能な領域の観点から追加されたコンポーネントとプロセスをサポートするためのワークロードの運用要素も増える場合があります。
ワークロードの包括的な監視戦略を持つことは、オペレーショナル エクセレンスの重要な一部です。 信頼性設計パターンを実装するためにアーキテクチャに追加のコンポーネントを導入すると、管理対象のデータ ソースが増え、分散トレースと監視の実装の複雑さが増します。
単一リージョンのリソース容量の制約を克服したり、アクティブ/アクティブ アーキテクチャを実装したりするために、複数のリージョンを使用すると、ワークロードの運用管理の複雑さが増します。 この複雑さは、複数のリージョンを管理する必要性と、これらの間のデータ レプリケーションを管理する必要性によってもたらされます。
信頼性のコンポーネントとパターンの追加を介してワークロードの堅牢化が進むにつれて、運用手順と成果物のドキュメントを維持するための時間がより多く費やされます。
ワークロード内のコンポーネントの数が増えると、トレーニングがより複雑になります。 この複雑さは、オンボーディングに必要な時間に影響します。 また、この複雑さにより、製品ロードマップと最新のサービス レベル ガイダンスを追跡するために必要な知識も増します。
パフォーマンス効率による使用率のトレードオフ
多くの場合、信頼性パターンには、レプリカの誤動作に耐えるためにデータ レプリケーションが組み込まれています。 レプリケーションにより、信頼性の高いデータの書き込み操作の待機時間が長くなります。この結果、特定のユーザー フローまたはデータ フローのパフォーマンス予算の一部が消費されます。
信頼性では、負荷を正常なレプリカに分散または再配布するためにさまざまな形式のリソース分散が採用されることがあります。 分散に使用される専用コンポーネントは通常、分散されている要求またはプロセスのパフォーマンスに影響します。
スコープ指定された影響に耐えるために地理的な境界または可用性ゾーンにまたがってコンポーネントを分散すると、これらの可用性境界にまたがるコンポーネント間の通信でネットワーク待機時間が発生します。
ワークロードの正常性を監視するために、広範なプロセスが使用されます。 監視は信頼性にとって極めて重要ですが、インストルメンテーションはシステムのパフォーマンスに影響を与える可能性があります。 監視が増加すると、パフォーマンスが低下する可能性があります。
自動スケーリング操作は瞬時に行われるわけではないため、成型または平滑化できない需要の急激かつ大幅な急増を確実に処理することはできません。 このため、より大規模なインスタンスまたはより多くのインスタンスを介した過剰プロビジョニングが、急増を吸収するのに役立つ需要信号と供給作成の間のラグに対応する上で極めて重要な信頼性戦術になります。 未使用の容量が存在すると、パフォーマンス効率の目標達成が阻害されます。
場合によっては、需要に応じてコンポーネントをスケーリングできず、その需要を完全に予測できない場合があります。 最悪のケースに対応するために大規模なインスタンスを使用すると、そのユース ケースを超える状況下で過剰なプロビジョニングの無駄が生じます。
関連リンク
次に挙げる他の重要な要素のトレードオフを確認してください。