デュアルスタック環境とCDN

前回、DNSサーバを利用した名前解決と利用するIPバージョンの組み合わせに関して紹介しました。今回は、IPv4とIPv6を別々のISPで接続しているような場合、DNSを利用するCDNとの相性が問題になる可能性について紹介します。

問題が発生するのは、以下の図のようにIPv4とIPv6で別々のISPを利用しつつ、キャッシュDNSサーバはどちらか片方のISPを利用しているような環境です。たとえば、フレッツでIPv4とIPv6を別々のISPにするような設定をしていたり、IPv4しか提供されていない環境で、Hurricane Electricなどが提供しているようなIPv6 over IPv4トンネルを使っているようなときに発生する可能性があります。

この図では、家庭に対してIPv4はISP Aによって提供され、IPv6はISP Bによって提供されます。ユーザが利用しているPCに設定されているキャッシュDNSサーバは、IPv4を利用しているISP Aのものを利用しています。

このような環境で、CDNによって負荷分散が行われているコンテンツをユーザが取得するときの流れをみます。

まず、最初にユーザがISP AにあるキャッシュDNSサーバを利用して名前解決を行います(1)。このとき、ユーザはIPv4とIPv6の接続性を両方持っているので、AAAAレコードの問い合わせを先に行っているものとします。また、AAAAレコードの問い合わせに使われるキャッシュDNSサーバまでのトランスポートはIPv4とします。

ISP AにあるキャッシュDNSサーバは、権威DNSサーバにAAAAレコードの問い合わせ行い、回答を得ます。ISP AとISP Bは、双方ともにIPv4とIPv6両方で運用されており、IPv6で運用されたCDNキャッシュが両方のISP内にあるものとします。

このような環境下では、権威DNSサーバは問い合わせを行ったキャッシュDNSサーバの最寄りコンテンツキャッシュであるCDNキャッシュAを、キャッシュDNSサーバへと返答します(2)。

キャッシュDNSサーバからの名前解決結果を受け取ったユーザは、CDNキャッシュAからコンテンツを取得します。このとき、コンテンツ取得に利用されるトランスポートはIPv6となるため、ユーザはISP Bを経由してCDNキャッシュAにあるコンテンツを取得します。

しかし、ISP BにもCDNキャッシュBというコンテンツキャッシュがある場合、ユーザは遠回りをしてコンテンツを取得していることになってしまいます。このような遠回りが発生するのは、CDNによる負荷分散機能の一部である権威DNSサーバが「ユーザはISP Aにいる」と認識しているために発生しています。

ISP BのキャッシュDNSサーバを利用すれば、ユーザはCDNキャッシュBからIPv6トランスポートを利用してコンテンツを取得できるようになりますが、今度は逆にIPv4でのCDNキャッシュコンテンツ取得が遠回りになってしまいます。

DNSのリソースレコードごとに、利用するキャッシュDNSサーバを設定できれば、このような問題は軽減できると推測されます。たとえば、IPv4のAレコードを取得するときと、IPv6のAAAAレコードを取得するときに利用するキャッシュDNSサーバをそれぞれ設定することによって、キャッシュDNSサーバとのトランスポートとリソースレコードをマッチさせることができれば回避可能です。しかし、現時点では、そういった使い分けが行われることは稀であるため、このような問題が発生していると思われます。

ただし、このような状況に陥ったとしても、単に遅くなるだけでユーザが気がついていない可能性も考えられます。そもそも、CDNとの相性を追求するような設定をユーザ側が行うことが正しいのかどうかという問題もあります。

この話は多少マニアックではありますが、IPv4とIPv6のデュアルスタック環境において発生する課題発見や運用ノウハウの蓄積は、まだまだこれからかも知れません。

DMM.com のトラフィックについて APRICOT2015 でしゃべってきました

弥生のみぎり、皆様にはいかがお過ごしでしょうか。ホワイトデーも間近だというのに悩みがないのが悩みな初心者ツチノコです。 さて、本日は APRICOT 2015 という国際会議で DMM.com ラボとして発表をしてきましたので、そのお話を書いてみます。

