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