View a markdown version of this page

Amazon Route 53 ヘルスチェック実行ブロック - Amazon Application Recovery Controller (ARC)
設定Route 53 ヘルスチェック実行ブロックが高可用性 DNS フェイルオーバーメカニズムとして機能する仕組みプラン評価の一環として評価されるものARC ルーティングコントロールと Route 53 ヘルスチェック実行ブロックの比較

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

Amazon Route 53 ヘルスチェック実行ブロック

Amazon Route 53 ヘルスチェック実行ブロックを使用すると、フェイルオーバー中にアプリケーションのトラフィックがリダイレクトされる先のリージョンを指定できます。実行ブロックは Amazon Route 53 ヘルスチェックを作成し、アカウントの Route 53 DNS レコードにアタッチします。リージョン切り替えプランを実行すると、Route 53 ヘルスチェックの状態が更新され、DNS 設定に基づいてトラフィックがリダイレクトされます。

重要

Route 53 ホストゾーンは、リージョンスイッチプランと同じパーティションにある必要があります。

設定

Route 53 ヘルスチェック実行ブロックを設定するには、次の値を入力します。

重要

実行ブロックを設定する前に、プランの実行ロールに正しい IAM ポリシーが設定されていることを確認してください。詳細については、「Route 53 ヘルスチェック実行ブロックのサンプルポリシー」を参照してください。

  1. ステップ名: 名前を入力します。

  2. ステップの説明 (オプション): ステップの説明を入力します。

  3. ホストゾーン ID: Route 53 のドメインと DNS レコードのホストゾーン ID。

  4. レコード名: 使用するレコードのレコード名 (ドメイン名) と、関連するヘルスチェックを入力して、アプリケーションのトラフィックをリダイレクトします。リージョン切り替えは、レコード名の Route 53 レコードセットを見つけ、レコードセットの [値] または [セット識別子] 内のリージョン名に基づいて、各レコードセットをリージョンにマッピングしようとします。

  5. レコードセット識別子 (オプション): プランの作成後にステップ 4 で指定したレコード名からリージョン切り替えがレコードセットを自動的にリージョンにマッピングできない場合、レコードセット識別子を手動で指定できます。プラン評価で詳細情報が必要であることを示す警告が返された場合は、リージョンごとに以下を含めて、レコードセット識別子でプランを更新します。

    • レコードセット識別子: レコードセットの [セット識別子] または [値/トラフィックのルーティング先] を入力します。

    • リージョン: レコードセット識別子情報を持つレコードセットに関連付けられたリージョンを入力します。

  6. [保存ステップ] を選択します。

  7. Route 53 でヘルスチェックを設定します。

    リージョン切り替えは、実行ブロックで定義されたホストゾーン内の各レコード名について、リージョンごとにヘルスチェック ID を提供します。Route 53 のアカウント内の対応するレコードセットのヘルスチェックを設定し、プランの実行中にリージョン切り替えがアプリケーションのトラフィックを正しくリダイレクトできるようにします。プランの詳細ページの [ヘルスチェック] タブで、すべての実行ブロックとリージョンのヘルスチェックを表示できます。

Route 53 ヘルスチェック実行ブロックが高可用性 DNS フェイルオーバーメカニズムとして機能する仕組み

ARC リージョンスイッチ Route53 ヘルスチェック実行ブロックは、ワークロードが 2 つのリージョンにデプロイされている場合はリージョンごとに 1 つずつ、2 つのヘルスチェックセットを作成します。これらのヘルスチェックをお客様に提供します。これらは、「モニタリング」タブのリージョンスイッチコンソールまたは ListRoute53HealthChecks API を使用して表示できます。次に、これらのヘルスチェックを Route 53 DNS レコードに関連付けます。

Route 53 ヘルスチェック実行ブロックが実行されると、内部の STOP (Standby Takes Over Primary) パターンを使用してヘルスチェックの状態を変更し、DNS フェイルオーバーを調整します。プライマリヘルスチェックは「異常」とマークされ、プライマリからセカンダリへのフェイルオーバーを調整すると、セカンダリヘルスチェックは「異常」とマークされます。このヘルスチェック状態の変更は、Route 53 がフェイルオーバー中にトラフィックをリダイレクトするために使用されます。

アクティブ/パッシブの場合: プライマリリージョンのヘルスチェックは正常で、パッシブリージョンは異常で始まります。Route53 ヘルスチェック実行ブロックを使用してフェイルオーバーすると、これらの状態は反転します。

アクティブ/アクティブの場合: すべてのヘルスチェックが正常を開始します。非アクティブ化ワークフローで Route53 ヘルスチェック実行ブロックを使用すると、ワークフローは非アクティブ化されたリージョンのヘルスチェック状態を異常に設定します。リージョンのアクティブ化ワークフローで Route53 ヘルスチェック実行ブロックを使用すると、ワークフローはアクティブ化リージョンのヘルスチェック状態を正常に設定します。

これが高可用性フェイルオーバーメカニズムであるのはなぜですか?

