ゾーンオートシフトを設定する際のベストプラクティス - Amazon Application Recovery Controller (ARC)

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ゾーンオートシフトを設定する際のベストプラクティス

Amazon Application Recovery Controller (ARC) でゾーンオートシフトを有効にするときは、次のベストプラクティスと考慮事項に注意してください。

ゾーンオートシフトには、オートシフトと練習実行ゾーンシフトの 2 種類のトラフィックシフトが含まれます。

  • オートシフト AWS を使用すると、ユーザーに代わってイベント中にアプリケーションリソーストラフィックをアベイラビリティーゾーンから遠ざけることで、復旧までの時間を短縮できます。

  • 練習実行では、ARC がユーザーに代わってゾーンシフトを開始するか、ゾーンシフト練習実行を開始します。 AWS 練習実行ゾーンシフトは、トラフィックをリソースのアベイラビリティーゾーンから遠ざけ、毎週の頻度で再度シフトします。練習実行は、リージョンのアベイラビリティーゾーンの容量を十分にスケールアップして、1 つのアベイラビリティーゾーンが失われてもアプリケーションの正常な動作を確保できます。

オートシフトと練習実行には、いくつかのベストプラクティスと考慮事項があります。ゾーンオートシフトを有効にしたり、リソースの練習実行を設定したりする前に、以下のトピックを確認してください。

トピック

クライアントがエンドポイントに接続したままになる時間を制限する

Amazon Application Recovery Controller (ARC) がゾーンシフトやゾーンオートシフトなどを使用してトラフィックを障害から遠ざける場合、ARC がアプリケーショントラフィックを移動するために使用するメカニズムは DNS 更新です。DNS 更新により、すべての新しい接続が障害のある場所から遠ざけられます。ただし、既存のオープン接続を持つクライアントは、クライアントが再接続するまで、障害が発生したロケーションに対してリクエストを引き続き行う場合があります。迅速な復旧を確保するために、クライアントがエンドポイントに接続したままになる時間を制限することをお勧めします。

Application Load Balancer を使用する場合は、 keepaliveオプションを使用して接続の継続時間を設定できます。300 秒など、アプリケーションの目標復旧時間に合わせてkeepalive値を小さくすることをお勧めします。keepalive 時間を選択するときは、この値が一般的に再接続の頻度が高いことによるトレードオフであり、レイテンシーに影響を与える可能性があり、すべてのクライアントをより迅速に障害のある AZ またはリージョンから遠ざけることができることを考慮してください。

Application Load Balancer keepaliveのオプションの設定の詳細については、Application Load Balancer ユーザーガイドの HTTP クライアントのキープアライブ期間を参照してください。

リソース容量の事前スケーリングとトラフィックの移行のテスト

がゾーン AWS シフトまたはオートシフトのためにトラフィックを 1 つのアベイラビリティーゾーンから遠ざける場合、残りのアベイラビリティーゾーンがリソースのリクエストレートの増加に対応できることが重要です。このパターンは静的安定性と呼ばれます。詳細については、The Amazon Builder's Library のホワイトペーパー「アベイラビリティーゾーンを使用した静的安定性」を参照してください。

例えば、アプリケーションがクライアントにサービスを提供するために 30 個のインスタンスを必要とする場合、3 つのアベイラビリティーゾーンに 15 個のインスタンスをプロビジョニングして、合計 45 個のインスタンスをプロビジョニングする必要があります。これにより、 がオートシフトまたは練習実行中の 1 つのアベイラビリティーゾーンからトラフィックを遠ざ AWS ける場合でも、2 つのアベイラビリティーゾーンにまたがる合計 30 個のインスタンスをアプリケーションのクライアントに提供AWS できます。

ARC のゾーンオートシフト機能は、1 つのアベイラビリティーゾーンが失われても正常に動作するように事前にスケーリングされたリソースを持つアプリケーションがある場合に、アベイラビリティーゾーンの AWS イベントから迅速に復旧するのに役立ちます。リソースのゾーンオートシフトを有効にする前に、 AWS リージョン内の設定済みのすべてのアベイラビリティーゾーンのリソース容量をスケーリングしてください。次に、リソースのゾーンシフトを開始して、トラフィックがアベイラビリティーゾーンから遠ざけられても、アプリケーションが正常に動作することをテストします。

ゾーンシフトでテストした後、ゾーンオートシフトを有効にして、アプリケーションリソースの練習実行を設定します。独自のオンデマンド練習実行を実行して、設定が適切にスケーリングされるようにします。ゾーンオートシフトを使った定期的な練習実行は、容量が引き続き適切にスケーリングされていることを継続的に確認するのに役立ちます。複数のアベイラビリティーゾーンにまたがって十分な容量があれば、アプリケーションはオートシフト中も中断することなくクライアントにサービスを提供し続けることができます。

リソースのゾーンシフトを開始する方法の詳細については、「ARC でのゾーンシフト」を参照してください。

リソースタイプと制限に注意する

ゾーンオートシフトは、ゾーンシフトによってサポートされるすべてのリソースについて、アベイラビリティーゾーン外へのトラフィックのシフトをサポートします。一部の特定のリソースシナリオでは、ゾーンオートシフトではオートシフトのためにアベイラビリティーゾーンからトラフィックがシフトされません。

