こんにちは。AWSサポート課の宮崎です。
今回は、先日の AWS Summit のミニステージ「AZ 障害に備えよう」を聴講し、「ゾーンシフト」と「ゾーンオートシフト」について初めて知ったので、調べたことをまとめます。
ゾーンシフト
ゾーンシフトとは
ゾーンシフトは、Route 53 Application Recovery Controller (以下 ARC) の機能の一つです。
Application Load Balancer (以下 ALB) や Auto Scaling group 等特定のリソースの通信において、ユーザーが任意の AZ を指定することで、指定した AZ へのルーティングを一時的に中断する (切り離す) ことができます。
そう聞くと、「ALB って、AZ 障害でヘルスチェックが不合格になったインスタンスにはルーティングしなくなるじゃん。ゾーンシフトを使う必要はあるの？」と思われるかもしれません。
確かに、例えば基盤障害により EC2 インスタンス自体がダウンしているような状態のときは、ALB のヘルスチェックは不合格となり、そのインスタンスへのルーティングを停止することが期待されます。
しかし、「ヘルスチェックには合格しているが、特定の AZ だけ動作に異常があるように見える」というグレーな状況も起こりえます。
例えば、AZ 内の一部の EC2 インスタンス間の通信で断続的にパケットロスが発生しているときに、ALB のヘルスチェックでは合格となってしまう場合があり、問題のある AZ に引き続きルーティングされてしまう、というようなことが考えられます。
このようなときにゾーンシフトを使用することで、お客様の判断でその AZ のリソースを切り離す対処が可能です。
aws.amazon.com Even with deep health checks in place, more ambiguous or intermittent gray failure modes can arise that are challenging to detect. For example, after a zonal deployment, a replica might respond to probes as healthy, but have a functional bug that impacts customers. Or perhaps new code is performing less efficiently or is crashing intermittently but is still responsive enough to appear healthy when checked. Subtle infrastructure issues, such as packet loss or intermittent dependency failures, can also result in slower responses that still pass health checks.
（以下、機械翻訳）
徹底的なヘルスチェックを実施していても、検出が困難な、より曖昧で断続的なグレー障害モードが発生する可能性があります。例えば、ゾーン展開後にレプリカがプローブに正常と応答するにもかかわらず、顧客に影響を与える機能上のバグがある場合があります。あるいは、新しいコードのパフォーマンスが低下したり、断続的にクラッシュしたりしているにもかかわらず、チェック時には正常と表示されるほど応答が遅い場合もあります。パケットロスや断続的な依存関係の障害といった、インフラストラクチャの微細な問題によっても、ヘルスチェックに合格しながらも応答が遅くなる場合があります。
ゾーンシフトの検証
実際に簡易的な検証を行ってみました。
構成は、以下のようになっています。
便宜上、ap-northeast-1a を AZ-A、ap-northeast-1c を AZ-C とします。
Auto Scaling group では Web サイトを立ち上げていて、index.html でそれぞれのインスタンスが起動している AZ (AZ-A または AZ-C) を表示します。
デフォルトの状態では、ページを再読み込みするたびにルーティングされる AZ が切り替わり、AZ-A と AZ-C が交互に表示されます。
今回は、ALB でゾーンシフトを設定してみます。
ALB を作成後、「アクション」>「ロードバランサー属性を編集」画面で、「アベイラビリティーゾーンのルーティング設定」の「ARC ゾーンシフト統合」を有効化します。
有効化すると、ARC のコンソール画面からゾーンシフトを実行できるようになります。
今回は、ゾーンシフトの対象 (切り離す対象) として AZ-C を選択してみました。
諸々設定して、「開始」ボタンをクリックすると、ゾーンシフトが始まります。
ゾーンシフトが始まったようです。
Web ページの再読み込みを繰り返していると、ゾーンシフト開始から約 1 分後、AZ-A のみ表示されるようになり、AZ-C が表示されなくなりました。
AZ-C にルーティングされなくなったということですね。
今回はゾーンシフトの有効期限を 10 分に設定していたので、10分経過後に再読み込みをしたところ、AZ-C が再び表示されるようになりました。
以上、ゾーンシフトの簡易的な検証でした。
ゾーンオートシフト
ゾーンオートシフトとは
ゾーンオートシフトとは、その名の通り自動的なゾーンシフトです。
AWS が内部メトリクスを監視して、電源障害やネットワーク障害などの潜在的な障害を検知すると自動的にゾーンシフトを開始し、復旧すると自動で終了します。
ゾーンシフトと比較したゾーンオートシフトの一番のメリットは、「障害発生の有無の判断が不要である」という点でしょう。
上述の通りゾーンシフトは、特定の AZ で障害が発生していると思われるが、ヘルスチェックには合格している…といった少し特殊な状況で利用する機能なので、「障害が発生している」という判断を下すこと自体に一定のハードルがあるように感じられます。
(ここでは詳細を割愛しますが、AWS Summit のミニセッションでは、上記のようなグレーな AZ 障害を検知するには、「単一の AZ でのみ影響が発生していることを検知するアラーム」と「複数のインスタンスで影響が発生していることを検知するアラーム」を組み合わせることが必要だと述べられていました。難しい…)
そんな問題を解決してくれるのがゾーンオートシフトです。AWS が判断してゾーンシフトを実行してくれるので、ユーザーはゾーンシフトにかかる監視や判断をする必要がなくなります。
なお、AWS の判断基準については公開されていません。
ゾーンオートシフトは、ゾーンシフトのリソース画面から有効化できます。
なお、今回ゾーンオートシフトが実行されたら確認してみようと思ったのですが、執筆期間中には一度も実行されませんでした。喜ばしいことです。
ゾーンオートシフトの練習実行について
ゾーンオートシフトを有効化すると、毎週のどこか約 30 分を使って、ゾーンオートシフトの本番に備える「練習実行」が行われます。
この練習実行では実際にリソースから通信が切り離されるため、リソースの様子を監視する任意の CloudWatch アラームを設定し、練習実行の成功 / 失敗の判定や、場合によっては練習実行を中止する判断材料として使用されます。
また、特定の日次で練習実行が行われないように設定することも可能です。
注意点
ゾーンシフトとゾーンオートシフトを利用する際の注意点としては、特定の AZ から通信が切り離されることで残りの AZ のリソースの負荷が高まる可能性があるという点が挙げられます。
残りの AZ のリソースのみでも許容範囲内のパフォーマンスで稼働できるかは、検証しておく必要がありそうです。
特にゾーンオートシフトの場合、ユーザーの予期しないタイミングで実行されるため、「急にゾーンシフトされて通信がすごく遅延してる！」というような状況にならないように、より慎重に検討する必要があるでしょう。
aws.amazon.com 第一に、お客様はすべてのアベイラビリティーゾーンに十分な容量がデプロイされていることを確認して、トラフィックが移動した後に残りのアベイラビリティーゾーンのトラフィックが増加しても対応できるようにする必要があります。残りのアベイラビリティーゾーンには常に十分な容量を確保し、アプリケーションの復旧を遅らせたり可用性に影響を与えたりする可能性のあるスケーリングメカニズムに依存しないことを強くお勧めします。
終わりに
今回は、ゾーンシフトとゾーンオートシフトについての概要を記載しました。
私はゾーンシフトはおろか ARC すら知らなかったのですが、皆さんはご存知でしたでしょうか？
本記事が、これから利用を検討されている方のご参考になれば幸いです。
宮崎 拓実(執筆記事の一覧)
金融系企業から研修生として出向中です。 エンタープライズ本部クラウドコンサルティング2課所属。
