「魔法の数字8.8.8.8」を検証する

   このエントリをはてなブックマークに登録    2011/9/22-1

ここ数日、8.8.8.8や8.8.4.4というIPv4アドレスを持つGoogle Public DNSに関する話題が盛り上がっているのですが、多くの人が「よくわからないけど設定変更したら早い!」と言っているので、そこら辺の話を調査してみました。

昨日、Twitterブログでtracerouteやdigによる調査協力のお願いを発信し、8.8.8.8へのtracerouteを37件、8.8.8.8とISP DNSへのtraceroute比較及びAkamaiキャッシュサーバへのtraceroute比較を21件、日本各地及び海外のいくつかの地点からご協力頂けました(皆様ありがとうございました!)。 それらのデータをもとに、Google Public DNSを利用した場合の通信経路と、それによる遅延に関する検証を行いました。

Google Public DNSに対する私の感想

まず最初に。 調査前からの私のスタンスとしては、「ISPが提供するDNSキャッシュサーバを使っている方が早いことが多いので、ISPが提供するDNSキャッシュサーバに不満があるなど明確な理由がない限りは変更しない方が良いのでは?」という感じです。

ただ、8.8.8.8と覚えやすいことや、セキュリティ上の理由でオープンリゾルバが減少してしまったという背景もあり、私もGoogle Public DNSを使うことがあります。 たとえば、イベント等の会場でうまく現地のDNSキャッシュサーバに関する情報が提供されていなときに、とりあえず8.8.8.8と入れてみることが多いです。 また、以前、ISPのDNSキャッシュサーバ障害が発生して、Twitter上で「インターネットが使えない!」と多くの人々が言っていたときに「8.8.8.8をDNSキャッシュサーバとして登録したら障害を回避できますよ」とアドバイスしたりもしています。

ということで、私にとってGoogle Public DNSは日常的に使うものというよりは、知っていると障害時等に便利なサービスという位置づけです。

Google Public DNSの早さを産み出しているもの

ISPのDNSと比べてGoogle Public DNSが優れているのは、恐らくキャッシュヒット率の高さだろうと思います。

ユーザからのリクエストがなくても、自動的にDNS権威サーバへの問い合わせを行うなど、出来るだけ多くのキャッシュを保持し続けるような仕組みになっています。 ユーザからのリクエストを受けとってから再帰検索を行うのではなく、はじめからキャッシュが存在している場合が多くなるというのがGoogle Public DNSの「早さ」を実現しています。

さらに、キャッシュの検索が高速であるという特徴もありそうです。 既にキャッシュされている項目を問い合わせた時の回答送信のスピードは結構早い印象があります。 ただ、この「早さ」はISPのDNSと比べて1〜2msec早いとか、数msec早いという場合が多いので、人間が認知できる違いではなさそうです。

1. 調査結果 (物理的な位置とRTTの違い)

「とりあえず細かい話はいいから結果を教えろ!」という方々も多いと思うので、最初に結果を掲載します。

まず最初に、ISPのDNSと、Google Public DNSの位置構成概要です。

今回ご提供頂いたtraceroute結果に含まれていた結果から、Google Public DNSが設置されているGoogleのASとの接続形態という視点で図を作成すると下記図のようになります。 地方にあるISPや学術ネットワーク(学術機関)が商用IX経由でGoogle ASと接続、大手ISPはGoogle ASと直接接続、大手ISPからトランジットサービスを購入している地方ISPは大手ISP経由でGoogle ASに接続というものです。

次に、Google Public DNSまでのRTT(Round Trip Time)です。

ISPのDNSがISP内にあるのに対して、Google Public DNSがISP外にあるという特徴があります。 そのため、Google Public DNSまでのRTTは基本的にISPのDNSよりも大きくなることが多いのですが、東京近郊ではGoogle Public DNSまでのping結果の方がISPのDNSへのping結果よりも早い場合もあるようです(恐らくGoogle Public DNSの方がICMPへの応答速度が早いからだと推測されます)。

GoogleのAS(Autonomous System)は、かなり多くのISPと「お隣さん」になっているので、東京近郊ではISPのDNSとGoogle Public DNSとのRTTの差は非常に小さくなっています。 しかし、地方からの計測では、ISPのDNSへのRTTと、Google Public DNSへのRTTとの差が大きくなります。 今のところ皆様から頂いたtraceroute結果から、日本国内におけるGoogle Public DNSの拠点は現時点では東京のみであると推測しています(Google Public DNSそのものはエニーキャストで運営されているので世界中に拠点があります)。

