翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ゾーンオートシフトと練習実行の仕組み
Amazon Application Recovery Controller (ARC) のゾーンオートシフト機能を使用すると、 がアベイラビリティーゾーンの顧客に影響を与える可能性のある障害がある AWS と判断した場合、ユーザーに代わってリソースのトラフィックをアベイラビリティーゾーンから AWS 遠ざけることができます。ゾーンオートシフトは、 のすべてのアベイラビリティーゾーンで事前にスケーリングされたリソース用に設計されているため AWS リージョン、アプリケーションは 1 つのアベイラビリティーゾーンが失われても正常に動作します。
ゾーンオートシフトでは、ARC がリソースのトラフィックを定期的に 1 つのアベイラビリティーゾーンから遠ざけるようにする練習実行を設定する必要があります。ARC は、練習実行設定が関連付けられているリソースにつき、約 1 週間ごとに練習実行をスケジュールします。各リソースの練習実行は個別にスケジュールされます。
各練習実行について、ARC は結果を記録します。練習実行がブロック条件によって中断された場合、練習実行の結果は成功としてマークされません。練習実行の結果の詳細については、「[練習実行の結果](arc-zonal-autoshift.considerations.md#ZAConsiderationsPracticeRunOutcomes)」を参照してください。
Amazon EventBridge 通知を設定して、オートシフトや練習実行についてアラートを受け取ることができます。詳細については、「[Amazon EventBridge でのゾーンオートシフトの使用](eventbridge-zonal-autoshift.md)」を参照してください。
**Topics**
+ [ゾーンオートシフトについて](arc-zonal-autoshift.how-it-works.about.md)
+ [がオートシフト AWS を開始および停止する場合](arc-zonal-autoshift.how-it-works.start-stop-auto.md)
+ [ARC が練習実行をスケジュール、開始、終了するタイミング](arc-zonal-autoshift.how-it-works.scheduled-practice-runs.md)
+ [練習実行の容量チェック](arc-zonal-autoshift.how-it-works.capacity-check.md)
+ [練習実行とオートシフトの通知](arc-zonal-autoshift.how-it-works.notifications.md)
+ [ゾーンシフトの優先順位](arc-zonal-autoshift.how-it-works.precedence.md)
+ [アクティブなオートシフトまたは練習実行を停止する](arc-zonal-autoshift.how-it-works.stop-shift.md)
+ [トラフィックを遠ざける方法](arc-zonal-autoshift.how-it-works.how-traffic-shifted.md)
+ [練習実行のアラーム](arc-zonal-autoshift.how-it-works.alarms.md)
+ [ブロックされた時間枠と許可された時間枠 (UTC)](arc-zonal-autoshift.how-it-works.blocked-windows.md)
# ゾーンオートシフトについて
ゾーンオートシフトは、ユーザーに代わってアプリケーションリソーストラフィックをアベイラビリティーゾーンから AWS 遠ざける機能です。 は、内部テレメトリが、顧客に影響を与える可能性のあるアベイラビリティーゾーンの障害があることを示すと、オートシフト AWS を開始します。内部テレメトリには、 AWS ネットワーク、Amazon EC2、Elastic Load Balancing サービスなど、複数のソースからのメトリクスが組み込まれています。
サポートされている AWS リソースに対してゾーンオートシフトを手動で有効にする必要があります。
リージョン内の複数の (通常は 3 つの) AZs のロードバランサーに AWS アプリケーションをデプロイして実行し、静的安定性をサポートするように事前スケーリングすると、 はトラフィックをオートシフトで移行することで、AZ 内の顧客アプリケーションをすばやく復旧 AWS できます。リソーストラフィックをリージョン内の他の AZs に移行することで、 は、停電、AZ のハードウェアまたはソフトウェアの問題、またはその他の障害による潜在的な影響の期間と重大度を減らす AWS ことができます。
ARC がサポートするリソースは、指定した AZ を異常としてマークするための連携機能を備えており、その結果として、障害のある AZ からトラフィックがシフトされます。
リソースのゾーンオートシフトを有効にする場合は、そのリソースの練習実行も設定する必要があります。リージョンのアベイラビリティーゾーンの 1 つがなくてもアプリケーションを実行するのに十分な容量があることを確認できるように、 AWS は約 1 週間ごとに 30 分間の練習実行を実施します。
ゾーンシフトと同様に、ゾーンオートシフトによってトラフィックが AZ から遠ざけられない特定のシナリオがいくつかあります。例えば、AZ 内のロードバランサーのターゲットグループにインスタンスが含まれていない場合や、すべてのインスタンスが「異常」である場合、ロードバランサーはフェイルオープン状態であり、AZ の 1 つをシフトできません。
ゾーンオートシフトの詳細については、「[ARC のゾーンオートシフト](arc-zonal-autoshift.md)」を参照してください。
# がオートシフト AWS を開始および停止する場合
リソースのゾーンオートシフトを有効にすると、 AWS がユーザーに代わってイベント中にアプリケーションのリソーストラフィックをアベイラビリティーゾーンから遠ざけることを承認し、復旧までの時間を短縮できます。
これを実現するために、ゾーンオートシフトは AWS テレメトリを使用して、顧客に影響を与える可能性のあるアベイラビリティーゾーンの障害をできるだけ早く検出します。 AWS がオートシフトを開始すると、設定済みリソースへのトラフィックは、顧客に影響を与える可能性のある障害のあるアベイラビリティーゾーンからただちに遠ざけられます。
ゾーンオートシフトは、 AWS リージョン内のすべてのアベイラビリティーゾーンのアプリケーションリソースをあらかじめスケールされたお客様向けに設計された機能です。オートシフトまたは練習実行が開始されるとき、オンデマンドでのスケーリングに頼るべきではありません。
AWS は、アベイラビリティーゾーンが回復したと判断されると、オートシフトを終了します。
# ARC が練習実行をスケジュール、開始、終了するタイミング
ARC は、1 つのリソースについて、毎週約 30 分間の練習実行をスケジュールします。ARC は、各リソースの練習実行を個別にスケジュール、開始、および管理します。ARC は、同じアカウントの複数のリソースの練習実行をまとめることはありません。ゾーンオートシフトイベントのセットアップが安全であることを確認するために、オンデマンドの練習実行を自分で開始することもできます。
練習実行が予想された時間だけ中断されずに続行すると、`SUCCESSFUL` という結果でマークされます。他にも可能性のある結果として、`FAILED`、`INTERRUPTED`、`CAPACITY_CHECK_FAILED`、`PENDING` があります。結果の値と説明は、「[練習実行の結果](arc-zonal-autoshift.considerations.md#ZAConsiderationsPracticeRunOutcomes)」セクションに記載されています。
ARC が練習実行を中断して終了するシナリオがいくつかあります。例えば、練習実行中にオートシフトが開始した場合、ARC は練習実行を中断して終了します。別の例として、練習実行に対してリソースが不利な反応を示し、練習実行を監視するために指定したアラームが `ALARM` 状態になったとします。このシナリオでも、ARC は練習実行を中断して終了します。
さらに、ARC がリソースについてスケジュールされた練習実行を開始しないシナリオもいくつかあります。
リソースの練習実行が中断またはブロックされた場合に対応して、ARC は次のことを行います。
+ リソースの練習実行が進行中に中断された場合、ARC は毎週の練習実行が終了したとみなし、そのリソースの新しい練習実行を次の週にスケジュールします。このシナリオでは、毎週の練習の結果は `FAILED` ではなく `INTERRUPTED` です。練習実行の結果が `FAILED` に設定されるのは、練習実行を監視する結果アラームが練習実行中に `ALARM` 状態になった場合のみです。
+ リソースの練習実行の開始が予定されているときにブロッキング制約がある場合、ARC は練習実行を開始しません。ARC は引き続き定期的な監視を行い、ブロッキング制約が 1 つ以上あるかどうかを判断します。ブロッキング制約がない場合、ARC はリソースの練習実行を開始します。
以下は、ARC がリソースの練習実行を開始または続行することを禁止するブロック制約の例です。
+ ARC は、進行中の AWS Fault Injection Service 実験がある場合、練習実行を開始または続行しません。ARC が練習実行の開始をスケジュールしたときに AWS FIS イベントがアクティブな場合、ARC は練習実行を開始しません。ARC は、 AWS FIS イベントを含むブロック制約について練習実行全体を監視します。練習実行がアクティブな間に AWS FIS イベントが開始された場合、ARC は練習実行を終了し、リソースに対して次に定期的にスケジュールされた練習実行まで別のイベントを開始しようとしません。
+ リージョンに現在の AWS イベントがある場合、ARC はリソースの練習実行を開始せず、リージョンでアクティブな練習実行を終了します。
練習実行が中断されずに終了すると、ARC は通常どおり 1 週間後に次の練習実行をスケジュールします。指定した AWS FIS 実験やブロックされた時間枠などのブロック制約が原因で練習実行が開始されない場合、ARC は練習実行が開始されるまで練習実行の開始を試行し続けます。
# 練習実行の容量チェック
練習実行が開始されると、一時的にトラフィックをアベイラビリティーゾーンから遠ざけるため、ARC は他のアベイラビリティーゾーンにトラフィックを安全に AZ から遠ざけるのに十分な容量があることをチェックします。十分な容量がない場合は、練習実行のトラフィックシフトは開始されず、練習実行が終了します。
さらに、ゾーンオートシフトが完了すると、オートシフトによって開始されたトラフィックシフトを ARC が終了する前に、ARC はロードバランサーリソースの容量チェックを実行します。オートシフトの終了時に容量チェックに失敗する場合、トラフィックは移動元のアベイラビリティーゾーンにシフトされません。
バランス容量のチェックは、ロードバランサーと Auto Scaling グループに対してのみ完了します。
ロードバランサーリソースの場合、容量チェックは、ロードバランサーに関連付けられた正常なホストがアベイラビリティーゾーンに分散されていることを検証します。特に、容量チェックでは、リソースが登録されているすべてのアベイラビリティーゾーンで、正常なホストの数のバランスが取れていることを確認します。容量チェックにおけるバランスとは、各アベイラビリティーゾーンの正常な容量が他のゾーンと同等であり、差異がわずかであることを意味します。
容量チェックは、Lambda タイプであるターゲットグループのロードバランサーにも、Application Load Balancer にも適用されないことに注意してください。これらのターゲットはゾーンに設定されていないためです。
Auto Scaling グループのキャパシティチェックも完了します。Auto Scaling グループの場合、キャパシティチェックは、Auto Scaling グループの正常なゾーン容量の合計、つまりすべてのアベイラビリティーゾーンにわたる正常なホストの合計数が、その Auto Scaling グループに必要な容量セットを満たしていることを確認します。
**容量チェックが失敗する場合**
リソースで使用可能な容量のバランスが取れていないことが容量チェックでわかった場合、練習実行の結果は `CAPACITY_CHECK_FAILED` になります。容量チェックが失敗する理由の詳細については、`ZonalShiftSummary` のコメントフィールドを参照してください。練習実行ゾーンシフトのコメントフィールドを見つけるには、以下を実行してください。
1. を使用して AWS CLI、[ListZonalShifts](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_ListZonalShifts.html) API オペレーションを使用して練習実行で指定したリソースのゾーンシフトを一覧表示します。
例えば、ゾーンシフトを返すために、次のようなコマンドを実行できます。
```
aws arc-zonal-shift start-practice-run
--resource-identifier="arn:aws:elasticloadbalancing:Region:111122223333:ExampleALB123456890"
```
1. 返された `ZonalShiftSummary` オブジェクトの配列を確認して、容量チェックのために失敗した練習実行のゾーンシフトを見つけます。
1. 該当するゾーンシフトに関して、`Comment` フィールドの情報を確認してください。
# 練習実行とオートシフトの通知
Amazon EventBridge 通知を設定すると、リソースの練習実行とオートシフトに関する通知の受信を選択できます。*オートシフトオブザーバー通知*と呼ばれるリソースに対してゾーンオートシフトを有効にしていない場合でも、EventBridge 通知を設定できます。オートシフトオブザーバー通知では、アベイラビリティーゾーンに障害が発生する可能性があるときに ARC が開始するすべてのオートシフトについて通知されます。このオプションは、通知 AWS リージョン を受信する各 で設定する必要があることに注意してください。
オートシフトのオブザーバー通知を有効にする手順については、「[オートシフトのオブザーバー通知の有効化または無効化](arc-zonal-autoshift.enable-autoshift-observer.md)」を参照してください。通知オプションの詳細と EventBridge での構成方法については、「[Amazon EventBridge でのゾーンオートシフトの使用](eventbridge-zonal-autoshift.md)」を参照してください。
# ゾーンシフトの優先順位
一度に適用できるゾーンシフトは 1 つのみです。つまり、リソースに対してゾーンシフト、お客様が開始したゾーンシフト、オートシフト、または AWS FIS 実験を実行する練習は 1 つだけです。2 番目のゾーンシフトが開始されると、ARC は優先順位に従いリソースに有効なゾーンシフトタイプを判断します。
優先順位の一般的な原則は、顧客として開始するゾーンシフトを他のシフトタイプよりも優先することです。ただし、現在実行中 AWSの練習実行では、オンデマンドの練習実行を開始できないことに注意してください。
ARC における優先順位について説明するために、シナリオ例における優先順位の仕組みを以下に示します。
| 適用されるゾーンシフトタイプ | 開始されるゾーンシフトタイプ | 結果 |
| --- | --- | --- |
| AWS FIS 実験 | 練習実行 | AWS FIS 実験が優先されるため、練習実行は開始されません。 |
| AWS FIS 実験 | 手動ゾーンシフト | AWS FIS 実験はキャンセルされ、手動ゾーンシフトが適用されます。 |
| AWS FIS 実験 | ゾーンオートシフト | AWS FIS 実験はキャンセルされ、ゾーンオートシフトが適用されます。 |
| AWS FIS 実験 | AWS FIS 実験 | 自動 AWS FIS シフトアクションをトリガーした既存の AWS FIS 実験が実行されているため、開始された実験は開始できません。 |
| 練習実行 | 手動ゾーンシフト | 練習実行がキャンセルされて結果が INTERRUPTED に設定され、ゾーンシフトが適用されます。 |
| 練習実行 | AWS FIS 実験 | 練習実行がキャンセルされて結果が INTERRUPTED に設定され、 AWS FIS 実験が適用されます。 |
| 練習実行 | ゾーンオートシフト | 練習実行がキャンセルされて結果が INTERRUPTED に設定され、ゾーンオートシフトが適用されます。 |
| 手動ゾーンシフト | 練習実行 | 練習実行の開始が失敗します。 |
| 手動ゾーンシフト | AWS FIS 実験 | AWS FIS 実験は開始に失敗するか、すでに進行中の場合は失敗します。 |
| 手動ゾーンシフト | ゾーンオートシフト | ゾーンオートシフトは ACTIVE ですが、リソースに APPLIED されません。手動ゾーンシフトが優先されます。 |
| ゾーンオートシフト | AWS FIS 実験 | AWS FIS 実験は開始に失敗するか、進行中の場合は失敗します。 |
| ゾーンオートシフト | 手動ゾーンシフト | ゾーンオートシフトは ACTIVE ですが、リソースに APPLIED されません。手動ゾーンシフトが優先されます。 |
| ゾーンオートシフト | 練習実行 | ゾーンオートシフトが優先されるため、練習実行の開始が失敗します。 |
リソースで現在実施されているトラフィックシフトは、適用されたゾーンシフトステータスが `APPLIED` に設定されています。一度に `APPLIED` に設定できるシフトは 1 つだけです。進行中の他のシフトは `NOT_APPLIED` に設定されますが、`ACTIVE` ステータスのままです。
# リソースのアクティブなオートシフトまたは練習実行を停止する
リソースの進行中のオートシフトを停止するには、ゾーンシフトをキャンセルする必要があります。
そのリソースについては、これまでと同じスケジュールで定期的に練習実行が行われます。オートシフトを無効にするだけでなく、練習実行も停止したい場合は、リソースに関連付けられている練習実行設定を削除する必要があります。
練習実行設定を削除すると、 はリソースのトラフィックを毎週アベイラビリティーゾーンから遠ざける練習実行を AWS 停止します。さらに、ゾーンオートシフトには練習実行が必要なため、ARC コンソールを使用して練習実行設定を削除すると、このアクションによりリソースのゾーンオートシフトも無効になります。ただし、ゾーンオートシフト API を使用して練習実行を削除する場合は、まずリソースのゾーンオートシフトを無効にする必要があることに注意してください。
詳細については、「[ゾーンオートシフトのキャンセル](arc-zonal-autoshift.canceling-an-autoshift.md)」および「[ゾーンオートシフトの有効化と操作](arc-zonal-autoshift.start-cancel.md)」を参照してください。
# トラフィックを遠ざける方法
オートシフトと練習実行のゾーンシフトの場合、ARC が顧客によって開始されたゾーンシフトに使用するのと同じメカニズムを使用して、トラフィックはアベイラビリティーゾーンから遠ざけられます。ヘルスチェックに異常があると、Amazon Route 53 は、リソースの対応する IP アドレスを DNS から削除します。それにより、トラフィックはアベイラビリティーゾーンからリダイレクトされます。新しい接続は、 AWS リージョン 代わりに の他のアベイラビリティーゾーンにルーティングされるようになりました。
オートシフトでは、アベイラビリティーゾーンが回復してオートシフトを終了する AWS と、ARC はヘルスチェックプロセスを元に戻して、Route 53 ヘルスチェックの元に戻すようリクエストします。その後、元のゾーン IP アドレスが復元され、ヘルスチェックが引き続き正常であれば、そのアベイラビリティーゾーンはアプリケーションのルーティングに再び含まれます。
オートシフトは、ロードバランサーやアプリケーションの基本的な状態を監視するヘルスチェックに基づくものではないことに注意することが重要です。ARC は、ヘルスチェックを「異常」に設定し、オートシフトまたはゾーンシフトを終了したときにヘルスチェックを再び「正常」に戻すようにリクエストすることにより、ヘルスチェックを使用してトラフィックをアベイラビリティーゾーンから遠ざけます。
# 練習実行のアラーム
ゾーンオートシフトでは、練習実行に CloudWatch アラームを 2 つ指定できますが、それは結果アラームとブロッキングアラームです。
**結果アラーム (必須)**
最初のタイプのアラームである*結果アラーム*では、少なくとも 1 つのアラームを指定する必要があります。30 分間の練習実行中にトラフィックがアベイラビリティーゾーンから遠ざけられるときに、結果アラームを設定して、アプリケーションの状態を監視する必要があります。
練習実行を有効にするには、結果アラームとして、次の両方の基準を満たす CloudWatch アラームを少なくとも 1 つ指定します。
アラームは、リソースまたはアプリケーションのメトリクスをモニタリングします。
AND
1 つのアベイラビリティーゾーンを失ってアプリケーションに悪影響が及ぶと、アラームは `ALARM` 状態で応答します。
詳細については、「[ゾーンオートシフトを設定する際のベストプラクティス](arc-zonal-autoshift.considerations.md)」の「**練習実行について指定するアラーム**」セクションを参照してください。
結果アラームには、ARC が各練習実行について報告する*練習実行結果*の情報も表示されます。結果アラームが `ALARM` 状態になると、ARC は練習実行を終了し、`FAILED` の練習実行の結果を返します。練習実行が 30 分間のテスト期間を完了しても指定した結果アラームが `ALARM` 状態にならない場合、返される結果は `SUCCEEDED` です。すべての結果値のリストと説明は、「[練習実行の結果](arc-zonal-autoshift.considerations.md#ZAConsiderationsPracticeRunOutcomes)」セクションに記載されています。
**ブロッキングアラーム (オプション)**
オプションで、2 種類目のアラーム、*ブロッキングアラーム*を指定できます。1 つ以上のアラームが `ALARM` 状態のとき、ブロッキングアラームは練習実行の開始または続行をブロックします。ブロッキングアラームは、少なくとも 1 つのアラームが `ALARM` 状態になると、練習実行のトラフィックシフトの開始をブロックし、進行中の練習実行を停止します。
例えば、複数のマイクロサービスを使用する大規模なアーキテクチャでは、1 つのマイクロサービスに問題が発生すると、通常、アプリケーション環境内の他のすべての変更を停止する必要があり、これにはブロッキング練習実行も含まれます。ARC にブロッキングアラームを追加してこれを実行できます。
# ブロックされた時間枠と許可された時間枠 (UTC)
特定の歴日、または特定の時間枠 (つまり UTC の日時) について練習実行を*ブロック*または*許可*するオプションがあります。
例えば、2024 年 5 月 1 日にアプリケーションの更新を開始する予定があり、その時点で練習実行によってトラフィックが遠ざけられないようにしたい場合は、`2024-05-01` をブロック日に設定できます。
または、ビジネスレポートの概要を週に 3 日作成するとします。このシナリオでは、次のような定期的な曜日と時刻をブロックされる時間枠として設定できます (例: UTC: `MON-20:30-21:30 WED-20:30-21:30 FRI-20:30-21:30`)。
または、ARC が練習実行を開始してセットアップをテストするには、水曜日と金曜日の正午から 5:00 までが最適だと思うかもしれません。このシナリオでは、次のような定期的な曜日と時刻を許可される時間枠として設定できます (例: UTC: `WED-12:00-17:00 FRI-12:00-17:00`)。