APRICOT とは “Asia Pacific Regional Internet Conference on Operational Technologies” の略で長ーいですが、要するにアジア太平洋地域のインターネットに関する運用と技術について議論する国際カンファレンスです。

今回発表したのは “Traffic in Japan” という JANOG が担当するパネルセッションで、コンテンツプロバイダのトラフィックの傾向をお話して来ました。その他にもインターネットマルチフィードの吉田さんが日本全体のトラフィック、IIJ の松崎さんがトランジット ISP のトラフィック、QTNet の忽那さんが地域 ISP のトラフィック、ソフトバンクの平井さんがモバイルを持っているキャリアのトラフィックという形で発表されていました。近々、JANOG のページ http://www.janog.gr.jp/http://www.janog.gr.jp/meeting/index.html から辿れる形で公開されるとおもいますので、そちらもご覧くださいませ。

DMM.com ラボの資料は先行してこちらにおいておきます。( 版権が絡む様な画像は抜いてあるのでちょっと味気ないかも… )

 

さて、肝心のトラフィック傾向ですが、やはり我々のものは ISP の皆さんとは傾向が違いました。かくいう私も元々トランジットISPの出身で、2月に DMM.com ラボに入社したばっかりの超新人なので調査中から驚くことばかりでした。

特筆すべきはトラフィックの種類。通常トラフィックというと、ISP の人間は外部接続回線のトラフィックの合計みたいなものをまず意識します。DMM.com の場合もちろんそれも存在するのですが、他にもトラフィックソースが存在するわけですね。

弊社では以下の様なトラフィックソースの使い分けをしています。

まずは、自社でサーバ、ネットワーク、データセンタを運用しているオンプレミストラフィック。これが真っ先にコンテンツプロバイダのトラフィックとして想像されるものではないかと思います。DMM.com の場合、こちらには認証情報や各種APIサーバ、あとは動画、画像系のコンテンツが置かれています。とにかく定常的に大量のトラフィックが発生するトラフィックソースです。

次に CDN。こちらは Akamai さんに代表される様な CDN 事業者さんにオフロードしているトラフィックです。弊社では複数の事業者を利用しています。使い方としては、ライブイベント配信の様な事前に予測される一時的なトラフィックのオフロードの他、オンプレミストラフィックのうち急激に使用量が増えた人気コンテンツを移動する場合もあります。これは自動で出来れば大変にかっこいいのですが、今はまだ職人的運用者が「エイッ」って手動で移しています。

最後に、パブリッククラウドプロバイダの利用です。こちらは世界で一番メジャーと思われるあそこ、国内のあそことあそことあそこ、の様にたくさんの業者を使っています。こいつは主にオンラインゲームのトラフィックが乗っています。ゲームの開発元である SAP さんごとに、好みの環境というかクラウドサービスがあるので、ゲームごとに SAP さんに合わせて DMM.com ラボが契約する形です。この場合、お客さんがブラウザからアクセスすると、最初はオンプレミス上にある認証システムやトップ画面にアクセスした後、実際のゲームデータはどこかのパブリッククラウド上にいくわけですね。興味がある人はパケットを眺めてみるとあのゲームがどこにあるなんていうのは分かるかも知れませんね。

各トラフィックの傾向や比率については、前掲の資料をご覧くださいませ。

本当は帯域 だけではなく、同時接続数や単位時間あたりのセッション数でそれぞれのトラフィック傾向を語れるとよかったのですが、今回は時間がなかったり、各トラフィックソース毎に記録している情報の種類や粒度が違ったりで、残念ながら細かい比較ができませんでした。今後は是非、ここらへんも視覚化してみたいですね。

それではまた。

googleとakamaiは仲良し?

昨日、geekなページのあきみち氏ご本人からアカマイの本をいただいたので、早速、読んでみました。

いただいた本↓
Geekなページ:『アカマイ 知られざるインターネットの巨人』を書きました

Akamaiのsurerouteサービスがispにどのような影響を与えるのか、
また、そのサービスはもろ刃の剣でありispに対する優位性が変化してきているというくだりが面白かったです。
あきみちさん献本ありがとうございました。