1.1. 北陸の事例

北陸の地域ISPからの計測結果は以下のようになっています。

日本各地の学術機関や学術ネットワークでの結果も、これに類似するものでした。

1.2. 東京にISPのDNSがある場合

全国的にサービスを行っている某大手ISPの関西圏のユーザがISPのDNSキャッシュサーバへのtracerouteを行った結果です。 ISPのDNSキャッシュサーバと、Google Public DNSのRTTに大きな違いはありませんでした。 関西圏からtracerouteをすると東京でISPのAS外に出ていました。

1.3. 大阪にISPのDNSがある場合

全国的にサービスを行っている某大手ISPの関西圏のユーザがISPのDNSキャッシュサーバへのtracerouteを行った結果です。 ここでも、関西圏からtracerouteをすると東京でISPのAS外に出ていました。

1.4. 九州のISPの場合

大手ISPからトランジットサービスを購入していると思われる九州のISPの場合です。 この場合も、やはりGoogle Public DNSまでのtracerouteは東京へ向かいました。

この他、北海道、北陸、中部、関東からのtracerouteも、上記結果のどれかに類似するものでした。

2. 調査結果 (Akamaiキャッシュサーバ)

次に、Akamaiキャッシュサーバまでの経路の違いを計測しました。

Google Public DNSが抱える最大の欠点は、既存のCDNとの相性が悪い場合があることです。 特に影響が大きいのが、世界のWebトラフィックの3割を扱っているとされるAkamaiとの相性の悪さです。

Akamaiが関連しているものとしては、たとえば、Windows Update、ウィルス対策ソフトのアップデート、Ustreamでの視聴者数が多いストリーム、Huluのコンテンツ、Apple社のiOSアップデートなどがあげられます。 大規模なWebサイトなどでもAkamaiサービスが利用されています。 ぱっと見だと、Twitterの画像部分やasahi.comなどがAkamaiを利用しているようです。 他にも、必要に応じて一部や全部を切り替えつつAkamaiなどのCDNを利用しているWebサイトが色々とあります。

Akamaiは世界中のISP内にコンテンツキャッシュサーバを運用していますが、DNS権威サーバへの問い合わせに対する相手の送信元アドレスに応じて結果を変えます。 たとえば、ISP Aから来ているDNS queryには、ISP A内にあるAkamaiキャッシュサーバのIPアドレスを返し、ISP Bから来ているDNS queryにはISP B内にあるAkamaiキャッシュサーバのIPアドレスを返すという具合です。 DNS queryが来たISP内にAkamaiキャッシュサーバが存在しない場合、Akamaiが「最寄りである」と判断したAkamaiキャッシュサーバのIPアドレスを返します。

このように、Akamaiの仕組み上は、「DNSへの問い合わせがどこから来たのか」が非常に重要なのです。 各ユーザがISP内にあるDNSキャッシュサーバを利用する限りは、この仕組みが非常に有効に機能します。

しかし、Google Public DNSが利用された場合、Google Public DNSからのDNS queryは各ユーザの最寄りにあるわけではないので、適切なAkamaiキャッシュサーバが紹介されません。 結果、Google Public DNSを利用するとAkamaiに関連するコンテンツを取得する際の速度が低下します。

2.1. 北陸の事例

北陸の地方ISPでは、Akamaiキャッシュが地域IX内にあるため、そのISP内DNSキャッシュサーバを使う場合にはAkamaiキャッシュ(この場合はwww.asahi.comのコンテンツ)からのデータ取得は、ISPが接続している地域IX経由で行われます。

一方、Google Public DNSを利用している場合、「最寄りのAkamaiキャッシュ」として紹介されたのが太平洋を越えた米国内のISPにあるAkamaiキャッシュサーバでした。 ISPのDNSキャッシュサーバを利用した場合には、AkamaiキャッシュサーバまでのRTTは約3msecでしたが、Google Public DNSを利用した場合には120msecまで遅くなってしまいます。

RTTの低下は、TCPスループットの低下も招くため、ダウンロードにかかる時間も大幅に遅くなるはずです。

DNSへの問い合わせ時間だけを比べると、ISPのDNSキャッシュサーバとGoogle Public DNSでは数msecしか変わりませんが、その結果、Akamaiが提供しているデータへのアクセスが大幅に低下してしまうことがわかる結果と言えそうです。

2.2. 大阪にISPのDNSがある場合

大阪にISPのDNSがある事例での、Akamaiキャッシュサーバへのtraceroute結果です。 同一ISP内(同一AS内)の東京地域にAkamaiキャッシュサーバが設置してあり、ISPのDNSを利用していると、そこからデータを取得するようになります。 一方、Google Public DNSを利用していると、香港もしくは米国のAkamaiキャッシュサーバを取得しに行くようです。

東京にISPのDNSがある事例での、Google Public DNSでのAkamaiキャッシュサーバへのtracerouteも同様に、香港もしくは米国のAkamaiキャッシュサーバへ向かっていました。

関西圏にある学術ネットワークからの結果も同様の結果でした。

2.3. 九州のISPの場合

大手ISPからトランジットサービスを購入していると思われる九州のISPの場合です。 Google Public DNSを利用した場合、Akamaiキャッシュサーバへのトラフィックは主に香港に向かうようです。

他の事例同様に、Google Public DNSを利用した場合、Akamaiキャッシュサーバまでのtracerouteが米国のISPを指す結果もありました。 このときのAkamaiキャッシュサーバまでのRTTは、ISPのDNSを利用している場合は15msec〜17msecであったのに対して、Google Public DNSを利用した場合は158〜181msecでした。

総評

今回の調査結果からわかるのは、以下のようなことです。

  • 日本国内のGoogle Public DNS拠点は、現時点では恐らく東京にのみである(Google Public DNSはエニーキャストを利用して運営されているため、世界中に拠点があります)
  • Google Public DNSを東京近郊で使う場合には、RTTがISPのDNSよりも小さくなることがある(Google Public DNSの方が応答が早い場合がある)
  • Google Public DNSを地方から使う場合には、RTTがISPのDNSよりも大きくなる(Google Public DNSを使うと東京までの往復を必ずしてしまう)
  • Google Public DNSはAkamaiとの相性が悪い

特にISPのDNSとGoogle Public DNSで大きな差が出るのが、Akamaiとの相性の悪さの問題だと思われます。 今回頂いた全てのtraceroute結果で、Google Public DNSを利用すると、Akamaiキャッシュサーバに含まれているwww.asahi.comのコンテンツを取得するために香港もしくは米国まで通信を行っていました。

ISPのDNSを利用している場合には、ISP内、もしくは隣のASにあるAkamaiキャッシュサーバが紹介されるのでRTTが数msec〜十数msecであるのに対して、香港までのRTTが70msec前後、米国までのRTTが120〜180msecぐらいと、Google Public DNSを利用すると大幅にRTTが大きくなっているのが特徴的です。

Google Public DNSを使った場合、最も良い結果で日本国内の「隣のAS」かなぁと思っていたので、現状は私の予想よりもAkamaiとGoogle Public DNSの相性が悪いことを示していました。 このような「CDNとの相性の悪さ」は、単純にGoogle Public DNSに対してtracerouteやベンチマークツールを使っただけではわからないのが難しところです。

Google Public DNSはISPの収益を圧迫する可能性がある

これは、ユーザには直接関係がある話ではありませんが、Google Public DNSがCDNと相性が悪いため、多くのユーザがGoogle Public DNSを利用することによって今よりも余計なトラフィックが増え、そのトラフィックを処理するコストがISPの収益を圧迫する可能性があるというデメリットがあります。 最近は、データ量の多いビデオトラフィックを運ぶためのCDNの存在感が非常に大きくなっているという背景もあります。

「トラフィックを処理するためのコスト」というと設備投資などを思い浮かべる方々も多いと思いますが、トラフィック増加でコストが上昇する例としては、トランジット料金の上昇もあげられます。 どれぐらいの価格かは「トランジット+料金」というような単語でWeb検索して頂ければと思いますが、恐ろしく大まかに言って「1Mbpsあたり数千円の従量課金制度」と考えて下さい。

ISP内にあるAkamaiキャッシュからユーザがデータを取得すれば、AS間のトラフィックが発生しないのでトランジット料金も発生しませんが、Google Public DNSを利用するユーザが紹介されるAkamaiキャッシュがISP外のものになるとAS間トラフィックがその分発生します。 そして、AS間トラフィックが増えれば増るほどトランジット料金が発生するので、ISPにとってはトラフィック処理コストが上昇するという仕組みです(凄く大まかに書いてます。詳細は「インターネットのカタチ - もろさが織り成す粘り強い世界」の8章をご覧下さい)。

余談ですが、現状と比較するとトラフィックが増えるということは、ルータやスイッチなどのネットワーク機器の稼働率が上昇することでもあり、日本のインターネット全体として見た時に消費電力が上昇するという見方もできるのかも知れません。

Google Public DNSとCDNの相性を改善する取り組み

Google Public DNSがCDNと相性が悪いことは、Googleも十分認識しています。 Google Public DNSのFAQにも以下のような「良くある質問」が掲載されています。

I've read claims that Google Public DNS can slow down multimedia applications such as iTunes and Apple TV. Are these true?

さらに、その中でCDNとの相性の悪さを解消するためにIETFで標準化を行っていることが述べられています。

しかし、標準化作業が順調に進んでいるようには思えません。 2010年の始めにIETFでdraftを発表していますが、いまだにIETFのWorking Group Draftとして採用されるに至ってませんし、つい最近も多くの反対意見がdnsextメーリングリストに送られていました(議論の発端となったメール)。

dnsext WG Chairのメールを見る限り、二人のChairは「ExperimentalなRFCを目指すdraftだし、必要なら手伝うよ」というような感想を「個人として」表明しているようにも読めます。

そのようなIETFでの状況が背景にあるのかどうかは不明ですが、先月、GoogleとOpenDNSが共同でオープンリゾルバとCDNの相性問題を解消するための実験的な取り組みをいくつかのCDN事業者と開始しています(このニュースがdnsextメーリングリストでの議論の発端でした)。

ただ、これらの取り組みに業界ぶっちぎり1位のAkamaiと、恐らく業界2位であると思われるLimelightが含まれていません。 AkamaiとLimelightは、現時点ではGoogle Public DNSとOpenDNSのために、工数を割いて実装するメリットが少ないと判断しているのかも知れないと思いました。 あとあまり本質ではありませんが、GoogleとOpenDNSの協業は「ネット高速化」というよりは「オープンリゾルバが既存システムに追いつく」という側面が強いと思うので、ものは言いようかなぁという感想もないわけではありません。

これらの状況から、Google Public DNSとCDNの相性問題が完全に解決するには相当の時間がかかるか、もしくは解決しないという可能性もゼロではない気がしています。

日本の8.8.8.8はミラー?

今回の調査結果では、Google Public DNS経由で紹介されるAkamaiキャッシュサーバの多くは、香港に設置されていると推測されるものでした。 2年前の計測結果でも似たような状況だったのですが、もしかしたら、Google Public DNSの本体機能は今でもいくつかの地点にしかなく、それが香港周辺や米国であって、日本にあるのはDNSキャッシュのミラーだけなのかも知れないと思いました。

日本国内からの8.8.8.8宛DNS queryは、日本国内の8.8.8.8に届きますが、実際に再帰検索を行っているのは香港周辺のIPアドレスを持つDNSキャッシュサーバであると考えると、今回の挙動を説明可能です。

DNSキャッシュサーバの運用では、ユーザが問い合わせるIPアドレスと、DNSキャッシュサーバが再帰検索を行う際にDNS権威サーバに問い合わせるときのIPアドレスが異なる設定にしてあることが多いです。 たとえば、BINDでは「query-source address 198.51.100.76」のようにすることで「DNSキャッシュサーバが問い合わせに使う送信元IPアドレス」を設定可能です。 query-sourceは、通常であれば同じ機器で別ネットワークインターフェースを利用するというものですが、Google Public DNSの場合は地域を越えてquery-source設定が行われているのかも知れないと思うと「凄いなぁ」と思います (forwarders設定でbindでもできるようです)。

その「早くなった」は本当か?

今回、様々な方々が「試してみたら早くなった!」と発言されていますが、ISPが用意しているDNSキャッシュサーバが遅いわけではない場合に、実はGoogle Public DNSとは関係が無いところで「早くなった」と誤解してしまいそうなケースを考えてみました。

1. 手元のDNSキャッシュ/Webキャッシュを参照している?

「キャッシュが存在するのか?」や「どの名前を解決するのか?」などによっても大きく結果が異なるため、DNSの検証は容易ではありません。

今回は検証としてWebブラウザやiPhoneアプリをいくつか試してみて、体感で「早くなった」と結論付けている反応が多いのですが、実はGoogle Public DNSを利用したときに以前と同じサイトを表示して、手元PC内にDNSキャッシュやWebブラウザのキャッシュがあっただけでDNS設定とは関係がなく早く表示される場合もあり得ると推測しています。

2. SOHOルータのDNSフォワーディング機能という要素

最近のSOHOルータの多くは、DNSフォワーディング機能があります。 Google Public DNSを利用することそのものではなく、このDNSフォワーディング機能を回避することが高速化に繋がる事例もあるのではないかという指摘もあります。 私の手元にあるSOHOルータでは有意な差があるようには見えませんでしたが、設定や環境や製品によっては要素として考慮しても良いのかも知れないとは思います。

逆に、SOHOルータのDNSフォワーディング機能を利用していつつ、そこにキャッシュが存在する場合、応答速度は激烈に早くなります(当たり前ですが。。。)。 たとえば、私の手元の環境では1msecで応答が返ります。 同じサイトを何度も見るような場合、PCのDNS設定を変更するより、SOHOルータのDNS設定を変更した方が良い場合も多そうです。

最後に

インターネットは、各自が自律的に判断して行動することが前提となっている部分があります。 そのため、他人に対して「DNSキャッシュサーバの設定をああしろ」とか「○○はすべきではない」と言うつもりはありません。

SF作家のアーサー・C・クラーク(Arthur C. Clarke)氏のクラークの三法則に「高度に発達した科学技術は魔法と見分けがつかない」という項目がありますが、DNSもネットワークエンジニア以外からは「魔法」に見えるぐらい高度に発達した科学技術と言えるのかどうかに関して漠然と妄想する今日この頃です。

おまけ

中には「空気を読まずにIPv6で調査してみました」というデータ提供もありました。 ISPのDNSキャッシュサーバとGoogle Public DNS(2001:4860:4860::8888)までのtracerouteがIPv6で行われていました。 結果は、ISPのDNSキャッシュサーバがISP内で、Google Public DNSがISPの隣のASだったので、恐らくIPv4と変わらないと思います。

その同じ調査結果内で頂いたAkamaiキャッシュサーバまではIPv4でしたが、AkamaiのIPv6サービスを購入しているコンテンツ事業者までのtracerouteを行えばIPv6でAkamaiキャッシュサーバまで到達可能であると予想しています。

他には、カナダや台湾からの結果も頂けました。 カナダの事例では、Akamaiキャッシュサーバからデータを取得するために米国のISPへ向かっていました。

関連する過去記事

Google Public DNSに関するもの

Akamaiに関するもの

インターネットのカタチ もろさが織り成す粘り強い世界 過去に実際に起きた「インターネットが壊れて復旧した」事件を端緒に、「粘り強いが壊れやすく、壊れやすいが粘り強い」という視点でインターネットの形を探るという本を書きました。 インターネットを構成する基礎技術TCP/IPを解説した書籍は非常に多くありましたが、そのTCP/IPを使ってインターネットがどのように運用構築されているのかに関しては、あまり知られていません。本書は「TCP/IPを知っていてもインターネットはわからない、一方でインターネットを知るにはTCP/IPの細かい話を全て知る必要もない」という思想で、教科書的にならずに、あくまで「読み物」として楽しんで頂けることを目標に書いています。ISP同士の繋がり、DNSの仕組み、AkamaiなどのCDNも解説しています。

   このエントリをはてなブックマークに登録   



コメント

gatchang
校正をば。
>> 日本国内からの8.8.8.8宛DNS qeuryは、日本国内の8.8.8.8に届きますが、実際に再帰検

DNS qeury

DNS query
と文脈から思いましたがどうでしょ。

記事は、わかりやすくてとても参考になりました。素晴らしいと思います。
あきみち
gatchangさん、ありがとうございます。修正しました。


あきみち

アカマイ 知られざるインターネットの巨人

インターネットのカタチ もろさが織り成す粘り強い世界
「インターネットのカタチ - もろさが織り成す粘り強い世界 -」関連資料

マスタリングTCP/IP OpenFlow編
「マスタリングTCP/IP OpenFlow編」関連資料

Linuxネットワークプログラミング




外部サイト

プレコ王国
ディスカス魂
金魚タイムズ
YouTubeチャネル
Twitter
Facebook

フィードメーター - Geekなぺーじ
Copyright (C) Geekなページ.
All rights reserved. 無断転載や無断コピーなど、私的利用の範囲を逸脱した利用はおやめ下さい.