ニュースレターNo.43/2009年11月発行

JPNIC会員企業紹介

新コーナー「会員企業紹介」は、JPNIC会員の、興味深い事業内容・サービス・人物などを紹介するコーナーです。

ネットワークインフラの結節点において、大量のトラフィックを確実に交換、配信、伝送するインターネットデータセンター事業、インターネットエクスチェンジ(IX：Internet eXchange)事業を展開している、インターネットマルチフィード株式会社を訪問しました。同社は最近、日本経済新聞社と共同でIPv6環境での大規模コンテンツ配信実験も行っており、注目されています。そのお話も伺いました。

インターネットは、私達の「親」みたいなもの親孝行しないとね

研究所生まれのビジネス ～設立の経緯～

■ まず、貴社の業務内容について、教えてください。

大きなサービスは、インターネット相互接続(IX)サービスとインターネットデータセンター(iDC)サービスの二つです。IXサービスを「JPNAP」と呼んでおり、これが主要なサービスです。東京に3拠点、大阪に1拠点あります。また、「タイムフィード」という日本標準時配信・監査サービス、インターネット上での時刻情報提供サービス等を行っています。

■ 貴社は国内におけるiDCの草分けとされています。事業を始める時に「iDC」の明確なイメージがあったのでしょうか。それとも、進めるうちに見えてきたものなのでしょうか。

私(外山)は、当時、NTTの研究所にいました。この時期にコンテンツ配送の実験である「マルチフィード(Multi + Feed=コンテンツを複数ISPに直接送るの意)実験」を、NTTとIIJが共同でスタートさせました。事前準備を経て、1997年4月にスタートしてすぐに、コンテンツ配送のためのサーバを集中的にハウジングする形態がビジネスになるのではないかと予感し、5月くらいにはもう意志決定して、9月には会社ができ上がっていました。NTTグループとしては非常に速いペースでしたね。もっとも、その頃は「データセンター」という名前すらもありませんでしたけれども。

■ 「データセンター」という言葉を使い始めたのは2000年ぐらいでしょうか。当時は「コンテンツを配信する」という話を聞いても、その言葉以上の、具体的なイメージが持てませんでした。

NTT研究所の技術者たちは、コンテンツをユーザーに効率的に配信するにはコンテンツと大手ISPを直結する環境を用意するのが良いと考えていました。こうすれば、いろいろなサービスやコンテンツが、より多くネット上で提供されるようになるはずですから。結果として、コンテンツを配信するのに最適化された環境を作ることができました。ただ、こういうサービスが今後伸びていくとは思ってはいたものの、正直、ここまでの伸びは予想できていませんでしたね。

■ 1995～97年だと、インターネットの新サービスはアメリカの状況を参考にしてという雰囲気もありましたが、お手本にしたり意識した会社はありましたか？

サーバのハウジングなどについては、海外に視察にも行きましたが、「マルチフィード」というネットワークの構想、「ISPと直結する」という思想は、研究所由来のものです。そして、ファシリティや運用の細かいところは相談しながら、都度構築していきました。そういうことは研究所の研究からは生まれませんから。

■ 事業の立ち上げで、何か得られたことはありますか？

「コンテンツを流すのに良い環境」「コンテンツの集積地」と宣伝したので、サービスレベルに対してシビアなお客様が多く集まりました。ISPなどの技術者であれば、ある程度ネットワーク運用の難しさもわかってくれますが、コンテンツやサービス提供をやっている人たちは、自分たちのサービスが最優先であり、乱れたり、ダウンタイムがあってはいけないと、インターネットの世界ではある程度通用していた、ベストエフォート的なものが許されませんでした。ここから、お客様に対して、どういう運用をすれば良いのか、障害や工事などの際に、どう情報提供をすればいいのか、どうすれば理解してもらえるのかを勉強させていただきました。

■ コンテンツの集積地と聞くと、今の感覚では、そこにはIXがあるのが当然だと思えます。しかし、貴社は当時、「IX」を特に標榜しておられませんでした。実際にIXサービスのJPNAPを始めたのは2001年ですね。

