PR
ライブドア執行役員CTA情報環境技術研究室長の伊勢幸一氏
ライブドア執行役員CTA情報環境技術研究室長の伊勢幸一氏
[画像のクリックで拡大表示]

 「サーバー・ソフトのIPv6対応はたやすい。だが,DNSやアクセス環境の整備など,Web開発者の立場からは見落としがちな盲点がある。IPv6化実践プロジェクトに取り組んだ結果,いくつかの確認ポイントが判明した」---。2009年2月23日,ライブドア執行役員CTA情報環境技術研究室長の伊勢幸一氏はITproテクノロジ・カンファレンス「プロバイダ/データセンターのIPv4アドレス枯渇対策」で講演し,自身が取り組んだIPv6化プロジェクトの成果を発表した。

 Webコンテンツ・プロバイダとしての立場から,伊勢氏は2つのWebアプリケーションについてIPv4/v6デュアル・スタック化事例に取り組んだ。その1つは,2008年7月に立ち上げた,インターネット掲示板「2ちゃんねる」のIPv6掲示板「ipv6.2ch.net」である(AAAAレコードは2407:3000:6:175::12,Aレコードは125.6.175.12)。プロジェクトの開始は5月22日。データセンター内のIPv6対応,Webサーバー環境のv6対応,上位ネットワークとの接続などを経て,7月28日にIPv6掲示板を開設した。

 「2ちゃんねるは,うまく事が運んだ事例」と伊勢氏は振り返る。2ちゃんねるのサーバーOSはFreeBSD,Webサーバー・ソフトはApache 2.0であり,ともにIPv6に対応済みだった。OSの設定ファイルとWebサーバーの設定ファイルである/etc/rc/confとhttpd.confにIPv6向けの設定を多少施すだけでIPv6対応が済んでしまった。アプリケーションで書き換えたのは,IPアドレスなどをハッシュにかけてIDを作成する部分だけである。加えて,本来は必要ないものの,CGI経由で環境変数「$ENV{REMOTE_ADDR}」を取得し,IPv6アドレスから来ているかどうかを判別できるようにした。

既存サービスのIPv6化にも取り組む

 2ちゃんねるのIPv6掲示板に引き続き,2008年11月19日には,ライブドアが手がけるサービスのデュアル・スタック化にもとりかかった。対象としたのは,社内/社外にいるWeb開発者向けの,Webサービス運用プラットフォーム・サービス「EDGE Co.Lab」である。まずはタスク共有アプリケーション「fixdap」をIPv6化した。18日間のプロジェクトを経て,2008年12月15日にIPv6化した「EDGE Co.lab v6」と「fixdap v6」をリリース。Webサービスのプログラムの改修作業は正味2日である。

 EDGE Co.Labのサーバー資源はプライベート・アドレス空間に存在しており,インターネットからはリバース・プロキシ経由で利用する。このため,IPv6対応を施す個所は,リバース・プロキシ部分となる。内部アドレスからのアクセスとなるため,リバース・プロキシ側でIPv6かIPv4かに応じてリクエスト・ヘッダー情報を独自に付与し,Webサーバー側のCGI経由で取得するようにした。

 ところが,2ちゃんねるの掲示板とは異なり,EDGE Co.LabではIPv6化を完了するまでに,いくつかの課題にぶつかった。具体的には,18日間のIPv6化プロジェクトを通じて,7つのチェックポイントが見えたという。講演では,同プロジェクト18日間のすべてとチェックポイントを記した別冊子を配布した。冊子に書かれていた7つのチェックポイントは,それぞれ以下の通り。

  1. サーバーOSはIPv6対応しているか?
  2. HTTPサーバーはIPv6対応しているか?
  3. SSL証明書にはv4,v6の区別は無い(ホスト名だけでよい)
  4. ロギングのIPアドレス長は十分か?
  5. (ログの解析時に必要な)IPアドレスparserは対応しているか?
  6. 端末側UNI(User Network Innterface)はIPv6に対応しているか?
  7. DNSサーバーはIPv6対応か?

 ポイントとして指摘したのは,同社はWeb開発が主体であったため,サーバー側アプリケーションのデュアル・スタック化に気を取られて意外な落とし穴にはまったこと。具体的には,アプリケーション開発者向けの端末側のIPv6対応が遅れていた。例えば,同社の社内LANがIPv6未対応だったため,ユーザーの端末からのアクセスができない状態だった。もう1つは,livedoorポータルのDNS(tcpserverとdjbdnsの組み合わせ)がIPv6対応していなかったこと。このため,代替案の用意などに1週間程度を費やした。

新たに作る分だけデュアル・スタック化しよう

 IPv6対応の難しさについて,技術面で新規サービスは問題がなく,すでにサービスを提供済みのものについては若干の注意が必要だ,という。問題なのはビジネス面で,IPv6化による収益向上は皆無であること,IPv6への投資額は大きいこと,現状では需要が薄いこと,と指摘する。これらの諸問題に対して,どう対処するのかが問われる。

 IPv6需要が少ない点について伊勢氏は,IPv6掲示板とfixdapのアクセス数を紹介した。IPv6掲示板は,サービス開始当初の2008年8月が1日あたり1万5000PV,うちIPv6経由は1500PVで10%がIPv6経由だった。それが,10月には全体のアクセス数は1万5000PVと変わらないもののIPv6経由は250PVに減り,2009年1月にはさらに全体が2万PVに対してIPv6経由は50PVになってしまった。直近の2009年2月では,2万PVに対してIPv6経由は250PVである。fixdapもアクセスは少ない。全体で2300PVに対して,IPv6経由は10PVである。「100万PV単位でモノを見ているWeb開発者にとって,この数値は存在していないのに等しい」(伊勢氏)。

 このように,Web開発者にとって,IPv6対応は現時点では何のメリットも生まない。だが,IPv4アドレスはいずれは枯渇する。では,どうすればよいのか。この現実解として伊勢氏は,すでにあるアプリケーションやすでにある設備をIPv6化するのは止めようと訴える。「新規開発や新規機器の導入/ファームウエアのアップグレードといった,機能の更新時点において,コストをかけずにIPv6/v4のデュアル・スタックにしておくことが大切」と結論付けた。スクラッチで新規開発する際に,IPv4だけに対応するのと,デュアル・スタック対応にするのとで,コストはほとんど変わらないからだ。

 一方,ネットワーク機器の購入に関しては,ベンダー選びが重要と説く。「IPv6対応のために特別なコストがかかるベンダーは,選ばない方がよい。同じ値段でデュアル・スタックが組める機器や保守サポートを選ぼう」とした。