今回は、
取材時点においてAAAAレコードを外部サービス用にDNSに登録していないものの、
「技術で押していく会社がIPv6で引いてどうする」
- ──御社でのIPv6への取り組みを教えてください。
新データセンターの内側はIPv6での運用になっています。ただし、
外側はまだIPv4のみです。 内側はNAT64などを利用しつつ、
IPv6とデュアルスタックで運用しています。一部、 マネジメントポートがIPv4にしか対応していないなどの理由によってIPv4のみで運用されている部分もありますが、 基本的にIPv6です。 - ──なぜ内側を全てIPv6で運用しようと思い立ったのでしょうか？
新しいデータセンターを作るときに、
IPv6に行くかどうかを社内で議論しました。そのとき、 決め手となるものがありませんでした。IPv6導入を決断する決め手ってないじゃないですか （笑）。 じゃあ、
どうするのという話になったときに、 うちの会社は技術で押して行くという方針があったので、 技術で行くと言っているのにそこを引いていてどうするのかということで、 なんとなくという部分もありましたが、 そこは決断して実行しました。 - ──技術で押して行くという方針はいつごろからでしょうか？
弊社社長が技術で行くという方針を最初に打ち出したのは、
確か2005年頃であったと思います。 IPv6に関して行くぞと決断したのは2年くらい前で、
その後、 インターネットの環境であるとか、 ファイアウォール、 ルータなどを組み合わせてIPv6に関する検証を一通り行いました。サーバもミドルウェアクラスまでは、 動くか動かないかの検証を行いました。それらを踏まえたうえで、 次のデータセンターはIPv6ベースで行こう、 という感じでした。 - ──IPv6を導入するうえで技術的にがんばったところはどういったところですか？
思ったよりもあっさりと動きました。ただ、
やはりNAT64をかける場所であったり、 RAとかでしょうかね。NAT64だけではなく、 DNS64との組み合わせも考える必要がありました。 また、
我々がIPv6を扱ったのが当時は初めてだったので、 まずは違いを認識しつつ、 IPv6はこういうものだというところをやっていきました。基本的にはIPv4とそこまで変わらなかったのですが、 IPアドレスが長いので覚えにくいとか、 そういうところがあるぐらいですね。 やはり10年以上前からの技術なので、
大手のネットワーク機器メーカさんのものはちゃんと動くということを実感しました。 - ──IPv4からIPv6へと内部環境を変更して、
何か大きな変化はありましたか？ - IPアドレスデザインが劇的に楽になりました。IPv4のときには、
結構気にしてやらないとすぐになくなってしまったのですが、 IPv6はやっぱりそこが楽だなぁと思います。 - ──IPv4での苦労というのは、
プライベートIPアドレスでも苦労しているということですか？ はい。うちも結構台数があるので苦労します。
新しいデータセンターは10/
8で使っていたのですが、 古いデータセンターは172で切ったりしていたので、 最後の方で多少足りなくなるようなことがありました。 - ──先ほどIPv6での問題としてRAの問題とおっしゃっていましたが、
それはどういった問題でしょうか？ 上位のルータが切り替わったときに、
挙動が煮え切らないことがあったのですが、 そのときにどっちのルータからのRAを受け取っているのかを調べる必要があったというのはありました。 またトップオブラックのところで、
RAガードが実装されていなくて機器選定に困ることがありました。RAガードを実装していたメーカが少なかったというのもあり、 そういった部分でRAは苦労しました。去年の11月ぐらいの話です。データセンターを構築する前に、 まずはネットワークチームで基本的なところの動作を確認しようというときに、 その辺のところでつまづいてしまいました。その後、 その問題は解決し、 今は問題なく稼働しています。 この他、
次期データセンターなどを検討するときに、 IPv6に対応していないところもまだまだ多いのですが、 現時点で弊社が稼働させている部分に関してはちゃんと動いています。 - ──今はまだ内部ネットワークのみとのことですが、
表にIPv6を出すことも近いうちにできそうなのでしょうか？ - 技術的には、
完全に準備ができています。DNSで実際にAAAAレコードを出せば動くような状態にまではしてあります。あとは、 アプリケーションレイヤでの確認が必要になるのかなと考えています。それとユーザの対応状況ですね。まわりが動けばいつでもいけるかなという感じです。
Ameba Infra Unit アーキテクト開発
グループ 篠原雅和氏
Ameba Infra Unit アーキテクト開発
グループ 髙橋哲平氏
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でやることを考えています。 - ──ありがとうございました。
