ゾーンオートシフト – 潜在的な問題を検出時にトラフィックをアベイラビリティーゾーンから自動的に移動

2023 年 11 月 30 日、 Amazon Route 53 Application Recovery Controller の新機能であるゾーンオートシフトを提供開始しました。これにより、AWS があるアベイラビリティーゾーンに影響する潜在的な障害を特定したときに、ワークロードのトラフィックをそのアベイラビリティーゾーンから自動的かつ安全にシフトし、障害が解決したら元のアベイラビリティーゾーンに戻すことができます。

耐障害性の高いアプリケーションのデプロイでは、通常、リソースをリージョンの複数のアベイラビリティーゾーンにデプロイします。アベイラビリティーゾーンとは、独立した電力、接続、ネットワーク機器、および氾濫原を確保するために、意味のある距離（通常100 km 以内）離れた物理データセンター群のことです。

デプロイの失敗、構成の誤り、オペレーターのミスなど、アプリケーションのエラーからユーザーを保護するために、2022年に手動またはプログラムでゾーンシフトをトリガーする機能を導入しました。これにより、あるアベイラビリティーゾーンでメトリクス値の低下を検出したときに、トラフィックをそのアベイラビリティーゾーンから遠ざけることができます。そのためには、すべての新しい接続を正常なアベイラビリティーゾーンのインフラストラクチャのみに転送するようにロードバランサーを設定します。これにより、障害の根本原因を調査する間、顧客はアプリケーションの利用を継続できます。障害が解消されたら、ゾーンシフトを停止して、トラフィックが再びすべてのゾーンに分散されるようにします。

ゾーンシフトは、Application Load Balancer (ALB) または Network Load Balancer (NLB) のクロスゾーン負荷分散がオフになっている場合に機能します。これは NLB のデフォルト設定です。ロードバランサーには 2 つのレベルの負荷分散があります。最初のレベルは DNS で設定されます。ロードバランサーはアベイラビリティーゾーンごとに 1 つ以上の IP アドレスを公開し、ゾーン間のクライアントサイドの負荷分散を実現します。トラフィックがアベイラビリティーゾーンに到達すると、ロードバランサーは登録された正常なターゲット、通常は Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにトラフィックを送信します。デフォルトでは、ALB はすべてのアベイラビリティーゾーンのターゲットにトラフィックを送信します。ゾーンシフトを正しく機能させるには、クロスゾーン負荷分散を無効にするようにロードバランサーを設定する必要があります。

ゾーンシフトが始まると、次の図に示すように、DNS は全てのトラフィックを一つのアベイラビリティーゾーンから遠ざけます。

手動によるゾーンシフトは、ユーザー側で発生したエラーからワークロードを保護するために役立ちます。しかし、アベイラビリティーゾーンで障害発生の可能性がある場合、時に障害の特定や検出が困難な場合もあります。アベイラビリティーゾーン単位でメトリクスを追跡することは多くないかもしれません。そのため、アプリケーションメトリクスを使用してアベイラビリティーゾーンの問題を検出することは困難です。さらに、サービスがアベイラビリティーゾーンの境界を越えて依存関係を呼び出すことも多くあります。その結果、すべてのアベイラビリティーゾーンでエラーが発生してしまいます。モダンマイクロサービスアーキテクチャでは、これらの検出と復旧の手順を数十または数百の個別のマイクロサービスで実行しなければならないことが多く、復旧に数時間かかってしまいます。

お客様から、アベイラビリティーゾーンで発生した可能性のある障害を特定する負担を軽減できないかとご要望を頂いてきました。確かに、AWS が内部のモニタリングツールを使用すれば、潜在的な問題についてお客様より先に検出できる可能性があります。

今回のリリースにより、アベイラビリティーゾーンで発生する可能性のある障害からワークロードを保護するようにゾーンのオートシフトを設定できるようになりました。AWS が、ネットワークトラフィックのシフトをいつトリガーするかを決定するために、独自の AWS 内部モニタリングツールとメトリクスを利用します。シフトは自動的に開始され、API を呼び出す必要はありません。ゾーンに電源障害やネットワーク障害などの潜在的な障害が発生していることが検出されると、インフラストラクチャの NLB または ALB トラフィックのオートシフトが自動的にトリガーされ、障害が解決された時点でトラフィックを元に戻します。

言うまでもなく、トラフィックを一つのアベイラビリティーゾーンから遠ざけることはデリケートなオペレーションであり、慎重に準備する必要があります。アプリケーションの可用性を誤って低下させないように、一連の保護手段を構築しました。