コンテンツを集め、ISPを集め、という「マルチフィード」のサービスをいろいろ進めていくうちに、IXがここにあった方がいいだろうなということにつながっていきました。つまり、コンテンツを集積するのに適している場に、ISPに来てもらい、トラフィックを交換するのに良い環境も提供するということは、データセンターとIXが融合していくことを意味します。そんな経緯で、時間差ができましたが、IXサービスを始めました。

■ 「商用のIX」ということでは他社のサービスインが先となりましたが、それに対する意識はありましたか。

確かに、我々より先にサービス提供を始めた会社がありましたが、我々のところには既に大手のISPが集まっていたこともあり、交換するトラフィックではすぐに追いつけると考えていました。「コンテンツの集積地」のイメージも活用できますし。また、IXネットワークの設計・冗長構成、さらになるべくダウンタイムを短くするにはどうしたら良いかなどの点に、マルチフィードで培った「高品質なサービス提供」に関する経験・ノウハウが応用できるとも思っていました。

現在の事業と、苦労について

■ IXのサービスは開始からそろそろ丸8年になりますが、8年間見てきてどうですか？

当時は我々のような小規模な事業者にダークファイバーなんて提供されていませんでしたし、ネットワークとして使える回線サービスも、トラフィック量も当然昔とは全然違います。設計の見込みを超えたトラフィックの伸びを、どう捌くのかというところが難しかったところですね。

■ そういう悩みは、ネットワークを拡充するに当たっての継続的な苦労だったのか、それとも一時の急激なものだったのでしょうか

継続的なものです。トラフィックが増加し、1Gbpsが出てきたらそれを導入して、落ち着いた頃には10Gbpsが出たので導入して……ということを繰り返してきました。イーサのネットワークはとても貧弱なため、どのように安定的に運営していくかは難しい問題です。また、10Gbpsまでは来ましたが、最近になっても100Gbpsはなかなか出てきません。太い束を有効に使ってこそのIXなのに、それが用意できない。そのあたりは、今、一番困っているところです。

■ 貴社への最近のリクエストには、どんなものが多いのですか？

IX事業よりはデータセンター事業へのリクエストなのですが、1ラックあたりの電気使用量を多く使いたいとか、ラックの中に機材を多く積みたいとかですね。テナント側の床重量制限があるので、補強工事でどう解消すればいいかテナント側と相談し、要望に応えるよう努力しています。元々我々はネットワークの人間ですが、電力とか耐荷重とか、建築的なところを自分たちで全部見ないといけないため、そういう意味でファシリティの知識がかなりつきましたし、試行錯誤していくうちに、ノウハウが貯まりました。

我々は多くのお客様を収容していますが、年々、インターネットやセキュリティに対する要求が大きくなっています。現状、郊外型iDCにはかなり自由度が高いものがありますが、弊社はテナントなので、限られた制限の中でやるしかありません。ファシリティで純粋に比較すれば、郊外型iDCには勝てないかもしれませんが、素早い対応や柔軟性、立地条件といった部分に強みを発揮したサービスを提供しています。つまり、IXの会社ながらも、L1のさらに下、L0に相当するような知識を持つエンジニアを多く抱え、幅広くやっているところが当社の強みですね。

30分のダウンタイムが許せなかった ～サービスについて～

■ 貴社が導入している「光スイッチ」について、お聞かせください。

お客様のルータから来た線は1本でも、それを弊社で冗長化しています。当然のごとく、障害やメンテナンスの際に、線を切り替えたいという要望がありましたが、以前は、手動のパッチで切り替えていました。結果、切り替えには30分以上かかっていましたが、この「30分」という時間の長さが、エンジニアとしての、最初の疑問点でした。

この30分を短縮すべく、自動で切り替わるものを探したところ、某ベンダーの切り替え型光パッチパネルを見つけました。これを改良してもらったところ、ダウンタイムを数10msecに縮めることができ、availabilityが飛躍的に向上しました。そのスピードなので、リンクダウンも検知されないし、BGPもダウンしません。お客様からすると何もなかったように見えます。

