今回は、
IPv6環境のユーザテストが課題
- ──IPv6に関して御社で行われている取り組みを教えてください
弊社は、
ネットワークインフラの部分に関しては、 すでにIPv6の対応は終わらせてあります。DNSのレベルでIPv6も対応するようになっています。ただ、 サービスという観点に行きますと、 IPv6を使って楽天市場のいろいろなサービスを提供するところまでは至っていません。 楽天技術研究所所長 森 正弥氏 
以前、
ソフトバンクのBBIXさんやASPさんと一緒に共同実験を1年以上行っておりまして、 そのクローズドな環境で特定ユーザさんに向けて、 検証用コーポレートサイトを一部ご用意させていただいてます。それを見せることによって、 お互いノウハウを溜めましょうと。 BBIXさんやKDDIさんのユーザさんに見せて、
IPv6でアクセスしてもらい、 我々としてはアクセスログなどを見ながらサービスインに向けての問題点洗い出しを行うというテクニカルな取り組みは積極的に行っています。
- ──その取り組みでわかったノウハウや課題を教えてください
いまのところ、
目立って大きな問題はありません。やろうと思えばできる、 というところですね。ただ、 私達が行っているのはIPv6ネイティブではなく、 いわゆる他社さんが行っているのと同様なNAT方式です。 課題ですよね…。クローズドな環境で行っていたこともあり、
IPv6でのアクセスが微々たるものしかなかったので、 実際に負荷がかかったときにどうなるのかは今後の課題かもしれません。我々も負荷試験は行っていますが、 今回は生きたデータが取れない環境でしか行えていません。逆に、 生きたデータを取ろうとすると、 それは我々にとっては生きたコンテンツであり、 プロダクションになるので、 なかなかテスト的に行うのも難しいのかなというのもあります。 我々も提案はできるのですが、
それをやることでお客様のビューが増えるのかと言われると、 データも取れない状況もあって明確な答えが返せないのが現状です。 - ──
「NAT方式」 というのは、 IPv6でユーザからのセッションを受け取るプロキシを経由して、 IPv4のWebサーバに接続するという方式ですか？ はい。一度IPv6で受けまして、
中の環境はIPv4で作るという形になります。全てをネイティブIPv6では作っているわけではありません。その目的としては、 既存のシステムがあまり意識をせずに容易にIPv6に対応できるように、 インフラ側で調整するというものです。 - ──そのときのアクセスログは、
どのように処理されていますか？ いまのところは、
普通にIPv4のアクセスログとして保存しています。IPv6で受けてIPv4へと中継しているアプライアンス部分で取得しているログの管理をどうしていくのかは課題です。その辺の運用は考えて行かなければならないと思います。
& Network Administration Group,
Vice Group Manager 岩崎 磨氏
IPv6環境しかないユーザが現れたときのために
- ──それ以外に、
何か気づかれたことはありますか？ 今回は取れたデータが限られていたので、
たとえば、 CGNなどでの課題洗い出しなどを行いながら、 まだデータを取りたいなぁという感じです。 そういう意味では、
我々は、 用意はできているとはいえ、 まだまだ準備はできていないという状況です。 - ──CGN以外にもっとデータを取りたいものなどはありますか？
もしくは、 まだ調べられていない話などはありますか？ 先ほども申し上げた通り、
一般的な負荷試験は行っていますが、 やはり生きたユーザのトラフィックでのテストができていないことが挙げられます。 私たちのビジネスは、
お客様がページをご覧になって、 商品をカゴに入れてという部分がデータベースへのトランザクションとなっています。この場合、 表と裏のシステム全体が連動しなければならないのですが、 そこまでを試してみることができる生きたデータをどうやって取れるのかという問題はあります。実験イコール実環境になってしまうので、 そもそもが難しいです。 そのため、
すごく感じるのは、 実験はしたいと思う一方でリスクがあるので、 「大丈夫です」 とは言えるのですが、 本質的なリスクの洗い出しができない状態で、 楽天市場のトップページをIPv6にすることの承認を得られますかというと、 なかなか理解を得にくいというもどかしさがあります。 - ──そのような状況は、
どれぐらいの期間が経てば変わりそうですか？ それともずっと変わらなそうですか？ IPv4アドレスの枯渇問題が密接に関わっています。IPv6でしかアクセスできないユーザさんが出てきたときにどうするかだと思います。
我々はグローバル展開していますので、
たとえば発展途上国の方々がIPv4アドレスが確保できずにNAT環境のみになり、 グローバルIPアドレスはIPv6しかないという環境が出てきたときに、 ビジネスチャンスを失わないようなタイミングで準備をしたいと考えています。 IPv4の延命が意外と続いているので、
いますぐではないかも知れませんが、 何も準備をしないことで火傷はしたくないですね。たとえば、 ある日突然中国のような大きなマーケットで国の政策としてIPv6 onlyのようなことをされてしまうと、 大変なことが起きてしまいます。 - ──たとえば、
それまで全くIPv6に取り組んでなくて、 ある日突然IPv6に取り組もうと思った時に、 どれぐらいの期間で準備ができるものですか？ 難しい質問ですね。
インフラエンジニアの立場で言えば、
「オッケーです」 と言えてしまいますが、 それが生きているサービスに実装されたときに、 どれくらい受け入れられるのかですね。もちろんサーバエンジニアも理解はしており、 できるのはわかっていますし、 やれと言われたらかなり短い期間で 「できます」 と言えるとは思います。 リスクとメリットの境界線の部分が意思決定ですよね。現時点で意思決定のために十分な情報を取れているかというと、
難しいかなという感じです。
プライベートIPv4アドレスの枯渇がIPv6対応の契機に？
- ──その他、
最近取り組まれていることはありますか？ 昨年
（2012年） 末に、 我々のDNSに対してIPv6 enableにしました。いまはIPv6で名前解決が行えるようになっています。 - ──それは、
DNSのトランスポート部分をIPv6で行えるようになったということで、 Webサーバ等のAAAAレコードが登録されたわけではないという理解で正しいですか？ 登録されたのは権威DNSのIPv6アドレスですね。 はい。そうです。
- ──現在はまだ行われていないことや検討されていることを含めて、
IPv6関連で何かおもしろい話はありますか？ 実は、
我々の内部ネットワークでプライベートIPv4アドレスの枯渇問題に直面しています。 もともとは、
日本国内の楽天市場を運営するためにプライベートIPv4アドレスを使っていたのですが、 結構ダイナミックに使っていました。ところが、 楽天が成長するにつれて、 いろいろな会社の買収や企業とのネットワーク統合等を行い始めると、 どうしてもプライベートIPv4アドレスのアサインする必要が出てきます。 「データセンター拡張のためのプライベートIPv4アドレスがなくなってきました。これはマズい」 という感じです。 プライベートIPv4アドレスそのものは結構まだ空いているのですが、
レンジの概念で切って行くと、 先が見えて来ているという状況です。10/ 8がもうほとんど無くなっていますし、 172. 16. 0.0/ 16も無くなってます。 NATやリナンバーなどの方法もあるのですが、
その工数を考えると、 IPv6を使ってしまった方がシンプルになります。我々のシステム内部で、 IPv4アドレスをベタ書きしているようなところは比較的駆逐されているので、 そういう意味ではやりやすいとは思います。まあ、 できるかどうかですね。 - ──内部ネットワークにおけるプライベートIPv4アドレス枯渇がIPv6利用のインセンティブになり得るということですね。DOCSIS 3.
0の話みたいですね。 はい。そうですね。どちらかというと、
我々が直近で直面しているのは、 内部のプライベートIPv4アドレス枯渇問題です。 - ──中がIPv6になってしまえば、
対外的なサーバもIPv6対応することへの障壁が低くなりますかね？ はい。なると思います。
- ──内部ネットワーク用にIPv6を使う場合には、
どのようなIPv6アドレスを使うのですか？ それはまだ検討中です。人間がわかりやすいオペレーションをするという視点も持ちつつ、
そこは上手くやる必要があるとは考えています。 ノウハウというか、
ベストプラクティスがわからない状態で作っているので、 他社さんはどういう風にしているのだろうかとか、 どういう失敗があり得るのかとかは非常に気になります。そういったところのノウハウ共有があるとすごく嬉しいですね。 - ──ありがとうございました。