例えば、アベイラビリティーゾーン内のロードバランサーのターゲットグループにインスタンスが含まれていない場合や、すべてのインスタンスが「異常」である場合、ロードバランサーはフェイルオープン状態になります。がこのシナリオでロードバランサーのオートシフト AWS を開始した場合、ロードバランサーがすでにフェイルオープン状態になっているため、ロードバランサーが使用するアベイラビリティーゾーンはオートシフトによって変更されません。これは想定される動作です。Autoshift では、すべてのアベイラビリティーゾーンがオープンに失敗 (異常) AWS リージョン した場合、1 つのアベイラビリティーゾーンが異常になり、トラフィックを の他のアベイラビリティーゾーンにシフトすることはできません。

すべての要件や注意すべき例外など、サポートされているリソースの詳細を確認するには、「サポート リソース」を参照してください。

練習実行のアラームを指定する

ゾーンオートシフトによる練習実行には、少なくとも 1 つのタイプのアラーム (結果アラーム) を設定する必要があります。必要に応じて、2 番目のタイプのアラーム (アラームのブロック) を設定することもできます。

リソースの練習実行用に設定した CloudWatch アラームを検討するときは、次の点に注意してください。

  • 練習実行設定には、少なくとも 1 つの結果アラームを設定する必要があります。結果アラームの場合、リソースまたはアプリケーションのメトリクスが、トラフィックをアベイラビリティーゾーンから遠ざけるとパフォーマンスに悪影響を与えることを示すと、CloudWatch アラームが ALARM状態になるように設定することをお勧めします。例えば、リソースのリクエストレートのしきい値を決定して、そのしきい値を超えたときには ALARM 状態になるようにアラームを設定できます。が AWS 練習実行を終了してFAILED結果を返す適切なアラームを設定するのはお客様の責任です。

  • 重要業績評価指標 (KPI) を CloudWatch アラームとして実装することを推奨している「AWS Well Architected フレームワーク」に従うことをお勧めします。その場合、これらのアラームを使用して、安全トリガーとして使用する複合アラームを作成し、アプリケーションが KPI を見逃す可能性がある場合には練習実行が開始されないようにすることができます。アラームが ALARM状態ではなくなった場合、ARC は次にリソースに対して練習実行がスケジュールされたときに練習実行を開始します。

  • 練習実行のブロックアラームでは、1 つ (または複数) を設定することを選択した場合、 AWS 練習実行を開始しないことを示すために使用する特定のメトリクスを追跡することを選択できます。例えば、アラームが進行中のインシデントがあることを示す場合などです。

  • 練習実行アラームでは、アラームごとに Amazon リソースネーム (ARN) を指定するため、まず Amazon CloudWatch でアラームを設定する必要があります。指定する CloudWatch アラームは複合アラームでもかまいません。これにより、アラームの ALARM 状態への移行をトリガーできるアプリケーションとリソースの複数のメトリクスとチェックを含めることができます。または、個別のアラームを設定し、練習実行設定に各タイプの複数のアラームを指定できます。詳細については、「Amazon CloudWatch ユーザーガイド」の「アラームの結合」を参照してください。

  • 練習実行について指定する CloudWatch アラームが、練習実行を設定しているリソースと同じリージョンにあることを確認してください。

練習実行の結果を評価する

ARC は、練習実行ごとに結果を報告します。練習実行後、結果を評価し、アクションを実行する必要があるかどうかを判断します。たとえば、容量をスケールしたり、アラームの設定を調整する必要がある場合があります。

可能な練習実行の結果は以下のとおりです。

  • 成功: 練習実行中に結果アラームが ALARM状態に入ることはなく、練習実行は 30 分間のテスト期間全体を完了しました。

  • FAILED: 練習実行中に少なくとも 1 つの結果アラームが ALARM状態になりました。

  • INTERRUPTED: 結果アラームが ALARM 状態になったのではない理由で、練習実行は終了しました。練習実行は、以下のようなさまざまな理由で中断される可能性があります。

    • が でオートシフト AWS を開始した AWS リージョン か、リージョンにアラーム条件があったため、練習実行が終了しました。

    • 練習実行は、リソースの練習実行設定が削除されたために、終了しました。

    • 練習実行は、練習実行ゾーンシフトでトラフィックが遠ざけられたアベイラビリティーゾーンのリソースについて、顧客開始のゾーンシフトが開始されたために終了しました。

    • 練習実行設定に指定された CloudWatch アラームにアクセスできなくなったため、練習実行が終了しました。

    • 練習実行に指定されたブロッキングアラームが ALARM状態になったため、練習実行が終了しました。

    • 練習実行は未知の理由で終了しました。

    • 優先順位が のゾーンオートシフトが開始されたため、練習実行が終了しました。ゾーンシフトの優先順位を参照してください。

  • CAPACITY_CHECK_FAILED: ロードバランシングと Auto Scaling グループリソースのアベイラビリティーゾーン間でバランスの取れた容量のチェックに失敗しました。

  • PENDING: 練習実行はアクティブ (進行中) です。まだ結果は戻されていません。