さらには、お客様が気づかないうちにバックアップ側に切り替えメンテナンス作業をし、また元に戻すということが可能です。IX自体の信頼性を上げることで、お客様側がIX側の都合で何か余計な作業をしなくてもいい、という環境を作っています。そのため、お客様からは高い評価を得ています。BGPのピアが切れると、オペレーターは本当に大変ですから。

■ 「タイムフィード」サービスのきっかけは？

元々はNTTの研究所で今の日本標準時(JST：Japan Standard Time)をパブリックに使うための時刻配信と認証に関する、NTP(Network Time Protocol)の共同実験から始まりました。JSTに同期したサーバを持ち、それで時刻配信とか時刻認証などを行うビジネスに関する検討です。つまり、契約書、取引、特許などの、その時点で「確かに存在した」という時刻の証明が必要になるもののための認証の仕組みとサービスとなります。今後は電子取引も増えていくと考えたのも背景にあります。

■ 独立行政法人情報通信研究機構(NICT)が提供していたJSTのサービスですね。時刻監査というと、クリティカルなビジネス向けのサービスという印象があります。データセンターとしての高信頼性とのワンストップで提供するとすると、貴社を利用するような顧客と関連が深いのではないかと思うのですが。

時刻監査はインターネットとはまた別に、専用線を使って提供しています。しかし、現在利用されているお客様数はさほど多くはありません。ビジネスの方は少しずつ広がっているものの、期待値ほどのニーズはまだまだこれからかもしれません。弊社は、幅広くというよりも、一つのバックボーンとして、特定の方に高い信頼性のサービスを提供するという方向でやっていきたいと考えています。

■ 事業全体の業績はいかがですか？特に池袋の第2サイトの方はどうでしょうか。

全体的には順調に推移しています。ユーザー数も急激にではありませんが、伸びています。

池袋も、お客様が増え、そこそこトラフィックが出てきています。大手町と池袋は、互いに影響が及ばないように完全に独立したネットワークです。「大阪まではいけないけれど拠点は分散したい」という、ディザスターリカバリー等に、価値を見い出したお客様に来ていただいています。大手町だと電力が足りないという話もあり、局所的なダウンやテロも考えられます。かといって、トラフィック全体を他所にバックアップというのは難しい。そうなると、東京にもう1ヶ所あった方が良いということになりますしね。

IPv6環境下での大規模コンテンツの配送 ～日本経済新聞社との共同実験について～

■ レジストリにおけるIPv4アドレスの在庫は、2011年頃には枯渇すると言われています。このことはデータセンターサービスはもちろん、IXに接続する多くの顧客にとっても大きなインパクトがあると思いますが、この問題に対して、貴社は日本経済新聞社さんと組んで、具体的な実証実験をされていますね。この内容について、詳しく教えてください。

簡単に言えば、IPv6の環境で、既存のコンテンツを見るためにはどうするか、アクセスは問題ないのかを、トランスレータやリバースプロキシを置いた中でサービスするという実験です。

日経さんは、サーバ側をどう設定すれば、アクセスラインがIPv6だけの場合に既存のコンテンツへのアクセスに対する問題が出ないのかを検証し、一方、弊社は、IPv4在庫枯渇の際に、トランスレータサービスなど、データセンター側でどんなサービスを提供できるのかを検証しました。

具体的には、IPv6の端末を用意し、トランスレーションをする環境を整え、IPv6オンリーの環境でIPv4のコンテンツを表示した時と、IPv4の環境でIPv4のコンテンツを表示した時との「差」を確認しました。コンテンツが見えることが第一条件で、見えないところがあるのかどうか、見えない場合は何が原因なのかを調査しました。

■ 日経側とマルチフィード側で二つの実験が走ったということですね。

はい、そうなります。コンテンツは日経、ネットワークコネクティビティは弊社のものを使うことでリソースを持ち寄り、実験結果は定期的なミーティングに持ち寄り、そこで話し合いをして進めました。

