転載・引用について

ユーザ用ツール

サイト用ツール


サイドバー

Site Contents Index

転載・引用について

RSS

tweet:2015:0115_01

Facebookに書いた駄文(20150115)

Twitterでつぶやいたんだけど、こっちにも。こっちに書くのはそれはそれで怖いんだけど。

今日のJANOGで「なぜ、IPv6 対応したくないのか」というセッションがあって、そのツダリを見てて思った事。

IPv6にしたくない理由なんて、おそらく星の数ほどある。で、僕の観測範囲に限定すれば、「面倒臭い」と言えないから理由をつけてやらないと云うのが多い。(全てではない)

IPv6の最大の弱点はおそらくこの「面倒臭さ」を解消できなかった事じゃないかと。

で、面倒臭い理由が

  • 「既にv4が広がってしまい、始めるためには結局v4もやらなければならない」
  • 「v4でやれるなら両方ヤルのは工数からも運用からもコスティ」
  • 「もういいよv4だけで」と多くの「Contents作成者」が思う

じゃないかと。(全てではない)

僕らインフラ側は、もう、IPv4だろうがv6だろうがなんとかなると思うわけですよ。それだけの期間IPv6を触ってきたし、そういうインフラも作ってきたし、ここからやることは恐らくほとんどデバッグ。

でも、コンテンツ側って、恐らく僕らがIPv6ネットワークを作り始めた頃はIPv6なんて関係なかったし、IPv6って言われ始めた頃は「対応が面倒」な上に、利用者も少なかった。しかも、今よく考えてみれば、v4 or v6なんて、本質的にどうでもよくて、作成したコンテンツが「最も消費してもらえる」プラットフォームを利用したいだけでしょう。Social Game作る人ですら、ほとんどの場合HTTPプロトコルのPayloadを利用するだけで別にSocket Programmingしているわけじゃないし。

(まぁ、log分析だの何だのを考えれば色々やることはあるだろうけど、そこはコンテンツ提供という当初の目的からすれば二次的な範囲なわけで)

その上で、IPv6は実質的に「アドレス空間が広いという事」以外にIPv4に対する優位点はないわけで、それも、「今のサービスモデル」を前提にするなら、NATだのLBだのである程度逃げられるから、Protocol的な優位点はないと思うわけです。

(新しいサービスモデルを考えるという「銀の弾丸」による解決は、コンテンツ提供側から出てこない限りインフラがいくら物申しても実装されない現状を考えれば、不可能という結論に落ちざるを得ない)

そういう状況だという僕の認識の上で、「僕が」今からIPv6「も」使ってもらおうとするなら、

  1. 「ミドルウェアまで面倒見るから、そこにアプリを乗せてくれれば大丈夫」と云える(一種のPaaSのようなBaaSのような)サービス基盤作る
  2. コンテンツ制作者側に「本当に」アプリに注力してもらい、上記インフラを使ってもらう
  3. インフラの運用はコンテンツ製作者側と連動しながら自前で行う

と云う作戦を取るような気がする。

この作戦がうまく行くとは言えない(時間かかるし、そもそもそういうニーズがあるか、コストが回収できるかなどの問題がある)が、もう「銀の弾丸はない」と骨身に沁みてる人が、「小さなことからコツコツと」時間かけてゆっくりやるしかないのかな、と思っている。

僕の結論は、よほど「新規性があっ」て「今までのインフラ上ではできない」ものでない限り、インフラの根本に関する巨大な変化を要求する技術のdeploymentは「結局面倒臭い」ものだということ。

それでも、僕は、「僕の出来ることはやり続ける」つもりだけどね。

まぁ、20年近くIPv6と付き合ってきて、今だから言えることなんだけどね。

このウェブサイトはクッキーを使用しています。 Webサイトを使用することで、あなたはあなたのコンピュータにクッキーを保存することに同意します。 また、あなたはあなたが私たちのプライバシーポリシーを読んで理解したことを認めます。 同意しない場合はウェブサイトを離れてください。クッキーに関する詳細情報
tweet/2015/0115_01.txt · 最終更新: 2015/05/20 15:07 (外部編集)