まず、トラフィックを一度に複数のアベイラビリティーゾーンから移動させないようにするために、当社には内部制御があります。次に、毎週 30 分間、インフラストラクチャの移行を練習します。お客様は練習実行をブロックする時間帯を定義できます。例えば、月曜日から金曜日の 08:00～18:00 のように定義します。3 つ目は、練習実行中のサーキットブレイカーとして機能する 2 つの Amazon CloudWatch アラームを定義できます。1 つは練習実行をまったく開始しないようにするアラーム、もう 1 つは練習実行中のアプリケーションの正常性を監視するアラームです。練習中にどちらかのアラームがトリガーされると、練習を停止し、すべてのアベイラビリティーゾーンへのトラフィックを復元します。練習終了時のアプリケーション正常性をチェックするアラームの状態は、実行の結果 (成功または失敗) を示します。

責任共有モデルにより、お客様も 2つの責任を担います。

第一に、お客様はすべてのアベイラビリティーゾーンに十分な容量がデプロイされていることを確認して、トラフィックが移動した後に残りのアベイラビリティーゾーンのトラフィックが増加しても対応できるようにする必要があります。残りのアベイラビリティーゾーンには常に十分な容量を確保し、アプリケーションの復旧を遅らせたり可用性に影響を与えたりする可能性のあるスケーリングメカニズムに依存しないことを強くお勧めします。ゾーンオートシフトがトリガーされると、 AWS Auto Scaling はリソースをスケーリングするのに通常よりも時間がかかる場合があります。リソースを事前にスケーリングすることで、最も要求の厳しいアプリケーションの復旧時間を予測できます。

通常のユーザートラフィックを吸収するために、アプリケーションが 3 つのアベイラビリティーゾーンに 6 つの EC2 インスタンス (2×3 インスタンス) を必要とするとします。ゾーンオートシフトを設定する前に、1 つのアベイラビリティーゾーンが利用できない場合にトラフィックを吸収するのに十分な容量が残りのアベイラビリティーゾーンにあることを確認する必要があります。この例では、アベイラビリティーゾーンごとに 3 つのインスタンスがあることを意味します (トラフィックが 2 つのアベイラビリティーゾーンに移動されたときに 2×3 = 6 つのインスタンスを維持して負荷分散する必要があるため、3 つのアベイラビリティーゾーンに 3×3 = 9 つのインスタンスが必要) 。

実際には、高い信頼性が求められるサービスを運用する場合、顧客を起点とする負荷の急上昇やまれにあるホスト障害などの不測の事態に備えて、ある程度の冗長容量をオンラインで運用するのが一般的です。この方法で既存の冗長性を満たすことで、アベイラビリティーゾーンの問題が発生したときに迅速に復旧できるだけでなく、他のイベントに対する堅牢性も高まります。

第二に、お客様は選択したリソースのゾーンオートシフトを明示的に有効にする必要があります。AWS は、選択したリソースにのみゾーンオートシフトを適用します。ゾーンオートシフトの適用は、アプリケーションに割り当てられる合計容量に影響します。先ほど説明したように、残りのアベイラビリティーゾーンに十分な容量をデプロイして、アプリケーションを準備する必要があります。

もちろん、この追加容量をすべてのアベイラビリティーゾーンにデプロイすることにはコストがかかります。当社がレジリエンスについて話すとき、アプリケーションの可用性とコストのどちらを決めるかというビジネス上のトレードオフがあることを説明します。これが、選択したリソースにのみゾーンオートシフトを適用するもう 1 つの理由です。

ゾーンオートシフトの設定方法を確認しましょう

ゾーンオートシフトの設定方法を示すために、よく知られている TicTacToe Web アプリケーションを CDK スクリプトを使ってデプロイします。クロスゾーン負荷分散を無効化するための CDK スクリプトのカスタマイズ方法は本記事の最後に記載しています。デプロイ後、 AWS マネジメントコンソールの Route 53 Application Recovery Controller ページを開きます。左側のペインで、「ゾーンオートシフト」を選択します。次に、ウェルカムページで、「ゾーンオートシフトを設定」を選択します。

デモアプリケーションのロードバランサーを選択します。現在、クロスゾーン負荷分散が無効になっているロードバランサーのみがゾーンオートシフトの対象であるということに注意してください。コンソールの警告からもわかるように、アベイラビリティーゾーンが 1 つ失われても動作を継続するのに十分な容量がアプリケーションにあることも確認します。

ページを下にスクロールして、AWS に 30 分間の練習を実行させたくない時間と曜日を設定します。最初は、オートシフトに慣れるまで、月曜日から金曜日の 08:00〜18:00 は練習をブロックします。時間はUTCで表され、サマータイムによって変化しないことに注意してください。UTC Converter を使用すると便利です。最初は営業時間を外して問題ありませんが、アプリケーションのトラフィックが少ない時や全くない場合に観測できないかもしれない問題を確実にキャプチャできるように、営業時間中にも練習を実行する設定をお勧めします。おそらく、ピーク時に影響を与えずにゾーンオートシフトを実行することが最も要求されることかもしれませんが、テストしたことがないことに、どの程度自信を持てるでしょうか。 常時ブロックしないのが理想ですが、それが常に現実的であるとは限らないことを我々は認識しています。