日経さんは、IPv4のコンテンツをIPv6でも提供したことで、表示されない、遅くなるなど、既存のIPv4のユーザーに影響ができることを懸念していました。そのため、IPv6でのコンテンツ提供専用にURLを用意するところまで準備はしていましたが、しかしコンテンツの中身までIPv6用に書き換えることは労力的にできません。それではフロントに用意した機械でどうにかできないだろうか、という話になりました。

一方、我々はURLは特に気にしませんが、トランスレータでIPv4、IPv6の双方に問題なくアクセスできるかを知りたい要望がありました。それには、コンテンツの中身を教えてもらわないと、詳しいトラブルシューティングができません。弊社が勝手にアクセスしてある程度の実験はできても、ここまで詳しいことは、日経さんと協力しないとできないことだったと思います。

■ 実証実験を始めるきっかけを教えてください。

昨夏、とある懇親会で話をしたのがきっかけです。IPv6はどうなんだという話になりました。最近はコンテンツも複雑になってきたので、サーバ側だけではなく、コンテンツ側でも何か対策が必要なんじゃないか、社内でトライアルが必要だ、と考えているということでした。そういうことなら、日経のサイトを上手く活用し、それをIPv6にする時にはどうすればいいのかを探ろうという流れになりました。デュアルスタックにするのは簡単ですが、社内システムをそういじれないので、では外に付けて何とかしようと。

■ 実験の際に何かご苦労されたことや、トラブル等がありましたらお聞かせください。コンテンツとして日経グループというのは、一番複雑な類のものなのでしょうか？

日経さんのサイトは、複雑でグループ全体ではありとあらゆるページがあり、広告などもいろいろ組み込まれています。また、FlashやJavaScriptなどの、さまざまなダイナミックな要素が組み込まれているという点でも複雑です。ただ、プログラムの中ということだと、他の事業者でも、もっと組み込んでいるところもあるでしょう。

■ 外にトランスレータを置くというようなサービスを、今後、貴社では考えていかれるんでしょうか?

そうですね。そういうサービスも考えていきたいですね。IPv6に対応するといっても、既存のコンテンツ事業者は既にIPv4のアクセスがあるので、IPv6のアクセスが急激に増えてくるかというと、そうはならないでしょう。ですから、IPv6のアクセスが増えてくるまでは、データセンター側で対応策を用意するというのは、永続的なサービスにはなりえないものの、今後IPv4からIPv6の過渡期には絶対に必要なものだと思っています。

IPv4アドレスの在庫枯渇は、"ネットワーク"と"コンテンツ"の両面を見ないと克服できない ～共同実験の結果～

■ 約9ヶ月の実験期間がそろそろ終了しますが、現在までの成果や、想定外だったことを教えてください。

結果は、当初の想定より問題点が少なかったぐらいでした。MTU(Maximum Transmission Unit)の話とDNSの名前解決を除けば、NIKKEI NETについては概ね普通に見ることができました。

ただ、IPv4環境では問題なくても、トランスレータ経由だとあるサイトにアクセスできないという事例がありました。解析すると、IPv6のPCからトランスレータまでのアクセスはできていても、変換したパケットをIPv4のサーバ側に出すと、IPv6の端末まで戻ってきませんでした。これは、IPv4側のサーバが途中のルータでフラグメントしてくれることを前提にパケットを送信しているのが原因でした。

■ クライアントソフトウェア側の方で、IPv6のスタックを改良しないといけないということでしょうか？

そうではありません。
現在のIPv4ネットワークは、サーバのさまざまな設定の違いを吸収し、エンドユーザーまで届ける仕組みを兼ね備えています。そのため、サーバ側はMTU関連についてさほど気にすることはありませんでした。ところが、トランスレータを経由してIPv6からアクセスする場合には、IPv4サーバ側でパケットサイズの調整が必要なケースがありますが、現状、調整をしないサーバも存在します。そうなると、IPv4だけで済んでいた世界から、具体的にエンドユーザーが困る世界が出てきます。

