REL01-BP06 フェイルオーバーに対応するために、現在のクォータと最大使用量の間に十分なギャップがあることを確認する - AWS Well-Architected Framework
実装のガイダンスリソース

REL01-BP06 フェイルオーバーに対応するために、現在のクォータと最大使用量の間に十分なギャップがあることを確認する

リソースに障害が発生するか、アクセスできない場合、リソースが正常に終了されるまで、クォータにカウントされることがあります。障害が発生したリソースまたはアクセスできないリソースと、代替のリソースの合計リソース数がクォータ内に収まることを確認します。このギャップを算出する際は、ネットワーク障害、アベイラビリティーゾーンの不具合、またはリージョン規模の不具合などのユースケースを考慮する必要があります。

期待される成果: 現在のサービスのしきい値を使用して、規模を問わず、リソースやリソースへのアクセスで障害に対応できます。リソースプランニングでは、ゾーン障害、ネットワーク障害、さらにはリージョン規模の不具合が考慮されています。

一般的なアンチパターン:

  • フェイルオーバーシナリオを考慮せずに、現在のニーズに基づいてサービスクォータを設定する。

  • ピーク時のサービスクォータの計算時に静的安定性の原則を考慮しない。

  • 各リージョンに求められる合計クォータを計算する際に、アクセスできないリソースの可能性を考慮しない。

  • AWS サービス障害分離境界と、予測される異常な使用パターンを考慮していないサービスがある。

このベストプラクティスを活用するメリット: サービス中断イベントがアプリケーションの可用性に影響を与えるような場合、クラウドを使用すると、このようなイベントを軽減または復旧するための戦略を実装できます。そのような戦略には、多くの場合、障害が発生したリソース、またはアクセスできないリソースに置き換わる追加リソースの作成が含まれます。このようなフェイルオーバーの状況に対応し、サービス制限の枯渇による追加の低下を発生させないようなクォータ戦略を策定します。

このベストプラクティスを確立しない場合のリスクレベル: 中

実装のガイダンス

クォータ制限を評価する際は、何らかの劣化が原因で発生する可能性のあるフェイルオーバーのケースを検討します。以下のタイプのフェイルオーバーのケースを検討する必要があります。

  • 中断したり、アクセスできない VPC。

  • アクセスできないサブネット。

  • 多くのリソースへのアクセスに影響を及ぼすレベルまで低下したアベイラビリティーゾーン。

  • まざまなネットワークルートまたは受信ポイントと送信ポイントがブロックされたり、変更されたりしている。

  • 多くのリソースへのアクセスに影響を及ぼすレベルまで低下したリージョン。

  • 複数のリソースがあるが、すべてのリソースがリージョンやアベイラビリティーゾーンの不具合の影響を受けているわけではない。

上記のリストのような障害は、フェイルオーバーイベントを開始するトリガーになる可能性があります。ビジネスへの影響は大きく異なる可能性があり、フェイルオーバーの決定は状況や顧客ごとに異なります。ただし、アプリケーションまたはサービスのフェイルオーバーという運用上の決定を下す場合、イベントが発生する前に、フェイルオーバーのロケーションでのリソースのキャパシティプランニングと、それに関連するクォータについて対処する必要があります。

発生する可能性がある通常のピーク時よりも高いピークを考慮に入れて、各サービスのクォータを確認します。このようなピークは、ネットワークまたはアクセス許可のために到達でき、まだアクティブなリソースに関連している可能性があります。終了していないアクティブなリソースは、サービスクォータ制限に対して引き続きカウントされます。

実装手順

  • フェイルオーバーまたはアクセスできなくなった場合に対応するため、サービスクォータと最大使用量の間に十分なギャップがあることを確認します。

  • デプロイのパターン、可用性の要件、消費の増加を考慮して、サービスクォータを決定します。

  • 必要に応じてクォータの引き上げをリクエストします。クォータの引き上げリクエストの実行に必要な時間を計画します。

  • 信頼性の要件 (「9 の数」としても知られる) を決定します。

  • 障害シナリオ (コンポーネント、アベイラビリティーゾーン、リージョンの損失など) を確立します。

  • デプロイ手法 (例えば、Canary、ブルー/グリーン、レッド/ブラック、ローリングなど) を確立します。

  • 現在の制限に適切なバッファ (例えば、15%) を含めます。

  • 必要に応じて、静的安定性 (ゾーンおよびリージョン) の計算を含めます。

  • 消費の増加を計画します (例えば、消費の傾向をモニタリングする)。

  • 最も重要なワークロードへの静的安定性の影響を考慮します。すべてのリージョンとアベイラビリティーゾーンで静的に安定性のあるシステムに相当するリソースを評価します。

  • オンデマンドキャパシティ予約を使用して、フェイルオーバーが発生する前に容量をスケジュールすることを検討します。これは、フェイルオーバー発生時、最も重要なビジネススケジュール中に、適切な量および種類のリソースを取得するうえで予測できるリスクの軽減に役立つ戦略です。

リソース

関連するベストプラクティス:

関連するドキュメント:

関連動画:

関連ツール: