越境社内DNSでAkamai化が逆効果になる事象を発見した

まさかこんな影響があるとは思わなかった…

サンフランシスコにある私のオフィスから、San Francisco Chronicleという新聞社のWebサイトへのtraceroute結果

ある日のこと、オフィスで仕事をしていて「どうもWebサイトが開くの遅いよな、ウチのオフィス…」とボンヤリ考えていました。

遅いけれども、別に開かないわけじゃない。ちゃんとWebサイトは表示される。でも、画像がちょっとずつ表示されたり（スパっ、と出るのではなく、がっががっ、と出る、と言えば伝わりますでしょうか）、リンクをクリックしてから一瞬、時間にして1.5秒くらいブラウザが考え込んでから次のページのロードが始まったり、といった具合です。

最初は「Wi-Fiが混雑してるんだろうな、どうせ」と思っていましたが、有線LANにしても同じく遅い。これは何かがおかしいぞ、ということで調べてみることにしました。

まずはPingとTracerouteだよね

ネットワークエンジニアとしては、PingとTraceroute。最近はPingに応答しないWebサーバーも増えてきているので、インターネット上のHTTPを調べる時はいきなりTracerouteで途中の経路まで調べるのが私の中で常態化しています。

とりあえず遅いと感じたのが、私の地元にある地方紙新聞のSan Francisco Chronicle。さすがに地方紙だから地元にあるだろう、と思ってTracerouteしてみたら…。


その結果が、冒頭にも掲出したコチラ。

私のオフィスからwww.sfchronicle.comにtracerouteした結果（再掲）

異常が出ていること、お分かりでしょうか？

11ホップ目で、なんと日本のkddi.ne.jpを通っていて、その直前と直後で100ミリ秒（＝0.1秒）のレイテンシ差が出ています。

そして最終到達点はAkamai。最初はなんでこんなことになるのか分からなかったのですが、この画像をFacebookにシェアしたところ、友人の一人から「AkamaiのDNSが日本のサーバーのIPを返している、ということだ」とのご指摘。

このご指摘でピンと来ました。これ、原因はウチの社内DNSです。


どういうことか、というと…


セキュリティ的に詳しく書けないので相当模式化していますが、ざっくり絵にするとウチのネットワーク構成はこんな感じです。

今回のケースを説明するための模式図

まず右下が私のオフィスがあるネットワーク。社内ではWindows中心で、Active Directoryによるドメイン管理を行っています。

一方で私のオフィスはまだ規模が小さいため、ドメインコントローラーは日本にあるものを使っています（図の左下）。そして日米間はIPSec VPNで常時結ばれていて、100～300ミリ秒くらいのレイテンシはあるものの安定して日米間接続は稼働しています（図の中央下）。

Windowsドメインでの運用のためには、クライアントPCにDHCPで配布するDNSサーバーはドメコンにする必要があります。このため、すべてのDNS名前解決クエリは日米間VPNを通って日本から解決されます。

これを示しているのが以下の図。

クライアントPCからHTTPアクセスする際のDNS名前解決の模式図

名前解決で普通にアメリカのIPアドレスが帰ってくれば、HTTPリクエストは日米間VPNを通らず、普通に米国側のインターネットアクセスラインから出ていきます。実際、Google関連サービスなんかは（おそらく）その経路。

※GoogleへのTracerouteは経路上のホスト名が出てこず、すべてIPアドレスなので推測しかできないのですが、レイテンシが100ミリ秒以下とあまり大きくないことからまず間違いないです。


一方で、わざわざTracerouteが日本へ抜けているということは、DNS名前解決クエリで戻ってきたIPアドレス（つまりHTTPリクエストを送る先）のサーバーが日本にあるということ。


ここは推測ですが、Akamai化されているWebサーバーのDNSエントリはCNAMEで定義されていて、実態はAkamaiのキャッシュサーバー群に向いている。そしてAkamaiのゾーンオーソリティは、DNSクエリの発信元IPアドレスを元に、そのクエリ発信元にネットワーク的に最も近いキャッシュサーバーのIPアドレスを返しているのではないかというのが私の仮説です。


実際、Akamai社は全世界に20万台を超えるキャッシュサーバーを持っており、そのどれにクライアントからアクセスさせるかがAkamaiの技術のキモであるはず。そのくらいのことはやっていてもおかしくありません。


つまり、Akamai化されているWebサイトへのアクセスは、現状だと全て日本のキャッシュサーバーにデータを取りに行ってしまう。せっかくSan Francisco ChronicleやAppleが見る人にAkamaiで高速化を提供してくれているのに、こちら側のLAN構成によりそれが逆効果になってしまっている、という現象です。


Akamaiの仕様にツベコベいってもしょうがないし、そもそもわざわざ日本のDNSを見に行っているこっちの構成の方がイレギュラーなので、これはまぁ仕方ない。


とはいえWindowsドメインを運用するためには、少なくとも動的DNSを米国側に立てる必要がある。BINDとかで立てても良いが、どうせならドメコンを立てた方が耐障害性も高くなるので好ましい。

解決策は、と言うと…

要するに、こういう構成にする必要があるってこと。

ドメコンを米国側に立てた構成

そしてDNSクエリを模式化した絵がこちら。

米国のドメコンを通じた名前解決の流れ

米国にあるドメコンからAkamaiに対する名前解決クエリが飛ぶので、Akamai DNSが返してくるDNSの期待値は米国にあるAkamaiサーバーのIP。それが返ってくれば、HTTPリクエストもわざわざ日米間トンネルを通ることなく、直接インターネットに出ていくはず。


ドメコン立てるのもカンタンではないので、まだこの構成は試せていませんが、追って対策後についてもブログ記事にまとめてみようと思います。

しかしまぁ、なんというか。

インターネットもずいぶんと複雑化したものですね。AkamaiのようなCDNやらWAPやらIDSやら、セキュリティを高めたり利便性を高めたりするために色々なレイヤーが重なり合って、インターネットが持つ「シンプルさ」はとうの昔に捨て去られた、ということを改めて実感した次第です。


…とはいえ、ドメコンをわざわざ太平洋越しに見に行くようにした私の設計もちょっとどうかとは思いますけどね…。だって運用する時間もなければドメコン立てるような規模でもないんだもん…。