ARC のゾーンシフトのベストプラクティス

ゾーンシフトを開始するときは、事前にスケーリングするか、自動スケーリングができるようにキャパシティを計画することで、アベイラビリティーゾーンにかかる通常よりも大きな負荷に対応できるようにしておきます。リカバリに重点が置かれたアーキテクチャでは一般的に、(通常) 3 つのレプリカのうちいずれかがオフラインになったとき、ピーク時のトラフィックに対応できるだけの十分なヘッドルームを確保するように、コンピューティングキャパシティを事前にスケールすることが推奨されています。

サポートされているリソースのゾーンシフトを開始し、トラフィックが AZ から遠ざけると、アプリケーションがサービスリクエストに使用している容量は削除されます。AZ からのトラフィックの移行を計画し、残りの AZ で引き続きリクエストを処理できるようにする必要があります AZs 。

Amazon Application Recovery Controller (ARC) がゾーンシフトやゾーンオートシフトなどを使用してトラフィックを障害から遠ざける場合、ARC がアプリケーショントラフィックを移動するために使用するメカニズムは DNS 更新です。DNS 更新により、すべての新しい接続が障害のある場所から遠ざけられます。

ただし、既存のオープン接続を持つクライアントは、クライアントが再接続するまで、障害が発生したロケーションに対してリクエストを続ける可能性があります。迅速な復旧のために、クライアントがエンドポイントに接続したままになる時間を制限することをお勧めします。

ゾーンシフトを開始してトラフィックをアプリケーションのアベイラビリティーゾーンから移動するテストを、定期的に行います。ゾーンシフトを計画して、障害の発生時にアプリケーションをリカバリするフェイルオーバーの定期テストの一環として、できればテストと本番の両方の環境でその開始を実行します。定期テストは、運用上のイベントに備え、イベントの発生時には自信を持って緩和できるようにするために不可欠なものです。

ゾーンシフトは、アベイラビリティーゾーン内でリソース、つまりアプリケーションレプリカを異常とマークすることにより機能します。つまり、アプリケーション内のリソースが一般的に正常であり、リージョン内のアベイラビリティーゾーンでトラフィックをアクティブに受け取るようにすることが重要です。それを追跡するには、ダッシュボードを使うのがお勧めです。ダッシュボードでは、異常のあるターゲットの Elastic Load Balancing メトリクスや、アベイラビリティーゾーン別の bytesProcessed などを確認できます。

隣接する 2 番目のリージョンからリソースの正常性をモニタリングすることを検討してください。このアプローチの利点は、エンドユーザーのエクスペリエンスをより代表的なものにできることです。また、アプリケーションとモニタリングの両方が同時に同じ災害の影響を受けるリスクを軽減できることです。

依存関係がほとんどなく、アプリケーションを迅速に復旧する必要がある場合にゾーンシフトを開始するには、可能であれば、 AWS Command Line Interface または API をゾーンシフトアクションとともに、事前に保存された認証情報とともに使用することをお勧めします。でゾーンシフトを開始して AWS Management Console、使いやすくすることもできます。ただし、スピーディな、信頼性の高いリカバリがカギとなるケースでは、データプレーンオペレーションの方が適しています。詳細については、「Zonal Shift API Reference Guide」を参照してください。

ゾーンシフトは、障害を緩和するためにトラフィックをアベイラビリティーゾーンから一時的に移動する機能です。問題を解決するためのアクションを実行したら、すぐにアプリケーションのリソースをサービスに戻す必要があります。そうすることで、アプリケーション全体が、完全な冗長性とレジリエンスを備えた元の状態に戻ります。