しかし、今からIPv4の側で対応するのは難しいので、トランスレータで対応する、という解が導き出せます。今回そういう観点から、トランスレータに求められる機能は何だろうかを考えることができました。つまり、ベンダーとそういう話ができるようになった、ということです。

また、アクセスログの話もしかりです。リアルサーバのログとマッチングできることは、トランスレータの機能として重要です。DDoSを受けた時に、最初の方のログだけでいいのか、それとも全てのログが必要なのか、その辺も話しています。実装されていない機器については、メーカーに実装の交渉をしています。

■ 今後の展開は?

今回はIPv4、IPv6オンリーの環境での実験でしたが、今後は実環境に照らし合わせて、IPv4-v6のデュアルスタックについてや、NGNの普及とともにIPv6アクセスが増えることも考え、NAT、LSN(Large Scale NAT)経由のアクセスによるコンテンツへの影響についても、調べていきたいですね。今回の実験は、一つのドメイン名で一つのサーバというある意味、極端な環境であり、データセンター側のトランスレータで全て対応できましたが、実際の環境だと、広告やアプリケーションサービスが入るために、一つのサイトにアクセスすると複数のサーバへのアクセスが発生することが普通にあります。その場合、外部のサーバがIPv4オンリーだと、サイト全体にアクセスできる状態にはなりません。それでやはりIPv4が足りないとなり、LSNや2段NATを使うわけですが、そういったものを組み合わせた時にきちんと見えるのか、確認しないといけません。その環境が、クライアント側に必要だというということがわかってきました。

■ インターネット全体がIPv4アドレスの枯渇を乗り越えて、これがなくなってもどうにかできるようにするためには、ありとあらゆる環境に対応できないといけないということですね。そう考えると、現状ではまだまだ検証も足りないということでしょう。実験の第2ステージのスケジュール等は、もう決まっているんでしょうか？

年内もしくは年度内くらいまで、延長して実験しようと考えています。クライアントの環境がどんどん多様化してくる中、コンテンツ事業者は、見え方をチェックし続けないといけませんから。実験の結果、問題ない点が増えれば、検討項目が減りますから、お客様も安心ができます。

■ 我々は「枯渇対応」といっても、情報を集めて対応を促すことしかできません。そういう意味で、実際の実験は大きなワンステップ、特に日経というメディアの雄とマルチフィードのコラボレーションは、意義深い一歩だと感じました。実験の成果などを、どのようにフィードバックされていくのかなど、お考えがありましたらお聞かせください。

今、ネットワークを気にしている人が多いのですが、コンテンツも非常に大事です。コンテンツ自体も見てくれていないと、インターネット全体としてスムーズにIPv6に移行できません。実験結果については予想外のトラブルが少なく、弊社としても有意義であり、周りに聞いてみても、安心したという話を多く聞きました。何があるのかわからないという状況から、この部分については何もないのというのがわかってくると、大きく状況を進めることができますよね。

今後、実験成果の可能な部分はJANOGやInternet Weekなどで公開していく予定です。我々も、こういうことをやっているということを見て欲しいですし。

■ 実験でいろいろなことがわかり、それを次につなげるということはとても建設的ですね。IPv4アドレスの在庫枯渇問題等への対応に関し、JPNICに期待することは何かありますか。

JPNICはIPアドレスの管理を業務のコアにして、きちんとそれを非営利でやっていると思います。中立的な活動は評価するし、これからも頑張っていって欲しいです。ISPからすれば、JPNICだけではなくAPNICに直接申請もできるという選択肢がある中で、日本語を話す我々にとっての大きなランゲージバリアを超えたところで、日本の意見をワールドワイドに伝えて欲しい。日本のISPが世界と同一のところでやっていけるように頑張って欲しいし、そういうJPNICの活動をサポートしていきたいと考えています。

クラウドだって、最適化をめざした結果なだけで、最初からクラウドの世界をめざしていたわけじゃない ～他のレイヤの理解なしには何も生まれない～

■ 現在のインターネットについて思うところはありますか？

