トレードオフとリスクについて - AWS 規範ガイダンス

トレードオフとリスクについて

回復力のあるアーキテクチャでは、障害に対応するために、十分にテストされた、シンプルで信頼性の高いメカニズムを複数使用する必要があります。最高レベルの耐障害性を実現するには、ワークロードでできるだけ多くの障害モードを自動的に検出し、復旧させる必要があります。そのためには、耐障害性分析の実行に多大な投資が必要です。つまり、より高いレベルの耐障害性へと到達するには、トレードオフが必要です。ただし、トレードオフを継続すると、耐障害性目標と比較してリターンが低下します。最も一般的なトレードオフは次のとおりです。

  • コスト – 冗長コンポーネント、オブザーバビリティの強化、追加のツール、リソース使用率の増加により、コストが増大します。

  • 複雑なシステム — 軽減ソリューションを含む障害モードの検出と対応、およびマネージドサービスの不使用によって、システムが複雑になります。

  • エンジニアリング作業 – 障害モードを検出して対応するためのソリューションを構築するために、開発者はより多くの時間を費やす必要があります。

  • 運用オーバーヘッド – より多くの障害モードを処理するシステムをモニタリングおよび運用すると、特にマネージドサービスを使用して特定の障害モードを軽減できない場合に、運用オーバーヘッドが増大する可能性があります。

  • レイテンシーと一貫性 – 可用性を優先する分散システムを構築するには、PACELC の定理で説明されているように、一貫性とレイテンシーのトレードオフが必要です。

リターンが低下する段階まで到達した、実行中のトレードオフに基づいて耐障害性目標を達成できる確率

ユーザーストーリーで特定された障害モードの軽減策を検討するときは、必要なトレードオフを考慮してください。セキュリティと同様に、耐障害性も最適化の問題です。特定された障害によるリスクを回避、軽減、移管、または受け入れるかどうかを決定する必要があります。回避できる障害モード、受け入れるセット、転送できる障害モードがあるかもしれません。特定した障害モードの多くを軽減することもできます。どのアプローチを取るかを判断するには、次の 2 つの質問をして評価を実行します。1 つ目は、障害が発生する可能性はどれくらいか? 2 つ目は、障害が発生した場合にワークロードにはどのような影響があるか?

可能性とは、イベントが発生する妥当性の程度を表します。例えば、ユーザーストーリーに単一の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで動作するコンポーネントがある場合、パッチ適用手順やオペレーティングシステムのエラーなどにより、システムの運用中にコンポーネントが中断される可能性があります。または、プライマリインスタンスとセカンダリインスタンス間でデータを同期する Amazon Relational Database Service (Amazon RDS) によって管理されているデータベースを、完全に使用できなくなる可能性がわずかながら発生します。

影響とは、イベントによって生じる可能性のある損害の推定です。これは、財務的および評判的の両方の観点から評価する必要があり、それが影響するユーザーストーリーの価値にも関連します。例えば、データベースの過負荷は、e コマースシステムの新規注文受け入れ機能に重大な影響を与える可能性があります。ただし、ロードバランサーの背後にある 20 個のインスタンスのフリートから 1 つのインスタンスが失われても、ほとんど影響はないかもしれません。

これらの質問に対する回答を、リスク軽減に必要なトレードオフのコストと比較できます。リスクのしきい値と耐障害性目標の観点からこの情報を考慮すると、積極的に軽減する障害モードを判断できるようになります。