コントロールプレーン制御による退避

最初のパターンでは、データプレーン操作を使用して、影響を受けているアベイラビリティーゾーンでの作業の実施を防止し、イベントの影響を軽減します。ただし、ロードバランサーを使用しないアーキテクチャや、ホストごとのヘルスチェックを設定できないアーキテクチャを使用している場合があります。あるいは、自動スケーリングや通常の作業スケジュール設定によって、影響を受けているアベイラビリティーゾーンに新しいキャパシティがデプロイされないようにしたい場合もあります。

両方の状況に対処するには、リソースの設定を更新するためのコントロールプレーンのアクションが必要です。このパターンは、EC2 Auto Scaling、Amazon ECS、Lambda など、ネットワーク設定を更新できるすべてのサービスで機能します。サービスごとにコードを記述する必要がありますが、ビジネスロジックは標準的なパターンに従います。必要な依存関係を最小限に抑えるために、コードはイベントに応答するオペレーターがローカルで実行する必要があります。スクリプトロジックの基本的なフローを次の図に示します。

アベイラビリティーゾーンから退避するためのコントロールプレーンの更新

1. このスクリプトは、Auto Scaling グループ、ECS サービス、Lambda 関数など、指定されたタイプのすべてのリソースを一覧表示し、リソース情報からサブネットを取得します。サポートされるリソースは、スクリプトが何をサポートするように設定されているかによって異なります。

2. 各サブネットのアベイラビリティーゾーン名を、入力パラメータとして提供され、マップされたアベイラビリティーゾーン ID と比較することで、削除すべきサブネットを決定します。

3. 特定されたサブネットを削除するように、リソースのネットワーク設定を更新します。

4. 更新の詳細は DynamoDB テーブルに記録されます。アベイラビリティーゾーン ID はパーティションキーとして保存され、リソースの ARN または名前はソートキーとして保存されます。削除されたサブネットは、文字列配列として保存されます。最後に、リソースタイプも保存され、グローバルセカンダリインデックス (GSI) のハッシュキーとして使用されます。

ステップ 4 では、実行した更新が記録されるため、このアプローチは、次の図に示すように、復旧の準備ができたら簡単に元に戻すのにも役立ちます。

アベイラビリティーゾーンからの退避から復旧するためのコントロールプレーンの更新

回復手順:

1. GSI にクエリを実行して、指定したアベイラビリティーゾーン (指定していない場合はすべてのアベイラビリティーゾーン) 内の指定したタイプのリソースごとに削除済みのサブネットを取得します。

2. DynamoDB クエリで見つかった各リソースを記述して、現在のネットワーク設定を取得します。

3. 現在のネットワーク設定のサブネットと DynamoDB のクエリから取得したサブネットを組み合わせます。

4. リソースのネットワーク設定を新しいサブネットセットで更新します。

5. 更新が正常に完了したら、DynamoDB テーブルからレコードを削除します。

この一般化されたパターンにより、影響を受けたアベイラビリティーゾーンへの作業のルーティングと、そこでの新しい容量のデプロイの両方を阻止します。さまざまなサービスで、これを実現する方法の例を以下に示します。

• Lambda — 関数の VPC 設定を更新して、指定したアベイラビリティーゾーンのサブネットを削除します。

• Auto Scaling グループ — ASG 設定からサブネットを削除します。これにより、残りのアベイラビリティーゾーンでそのキャパシティを置き換えます。

• Amazon ECS — ECS サービスの VPC 設定を更新してサブネットを削除します。

• Amazon EKS — 影響を受けたアベイラビリティーゾーンのノードにテイントを適用して既存のポッドを削除し、そこに追加のポッドがスケジュールされないようにします。

サービスごとに、設定の更新に対する反応は異なります。例えば、Amazon ECS は、更新後にサービスのデプロイ設定に従い、新しいタスクのローリングデプロイやブルー/グリーンデプロイをトリガーします。

これらの更新により、一部のワークロードでは、作業が正常なアベイラビリティーゾーンにすぐに移行する可能性があります。障害に対して静的に安定するように設定されている一方 (影響を受けているアベイラビリティーゾーンの作業を処理するのに十分なキャパシティを残りのアベイラビリティーゾーンに事前にプロビジョニングしておく)、影響を受けているアベイラビリティーゾーンのキャパシティを徐々に段階的に廃止したい場合もあります。

クロスゾーン負荷分散が無効になっているロードバランサーのターゲットグループである Auto Scaling グループのネットワーク設定を更新する予定がある場合、このガイダンスに従ってください。

Auto Scaling はアベイラビリティーゾーンの再分散ロジックを使ってこの変更に対応します。希望するキャパシティに合わせて他のアベイラビリティーゾーンでインスタンスを起動し、削除したアベイラビリティーゾーンのインスタンスを終了します。ただし、ロードバランサーは、インスタンスが終了している間も、ASG から削除したアベイラビリティーゾーンを含め、各アベイラビリティーゾーンにトラフィックを均等に分散し続けます。これにより、すべてのインスタンスが正常に終了するまで、そのアベイラビリティーゾーンの残りのキャパシティが使い果たされる可能性があります。これは、クロスゾーン負荷分散が無効になっている場合のアベイラビリティーゾーンの不均衡に関する「アベイラビリティーゾーンの独立性」で説明されているのと同じ問題です。これを防ぐため、次のいずれかの方法を行うことができます。

• トラフィックが残りのアベイラビリティーゾーンにのみ分散されるように、必ずアベイラビリティーゾーンの退避を最初に実行します。

• そのアベイラビリティーゾーンに必要な最小ターゲット数と一致するように、DNS フェイルオーバー時の正常なターゲットの最小数を指定します。

これにより、インスタンスが終了を開始した後で削除したアベイラビリティーゾーンにトラフィックが送信されないようになります。