インターネットも、「ネットワーク」のone of themになっているような気がしますね。携帯電話からのアクセスもPC以上に一般的で、若い人は「ネット」と、一くくりに言っていますし、生まれた時からそこに何らかのネットワークがあるのが当たり前になっています。私自身は、そういう捉えられ方でも良いと思っています。

となると、その肝となるIXとかデータセンターとか、そういう部分をいかにスムーズに提供していくかという話になってきます。エンドユーザーにとっての「インターネット」という概念自体が、ボンヤリとしてきているのは仕方がないことだとしても、その中で、誰もが安全に使っていけるように、認証等を駆使して、世の中に貢献していくことが必要です。

PCを起動しなくても、生活でインターネットが利用できるのが当たり前ならば、インターネットのへそであるIXとして、我々への期待や信頼性の高いネットワークのニーズにいかに的確に応えられるか。研究所との共同実験から、さまざまなサービスを世の中に出してきましたが、拡大していくインターネットの中で、我々のできることは何か。これを考え続けるのが我々の使命だと思っています。

■ インターネットバンキングやTwitter、mixiといった、サービスやアプリケーションが一般ユーザーにとってのインターネットであって、そういう人からすると我々のような下支えの存在は想像もできないでしょう。でも、貴社やJPNIC会員も含め、我々が頑張らなければ、みなに楽しんでもらうことができませんものね。

そうですね。元々、我々が大学や会社である程度インターネットを使った時は、世の中の人全てが使うインフラではありませんでした。研究所でマルチフィードという会社を作り、技術の中心的な担当になると、いい加減なネットワークじゃない、ちゃんと使えるものじゃないとダメなんだぞ、インフラなんだぞと痛感させられました。これはこれできちんとした世界にしないといけないことを教えてくれたのがマルチフィードであり、ここを立ち上げた時の経験はとても大事なものです。電話屋さんから見るとまだまだ甘いかもしれませんが、インターネットの特性を上手く使って、高信頼性のサービスを提供していければと。

そして、皆様にはもっともっとネットを使いこなして欲しい。そして、もっと新しい発想を使って欲しいと思っています。

■ 同じ業界で働く人たちや、年齢の若い人たちに伝えたいことは？

弊社に入って来るような人は、高いバイタリティを持っています。インターネットがインフラになってしまった今、なかなか興味を持ちにくい分野であるかもしれませんが、そこに目を輝かせて入ってくる人はやはり違います。若くても同じように対等に話ができます。過去を共有しながら、どんどん新しい世界を作ってくれと思っていますね。

インターネットも随分、すそ野が広がってきたかなと思います。広がってくると分業も増え、分化してきます。その結果、インターネットは元々コンピュータのネットワークなのに、コンピュータやOSを知らない人が増えています。ネットワークだけでなく、コンピュータ同士がどうつながるのかとか、もう少しコンピュータのことも理解した上で話をしようよ、インターネットを語ろうよ、と思うことがありますね。

今、「クラウド」という語もはやっていますが、どちらか片方だけじゃなく、サーバもネットワークも両方やろうよと言いたいんですね。そういうエンジニアが出てこないと、次のステップが見えて来ないんじゃないのかな。IPのネットワークはとても上手に設計されているので、他のレイヤを見なくて良いという要因はあるとしても、「独立の最適なもの」だけを追い求めていてもダメでしょう。他のレイヤを見なくても良い、ということは反面、究極的に言えば相手が理解できない、気持ちがわからないということになります。両方理解できる、器用なエンジニアが、もう少し出てきて欲しいですね。今のクラウドの話も、最適化のためにクラウドになったのであって、最初からクラウドをめざしたわけじゃないんですよ。

■ 最後に、インターネットとは何でしょうか。

インターネットに育てられたように思っているので、親みたいに感じていますね。そろそろ親孝行しないといけないかなと思っています。

何も知らず使っている頃は気楽で良かったなと。ユーザーならつなぐだけでも良いですが、入ってみるとすごく苦労があります。でも、ありとあらゆるインフラがそうなんだと思います。蛇口を捻ると水が出るのも、きっと我々にはわからない陰の苦労があるんでそれを楽しんで、乗り越えたいですね。