IPv6対応への道しるべ

第16回 新データセンターの内部をまるごとIPv6化 ─サイバーエージェントに聞く

この記事を読むのに必要な時間:およそ 3 分

IPv6では「一歩踏み込んだこと」がまだできない

─⁠─IPv4アドレス在庫枯渇問題に関してですが,IPv4アドレスに関して何か苦労されていることはありますか?

グローバルIPv4アドレスに関しては,結構多めに確保してあったので,うちの中では比較的余裕があります。最近はあまり焦ってないです。どちらかというと,プライベートIPv4アドレスで苦労しています。古いデータセンターは10で切ってなかったので。

基本的にプライベートIPv4アドレスが被らないようにしていますが,子会社の中で利用しているIPv4アドレスがバッティングすることがあり,そういうときにはNATをしたり,えいやで変えてもらったりしています。そういう苦労があるので,IPv6の方がアドレス管理は楽です。

─⁠─6rdの取り組みについて教えてください。
6rdに関しては,やるかどうかがまだ決まっておらず検証段階なのですが,うちが持っているプライベートクラウドをAWSなどの商用クラウドとつないでも良いかなと考えています。そのとき,AWSはIPv4にしか対応していない一方,うちの内部ネットワークのメインはIPv6なので,そこでどうしてもトンネルが必要になってくる場合があり,その検証を進めています。
─⁠─他に,何かIPv6に関連して面白い取り組みや検討をされていますか?

次期データセンターの検討を行っているのですが,SDN(Software Defined Networking)を使ってどういったことができるのかを検討しています。

そのなかで,さまざまなメーカさんの機器を取り寄せて検証しているのですが,やはりまだまだIPv6が動かないものが多いです。IPv6で基本的なことをやる分にはそれほど問題はありませんが,そこから一歩出て複雑なことをやろうと思うとIPv6ではできないことが多いという実感です。とくにSDNのような出たての技術もIPv6機能を実装していないことが非常に多いです。

─⁠─SDNに関して非常に具体的に言うと,たとえば,OpenFlow 1.0はIPv6に対応しておらず,最近出はじめたOpenFlow 1.3対応機器である必要がある,といった話ですか?

はい。最近はちょこちょこOpenFlow 1.3に対応している機器が出てきたので,そこは何とかできるようになってきました。他にも,たとえばOpenFlow 1.0だけど,先にIPv6機能を実装していたりというのもあったので,不可能というわけではありませんでした。ただ,マルチベンダでそういったことをやっていくというのは,まだ大変だなぁという感想です。

IPv6以外にも,OpenFlowはフロー数の制限などの課題があるので,いまは別の切り口でも平行してSDNを考えています。とはいえ,OpenFlowを検証してみて,当初思ったよりも完成度が高かったことには驚きました。フロー数の上限さえどうにかなっていけば,意外と使えるという話を内部でしていました。

画像

─⁠─IPv6とは関係がなくても良いので,最近のSDNに関連する検討等の内容を教えてください。

我々は本当に新しいものが大好きなので,さまざまなメーカさんとやり取りさせていただきつつ,各種検証を行っています。日本初とか,世界初とかいうものには,本当にすぐ飛びついてしまいます。

シリコンバレー等で新しく出て来る会社はアイデアが凄く面白くて,たとえばトップオブラックのスイッチだけをSDNで置き換えてしまおうというのがあります。そういうのは非常に面白いと思いますね。ネットワーク全部を置き換えるのは難しいので,トップオブラックだけを置き換えるという考え方をしているところは多くて,それはすごく興味深いです。ただ,SDNは機器がコモディティ化していくには,まだまだ時間がかかると思います。

余談ですが,我々は米国出張に行ったりして,あちらの情報を知ることができるのですが,思いのほか向こうではOpenFlowという声が聞こえてこなくなっているのが印象的でしたね。夏ごろ行ったときには,かなりトーンダウンしていました。OpenFlowのことを話したら,⁠え?OpenFlowやるの?」ぐらいの勢いの反応をされました。使うことはあっても,一部限定された部分だけという感じでしたね。

─⁠─最後に今後のデータセンター利用設計の方向性などを教えてください。

現在都内4ヵ所にデータセンターがあるのですが,それぞれのデータセンター間の通信はL3で行っています。

これから作って行くところに関しては,L2延伸で延ばして行くということをやりたいと考えています。セグメントに関しては,L2延伸したうえでIPv6などをその上に乗せて行くことになります。

─⁠─L2延伸はVMマイグレーションなどを考慮しての設計ですか?

まだ構想段階ではありますが,いくつかのリージョンに分けて,そのリージョン内で拡張が必要になればL2延伸で延ばして,そうでなければL3でということを考えています。

何か新しいことをやりたいと思ったときに,ネットワークの要件でそれができないという状態になることを避けたいというのが主旨なので,VMの移動などが発生する環境が今すぐに必要というわけではありません。ただ,ネットワークは融通がきかないので,事前に準備しておくのは非常に大事だと思います。

延伸部分はVPLS(Virtual Private LAN Service)でという感じ対応しようと思っています。今は,米国の方ではL3でやるのが当たり前というか主流になってきてしまってますが,日本国内でのサーバ台数くらいであればL2でまだ全然大丈夫です。L3でやる方法なども各種検討しましたが,いまのところはVPLSでやることを考えています。

─⁠─ありがとうございました。

著者プロフィール

あきみち

「Geekなぺーじ」を運営するブロガー。

慶應義塾大学SFC研究所上席所員。全日本剣道連盟 情報小委員会委員。通信技術,プログラミング,ネットコミュニティ,熱帯魚などに興味を持っている。

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

Twitter IDgeekpage

インターネットってなんだろう?(てくらぼ)