Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey.
Route 53 の加重ルーティングポリシーに関する問題をトラブルシューティングする方法を教えてください。
Amazon Route 53 で加重ルーティングポリシーの DNS 解決をテストすると、予期しない結果になります。
簡単な説明
「weighted.awsexampledomain.com」という名前のテキスト (TXT) レコードを作成したとします。レコードの存続可能時間 (TTL) は 300 秒で、重みは次のように設定されています。
| 名前 | タイプ | TTL | 値 | 重み | ヘルスチェックステータス |
| weighted.awsexampledomain.com。 | TXT | 300 | 「重みが 0 のレコード」 | 重み = 0 | ヘルスチェック関連 |
| weighted.awsexampledomain.com。 | TXT | 300 | 「重みが 20 のレコード」 | 重み = 20 | ヘルスチェック関連 |
| weighted.awsexampledomain.com。 | TXT | 300 | 「重みが 50 のレコード」 | 重み = 50 | ヘルスチェック関連 |
| weighted.awsexampledomain.com。 | TXT | 300 | 「重みが 70 のレコード」 | 重み = 70 | ヘルスチェック関連 |
この構成は、次の例で参照されています。
解決策
**注:**AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、最新バージョンの AWS CLI を使用していることを確認してください。
加重ルーティングポリシーをテストして問題を特定してください
複数の (10,000を超える) クエリを送信して、加重ルーティングポリシーをテストします。複数の場所から DNS 解決をテストするか、権限のあるネームサーバーに直接問い合わせてポリシーを理解してください。次のスクリプトを使用して、ドメイン名に対して複数の DNS クエリを送信します。
再帰リゾルバーを使用して DNS クエリを送信します。
#!/bin/bash for i in {1..10000} do domain=$(dig <domain-name> <type> @RecursiveResolver_IP +short) echo -e "$domain" >> RecursiveResolver_results.txt done
DNS クエリを 権限のあるネームサーバーに直接送信します。
#!/bin/bash for i in {1..10000} do domain=$(dig <domain-name> <type> @AuthoritativeNameserver_IP +short) echo -e "$domain" >> AuthoritativeNameServer_results.txt done
AWS CLI の awk ツールを使用した場合の出力例:
$ for i in {1..10000}; do domain=$(dig weighted.awsexampledomain.com. TXT @172.16.173.64 +short); echo -e "$domain" >> RecursiveResolver_results.txt; done $ awk ' " " ' RecursiveResolver_results.txt | sort | uniq -c 1344 "Record with Weight 20" 3780 "Record with Weight 50" 4876 "Record with Weight 70"
テスト結果を使用して、特定の問題のトラブルシューティングを行います
問題: 加重レコードのエンドポイントリソースのトラフィック率が期待どおりではありません。
Route 53 は、すべてのレコードの合計重みに対するレコードに割り当てられた重みの割合に基づいて、トラフィックをリソースに送信します。中間 DNS リゾルバーは、レコード TTL の間 DNS 応答をキャッシュします。レスポンスがキャッシュされるため、クライアントはその間は特定のエンドポイントにのみリダイレクトされます。
例
キャッシュ DNS リゾルバー 192.168.1.2 に対してクエリを実行します。
$ for i in {1..10000}; do domain=$(dig weighted.awsexampledomain.com. TXT @192.168.1.2 +short); echo -e "$domain" >> CachingResolver_results.txt; done $ awk ' " " ' CachingResolver_results.txt | sort | uniq -c 3561 "Record with Weight 20" 1256 "Record with Weight 50" 5183 "Record with Weight 70"
前述の結果は、再帰的 DNS リゾルバーのキャッシュが原因で、期待どおりではないことに注意してください。
問題: 一部の加重レコードが返されません。
- ヘルスチェックをリソースレコードセットに関連付けると、Route 53 は関連するヘルスチェックが成功した場合にのみレコードを返します。詳細については、Amazon Route 53 がヘルスチェックが正常かどうかを判断する方法 を参照してください。
- ポリシー内の RRSet にヘルスチェックが添付されていない場合、常に正常と見なされます。これは、DNS クエリへの応答候補にも含まれています。ヘルスチェックに失敗したレコードは返されません。ヘルスチェックの設定をチェックして、正常と報告されていることを確認します。
- リソースレコードを設定した状態で「Evaluate Target Health」を使用すると、Route 53 はエンドリソースから報告されたヘルスチェックを使用します。詳細については、[Evaluate Target Health] (ターゲットの正常性の評価) の使用時に Application Load Balancer を参照するエイリアスレコードが異常とマークされるのはなぜですか?を参照してください。
例
一部のヘルスチェックが失敗しています。
| 名前 | タイプ | TTL | 値 | 重み | ヘルスチェックステータス |
| weighted.awsexampledomain.com。 | TXT | 300 | 「重みが 0 のレコード」 | 重み = 0 | ヘルスチェック成功 |
| weighted.awsexampledomain.com。 | TXT | 300 | 「重みが 20 のレコード」 | 重み = 20 | ヘルスチェック成功 |
| weighted.awsexampledomain.com。 | TXT | 300 | 「重みが 50 のレコード」 | 重み = 50 | ヘルスチェック失敗 |
| weighted.awsexampledomain.com。 | TXT | 300 | 「重みが 70 のレコード」 | 重み = 70 | ヘルスチェック成功 |
$ for i in {1..10000}; do domain=$(dig weighted.awsexampledomain.com. TXT @192.168.1.2 +short); echo -e "$domain" >> HealthCheck_results.txt; done $ awk ' " " ' HealthCheck_results.txt | sort | uniq -c 3602 "Record with Weight 20" 6398 "Record with Weight 70"
この例では、ヘルスチェックが失敗しているため、「重みが 50 のレコード」は Route 53 から返されません。
問題: 加重レコードがすべて異常です。
レコードのグループ内のどのレコードも正常でない場合でも、Route 53 は DNS クエリに応答する必要があります。ただし、あるレコードを別のレコードよりも選択する根拠はありません。この場合、Route 53 はグループ内のすべてのレコードが正常であると見なします。ルーティングポリシーと各レコードに指定した値に基づいて 1 つのレコードが選択されます。
例
| 名前 | タイプ | TTL | 値 | 重み | ヘルスチェックステータス |
| weighted.awsexampledomain.com。 | TXT | 300 | 「重みが 0 のレコード」 | 重み = 0 | ヘルスチェック失敗 |
| weighted.awsexampledomain.com。 | TXT | 300 | 「重みが 20 のレコード」 | 重み = 20 | ヘルスチェック失敗 |
| weighted.awsexampledomain.com。 | TXT | 300 | 「重みが 50 のレコード」 | 重み = 50 | ヘルスチェック失敗 |
| weighted.awsexampledomain.com。 | TXT | 300 | 「重みが 70 のレコード」 | 重み = 70 | ヘルスチェック失敗 |
$ for i in {1..10000}; do domain=$(dig weighted.awsexampledomain.com. TXT @205.251.194.16 +short); echo -e "$domain" >> All_UnHealthy_results.txt; done $ awk ' " " ' All_UnHealthy_results.txt | sort | uniq -c 1446 "Record with Weight 20" 3554 "Record with Weight 50" 5000 "Record with Weight 70"
この例では、Route 53 はすべてのレコードを正常 (フェイルオープン) と見なしました。Route 53 は、設定された比率に基づいて DNS リクエストに応答しました。「重みが 0 のレコード」は重みが 0 なので返されません。
注: 一部のレコードにゼロ以外の重みを設定し、他のレコードに重みをゼロに設定した場合、ヘルスチェックはすべてのレコードの重みがゼロ以外の場合と同じように機能します。ただし、いくつかの例外があります。
- Route 53 は最初、ゼロ以外の加重レコードが正常であれば、そのレコードのみを考慮します。
- 0 以外のレコードがすべて異常である場合、Route 53 は正常な 0 加重レコードと見なします。
例
| 名前 | タイプ | TTL | 値 | 重み | ヘルスチェックステータス |
| weighted.awsexampledomain.com。 | TXT | 300 | 「重みが 0 のレコード」 | 重み = 0 | ヘルスチェックパス |
| weighted.awsexampledomain.com。 | TXT | 300 | 「重みが 20 のレコード」 | 重み = 20 | ヘルスチェックパス |
| weighted.awsexampledomain.com。 | TXT | 300 | 「重みが 50 のレコード」 | 重み = 50 | ヘルスチェック失敗 |
| weighted.awsexampledomain.com。 | TXT | 300 | 「重みが 70 のレコード」 | 重み = 70 | ヘルスチェック失敗 |
$ for i in {1..10000}; do domain=$(dig weighted.awsexampledomain.com. TXT @192.168.1.2 +short); echo -e "$domain" >> HealthCheck_results.txt; done $ awk ' " " ' HealthCheck_results.txt | sort | uniq -c 10000 "Record with Weight 20"
この例では、Route 53 は重みが 0 のレコードを考慮しません。すべての加重レコードに異常がない限り、Route 53 は加重ゼロのレコードを返しません。
グループ内のすべてのレコードに同じ重みを設定すると、トラフィックは同じ確率ですべての正常なリソースにルーティングされます。グループ内のすべてのレコードで「重み」をゼロに設定すると、トラフィックは正常なすべてのリソースに同じ確率でルーティングされます。
関連情報
- 言語
- 日本語
