障害モードの観点からの考え方

可用性の高いアプリケーションやシステムを設計する際には、障害が発生する可能性のあるコンポーネント、コンポーネントの障害がシステムに与える影響、およびコンポーネントの障害の影響を軽減または排除するために実装できるメカニズムを検討する必要があります。アプリケーションは 1 台のサーバー、1 台のラック、1 つのデータセンターで実行されますか? サーバー、ラック、またはデータセンターに一時的または永続的な障害が発生した場合はどうなりますか? ネットワークなどの重要なサブシステムやアプリケーション自体に障害が発生した場合はどうなりますか? これらは、障害モードです。

Outposts とアプリケーションのデプロイを計画する際には、このセクションの障害モードを考慮する必要があります。以下のセクションでは、これらの障害モードを軽減してアプリケーション環境の高可用性を向上させる方法について説明します。

障害モード 1: ネットワーク

Outpost のデプロイメントは、管理とモニタリングにおいて親リージョンへのレジリエントな接続が不可欠です。ネットワークの中断は、オペレーターのミス、機器の故障、サービスプロバイダーの停止など、さまざまな障害によって引き起こされる可能性があります。Outposts は、サイトで相互に接続された 1 つ以上のラックで構成されている場合がありますが、サービスリンクを介してリージョンと通信できない場合、接続が切断されていると見なされます。

冗長なネットワークパスは、切断イベントのリスクを軽減するのに役立ちます。接続解除イベントがワークロード操作に与える影響を把握するには、アプリケーションの依存関係とネットワークトラフィックをマッピングする必要があります。アプリケーションの可用性要件を満たすために、十分なネットワーク冗長性を計画してください。

切断イベントが発生しても、Outpost で実行されているインスタンスは引き続き実行され、Outpost ローカルゲートウェイ (LGW) を介してオンプレミスネットワークからアクセスできます。ローカルのワークロードやサービスは、リージョンのサービスに依存している場合、問題や失敗が発生する可能性があります。Outpost がリージョンから切断されている間は、変更リクエスト (Outpost でのインスタンスの起動や停止など)、コントロールプレーンオペレーション、サービステレメトリ (CloudWatch メトリクスなど) は失敗します。

障害モード 2: インスタンス

EC2 インスタンスでは、実行中のサーバーに問題があったり、インスタンスにオペレーティングシステムやアプリケーションの障害が発生したりすると、問題や失敗が発生する可能性があります。アプリケーションでこれらのタイプの障害をどのように処理するかは、アプリケーションのアーキテクチャによって異なります。モノリシックアプリケーションは通常、リカバリのためにアプリケーションまたはシステム機能を使用しますが、モジュラー型のサービス指向またはマイクロサービスアーキテクチャでは、障害が発生したコンポーネントを交換してサービスの可用性を維持するのが一般的です。

EC2 Auto Scaling グループなどの自動メカニズムを使用して、失敗したインスタンスを新しいインスタンスに置き換えることができます。インスタンスの自動リカバリでは、残りのサーバーに十分な空き容量があれば、サーバー障害が原因で失敗したインスタンスを再起動できます。

障害モード 3: コンピューティング

サーバーでは、失敗や問題が発生する可能性があり、コンポーネントの障害や定期的なメンテナンス作業など、さまざまな理由で (一時的または永続的に) 運用を停止する必要がある場合があります。Outposts ラックのサービスがサーバーの障害を処理する方法はさまざまで、お客様が高可用性オプションをどのように設定するかによっても異なります。

N+M 可用性モデルをサポートするのに十分なコンピューティング性能を注文する必要があります。ここで、N は必要な性能、M はサーバー障害に対応するためにプロビジョニングされた予備性能です。

障害が発生したサーバーのハードウェア交換は、フルマネージド AWS Outposts ラックサービスの一環として提供されます。AWS は、Outpost デプロイ内のすべてのサーバーとネットワークデバイスの状態を積極的にモニタリングします。物理的なメンテナンスを行う必要がある場合、AWS は故障したコンポーネントを交換するためにサイトを訪問する時間をスケジュールします。予備の性能をプロビジョニングすることで、障害が発生したサーバーがサービスを停止して交換される間も、ワークロードを実行し続けることができます。

障害モード 4: ラックまたはデータセンター

ラックの障害は、ラックの電力が完全に失われることや、洪水や地震による冷却の喪失やデータセンターの物理的損傷などの環境の障害が原因で発生する可能性があります。データセンターの配電アーキテクチャの欠陥やデータセンターの標準的な電源メンテナンス中のエラーは、1 つまたは複数のラック、さらにはデータセンター全体の電力が失われる原因になる可能性があります。

これらのシナリオは、同じキャンパスまたは大都市圏内の互いに独立した複数のデータセンターのフロアまたは場所にインフラストラクチャをデプロイすることで軽減できます。

AWS Outposts ラックでこのアプローチを採用する際には、アプリケーションの可用性を維持するために、アプリケーションを複数の異なる論理的な Outposts にわたって実行するように設計および分散する方法を慎重に検討する必要があります。

障害モード 5: AWS アベイラビリティーゾーンまたはリージョン

各 Outpost は、AWS リージョン 内の特定のアベイラビリティーゾーン (AZ) にアンカーされます。アンカー AZ または親リージョン内で障害が発生すると、Outpost の管理や変更可能性が失われ、Outpost とリージョンの間のネットワーク通信が中断される可能性があります。

ネットワーク障害と同様に、AZ またはリージョンの障害により、Outpost がリージョンから切断されることがあります。Outpost で実行されているインスタンスは引き続き実行され、Outpost ローカルゲートウェイ (LGW) を介してオンプレミスネットワークからアクセスできますが、前述のように、リージョンのサービスに依存している場合は問題や失敗が発生する可能性があります。

AWS AZ とリージョンの障害による影響を軽減するために、それぞれ異なる AZ またはリージョンにアンカーされた複数の Outposts をデプロイできます。次に、現在 AWS で設計およびデプロイに使用している同様のメカニズムとアーキテクチャパターンの多くを使用して、分散型のマルチ Outpost アウトポストデプロイモデルで動作するようにワークロードを設計できます。