Route 53 Application Recovery Controller ゾーンシフトとは
Amazon Route 53 Application Recovery Controller (以下、Route 53 ARC) の新機能である、ゾーンシフトの一般提供が開始されました。
Route 53 ARC ゾーンシフトを利用することで、マルチ AZ のリソースに対し、特定の AZ を使用しないようアプリケーショントラフィックをシフトし、単一のAZにて、アプリケーションの障害からの迅速な復旧を可能にします。
クロスゾーン負荷分散がオフになっている ALB および NLBにて使用可能で、無料で利用することができます。
実際に試してみた
AWSより提供されているCloudFormation テンプレートファイルを使って、ゾーンシフトのデモを実施しました。
CloudFormation テンプレートはコチラ↓
https://github.com/aws-samples/arc-zonal-shift-demo/blob/main/README.md
デモ環境の構成
クロスゾーン負荷分散をオフにしたNLBと、各AZに2つのEC2を作成するAuto Scaling Groupを用意します。
CloudWatch Synthetics の Canary によって、NLB のゾーンエンドポイントを介してファイルをポーリングし、レイテンシーを記録します。
今回は、Fault Injection Simulatorによって、3つのAZのうち、AZ-2に障害を発生させます。
障害発生後、ゾーンシフトでAZ-2を利用しないよう、トラフィックをシフトさせます。
カスタマービューと、AZごとのビューを示す CloudWatch ダッシュボードにおいて、ゾーンシフトの前後でどのような変化があるかを確認します。
Fault Injection Simulator によって障害を注入
CloudFormation テンプレートでは、Fault Injection Simulatorに以下の2つの実験テンプレートが作成されます。
- 1つのAZに一時的にパケットロスを起こす
- 1つのAZにおいてApacheが機能しないようにする
今回は、AZ-2に一時的にパケットロスを起こします。
実験を注入すると、CloudWatch のResponse Time メトリクスにおいて、カスタマーエクスペリエンスとAZ-2のレイテンシーが上昇しました。
ゾーンシフトの開始方法
ゾーンシフトを開始するには、以下の2つの方法があります。
- AWS CLI または API を使用して開始（AWS 推奨）
StartZonalShift API 呼び出しを使用して、トラフィックをAZからシフト可能です。
以下のコマンドでは、AZ-2 を30分間ゾーンシフトさせるように設定しています。
% aws arc-zonal-shift start-zonal-shift
--away-from apne1-az2--expires-in 30m
--resource-identifier "arn:aws:elasticloadbalancing:ap-southeast-2:123456789012:loadbalancer/net/zonal-shift-demo/xxxxxxxxxxxxxxxx"
--comment "shift away from AZ B"
- マネジメントコンソールから開始
Route 53 ARCまたは、ELB の Integration タブから開始できます。
・Route 53 Application Recovery Controller＞Zonal shift
・EC2＞Load balancers＞[Integrations] タブ＞[Route 53 Application Recovery Controller]＞[Start zonal shift]
ゾーンシフト開始
ゾーンシフトを開始すると、設定した有効期限中はトラフィックをAZ-2から削除するようにリクエストされます。
トラフィックを削除している間に、トラブルシューティングを実施可能です。
※トラブルシューティングの時間が足りない場合は、UpdateZonalShift API で有効期限を延ばすことができます。
ゾーンシフトの実施結果
Response Time メトリクスにおいて、カスタマーエンドポイントが通常に戻っています。
AZ-2にレイテンシの問題は残っていますが、AZ-2は顧客のトラフィックを受け取ってません。
NLB ProcessedBytes が AZ4 と AZ3 で上昇し、AZ2 で低下しているのがその証拠です。
Route 53 ARC ゾーンシフトのベストプラクティス
キャパシティプランニングと事前スケーリング
-
ゾーンシフトによって特定AZへのトラフィックのルーティングを回避させた場合に、 AZに課せられる余分な負荷に対応するのに十分な容量を計画し、事前にスケーリングするか、自動スケーリングできることを確認します。
→ ゾーンシフトによってトラフィックのルーティングを回避させると、他のAZに負荷が増えます。その負荷に対応できなければ、ゾーンシフトのメリットを享受できません。 -
ゾーンシフトの開始を事前にテストします
AZからトラフィックが移動することを定期的にテストする
- 定期的なフェイルオーバーテストの一環として、テスト環境と運用環境の両方で、ゾーンシフトの開始を計画して実行します。
全てのAZが正常にトラフィックを処理していることを確認する
-
平常時にロードバランサーのターゲットが正常であり、リージョン内のAZでトラフィックをアクティブに処理していることを確認する。
-
ターゲットが正常かを追跡するためのダッシュボードを用意し、異常なターゲットの ELBメトリクスや、AZごとのProcessed Bytesを確認する。
→Processed Bytes によって、AZごとのELBエンドポイントへのトラフィックを確認できます。 -
隣接する2番目のリージョンからリソースの正常性を監視する。これにより、エンドユーザーのエクスペリエンスをより表現でき、アプリケーションと監視の両方が同じ災害によって同時に影響を受けるリスクを減らすことができる。
→ AWSの公式ドキュメントにも「可能であれば」との枕詞のもと推奨されていることです。
ディザスタリカバリーにデータプレーン API 操作を使用する
- 依存関係がほとんどないアプリケーションを、迅速に復旧する必要がある場合は、事前に保存された認証情報を使用して、ゾーンシフトアクションで AWS CLI または API を使用します。
→ マネジメントコンソールでゾーンシフトを開始することもできますが、高速で信頼性の高い復旧が重要な場合には、データプレーン操作が適します。
一時的にのみゾーン シフトを使用してトラフィックを移動する
- アプリケーションを復旧したらすぐに、アプリケーション全体を元の完全に冗長で回復力のある状態に確実に復元します。
→ ゾーンシフトは、あくまで一時的にトラフィックをAZから移動して障害を軽減するものです。復旧後はすぐに元の状態に復元することが推奨されます。
あとがき
本記事は初投稿となります。
今後もAWSをはじめとした勉強内容を発信していきたいと思いますので、よろしくお願いします。