これが信頼性の高いフェイルオーバーメカニズムになる理由は 2 つあります。

  1. Route 53 ヘルスチェックの状態遷移は Route 53 データプレーンの一部であり、100% の可用性を実現するように設計されています。

    Route53 ヘルスチェックの状態の変更は、データプレーンオペレーションです。Route53 データプレーンはグローバルに分散され、100% の可用性を実現するように設計されています。Route53 ヘルスチェックの状態の変更にコントロールプレーンの依存関係はありません。つまり、プライマリリージョンに障害が発生していても、ヘルスチェックの状態の変更は機能します。

  2. STOP パターン (スタンバイがプライマリを引き継ぐ)

    STOP パターンは DNS フェイルオーバーを調整するメカニズムであり、ブログ記事Amazon Route 53 を使用したディザスタリカバリメカニズムの作成」で公開されました。このパターンは、内部の Route53 ヘルスチェック実行ブロックで使用されます。STOP パターンでは、正常なリージョンを「決定エージェント」として使用して、障害のあるリージョンのヘルスチェックの状態を変更します。STOP パターンは、障害のあるリージョンに依存しません。

実際の仕組みは次のとおりです。

  • Route53 ヘルスチェック実行ブロックを作成すると、ワークロードの各リージョンのリージョンスイッチによってヘルスチェックが作成され、モニタリングタブのリージョンスイッチコンソールまたは ListRoute53HealthChecks API を通じて提供されます。

  • 次に、これらを各リージョンの DNS レコードに手動で関連付けます。1 つのヘルスチェックはプライマリリージョンの DNS レコードに関連付けられ、もう 1 つのヘルスチェックはセカンダリリージョンの DNS レコードに関連付けられます。

  • ヘルスチェックはプライマリリージョンの DNS レコードに関連付けられていますが、スタンバイ (セカンダリ) リージョンのリソース (S3 にファイルが存在するなど) をモニタリングして、ヘルスチェックの状態を変更します。

  • ヘルスチェックは逆になります。スタンバイリソースに到達できない場合、プライマリリージョンのヘルスチェックはデフォルトで正常になります。スタンバイリソースが検出されると、プライマリリージョンのヘルスチェックが異常に変更されます。これにより、誤ったフェイルオーバーを防ぐことができます。

  • フェイルオーバーをトリガーするために、ファイルはスタンバイリージョンのリージョンスイッチによって作成されます。ヘルスチェックはそれを検出し、プライマリの異常をマークし、Route53 は DNS を反転します。スタンバイリソースはリージョンスイッチサービスによって管理され、顧客に依存しません。

コントロールプレーンの依存関係なし (グローバルに分散されたデータプレーン) と障害のあるリージョンの依存関係なし (STOP パターン) の組み合わせにより、お客様が 2 つのリージョンからのみ運用している場合、これは高可用性の DNS フェイルオーバーメカニズムになります。「STOP pattern documented here: Creating disaster recovery mechanisms using Amazon Route 53」を参照してください。

プラン評価の一環として評価されるもの

リージョン切り替えがプランを評価すると、リージョン切り替えは Route 53 ヘルスチェック実行ブロックの設定とアクセス許可に対していくつかのチェックを実行します。リージョン切り替えは、ヘルスチェックが実行ブロック設定で指定された DNS レコードにアタッチされていることを確認します。つまり、リージョン切り替えは、特定の AWS リージョン の DNS レコードが、そのリージョンのヘルスチェックを使用するように設定されていることを確認します。

ARC ルーティングコントロールと Route 53 ヘルスチェック実行ブロックの比較

リージョンスイッチの Amazon Route 53 ヘルスチェック実行ブロックは、DNS ベースのトラフィック管理の低コストな代替手段を提供します。ただし、この実行ブロックは、アクティブ化する に依存する AWS リージョン ため、リージョンが使用可能である必要があります。これは、正常なリージョンをアクティブ化しているため、ほとんどのお客様のニーズを満たすことができます。

ARC ルーティングコントロールは、信頼性の高い DNS ベースのトラフィック管理と 100% の可用性 SLA を提供します。ルーティングコントロールを使用すると、運用チームは安全ガードレールを使用してリージョン間でトラフィックをシフトできます。ルーティングコントロールは、100% の SLA を備えたシングルテナントソリューションを提供します。ルーティングコントロールクラスターは 5 つのリージョンに分散され、2 つのリージョンがオフラインになることを許容できます。非常に重要なアプリケーションがある場合は、ルーティングコントロールの使用を検討してください。

リージョンスイッチを使用するには、ルーティングコントロールは必要ありません。リージョンスイッチを使用して、ルーティングコントロールなしで Route 53 ヘルスチェック実行ブロックを使用してトラフィックリダイレクトを管理できます。

ルーティングコントロールは、次の状況でリージョンスイッチで値を追加します。

  • トラフィック制御メカニズム自体には 100% の可用性 SLA が必要です。

  • 組織には、重要なアプリケーションの安全ルールを使用した手動操作コントロールが必要です。

  • 必要に応じて運用チームが自動トラフィックルーティングを手動で上書きできるように、defense-in-depthが必要です。

Route 53 ヘルスチェック実行ブロックはコントロールプレーンに依存しません。ヘルスチェックレコードの変更はデータプレーンを使用するため、設定の更新を処理するためにアクティブ化するリージョンは必要ありません。以下の状況では、Route 53 ヘルスチェック実行ブロックで十分です。

  • アプリケーションは、アクティブ化 AWS リージョン する によって異なります。

  • 復旧ワークフローの一部としての自動トラフィックリダイレクトは、要件を満たします。

  • コストの最適化が優先されます。Route 53 ヘルスチェック実行ブロックは、ルーティングコントロールよりもコストが低くなります。

ほとんどのお客様は、Route 53 ヘルスチェック実行ブロックをデフォルトのトラフィックルーティングメカニズムとして開始し、トラフィック管理メカニズムに最高の信頼性を必要とする最も重要なアプリケーションにのみルーティングコントロールを追加します。