本記事は、2014年9月にCDNetworks USが発表した記事を翻訳、一部改訂したものです。実験自体は2年前(2014年)に行なわれたものですが、CDNを検討される方にとっては今なおある程度有益であると考え、日本語でも公開いたします。
パブリックDNSがCDNに与える影響(1)
パブリックDNSがCDNに与える影響(2) ←本記事
前回の記事をうけて、この記事ではEDNS-Client-SubnetがCDNのグローバルなロードバランシングにどんな影響を与えるかについて紹介したいと思います。CDNetworksは、Cedexisを適用したドメインにおいてEDNS-Client-Subnetが有効になるようGSLBに設定し、その前後の結果を比べました。その違いは明らかでした。
Cedexis RadarはRUMの一つで、比較した2つの期間のエンドユーザのサンプルは厳密には同じではありません。しかし、大変多くのサンプルを集めることができたため、比較するに値するものと考え、結果を公表いたします。
EDNS-Client-Subnetを利用したロードバランシングの仕組み
CDNがEDNS-Client-Subnetに対応することで、Google DNSなどのパブリックDNSを利用したユーザに対しても正確にロードバランシングを行なうことができるようになります。
インドネシアのユーザがDNSリゾルバにGoogle DNSを利用してDNSリクエストを送信すると、おそらくシンガポールにあるGoogle DNSのPoPに届くでしょう。インドネシアのユーザにとってネットワーク的に最も近いのはシンガポールだからです。このとき、EDNS-Client-SubnetをサポートしていないCDNは、これをシンガポールからきたリクエストだと判断し、シンガポールにあるエッジサーバへ誘導するはずです。
もしCDN側がEDNS-Client-Subnetを適切にサポートしていたら、Google DNSはその情報をCDNに提供し、CDNはこの情報をDNSクエリの発信元IPのかわりに使うことで適切にロードバランシングします。そうすることでCDNは、このユーザがシンガポールではなくインドネシアにいるということを理解し、GSLBはインドネシアのエッジPoPのIPアドレスを返すことができます。
なお、Google DNSはDNSサーバがEDNS-Client-Subnetを受け入れるかどうかを検知する仕組みになっていますので、EDNS-Client-SubnetをサポートしていないDNSサーバへDNSリクエストを送信する場合は、クライアントIPの情報を送りません。しかしオープンDNSは、CDN側がEDNS-Client-Subnetに対応したかどうかを検知しません。CDN側は、EDNS-Client-Subnetに対応したということを彼らに連絡し、適切にクライアントIPの情報を受け取れるよう準備する必要があります。
補足として、他のDNSサーバに対してどんな情報を送るかというのはDNSリゾルバの自由です。Google DNSとオープンDNSはクライアントのパブリックIPのうち24ビットまでしか送信しませんので、CDNetworksのGSLBは最後の8ビットを知ることができません。これは、地理情報の正確性という意味では確かに問題は残りますが、一般的には十分であると考えます。
EDNS-Client-Subnetをサポートすることによるトラフィックのシフト
前回の記事では、Google DNSとオープンDNSの利用率が50%を超えるのは、インドネシア、ベトナム、アルジェリアの3つの国であることがわかりました。それぞれの国について、私たちがEDNS-Client-Subnetを有効化した際にトラフィックパターンがどのように変わったのかを見てみましょう。これらの国にあるCDNetworks PoPを通ったすべてのトラフィックを比較しました。
1.インドネシア
PoP | EDNS-Client-Subnet OFF |
EDNS-Client-Subnet ON |
Diff (%) |
---|---|---|---|
Jakarta-1, Indonesia | 16.13% | 53.60% | +37.47 |
Jakarta-2, Indonesia | 5.52% | 24.78% | +19.26 |
Singapore | 8.28% | 14.09% | +5.81 |
Taipei, Chinese Taipei | 66.34% | 0.1% | -66.24 |
etc | 3.73% | 7.43% |
インドネシアでは62.4%がGoogle DNS、6.3%がオープンDNSのリクエストです。EDNS-Client-Subnetを有効化する前は、70%以上のトラフィックがシンガポールや台北PoPへ誘導されていましたが、有効化後は台北経由だったトラフィックのすべてがジャカルタの2つのCDN PoPへ誘導され、シンガポールPoPのトラフィックも少し増えました。
Google DNSとオープンDNSのインドネシアに最も近いPoPは台北PoPなので、Google DNSやオープンDNSを利用するユーザのトラフィックは台北経由となっていました。
2.ベトナム
PoP | EDNS-Client-Subnet OFF |
EDNS-Client-Subnet ON |
Diff (%) |
---|---|---|---|
Hanoi, Vietnam | 22.25% | 46.41% | +24.16 |
Saigon, Vietnam | 7.81% | 22.16% | +14.35 |
Hong Kong | 11.38% | 24.09% | +12.71 |
Taipei, Chinese Taipei | 53.14% | 0.22% | -52.92 |
etc | 5.42% | 7.12% |
次は、全体の約60%がGoogle DNSやオープンDNS経由であるベトナムです。EDNS-Client-Subnetを有効化する前は、トラフィックの53.14%が台北経由となっていました。有効化後は、台北のトラフィックはほとんど完全にベトナムPoP(ハノイとサイゴン)と香港経由となり、これが全体の90%以上を占めています。
インドネシアと同様、Google DNSのベトナムに最も近いPoPは台北です。しかし、トラフィックがほとんど動いたことを見ると、ベトナムのユーザにとって最適なPoPは、実際には台北ではないということがわかります。
3.アルジェリア
PoP | EDNS-Client-Subnet OFF | EDNS-Client-Subnet ON | Diff (%) |
---|---|---|---|
Paris, France | 23.70% | 35.64% | +11.94 |
Frankfurt, Germany | 20.16% | 30.84% | +10.68 |
Palermo, Italy | 0.11% | 5.28% | +5.17 |
Milan, Italy | 7.95% | 12.65% | +4.70 |
London, UK | 0.89% | 4.74% | +3.85 |
Amsterdam, Netherlands | 24.10% | 2.28% | -21.82 |
Madrid, Spain | 22.48% | 0.95% | -21.53 |
etc | 0.61% | 7.62% |
アルジェリアについては、CDNetworksはPoPを有していないので、実際のトラフィックはレイテンシに応じてヨーロッパのPoPを利用します。面白いことに、40%以上のトラフィックがアムステルダム・マドリードからパリ・フランクフルト・パレルモ・ミラン・ロンドンへ移動しました。
パフォーマンスの違い
レスポンスタイムの変化を見てみると、インドネシアとベトナムではEDNS-Client-Subnetを有効化した後顕著にパフォーマンスが改善されていますが、アルジェリアについてはほとんど改善が見られないように見えます。これはCDNetworksが国内にPoPを有していないためと考えられます。実際、多くのトラフィックが他の国へ誘導されましたが、もともとトラフィックが誘導されていたパリとアムステルダムは比較的接続性が良い地域のため、あまり大きな変化が見られなかったのでしょう。
まとめ
これらの実験結果から、CDNがEDNS-Client-Subnetを利用することにより、パブリックDNSを利用するユーザを最適なPoPへ誘導することができる、ということがわかりました。CDNの肝であるGSLBがエンドユーザのいる場所をIPアドレスから正確に知ることができれば、パフォーマンスの改善効果はより高くなることでしょう。
但し、EDNS-Client-Subnetによる効果の違いを感じるには以下の2つの条件が必要です。
・Google DNSとオープンDNSユーザの割合が高いこと:そうでなければ全体としての変化は小さくなります
・CDNがその国にPoPを有していること:そうでなければ大きなパフォーマンス改善は見られません
また、CDNetworksはEDNS-Client-Subnetに対応しているため、パブリックDNSを利用したユーザからのリクエストも適切なPoPへ誘導することが可能です。CDNetworksのグローバルネットワークは以下よりご覧ください。