Route53レイテンシーベースレコードを利用したマルチリージョン構成のポイント / nw-jaws15_LT3

Transcript

1. Route53レイテンシーベースレコードを利用した マルチリージョン構成のポイント 2025年2月21日 野村総合研究所 マルチクラウドインテグレーション本部 金融基盤サービス部 池田浩明
2. 1 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 本日お話しすること 01 レイテンシーベースルーティングとは 02 Route53ヘルスチェック 03
3. 2 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 本日お話する構成 • Front-VPCにおけるセッション管理は行わないなど、LBRによる振り分けでの不整合は考慮しない tokyo-osaka.lbr.co.jp DNSquery • Route53 レイテンシーベースルーティング(LBR)に基づいて、東京・大阪リージョンのALBに振り分け rレイテンシーベースレコード tokyo-osaka.lbr.co.jp. 60 IN CNAME tokyo-ALB.amazonaws.com tokyo-osaka.lbr.co.jp. 60 IN CNAME osaka-ALB.amazonaws.com ✓ ✓ ALB URL HealthCheck • Route53 ヘルスチェックにて、東京・大阪経由の正常性を確認し、LBRのフェールオーバを設定 hc viaTokyo hc viaOsaka viaTokyo viaOsaka Cloudfront エンドユーザ https://example.co.jp 東京リージョン Back-VPC AZ ELB Front-VPC AZ tokyo-ALB 53 EC2 大阪リージョン Front-VPC AZ osaka-ALB 53 EC2 • Cloudfront経由での東京リージョン、大阪リージョンのALBに振り分けるActive-Active構成
4. 3 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. ① Route53 レイテンシーベースルーティングの動作説明 本日お話する内容 ✓ ✓ ALB URL HealthCheck viaTokyo viaOsaka エンドユーザ https://example.co.jp 東京リージョン Back-VPC AZ ELB Front-VPC AZ 53 EC2 大阪リージョン Front-VPC AZ 53 EC2 tokyo-osaka.lbr.co.jp DNSquery Cloudfront tokyo-ALB osaka-ALB rレイテンシーベースレコード tokyo-osaka.lbr.co.jp. 60 IN CNAME tokyo-ALB.amazonaws.com tokyo-osaka.lbr.co.jp. 60 IN CNAME osaka-ALB.amazonaws.com hc viaTokyo hc viaOsaka
5. 4 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Back-VPC 大阪リージョン 東京リージョン Cloudfront エンドユーザ https://example.co.jp 本日お話する内容 tokyo-osaka.lbr.co.jp DNSquery ② Route53ヘルスチェックを利用したDNSのフェールオーバ動作の説明と設計ポイント ※こちらがメイン Front-VPC AZ 53 EC2 Front-VPC AZ 53 EC2 viaTokyo viaOsaka AZ ELB tokyo-ALB osaka-ALB ✓ ✓ ALB URL HealthCheck rレイテンシーベースレコード tokyo-osaka.lbr.co.jp. 60 IN CNAME tokyo-ALB.amazonaws.com tokyo-osaka.lbr.co.jp. 60 IN CNAME osaka-ALB.amazonaws.com hc viaTokyo hc viaOsaka
6. 5 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 本日の内容 01 レイテンシーベースルーティング 02 Route53ヘルスチェック 03
7. 6 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. レイテンシーベースルーティングとは 大阪リージョン Front-VPC AZ Osaka- ALB EC2 権威DNSサーバ 東京リージョン Front-VPC AZ Tokyo- ALB EC2 ②DNSクエリを送信するクライアントの情報に基づいてレイテンシーの少ないレコードを確認 ④応答のあったレコードに対してアクセス ①DNSクエリ レイテンシーベース tokyo-osaka.lbr.co.jp Tokyo-ALB tokyo-osaka.lbr.co.jp Osaka-ALB https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/routing-policy-latency.html Tokyo-ALB tokyo-osaka.lbr.co.jp ③クライアントにレコードを応答 エンドユーザ
8. 7 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. DNSクエリを送信するDNSクライアントの情報に基づいたレイテンシーの確認方法 DNSクライアント $ dig tokyo-osaka.lbr.co.jp Resolver ResolverのIPに基づいたレイテンシー で応答レコードを判断 ResolverIP edns-client-subnet未対応 計測ポイント DNSクライアント $ dig tokyo-osaka.lbr.co.jp Resolver EDNSClientSubnet EDNSClientSubnetに基づいたレイテ ンシーで応答レコードを判断 edns-client-subnet対応 計測ポイント レイテンシーベース tokyo-osaka.lbr.co.jp Tokyo-ALB tokyo-osaka.lbr.co.jp Osaka-ALB レイテンシーベース tokyo-osaka.lbr.co.jp Tokyo-ALB tokyo-osaka.lbr.co.jp Osaka-ALB • 今回の構成においてLBRのDNSクエリを投げるのはCloudFront のエッジサーバー • 東京のエンドユーザは、東京リージョンに位置するエッジロケーションにアクセスするため、基本的には 東京のエンドユーザからのアクセスは東京のOrigin（ALBのエンドポイント名）を応答 DNSクエリ エンドユーザ（東京） レイテンシーベース tokyo-osaka.lbr.co.jp Tokyo-ALB tokyo-osaka.lbr.co.jp Osaka-ALB エンドユーザ（大阪）
9. 8 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. レイテンシーベースルーティングの可用性 • レイテンシーベースルーティング単独では、レジリエンスの実現は難しい • Route53ヘルスチェックを組み合わせることでDNSフェールオーバを実現可能 Route53ヘルスチェックは、データプレーンで実現され静的安定性を確保可能 • Route53ヘルスチェックは設定ミスなどによる全断を回避するフェールセーフ設計 ＃すべてのヘルスチェックを行ったレコードが異常(NG)の場合、全体を正常(OK)とする ✓ URL HealthCheck 権威DNSサーバ ②クライアントの情報に基づいて正常であり、レイテンシーの少ないレコードを確認 ④応答のあったレコードに対してアクセス ①DNSクエリ 大阪ALB test.latencytest.co.jp ③クライアントにレコードを応答 ✓ URL HealthCheck 大阪リージョン Front-VPC AZ ALB EC2 東京リージョン Front-VPC AZ ALB EC2 エンドユーザ レイテンシーベース tokyo-osaka.lbr.co.jp Tokyo-ALB tokyo-osaka.lbr.co.jp Osaka-ALB
10. 9 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 本日の内容 01 レイテンシーベースルーティングとEDNS Client-Subnet 02 Route53ヘルスチェック 03
11. 10 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Route53ヘルスチェック設計ポイント① • Route53 ヘルスチェックで監視する対象を明確に 例えば、 の障害は、viaTokyoのHCがNGとなるため、viaOsakaの経路に切り替えれば、継続して利 用可能だが、 の障害はRoute53ヘルスチェックで切り替えても救えないなどを整理 • の障害のフォローのため、Back-VPCでも大阪切り替えを行う場合は、切り替え後の経路もRoute53 ヘルスチェックで監視できることが必要 Cloudfront エンドユーザ https://example.co.jp tokyo-osaka.lbr.co.jp DNSquery viaTokyo Back-VPC 大阪リージョン 東京リージョン Front-VPC AZ 53 EC2 Front-VPC AZ 53 EC2 viaOsaka AZ ELB tokyo-ALB osaka-ALB ✓ ✓ ALB URL HealthCheck
12. 11 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 大阪リージョン 東京リージョン Front-VPC AZ EC2 Front-VPC AZ EC2 tokyo-ALB osaka-ALB Route53ヘルスチェック設計ポイント② • Route53のヘルスチェックのOK/NGによって、対象のDNSの応答を変更するため、Acitve/Standby構 成であればエンドユーザからのアクセスと同じ経路での監視が成り立つが、レイテンシーベースルーティングの ようなActive/Active構成では、監視すべき経路を個別に監視する必要がある • エンドユーザからのアクセスとは別のFQDN（ALBのエンドポイント名でも可）を用いて、振り分け対象を 個別に監視する エンドユーザ https://example.co.jp 大阪リージョン 東京リージョン Front-VPC AZ EC2 Front-VPC AZ EC2 tokyo-ALB osaka-ALB ✓ ✓ ALB URL HealthCheck ✓ ✓ ALB URL HealthCheck エンドユーザ https://example.co.jp Active/Standby構成 Active/Active構成 https://example.co.jpの監視でもOK https://example.co.jpの監視ではNG
13. 12 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 東京リージョン Route53ヘルスチェック設計ポイント③ Cloudfront エンドユーザ https://example.co.jp tokyo-osaka.lbr.co.jp DNSquery viaTokyo 大阪リージョン viaOsaka ✓ ✓ ALB URL HealthCheck Front-VPC AZ 53 EC2 osaka-ALB Front-VPC AZ 53 EC2 tokyo-ALB Back-VPC AZ ALB https://tokyo-example.co.jp https://osaka-example.co.jp • Route53ヘルスチェックではFQDNでエンドポイントを指定した場合、ホストヘッダの書き換えが行えない • アプリケーションがホストヘッダでルーティングを行う制御の場合、ヘルスチェック方法の検討が必要 （API-gatewayやProxyなどでの書き換えも一つの方法） • アプリケーションまでの動作確認が不要であれば、BackendVPCのALBで固定レスポンス応答でもOK • Route53ヘルスチェックでは証明書の検証は行わないため、証明書のエラーは考慮不要 （SNI有効化設定は、client_helloでserver_nameを送付する必要がある場合に利用） ・hostヘッダによる制御がないかを確認
14. 13 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. Route53ヘルスチェック設計ポイント④ • Route53ヘルスチェックのIPリストはAWSマネージドプレフィックスリストを利用可能 • 障害時ではない場合にも、東京のみ・大阪のみに片寄せを容易にできるようにしておくと便利 • Route53ヘルスチェック用のSecurityGroupで制御することで業務通信に影響なく切り替えが可能 • 全ALB切替と、個別ALB切替の方法を準備しておくことで切り替えを容易にできる ✓ URL HealthCheck ✓ URL HealthCheck 東京リージョン AZ EC2 route53SG EC2 route53SG 大阪リージョン AZ EC2 route53SG EC2 route53SG SecurityGroupの中身を削除することで、全 ALBの通信を片寄せ 特定のALBからSecurityGroupを外すことで一部 のALBの通信を片寄せ Route53ヘルスチェックのSGの操作のみで、業務通信のSGに手を 加えないため切替中の業務通信には影響を及ぼさない。
15. 14 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 1 移行前状態 2 レイテンシーベース レコードのみ作成 3 ALBログの送信元IP アドレスをもとに応答 されるレコードを確認 レイテンシーベースルーティングに移行する際のポイント • レイテンシーベースルーティングでは、クライアントとのレイテンシーに基づくためトラフィックに偏りが発生する • 移行前に偏りを把握しておく必要がある ALBのログの送信元IPアドレスをもとに、事前にどの程度偏りがあるかを確認することが可能 • AmazonProvidedDNSはedns-client-subnetに対応していないため、パブリックDNSを利用する rレイテンシーベースレコード tokyo-osaka.lbr.co.jp. 60 IN CNAME tokyo-ALB.amazonaws.com tokyo-osaka.lbr.co.jp. 60 IN CNAME osaka-ALB.amazonaws.com 東京リージョン Front-VPC AZ EC2 tokyo-ALB ALBログ Cloudfront ALBログ エンドユーザ [ec2-user@~]$ dig tokyo-osaka.lbr.co.jp @8.8.8.8 +subnet=x.x.x.0/24 +noall +ans ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.13 <<>> test.latency.co.jp@8.8.8.8 +subnet=x.x.x.0/24 +noall +ans ;; global options: +cmd tokyo-osaka.lbr.co.jp. 60 IN CNAME tokyo-ALB.amazonaws.com tokyo-ALB.amazonaws.com. 60 IN A 15.x.x.x.
16. 15 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 余談：CNAMEレコードとAliasAレコード • CNAMEレコードとAliasAレコードは同様の使い方だが、下記の理由からAliasAレコードが推奨される • AWSのリソースへのエイリアスでは、クエリの料金がかからない • ZoneApexへのエイリアスが可能。（CNAMEは他のリソースタイプと共存不可：SOAやNSと被る） • クエリの速度が速い など [ec2-user@ip~]$ dig test.latency.co.jp+noall +ans ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.13 <<>> test.latency.co.jp+noall +ans ;; global options: +cmd test.latency.co.jp. 60 IN CNAME xxxxx.ap-northeast-1.elb.amazonaws.com. xxxxx.ap-northeast-1.elb.amazonaws.com. 60 IN A 54.x.x.x [ec2-user@ip~]$ dig test.latency.co.jp+noall +ans ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.13 <<>> test.latency.co.jp+noall +ans ;; global options: +cmd test.latency.co.jp. 60 IN A 54.x.x.x Alias Aレコード CNAMEレコード • CNAMEを利用するメリット（とまではいかないが、AliasAではできないこと） • IPアドレスではなくエンドポイント名が返るため、レイテンシーベースにおいてどちらのALBが応答したかわかりやすい • TTLを60s以下にすることができる。（AliasAレコードはAlias先のTTLが引き継がれる） 正常なALBにDNS切り替えをするだけであれば、CNAMEでTTL短いほうが早く切替可能 （もちろん、TTLを短くすることによる弊害とのトレードオフ）
17. 16 Copyright （C） Nomura Research Institute, Ltd. All rights reserved. 【ご参考】ヘルスチェック切り替わり時間 • Route53のヘルスチェックのリクエスト間隔はスタンダード(30s)か高速(10s)。 ※高速は追加料金 • 机上での計算よりも実際の切替時間は長くなるため、動作検証をして切替時間を確認する。 ① ② ③ 切 替 30s 30s 30s 30s 30s ヘルスチェック間隔 30s×3回 DNS TTL 60s 60s 60s 切 替 切 替 切 替 切 替 切 替 10s ヘルスチェック間隔 10s×3回 10s 最短：1分数秒 最大：2分30秒 ＃計算上 最短：30数秒 最大：1分30秒 ＃計算上 ClientのDNSTTL HC 30s ×3回連続 HC 30s ×2回連続 HC 10s ×3回連続 HC 10s ×2回連続 残りTTL 55 1m55s 1m55s 55ms 55ms 残りTTL 45 2m45s 1m45s 1m45s 45ms 残りTTL 35 2m35s 1m35s 1m35s 1m35s 残りTTL 25 2m25s 1m25s 1m25s 1m25s 残りTTL 15 2m15s 1m15s 1m15s 1m15s 残りTTL 5 2m5s 2m5s 1m5s 1m5s 【参考】切り替わりまでの時間の検証結果（送信元は3か所） 下記から3~8の送信元を選択可能（AWSの推奨は、送信元として利用できる下記のすべて） 選択した送信元の18%以上が正常でOKと判断 3～5か所であれば1か所が正常 6～8か所であれば2か所が正常 ・米国東部 (バージニア北部) ・米国西部(北カリフォルニア) ・米国西部 (オレゴン) ・欧州 (アイルランド) ・アジアパシフィック (シンガポール) ・アジアパシフィック (シドニー) ・アジアパシフィック (東京) ・南米(サンパウロ) • Route53ヘルスチェックの送信元 切 替 切 替 10s