同じページのさらに下にある 2 つのサーキットブレーカーアラームを入力します。最初のものは練習の開始を防ぎます。このアラームを使って、今は練習を始めるのに良いタイミングではないと示します。例えば、アプリケーションで現在問題が発生している場合や、アプリケーションの新しいバージョンを本番環境にデプロイする場合などです。2 番目の CloudWatch アラームは、練習実行の結果を示します。これにより、ゾーンオートシフトにより、アプリケーションが練習実行にどのように反応しているかを判断できます。アラームが緑色のままであれば、すべてがうまくいったことがわかります。
練習中にこれら 2 つのアラームのいずれかがトリガーされると、ゾーンオートシフトは練習を停止し、すべてのアベイラビリティーゾーンへのトラフィックを復元します。
最後に、30 分間の練習が毎週実行され、アプリケーションの可用性が低下する場合があることに同意します。
そして、「作成」を選択します。

設定は以上です。

数日後、コンソールの「リソースのゾーンシフト履歴」タブに練習実行の履歴が表示されます。2 つのサーキットブレーカーアラームの履歴をモニタリングして、すべてが正しくモニタリングされ、設定されていることを確認しています。

オートシフト自体をテストすることはできません。アベイラビリティーゾーンで潜在的な問題を検出すると、自動的にトリガーされます。この記事で共有した手順をテストするためにアベイラビリティーゾーンをシャットダウンできるかどうかサービスチームに尋ねたところ、丁寧に断られました。
オートシフトと同じように動作する手動シフトをトリガーすれば、設定のテストができます。

さらに知っておくべきこと

ゾーンオートシフトは、現在中国と GovCloud を除くすべての AWS リージョンで追加料金なしで利用できます。
crawl, walk, run方式の適用をお勧めします。まず、手動のゾーンシフトから始め、アプリケーションに対する信頼性を確立します。次に、営業時間外に練習実行を設定したゾーンオートシフトを有効にします。最後に、営業時間中のゾーンオートシフトの練習を含めるようにスケジュールを変更します。イベントに対するアプリケーションの応答を、イベントを発生させたくないときにテストする必要があります。
また、トラフィックを 1 つのアベイラビリティーゾーンから別のアベイラビリティーゾーンに戻したときに、アプリケーションのすべての部分がどのように復旧するかを総合的に考えることをお勧めします。私が思いつくリスト (完全なものではありませんが) は次のようなものです。
まず、既に説明したように、容量増加の計画を立てます。次に、各アベイラビリティーゾーンで発生する可能性のある単一障害点について考えてみましょう。例えば、単一の EC2 インスタンスで実行されるセルフマネージドなデータベースや、1 つのアベイラビリティーゾーンに存在するマイクロサービスなどです。ゾーンシフトを必要とするアプリケーションには、 Amazon DynamoDB や Amazon Aurora などのマネージドデータベースを使用することを強くお勧めします。これらには、レプリケーションとフェイルオーバーのメカニズムが組み込まれています。3 番目に、アベイラビリティーゾーンが再び利用可能になったときに切り替える計画を立ててください。リソースのスケーリングにはどの程度の時間が必要ですか? キャッシュをrehydrateする必要がありますか?
回復力のあるアーキテクチャと方法論について詳しくは、同僚 Adrian が執筆したこの素晴らしいシリーズ記事をご覧ください。

最後に、現在ゾーンオートシフトの対象となるのは、クロスゾーン負荷分散が無効になっているロードバランサーのみであることに注意してください。CDK スクリプトからクロスゾーン負荷分散を無効にするには、 StickinessCookieDuration を削除し、ターゲットグループに load_balancing.cross_zone.enabled=false を追加する必要があります。 CDK と Typescript を使った例を以下に示します。

// Add the auto scaling group as a load balancing
// target to the listener.
const targetGroup = listener.addTargets('MyApplicationFleet', {
port: 8080,
// for zonal shift, stickiness & cross-zones load balancing must be disabled
// stickinessCookieDuration: Duration.hours(1),
targets: [asg]
});
// disable cross zone load balancing
targetGroup.setAttribute("load_balancing.cross_zone.enabled", "false");

さあ、次はあなたがゾーンオートシフトのメリットが得られるアプリケーションを選んでみましょう。まず、各アベイラビリティーゾーンのインフラストラクチャ容量を確認してから、サーキットブレーカーアラームを定義します。モニタリングが正しく設定されていることを確認したら、ゾーンオートシフトを有効にします。