翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# DNS フェイルオーバーの設定
複数の HTTP サーバー、あるいは複数のメールサーバーなど、同じ機能を実行するリソースが重複して存在する場合、それらのリソースの正常性をチェックし正常なリソースのみを使用して DNS クエリに応答するように、Amazon Route 53 を設定することができます。例えば、ウェブサイト (example.com) が、世界各地の 3 拠点のデータセンターにそれぞれ 2 台ずつ、合計 6 台のサーバーでホストされているとします。それらのサーバーの正常性をチェックし、その時点で正常なサーバーのみを使用して example.com の DNS クエリに応答するように Route 53 を設定することができます。
Route 53 では、構成が単純な場合と複雑な場合の両方で、リソースの正常性をチェックすることができます。
+ シンプルな構成では、example.com のタイプ A の加重レコードのグループなど、すべてが同じ名前とタイプのレコードグループを作成します。その上で、対応するリソースの正常性をチェックするように Route 53 を設定します。Route 53 は、リソースの正常性に基づいて DNS クエリへの応答を実行します。詳細については、「[Amazon Route 53 のシンプルな構成でのヘルスチェックの動作 の単純構成におけるヘルスチェックの動作](dns-failover-simple-configs.md)」を参照してください
+ より複雑な構成では、複数の基準に基づいてトラフィックをルーティングするレコードのツリーを作成します。例えば、ユーザーの待ち時間が最も重要な基準である場合、レイテンシーエイリアスレコードを使用して、ベストのレイテンシーを提供するリージョンにトラフィックをルーティングすることができます。レイテンシーエイリアスレコードは、エイリアスターゲットとして各リージョンのレコードに加重されている場合があります。加重レコードは、インスタンスタイプに基づいてトラフィックを EC2 インスタンスにルーティングします。シンプルな構成の場合と同様に、Route 53 は、リソースの正常性に基づいてトラフィックをルーティングするように設定することができます。詳細については、「[Amazon Route 53 の複雑な構成でのヘルスチェックの動作複雑な構成におけるヘルスチェックの動作](dns-failover-complex-configs.md)」を参照してください
**Topics**
+ [DNS フェイルオーバーを設定するためのタスクリスト](dns-failover-how-to.md)
+ [Amazon Route 53 のシンプルな構成でのヘルスチェックの動作](dns-failover-simple-configs.md)
+ [Amazon Route 53 の複雑な構成でのヘルスチェックの動作](dns-failover-complex-configs.md)
+ [ヘルスチェックが設定されている場合に Amazon Route 53 がレコードを選択する方法](health-checks-how-route-53-chooses-records.md)
+ [フェイルオーバー (アクティブ/アクティブとアクティブ/パッシブ) の設定](dns-failover-types.md)
+ [プライベートホストゾーンのフェイルオーバーの設定](dns-failover-private-hosted-zones.md)
+ [Amazon Route 53 でフェイルオーバーの問題を回避する方法](dns-failover-problems.md)
# DNS フェイルオーバーを設定するためのタスクリスト
Route 53 を使用して DNS のフェイルオーバーを設定するには、以下のタスクを実行します。
1. 全体的な設定の概略図を作成し、作成するレコードのタイプ (加重エイリアス、フェイルオーバー、レイテンシーなど) をノードごとに指定します。ツリーの上部には、ユーザーがウェブサイトやウェブアプリケーションにアクセスするために使用する example.com などのドメイン名のレコードを入れます。
概略図に表示されるレコードの種類は、設定の複雑さによって異なります。
+ シンプルな構成では、概略図にエイリアスレコードは含まれません。エイリアスレコードは、別の Route 53 レコードではなく、ELB ロードバランサーなどのリソースにトラフィックを直接ルーティングします。詳細については、「[Amazon Route 53 のシンプルな構成でのヘルスチェックの動作 の単純構成におけるヘルスチェックの動作](dns-failover-simple-configs.md)」を参照してください
+ 複雑な構成の場合は、エイリアスレコード (加重エイリアスやフェイルオーバーエイリアスなど) と非エイリアスレコードを複数レベルのツリーで組み合わせます (「[Amazon Route 53 の複雑な構成でのヘルスチェックの動作複雑な構成におけるヘルスチェックの動作](dns-failover-complex-configs.md)」トピックの例を参照)。
**注記**
複雑なルーティング設定のレコードをすばやく簡単に作成して、レコードをヘルスチェックに関連付けるには、トラフィックフロービジュアルエディターを使用して、設定をトラフィックポリシーとして保存することができます。その後、トラフィックポリシーを、同じホストゾーンまたは複数のホストゾーンで 1 つ以上のドメイン名 (example.com など) またはサブドメイン名 (www.example.com など) に関連付けることができます。さらに、新しい設定が期待どおりに機能していない場合は、更新を元に戻すことができます。詳細については、「[DNS トラフィックのルーティングにトラフィックフローを使用する](traffic-flow.md)」を参照してください
詳細については、次のドキュメントを参照してください。
+ [ルーティングポリシーの選択](routing-policy.md)
+ [エイリアスレコードと非エイリアスレコードの選択](resource-record-sets-choosing-alias-non-alias.md)
1. データセンターで実行されている Amazon EC2 サーバーや E メールサーバーなど、エイリアスレコードを作成できないリソースのヘルスチェックを作成します。これらのヘルスチェックは、非エイリアスレコードに関連付けます。
詳細については、「[ヘルスチェックの作成、更新、削除](health-checks-creating-deleting.md)」を参照してください
1. 必要に応じて、ヘルスチェックで指定したエンドポイントに対し、 Route 53 が定期的なリクエストを送信できるように、ルーターとファイアウォールのルールを設定します。詳細については、「[Amazon Route 53 のヘルスチェックができるようにルーターとファイアウォールのルールを設定する のヘルスチェックができるようにルーターとファイアウォールのルールを設定する](dns-failover-router-firewall-rules.md)」を参照してください
1. 概略図の中の非エイリアスレコードをすべて作成し、ステップ 2 で作成したヘルスチェックを該当するレコードに関連付けます。
エイリアスレコードを含まない設定で DNS フェイルオーバーを設定する場合、以降の作業は不要です。
1. ELB ロードバランサーや CloudFront ディストリビューションなどの AWS リソースにトラフィックをルーティングするエイリアスレコードを作成します。リソースが異常な場合に、Route 53 がツリーの別のブランチを試すようにするには、各エイリアスレコードの [**ターゲットの正常性の評価**] の値を [**Yes (あり)**] に設定してください。(**ターゲットヘルスの評価**は一部の AWS リソースではサポートされていません）。
1. ステップ 1 で作成した概略図の一番下から、ステップ 4 と 5 で作成したレコードにトラフィックをルーティングするエイリアスレコードを作成します。ツリーの 1 つのブランチの中で、非エイリアスレコードがすべて異常なときに別のブランチを試すように Route 53 を設定する場合は、各エイリアスレコードの [**ターゲットの正常性の評価**] の値を [**Yes (あり)**] に設定します。
別のレコードを作成するまで、トラフィックを別のレコードにルーティングするエイリアスレコードを作成することはできません。
# Amazon Route 53 のシンプルな構成でのヘルスチェックの動作
example.com を対象とした 2 つ以上のウェブサーバーなど、同じ機能を実行する 2 つ以上のリソースがある場合、次のヘルスチェック機能を使用して、正常なリソースにのみトラフィックをルーティングできます。
**EC2 インスタンスおよびその他のリソース (非エイリアスレコード) の正常性をチェックする**
エイリアスレコードを作成できないリソース (EC2 インスタンスなど) にトラフィックをルーティングする場合は、各リソースのレコードとヘルスチェックを作成します。次に、各ヘルスチェックを該当するレコードに関連付けます。ヘルスチェックは、対応するリソースの正常性を定期的にチェックし、Route 53 は、ヘルスチェックが正常とレポートするリソースにのみトラフィックをルーティングします。
** AWS リソース (エイリアスレコード) の正常性を評価する**
[エイリアスレコード](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)を使用して ELB ロードバランサーなどの選択した AWS リソースにトラフィックをルーティングする場合は、リソースの正常性を評価し、正常なリソースにのみトラフィックをルーティングするように Route 53 を設定できます。エイリアスレコードを設定してリソースの正常性を評価する場合、リソースのヘルスチェックを作成する必要はありません。
シンプルな構成でリソースの正常性をチェックするように、Route 53 を設定する方法の概要を以下に示します。
1. どのリソースの正常性を Route 53 で監視するかを明確にします。例えば、example.com のリクエストに応答するすべての HTTP サーバーを監視対象にするとします。
1. データセンターで実行されている EC2 インスタンスやサーバーなど、エイリアスレコードを作成できないリソースのヘルスチェックを作成します。リソースにヘルスチェックリクエストを送信する方法を指定します。具体的には、使用するプロトコル (HTTP、HTTPS、TCP)、使用する IP アドレスとポート、さらに、HTTP/HTTPS ヘルスチェックの場合はドメインの名前とパスが伝えられます。
**注記**
ELB ロードバランサーなどのエイリアスレコードを作成できるリソースを使用している場合は、それらのリソースのヘルスチェックを作成しないでください。
リソースごとにヘルスチェックを 1 つ作成し、ヘルスチェックのエンドポイントには、リソースと同じ IP アドレスを使用するのが一般的な構成です。ヘルスチェックは、指定された IP アドレスに要求を送信します。
**注記**
Route 53 では、リソースの IP アドレスがローカル、プライベート、ルーティング範囲外、またはマルチキャストのいずれかに該当する場合、正常性をチェックすることはできません。ヘルスチェックを作成できない IP アドレスの詳細については、「[RFC 5735, Special Use IPv4 Addresses](https://datatracker.ietf.org/doc/html/rfc5735)」と「[RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space](https://datatracker.ietf.org/doc/html/rfc6598)」を参照してください。
ヘルスチェック作成の詳細については、「[ヘルスチェックの作成、更新、削除](health-checks-creating-deleting.md)」を参照してください。
1. ヘルスチェックで指定したエンドポイントに対し、Route 53 が定期的なリクエストを送信できるように、ルーターとファイアウォールのルールを設定する必要があります。詳細については、「[Amazon Route 53 のヘルスチェックができるようにルーターとファイアウォールのルールを設定する のヘルスチェックができるようにルーターとファイアウォールのルールを設定する](dns-failover-router-firewall-rules.md)」を参照してください。
1. 例えば、加重レコードのグループなど、リソースのレコードのグループを作成します。エイリアスと非エイリアスレコードを混在させることができますが、[**名前**]、[**タイプ**]、および [**ルーティングポリシー**] のすべての値が同じである必要があります。
リソースの正常性をチェックするために Route 53 を設定する方法は、エイリアスレコードを作成するか非エイリアスレコードを作成するかによって異なります。
+ **エイリアスレコード** – ［**Evaluate Target Health (ターゲットの正常性の評価)**] で [**Yes (あり**)] を指定します。
+ **非エイリアスレコード**– ステップ 2 で作成したヘルスチェックを、対応するレコードと関連付けます。
設定が完了したら、次の図のような設定になります。この図には、非エイリアスレコードのみが含まれています。
![\[3 つの加重レコードおよび対応するヘルスチェック。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/hc-weighted.png)
Route 53 コンソールを使用したレコード作成の詳細については、「[Amazon Route 53 コンソールを使用したレコードの作成](resource-record-sets-creating.md)」を参照してください。
1. ヘルスチェックを作成した場合、Route 53 はヘルスチェックごとに定期的にエンドポイントにリクエストを送信します。つまり、DNS クエリを受信したときにヘルスチェックが実行されるわけではありません。Route 53 は、その応答に応じてエンドポイントが正常であるかどうかを判断し、その情報をもとにクエリへの応答方法を決定します。詳細については、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。
Route 53 によって正常性がチェックされるのは、レコードで指定されたリソース (example.com の A レコードで指定された IP アドレスなど) ではありません。レコードにヘルスチェックが関連付けられた場合、Route 53 では、ヘルスチェックで指定されたエンドポイントの正常性のチェックを開始します。また、他のヘルスチェックの正常性をモニタリングしたり、CloudWatch アラームのデータストリームをモニタリングしたりするように Route 53 を設定することもできます。詳細については、「[Amazon Route 53 ヘルスチェックの種類 ヘルスチェックの種類](health-checks-types.md)」を参照してください。
Route 53 が example.com のクエリを受信した場合の動作を以下に示します。
1. Route 53 が、ルーティングポリシーに基づいてレコードを選択します。このケースでは、重みに基づいてレコードが選択されます。
1. そのレコードのヘルスチェックのステータスをチェックして、選択されたレコードの現在の正常性を調べます。
1. 選択したレコードに異常がある場合、Route 53 は別のレコードを選択します。このとき、異常のあるレコードは候補から外されます。
詳細については、「[ヘルスチェックが設定されている場合に Amazon Route 53 がレコードを選択する方法ヘルスチェックが設定されている場合に Route 53 がレコードを選択する方法](health-checks-how-route-53-chooses-records.md)」を参照してください。
1. 正常なレコードを検出した Route 53 は、A レコードの IP アドレスなどの適切な値でクエリに応答します。
次の例は、加重レコードのグループを示しています。3 つ目のレコードに異常がみられます。まず、Route 53 は、3 つすべてのレコードの重みに基づいてレコードを選択します。最初に選択したレコードに異常が見つかると、Route 53 は別のレコードを選択します。このとき、3 つ目のレコードの重みは計算から除外されます。
+ 初めに Route 53 が 3 つすべてのレコードからの選択を行った際に、1 つ目のレコードがリクエストへの応答に使用される時間は全体の 20% (= 10/(10 \$1 20 \$1 20)) となります。
+ Route 53 により、3 つ目のレコードに異常が発見された場合、1 つ目のレコードがリクエストへの応答に使用される時間は、全体の 33% (=10/(10 \$1 20)) となります。
![\[3 つの加重レコードおよび対応するヘルスチェック。3 番目のヘルスチェックが異常であるため、Route 53 は関連するレコードが異常であると見なします。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/hc-weighted-failed-hc.png)
レコードグループ内の 1 つ以上のレコードからヘルスチェックを省略すると、Route 53 には対応するリソースの正常性を判断する方法がなくなります。Route 53 は、それらのレコードを正常と見なします。
![\[3 つの加重レコード (ヘルスチェックが関連付けられているのは 2 つだけ) Route 53 は、常に 3 番目のレコードが正常であると見なします。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/hc-weighted-missing-health-check.png)
# Amazon Route 53 の複雑な構成でのヘルスチェックの動作
複雑な構成であっても、リソースの正常性をチェックする方法は同じです。ただし、複雑な構成では、エイリアスレコード (加重エイリアスやフェイルオーバーエイリアスなど) と非エイリアスレコードを組み合わせてデシジョンツリーを構築し、リクエストに対する Route 53 の応答を柔軟に制御することができます。
例えば、レイテンシーエイリアスレコードを使用して、ユーザーに近いリージョンを選択することが考えられます。また、各リージョン内の複数のリソースに加重レコードを使用して、単一エンドポイントやアベイラビリティーゾーンの障害への対策を講じることも可能です。この設定は以下の図のようになります。
![\[レイテンシーエイリアスレコードおよび加重エイリアスレコードを含む DNS 設定。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted.png)
Amazon EC2 と Route 53 の設定方法は次のとおりです。ツリーの一番下から始めましょう。これはレコードを作成する順序です。
+ us-east-1 と ap-southeast-2 という 2 つのリージョンのそれぞれに、2 つの EC2; インスタンスが存在します。EC2 インスタンスが正常であるかどうかを判断して、Route 53 がトラフィックをルーティングするように、各インスタンスのヘルスチェックを作成します。各ヘルスチェックを設定して、インスタンスの Elastic IP アドレスで対応するインスタンスにヘルスチェックリクエストを送信します。
Route 53 はグローバルサービスであるため、ヘルスチェックを作成するリージョンは指定しないでください。
+ インスタンスタイプに基づいて各リージョンの 2 つのインスタンスにトラフィックをルーティングするため、各インスタンスに加重レコードを作成し、各レコードに重みを付与します。(後で加重を変更して、より多くのトラフィックを、またはより少ないトラフィックをインスタンスにルーティングできます。) また、該当するヘルスチェックを各インスタンスに関連付けます。
レコードを作成するとき、us-east-1-www.example.com. や ap-southeast-2-www.example.com. などの名前を使用します。ツリーの一番上に到達するまで待って、ユーザーがウェブサイトやウェブアプリケーションにアクセスするために使用する名前 (example.com など) をレコードに渡します。
+ ユーザーのレイテンシーが最も短いリージョンにトラフィックをルーティングする場合は、ツリー上部のレコードのレイテンシーの[ルーティングポリシー](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)を選択します。
トラフィックを各リージョンの*リソース*に直接ルーティングするのではなく、各リージョンの*レコード*にルーティンしたいとします（加重レコードはすでにしています）。その結果、レイテンシーの[エイリアスレコード](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)を作成することになります。
エイリアスレコードを作成するときに、ユーザーがウェブサイトやウェブアプリケーションにアクセスするために使用する名前 (example.com など) を指定します。エイリアスレコードは、example.com のトラフィックを us-east-1-www.example.com と ap-southeast-2-www.example.com のレコードにルーティングします。
レイテンシーエイリアスレコードの [**Evaluate Target Health**] の値は、どちらも [**Yes**] に設定します。これにより Route 53 は、リージョンにトラフィックをルーティングしようとする前に、そこに正常なリソースがあるかどうかを判断します。正常なリソースがない場合、Route 53 は、他のリージョンから正常なリソースを選択します。
![\[レイテンシーエイリアスレコードおよび加重エイリアスレコードを含む DNS 設定。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-both-failed.png)
前の図は、以下の一連のイベントを示したものです。
1. Route 53 が example.com のクエリを受信します。要求元のユーザーに対するレイテンシーに基づいて、Route 53 は us-east-1 リージョンのレイテンシーエイリアスレコードを選択します。
1. Route 53 は、重みに基づいて加重レコードを選択します。レイテンシーエイリアスレコードの [**Evaluate Target Health (ターゲットの正常性の評価)**] が [**Yes (あり)**] であるため、Route 53 は、選択された加重レコードの正常性をチェックします。
1. ヘルスチェックで不合格と判明した場合、Route 53 は、別の加重レコードを重みに基づいて選択し、その正常性をチェックします。そのレコードも異常であると判明します。
1. Route 53 は、ブランチの出発点に戻り、次善のレイテンシーを持つレイテンシーエイリアスレコードを検索して、ap-southeast-2 のレコードを選択します。
1. Route 53 は再度、重みに基づいてリソースを選択し、その正常性をチェックします。リソースは正常なので、Route 53 はクエリに対応した適切な値を返します。
**Topics**
+ [エイリアスレコードにヘルスチェックを関連付けるとどうなるか](#dns-failover-complex-configs-hc-alias)
+ [ヘルスチェックを省略するとどうなるか](#dns-failover-complex-configs-hc-omitting)
+ [[Evaluate Target Health] を [No] に設定するとどうなるか](#dns-failover-complex-configs-eth-no)
## エイリアスレコードにヘルスチェックを関連付けるとどうなるか
[**Evaluate Target Health**] の値を [**Yes**] に設定する代わりに (または設定したうえで)、エイリアスレコードにヘルスチェックを関連付けることができます。ただし、実用性の面からいうと、基盤になるリソース (HTTP サーバー、データベースサーバーなど、エイリアスレコードの参照先となるリソース) の正常性に基づいて Route 53 がクエリに応答する、という構成の方が一般的です。例えば、次の構成を考えてみます。
+ 一連の加重レコードをエイリアスターゲットとするレイテンシーエイリアスレコードにヘルスチェックを割り当てます。
+ レイテンシーエイリアスレコードの [**Evaluate Target Health**] の値は、[**Yes**] に設定します。
この設定で、加重レコードに応じた値を Route 53 が返すためには、次の 2 点が満たされなければなりません。
+ レイテンシーエイリアスレコードに関連付けられているヘルスチェックが合格すること。
+ 少なくとも 1 つの加重レコードが、合格したヘルスチェックに関連付けられているか、またはヘルスチェックそのものに関連付けられていないことから、正常と見なされること。後者のケースでは、Route 53 は常に加重レコードを正常と見なします。
次の図では、左上のレイテンシーエイリアスレコードのヘルスチェックに失敗しています。結果として、Route 53 は、加重レコードのすべてが正常であっても、レイテンシーエイリアスレコードが参照する加重レコードのいずれかを使用したクエリの応答を停止します。Route 53 は、レイテンシーエイリアスレコードのヘルスチェックが再び正常となった場合にのみ、これらの加重レコードの再チェックを開始します。(例外については、「[ヘルスチェックが設定されている場合に Amazon Route 53 がレコードを選択する方法ヘルスチェックが設定されている場合に Route 53 がレコードを選択する方法](health-checks-how-route-53-chooses-records.md)」を参照してください。)
![\[ターゲットの正常性の評価が Yes で、エイリアスレコードのヘルスチェックに設定してあるエイリアスレコードを含む DNS 設定。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-alias-hc-failed.png)
## ヘルスチェックを省略するとどうなるか
複雑な構成では、エイリアス以外のすべてのレコードにヘルスチェックを関連付けることが大切です。次の例では、us-east-1 リージョンのいずれかの加重レコードでヘルスチェックが欠落しています。
![\[ヘルスチェックが一度失敗し、ヘルスチェックのないレコードが 1 つある DNS 設定。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-missing-health-check.png)
以下に、この構成の非エイリアスレコードでヘルスチェックを省略した場合の動作を説明します。
1. Route 53 が example.com のクエリを受信します。要求元のユーザーに対するレイテンシーに基づいて、Route 53 は us-east-1 リージョンのレイテンシーエイリアスレコードを選択します。
1. Route 53 は、レイテンシーエイリアスレコードのエイリアスターゲットを探し、対応するヘルスチェックのステータスをチェックします。一方の加重レコードのヘルスチェックが不合格となり、そのレコードは考慮の対象から除外されます。
1. us-east-1 リージョンのエイリアスターゲット内のもう一方の加重レコードにはヘルスチェックが関連付けられていません。ヘルスチェックを行わない限り、対応するリソースが正常であるかどうかを Route 53 が認識する方法はありません。リソースは正常なので、Route 53 はクエリに応じて適切な値を返します。
## [Evaluate Target Health] を [No] に設定するとどうなるか
一般に、ツリー内のすべてのエイリアスレコードについて、[**ターゲットの正常性の評価**] を [**Yes** (あり)] に設定する必要があります。[**Evaluate Target Health (ターゲットの正常性の評価)**] を [**No (なし)**] に設定した場合、Route 53 は、レコードのヘルスチェックが失敗した場合でも、エイリアスレコードが参照するレコードにトラフィックをルーティングし続けます。
次の例では、すべての加重レコードに関連付けられたヘルスチェックがありますが、us-east-1 リージョンのレイテンシーエイリアスレコードの [**ターゲットの正常性の評価**] は [**No** (なし)] に設定されています。
![\[ターゲットの正常性の評価が No に設定されているエイリアスレコードを含む DNS 設定。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-eth-is-no.png)
この構成でエイリアスレコードの [**Evaluate Target Health**] を [**No**] に設定した場合の動作を以下に説明します。
1. Route 53 が example.com のクエリを受信します。要求元のユーザーに対するレイテンシーに基づいて、Route 53 は us-east-1 リージョンのレイテンシーエイリアスレコードを選択します。
1. Route 53 は、レイテンシーエイリアスレコードのエイリアスターゲットを特定し、対応するヘルスチェックを調べます。どちらも不合格です。
1. us-east-1 リージョンでは、レイテンシーエイリアスレコードの [**Evaluate Target Health**] の値が [**No**] であるため、Route 53 は、このブランチの中からいずれかのレコードを選ぶ必要があります。ブランチの出発点に戻って ap-southeast-2 リージョンから正常なレコードを探すことはありません。
# ヘルスチェックが設定されている場合に Amazon Route 53 がレコードを選択する方法
同じ名前、同じタイプ (A または AAAA など)、および同じルーティングポリシー (加重またはフェイルオーバーなど) を持つレコードグループ内のすべてのレコードのヘルスチェックを設定すると、Route 53 は正常なレコードを選択し、そのレコードから該当する値を返すことによって、DNS クエリに応答します。
例えば、3 つの加重された A レコードを作成し、そのすべてにヘルスチェックを割り当てたとします。1 つのレコードでヘルスチェックが正常でない場合、Route 53 は他の 2 つのレコードのいずれかの IP アドレスで DNS クエリに応答します。
正常なレコードを Route 53 が選択する際の動作を以下に示します。
1. 最初に Route 53 は、ルーティングポリシーと各レコードに指定した値に基づいてレコードを選択します。例えば、加重レコードの場合、Route 53 は各レコードに指定した重みに基づいてレコードを選択します。
1. Route 53 は、レコードが正常であるかどうかを判断します。
+ **関連付けられたヘルスチェックを持つ非エイリアスレコード** – ヘルスチェックを非エイリアスレコードに関連付けた場合、Route 53 はヘルスチェックの現在のステータスをチェックします。
Route 53 は、ヘルスチェックで指定されたエンドポイントの正常性を定期的にチェックします。DNS クエリが到着した時点でヘルスチェックを実行するわけではありません。
ヘルスチェックはエイリアスレコードに関連付けることができますが、ヘルスチェックはエイリアス以外のレコードにのみ関連付けることをお勧めします。詳細については、「[エイリアスレコードにヘルスチェックを関連付けるとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias)」を参照してください。
+ **[Evaluate Target Health (ターゲットの正常性の評価)] が [Yes (あり)] に設定されたエイリアスレコード** – Route 53 は、エイリアスレコードが参照するリソース (例えば、ELB ロードバランサーまたは同じホストゾーン内の別のレコード) のヘルスステータスをチェックします。
1. レコードが正常であれば、Route 53 は、適切な値 (IP アドレスなど) でクエリに応答します。
レコードが異常である場合、Route 53 は同じ基準で別のレコードを選択し、正常なレコードが見つかるまでそのプロセスを繰り返します。
レコードを選択する際、Route 53 は以下の基準を使用します。
**ヘルスチェックのないレコードは常に正常**
同じ名前とタイプを持つレコードのグループ内で、レコードに関連付けられているヘルスチェックがない場合、Route 53 はそのレコードを常に正常と見なします。クエリへの応答の候補には、そのレコードが常に含まれます。
**レコードが正常でない場合は、すべてのレコードが正常**
レコードのグループ内に正常なレコードが 1 つも存在しなかった場合でも、Route 53 は DNS クエリへの応答として何かを返す必要がありますが、レコードの優劣を選択するための判断材料がありません。この状況では、グループに含まれるすべてのレコードが正常と見なされ、Route 53 はルーティングポリシーと各レコードに指定した値に基づいて 1 つを選択します。
**重みが 0 である加重レコード**
加重レコードのグループ内のすべてのレコードにヘルスチェックを追加する一方で、一部のレコードにゼロ以外の重みを付け、他のレコードの重みをゼロにした場合、ヘルスチェックは、次の例外を除いて、すべてのレコードの重みがゼロ以外の場合と同様に動作します。
+ 最初に Route 53 は、ゼロ以外の加重レコード (存在する場合) のみを対象とします。
+ 重みが 0 より大きいレコードがいずれも異常であった場合、Route 53 は、重みがゼロである加重レコードを対象にします。
一部の状況では Route 53 は重みがゼロである加重レコードを考慮するので、重みがゼロのターゲットにも DNS クエリに対する実行可能な回答があるようにすることが重要です。
加重レコードの詳細については、「[ヘルスチェックと加重ルーティング](routing-policy-weighted.md#routing-policy-weighted-healthchecks)」を参照してください。
**エイリアスレコード**
各エイリアスレコードに対して [**ターゲットの正常性の評価**] を [**Yes** (あり)] に設定することで、エイリアスレコードのヘルスチェックを設定することもできます。これにより Route 53 は、レコードがトラフィックをルーティングする先のリソース (例えば、ELB ロードバランサーまたは同じホストされたゾーン内の別のレコード) で、その正常性を評価します。
例えば、エイリアスレコードのエイリアスターゲットが、一連の加重レコードから成るグループであり、そのグループの加重レコードの重みがいずれもゼロ以外であるとします。
+ 正常な加重レコードが 1 つでもあれば、Route 53 は、そのエイリアスレコードを正常と見なします。
+ 正常な加重レコードが存在しない場合、Route 53 は、そのエイリアスレコードを異常と見なします。
+ 少なくとも 1 つの加重レコードが正常に戻るまで、Route 53 は、そのツリーのブランチのレコードを候補から除外します。
詳細については、「[Amazon Route 53 の複雑な構成でのヘルスチェックの動作複雑な構成におけるヘルスチェックの動作](dns-failover-complex-configs.md)」を参照してください。
**フェイルオーバーレコード**
フェイルオーバーレコードは、通常、他のルーティングタイプと同じように動作します。ヘルスチェックを作成し、それらを非エイリアスレコードに関連付けて、エイリアスレコードの [**ターゲットの正常性の評価**] を [**Yes** (あり)] に設定します。次の点に注意してください。
+ プライマリレコードとセカンダリレコードは、どちらも非エイリアスレコードまたはエイリアスレコードです。
+ プライマリフェイルオーバーレコードとセカンダリフェイルオーバーレコードの両方にヘルスチェックが関連付けられている場合、Route 53 は、リクエストに対して次のように応答します。
+ プライマリレコードが正常 (ヘルスチェックのエンドポイントが正常) であると判断した Route 53 は、 DNS クエリへの応答としてプライマリレコードのみを返します。
+ プライマリレコードが異常でありセカンダリレコードが正常であると Route 53 が判断した場合は、セカンダリレコードが返されます。
+ プライマリレコードとセカンダリレコードの両方が異常であると Route 53 が判断した場合は、プライマリレコードが返されます。
+ セカンダリレコードを設定する際、ヘルスチェックを追加するかどうかは任意です。セカンダリのヘルスチェックが省略されていて、プライマリレコードのヘルスチェックエンドポイントが異常だった場合、Route 53 は常にセカンダリレコードで DNS クエリに応答します。セカンダリレコードが異常であったとしても同様です。
詳細については、以下のトピックを参照してください。
+ [1 つのプライマリリソースおよび 1 つのセカンダリリソースを使用したフェイルオーバー (アクティブ/パッシブ) の設定](dns-failover-types.md#dns-failover-types-active-passive-one-resource)
+ [複数のプライマリリソースおよびセカンダリリソースを使用したフェイルオーバー (アクティブ/パッシブ) の設定](dns-failover-types.md#dns-failover-types-active-passive-multiple-resources)
# フェイルオーバー (アクティブ/アクティブとアクティブ/パッシブ) の設定
Route 53 のヘルスチェックを使用して、フェイルオーバー (アクティブ/アクティブとアクティブ/パッシブ) を設定できます。フェイルオーバー以外のいずれかの[ルーティングポリシー](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) (またはルーティングポリシーの組み合わせ) を使用して、フェイルオーバー (アクティブ/アクティブ) を設定し、フェイルオーバールーティングポリシーを使用してフェイルオーバー (アクティブ/パッシブ) を設定します。
**Topics**
+ [フェイルオーバー (アクティブ/アクティブ)](#dns-failover-types-active-active)
+ [アクティブ/パッシブ (フェイルオーバー)。](#dns-failover-types-active-passive)
## フェイルオーバー (アクティブ/アクティブ)
すべてのリソースをほとんどの時間で利用できるようにするには、このフェイルオーバー設定を使用します。利用不可能になったリソースについては、Route 53 は異常として検出できるので、以後、クエリへの応答に使用しなくなります。
アクティブ/アクティブのフェイルオーバーでは、Route 53 がそれらを異常と見なさない限り、同じ名前、同じタイプ (A または AAAAなど)、および同じルーティングポリシー (加重またはレイテンシーなど) を持つすべてのレコードがアクティブとなります。Route 53 は、正常な任意のレコードを使用して DNS クエリに応答できます。
## アクティブ/パッシブ (フェイルオーバー)。
プライマリリソースまたはリソースグループをほとんどの時間で利用可能にして、すべてのプライマリリソースが使用できなくなった場合に備えて、セカンダリリソースまたはリソースグループをスタンバイ状態にする場合は、フェイルオーバー (アクティブ/パッシブ) 設定を使用します。クエリへの応答で Route 53 が返すのは、正常なプライマリリソースのみです。すべてのプライマリリソースで異常が発生した場合、Route 53 は、DNS クエリへの応答として正常なセカンダリリソースのみを返します。
**Topics**
+ [1 つのプライマリリソースおよび 1 つのセカンダリリソースを使用したフェイルオーバー (アクティブ/パッシブ) の設定](#dns-failover-types-active-passive-one-resource)
+ [複数のプライマリリソースおよびセカンダリリソースを使用したフェイルオーバー (アクティブ/パッシブ) の設定](#dns-failover-types-active-passive-multiple-resources)
+ [加重レコードを使用してフェイルオーバー (アクティブ/パッシブ) を構成する](#dns-failover-types-active-passive-weighted)
### 1 つのプライマリリソースおよび 1 つのセカンダリリソースを使用したフェイルオーバー (アクティブ/パッシブ) の設定
1 つのプライマリレコードと 1 つのセカンダリレコードでフェイルオーバー (アクティブ/パッシブ) 設定を作成するには、レコードを作成し、ルーティングポリシーとして [**フェイルオーバー**] を指定します。プライマリリソースが正常な場合、Route 53 はプライマリレコードを使用して DNS クエリに応答します。プライマリリソースが異常な場合、Route 53 はセカンダリレコードを使用して DNS クエリに応答します。
### 複数のプライマリリソースおよびセカンダリリソースを使用したフェイルオーバー (アクティブ/パッシブ) の設定
プライマリレコード、セカンダリレコード、またはその両方に複数のリソースを関連付けることもできます。この構成では、 関連付けられたリソースの少なくとも 1 つが正常である限り、Route 53 はプライマリフェイルオーバーレコードが正常であると見なします。詳細については、「[ヘルスチェックが設定されている場合に Amazon Route 53 がレコードを選択する方法ヘルスチェックが設定されている場合に Route 53 がレコードを選択する方法](health-checks-how-route-53-chooses-records.md)」を参照してください。
プライマリまたはセカンダリレコードの複数のリソースでフェイルオーバー (アクティブ/パッシブ) を設定するには、次のタスクを実行します。
1. トラフィックをルーティングするリソース (EC2 インスタンスやデータセンター内のウェブサーバーなど) ごとに、ヘルスチェックを作成します。
**注記**
[エイリアスレコード](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)を作成できる AWS リソースにトラフィックをルーティングする場合は、それらのリソースのヘルスチェックを作成しないでください。エイリアスレコードを作成する場合は、[**ターゲットの正常性の評価**] を [**Yes** (あり)] に設定します。
詳細については、「[ヘルスチェックの作成と更新](health-checks-creating.md)」を参照してください。
1. プライマリリソースのレコードを作成し、次の値を指定します。
+ 各レコードに同じ名前、タイプ、ルーティングポリシーを割り当てます。例えば、すべてが failover-primary.example.com という名前の 3 つの加重 A レコードを作成することができます。
+ エイリアスレコードを作成できる AWS リソースを使用している場合は、ターゲットの状態の評価に**「はい**」と指定します。 ****
エイリアスレコードを作成できないリソースを使用している場合は、ステップ 1 の該当するヘルスチェックを各レコードに関連付けます。
詳細については、「[Amazon Route 53 コンソールを使用したレコードの作成](resource-record-sets-creating.md)」を参照してください。
1. 該当する場合、セカンダリリソースのレコードを作成し、次の値を指定します。
+ 各レコードに同じ名前、タイプ、ルーティングポリシーを割り当てます。例えば、すべてが failover-secondary.example.com という名前の 3 つの加重 A レコードを作成することができます。
+ エイリアスレコードを作成できる AWS リソースを使用している場合は、ターゲットの状態の評価に**「はい**」と指定します。 ****
エイリアスレコードを作成できないリソースを使用している場合は、ステップ 1 の該当するヘルスチェックを各レコードに関連付けます。
**注記**
一部のお客様は、プライマリリソースとしてウェブサーバーを使用し、ウェブサイトエンドポイントとして構成された Amazon S3 バケットをセカンダリリソースとして使用されています。S3 バケットには、「一時的に使用できません」という簡単なメッセージが含まれています。その構成を使用している場合は、この手順をスキップして、ステップ 4 でセカンダリリソースのフェイルオーバーエイリアスレコードを作成します。
1. プライマリとセカンダリの 2 つのフェイルオーバーエイリアスレコードを作成し、次の値を指定します。
**プライマリレコード**
+ **Name (名前)** – Route 53 でトラフィックをルーティングさせるドメイン名 (example.com)、またはサブドメイン名 (www.example.com) を指定します。
+ **エイリアス **– **あり** を指定します。
+ **エイリアス先 **‐ ステップ 2 で作成したレコードの名前を指定します。
+ **ルーティングポリシー **– **フェイルオーバーを指定します。**
+ **フェイルオーバーレコードのタイプ **– **プライマリ**を指定します。
+ **ターゲットの正常性の評価** – **あり** を指定します。
+ **ヘルスチェックとの関連付け** – **なし **を指定します。
**セカンダリレコード**
+ **名前**－プライマリレコードに指定したものと同じ名前を指定します。
+ **エイリアス** – **ありを指定します**。
+ **エイリアス先 **– ステップ 3 でセカンダリリソースのレコードを作成している場合は、レコードの名前を指定します。セカンダリリソースに Amazon S3 バケットを使用している場合は、ウェブサイトエンドポイントの DNS 名を指定します。
+ **ルーティングポリシー**－ **フェイルオーバーを指定します**。
+ **フェイルオーバーレコードのタイプ **–** セカンダリ を指定します**。
+ **ターゲットの正常性の評価 ** －**あり を指定します**。
+ **ヘルスチェックとの関連付け** －**なしを指定します**。
### 加重レコードを使用してフェイルオーバー (アクティブ/パッシブ) を構成する
また、警告付きのフェイルオーバー (アクティブ/パッシブ) のために加重されたレコードを使用することもできます。一部のレコードに対してゼロ以外の重みを指定し、他のレコードに対してゼロの重みを指定した場合、Route 53 は重みがゼロ以外の健全なレコードのみを使用して DNS クエリに応答します。重みがゼロより大きいレコードがいずれも異常であった場合、Route 53 は重みがゼロであるレコードを使用してクエリに応答します。
**注記**
Route 53 がゼロの重みを持つレコードを使用して DNS クエリに応答するためには、ゼロ以外の重みを持つすべてのレコードが異常とみなされる必要があります。これにより、ウェブサーバーなどの最後の正常なリソースが、他のリソースが利用できないときにすべてのトラフィックを処理できない場合、ウェブアプリケーションまたはウェブサイトが信頼できなくなる可能性があります。
# プライベートホストゾーンのフェイルオーバーの設定
プライベートホストゾーンにフェイルオーバーレコードを作成する方法は、次の点に注意してください。
+ Route 53 ヘルスチェッカーは VPC の外にあります。IP アドレスを使用して VPC 内のエンドポイントの正常性をチェックするには、VPC 内のインスタンスにパブリック IP アドレスを割り当てる必要があります。
+ また、CloudWatch メトリクスを作成し、アラームをメトリクスに関連付けて、アラームのデータストリームに基づくヘルスチェックを作成することもできます。例えば、EC2 の `StatusCheckFailed` メトリクスのステータスをチェックする CloudWatch メトリクスを作成、このメトリクスにアラームを追加、さらにアラームのデータストリームに基づいたヘルスチェックを作成することが可能であり、バーチャルプライベートクラウド (VPC) 内にプライベート IP アドレスのみがあるインスタンスをチェックします。CloudWatch コンソールを使用して CloudWatch メトリクスおよびアラームを作成する方法について詳細は、[Amazon CloudWatch ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/)を参照してください。
詳細については、「[プライベートホストゾーンの使用](hosted-zones-private.md)」および「[CloudWatch を使用したヘルスチェックのモニタリング](monitoring-health-checks.md)」を参照してください。
# Amazon Route 53 でフェイルオーバーの問題を回避する方法
Route 53 に実装されたフェイルオーバーアルゴリズムは、正常なエンドポイントにトラフィックをルーティングするだけでなく、ヘルスチェックやアプリケーションの設定ミス、エンドポイントの過負荷、パーティションの障害などに起因する最悪のシナリオを回避するように設計されています。
**Topics**
+ [Amazon Route 53 でカスケードの失敗を回避する方法](#dns-failover-cascading-failures)
+ [Amazon Route 53 でのインターネットの分断への対処方法](#dns-failover-internet-partitions)
## Amazon Route 53 でカスケードの失敗を回避する方法
カスケードの失敗に対する第一の備えとして、すべてのリクエストルーティングアルゴリズム (加重やフェイルオーバーなど) には、最後の手段となるモードが用意されています。この特殊なモードでは、レコードがすべて異常と判断された場合に、Route 53 アルゴリズムは、再びすべてのレコードを正常と見なすようになります。
例えば、いくつかのホスト上で、アプリケーションの全インスタンスがヘルスチェックリクエストを拒否している場合、Route 53 の DNS サーバーは、DNS 応答を拒否したり NXDOMAIN (存在しないドメイン) 応答を返したりするのではなく、何等かの応答を返します。アプリケーションがユーザーに応答しても、ヘルスチェックには不合格になることがあるため、設定ミスから生じる問題をある程度防ぐことができます。
同様に、アプリケーションに過剰な負荷がかかっていて、3 つのエンドポイントのうち 1 つがヘルスチェックで不合格と判断され、Route 53 の DNS 応答から除外された場合、Route 53 は残りの 2 つのエンドポイントを使って応答を返します。残りのエンドポイントがそれ以上の負荷に耐えきれず障害が発生した場合、Route 53 は再度、3 つすべてのエンドポイントにリクエストを分配するようになります。
## Amazon Route 53 でのインターネットの分断への対処方法
一般的ではありませんが、インターネットに重大な分断が生じる場合があります。つまり、大規模な地理的リージョン間でインターネット経由の相互通信ができなくなることがあります。インターネットに分断が生じている間、エンドポイントの正常性ステータスに関して導き出される結論が Route 53 の拠点によって違ったり、CloudWatch に報告されるステータスと異なることがあります。各 AWS リージョンの Route 53 ヘルスチェッカーは、すべての Route 53 ロケーションにヘルスチェックステータスを常に送信しています。インターネットの分断が生じている間は、Route 53 の各拠点は、そうしたステータスの一部 (通常は最も近いリージョンのステータス) にしかアクセスできなくなります。
例えば、インターネットの分断で南米との接続に影響が生じているとします。その間、 南米 (サンパウロ) にある Route 53 DNS サーバーは、 AWS リージョンの南米 (サンパウロ) にあるヘルスチェックエンドポイントには問題なくアクセスできますが、その他のエンドポイントには正常にアクセスできない可能性があります。同時に、米国東部 (オハイオ) の Route 53 は、南米 (サンパウロ) リージョンのヘルスチェックエンドポイントへのアクセスに支障があるとして、対応するレコードを異常と判断することが考えられます。
こうした分断によって、Route 53 の各拠点が、それぞれ域内のエンドポイントの可視性によってエンドポイントの正常性ステータスを判断するようになり、最終的に拠点ごとにその結論が異なる、という状況に発展する可能性があります。そのため、Route 53 の各拠点は、到達可能なごく一部のヘルスチェッカーがエンドポイントを正常と判断していれば、そのエンドポイントを正常と見なします。