ところで、この本を読んでいて、ふと
パブリックDNSとCDNの相性問題を思いだしまして、突然ではありますが調べてみようと思い立ってしまいました^^;

一度、こう思ってしまうと寝る間を惜しんで調べてしまうところがツチノコ親分の性なんでしょうかね。

では調査結果を共有します。

googleの運用する8.8.8.8や8.8.4.4などのパブリックDNSは巷ではCDNとの相性は良くないと言われています。

確かに8.8.8.8はanycastのアドレスで台湾に設置されているサーバに振られます。

かつてはakamaiやその他のCDNを利用しているサイトのFQDNで名前解決を行うと台湾のサーバに振られるようになっていました。

結構前の話なので最近はどうなっているのかコマンドを叩いて調べてみます。

akamaiの場合

$ dig @8.8.8.8(台湾DNS) www.akamai.com
e8921.dscx.akamaiedge.net. 19 IN A 23.66.109.233(日本エッジ)

$ dig @168.95.1.1(台湾DNS) www.akamai.com
e8921.dscx.akamaiedge.net. 11 IN A 23.53.77.233(台湾エッジ)

$ dig @202.248.37.74(日本DNS) www.akamai.com
e8921.dscx.akamaiedge.net. 20 IN A 23.44.173.233(日本エッジ)

これを見ると8.8.8.8でもJPのエッジサーバに振り分けられています。
8.8.8.8は間違いなくRTTをみてもTRACEをみても国内のサーバではなさそうです。

limerightの場合

$ dig @8.8.8.8(台湾DNS) www.limelight.com
llnw.vo.llnwd.net. 349 IN A 203.77.189.7(香港エッジ)

$ dig @168.95.1.1(台湾DNS) www.limelight.com
llnw.vo.llnwd.net. 350 IN A 203.77.189.7(香港エッジ)

$ dig @202.248.37.74(日本DNS) www.limelight.com
llnw.vo.llnwd.net. 350 IN A 117.121.254.136(日本エッジ)

limerightは台湾にエッジがなく香港に設置されているのかもしれません。
いずれにしても台湾のDNSに対しては香港のエッジが返されています。
8.8.8.8を利用した環境においてlimerightを利用しているサイトを利用すると海外のサーバに飛ばされパフォーマンスが低下する可能性があります。

cdnetworksの場合

$ dig @8.8.8.8(台湾DNS) www.cdnetworks.co.jp
www.cdnetworks.co.jp.cdngc.net. 19 IN A 175.41.1.2(韓国エッジ)

$ dig @168.95.1.1(台湾DNS) www.cdnetworks.co.jp
www.cdnetworks.co.jp.cdngc.net. 20 IN A 14.0.63.201(台湾エッジ)

$ dig @202.248.37.74(日本DNS) www.cdnetworks.co.jp
www.cdnetworks.co.jp.cdngc.net. 20 IN A 14.0.33.242(日本エッジ)

ここはまた違った結果が。。
KDDIが買収する前は韓国資本の会社
ここの会社はもしかすると、アジア地域のanycastのアドレスは標準で韓国のエッジに飛ばすようになっているのかもしれません。
いずれにしても8.8.8.8を利用しCDNをcdnetworksを利用したサイトを訪れる際は韓国へ飛ばされパフォーマンスが低下する恐れがありそうです。

この3社の結果をまとめると
Akamaiだけが台湾の8.8.8.8でも日本のエッジが返されるようになっている。

ここから見えることは
※あくまで想像です。^^;

8.8.8.8を利用してもakamaiであれば遅延が発生しない

googleとakamaiは仲良しでgoogleがakamaiに顧客のIPを渡している可能性がある。

渡していないのであればJPアドレスなのか否かの情報は渡している可能性がある。

というところでしょうかね。

結論

改善はしている。ただしAkamaiだけで。

パブリックDNSを利用するにはまだ早いかもしれません。
※過去の記事で8.8.8.8に話しをしているのですが浅はかだったかもしれません。^^;

利用するにしても日本国内のpublic dnsを利用するといったところでしょうか。

推測を含んでいる部分が多く、
いろんな誤解が含まれている可能性がありますのでご指摘いただけると助かります。