今回はコーディングからはちょっと外野の立場からプログラマの皆さんに、Webサービスの基盤ともいえるインターネットの暗い未来:-)についてお話をさせていただければと思います。
いま、インターネットは大きな岐路に立っているといわれています。その1つは下位レイヤの人たち、特にネットワークエンジニアの人たちの間では長らくいわれていた「IPv4アドレスの枯渇」です。
いよいよ具体的な枯渇時期も明確になってきており、最短であと2年程度でIPv4アドレスの在庫は払底し、新規にアドレスを取得することができなくなる可能性が高まっています。
サービスを提供する側から見ると、IPv4枯渇によってグローバルIPアドレスを得ることができなければ、新しいサービスを提供する場所が失われることになります。
あなたが育てたWebサービスは生き残れますか?
一方、サービスを利用する側では、これらアドレスの枯渇を少しでも遅らせるために、ISPによるNAT(Carrier Grade Nat)の導入が現実的に検討されています。
これはISPからユーザーに割り当てる動的アドレスを、現在のグローバルアドレスからプライベートアドレスに変更し、少数のグローバルアドレスを多数のユーザーで共有するもので、自宅ブロードバンドルータと併せて多段NATを構成します。
CGN導入の大きな影響としては、1人当たり利用できるセッション数が限られるためAjax技術を利用し大量にセッションを使うリッチコンテンツは壊滅的な影響を受けること、多段NATの導入によりUPnPなど現在普及しているNAT越え技術の多くが使えなくなること、IPアドレスベースの認証や制限が効果を失うことが挙げられます。
これら枯渇による問題点を根本的に回避する最も現実的な解として、IPv6環境の導入が挙げられています。
しかし、仮にIPv6に移行するとして、いまあるネットワーク機器、サーバOS、開発言語やそのライブラリでちゃんとIPv6環境でサービスが動くのか、あと2年そこそこで運用実績、ノウハウが蓄積できるのか。難しい現実を待ったなしで突き付けられているのです。
他方、Googleなどリッチコンテンツ提供者の一部ではすでにサービスのIPv6対応化が急速に進んでおり、ISPではアドレス運用コストが高く将来性のないIPv4についてネガティブプレミアムを価格に上乗せする可能性が出てきています。これらの要因によりIPv6については意外と普及の展開が早いのではないかという観測も一部で出ています。
あなたが育てたWebサービスは生き残れますか?
関連リンク: | |
「インターネットの円滑なIPv6移行に関する調査研究会」報告書 http://www.soumu.go.jp/s-news/2008/080617_2.html |
|
IPv4アドレスの在庫枯渇に関して http://www.nic.ad.jp/ja/ip/ipv4pool/ |
|
JANOG22セッション「IPv4アドレス販売終了のお知らせ?〜ISPによるNATで起きること〜」 http://www.janog.gr.jp/meeting/janog22/program/day1/day1-5.html |
|
JANOG22セッション「IPv4枯渇、あなたがお使いのWebサービスは生き残れますか?」 http://www.janog.gr.jp/meeting/janog22/program/day2/day2-5.html |
インターネット崩壊
2つ目の岐路は、現在使われているインターネットについて、確実に崩壊に向かっているのではないかという議論です。
1つはJANOG22(JApan Network Operators' Group:日本ネットワーク・オペレーターズ・グループ主催のイベント)で議論された、運用上の破綻に起因する崩壊です。
インターネットは元来個別のネットワークの相互接続によって誕生した集合体であり、個々のネットワークはちゃんと管理されていることが前提でした。しかし、現在は基幹分散DBであるDNSも含めて個々のネットワークが適切なレベルで管理されておらず、「信頼性の基盤であったはずの自律協調が機能していないのではないか。これら信頼性幻想の『インフラ』の上に社会基盤を築いていいのか。『不完全なインターネット』をより良く運用するにはどうすればいいのか」が議論されました。
一方、インターネットは急激な発展の中で、その場しのぎの機能拡張を繰り返し、その結果プロトコル間の不整合や複数レイヤでの機能重複など複雑になり過ぎ、アークテクチャの側面からすでに破綻しているという議論がAKARIプロジェクトなど学術系の研究者を中心に始まっており、早ければ 2015〜2020年ごろにはいまとは全く異なるNwGN(New Generation Network)への移行が始まるとされています。
インターネットの屋台骨にかかわる議論、上位レイヤ、下位レイヤを問わず幅広く建設的な意見の集約のため、皆さんの積極的な参画がきっと必要です。
関連リンク: | |
JANOG22セッション「インターネット崩壊」 http://www.janog.gr.jp/meeting/janog22/program/day1/day1-4.html |
|
AKARIアーキテクチャ設計プロジェクト http://akari-project.nict.go.jp/ |
インターネットは地球を滅ぼす?
3つ目は熱に関する議論です。
近年Perl、Ruby、PHP、Pythonなどに代表される軽量言語の台頭など開発環境の進歩によりリッチなWebアプリケーションを気軽に開発できる環境が普及してきました。また、サーバマシンの能力の急激な向上によりリソースの制約をあまり意識しないプログラミングが可能となりました。
これらはWebサービスの爆発的な発展をもたらす一方で大量のリソースを消費し始めています。端的には消費電量の増大とそれによる排熱の急激な増加として表れてきています。
アプリケーションのパフォーマンスをたたき出すために大量のリソースが要求され、それを実現するためにサーバがどんどん増設されて多量の電気を消費し、CPUの発熱量とサーバの台数の積で排熱が発生する、そしてその排熱は行き場を求めてマシン内を、データセンターを、そして地球を熱し続けています。一時的にはサーバ仮想化で一息つくものの、仮想化の普及後は再度増大に向かうでしょう。
これからは、コンテンツはリッチに、リソースはチープに、そんな省電力のためのプログラミング技法やフレームワークが現れてくるのではないでしょうか。
直接省エネルギーにつながるというわけでもないようですが、Code Golfという一風変わったプログラム競作がここ最近盛り上がっているようです。2008年8月末に開催されるイベント「LL Future」でもセッションの1つとして熱戦が繰り広げられる予定です。ご期待ください。
レイヤ間断絶
これら3つの議論に触れ、本来あるべきレイヤ間のコミュニケーションの欠落が問題を大きくしているのではないか、と感じた人は多かったようです。
しばらく前までは、機器の設置からネットワーク、アプリケーションまで分かる人がそれぞれの現場でアーキテクトとして君臨して、設計から運用までやっていたように思います。
それがインターネット利用の発展やサービスの拡大とともに、レイヤ別の分業が進み、ある時点からお互いが見えなくなってきたのではないでしょうか。
最近の若いWebエンジニアと話をする機会がありますが、そもそもネットワーク屋さんの存在を知らない、まさに蛇口をひねれば水が出るごとくネットワークにはつながる。そんな感覚のようです。これはJANOGメンバーには衝撃的な事実だったようです。
意識していない、じゃなくて、そもそもいることを知らない。ネットワークエンジニアからは血の涙。一方でネットワーク屋さんもWeb屋さんやサーバ屋さんのやっていることややりたいことを知らない側面もあるようです。
相互のコミュニケーション不在がインターネットアーキテクチャの複雑化をはじめいろいろな問題に拍車を掛けているのではないでしょうか。いろいろな方面で話を聞くにつれ、レイヤ間だけではなくいろいろな軸で断絶が発生している話を伺いました。まさに断絶が各所で発生。
では、そんな断絶を解消してみよう
今年6年目を迎える LLカンファレンスももともと言語間の断絶を解消するために、各言語コミュニティの有志や日本UNIXユーザ会(jus)のメンバーで作り上げてきたもので、国内でのLLの普及や地位向上に微力ながら貢献できてきたのではないかと考えています。
では、言語間の断絶解消の次は、上位レイヤと下位レイヤの断絶解消です。jusのメンバーやJANOGのメンバーと「チーム断絶」を立ち上げ、第1弾としてJANOG22でやってみたのが上でも触れたこれらの「レイヤ間交流」セッションでした。
JANOG22参加者のアンケートではいずれも好評で、「良かったプログラム」上位3つを占める結果となりました。また今後もJANOGとほかのレイヤのコミュニティとの交流は重要となってくるというコメントも多くいただきました。次回以降も上位レイヤを意識したセッションがいくつか用意されていくでしょう。またネットワークにおける運用と研究の交流も始まっています。
下位レイヤはすでにのっぴきならない状態を覚悟している現実があります。これらの問題点や解決のアイデアを、レイヤを超えて共有し、議論する場がどんどん重要になっていくでしょう。
2008年11月に開催されるInternet Week 2008においても「レイヤ間交流」を大きなテーマの1つとして捉え、上位レイヤをターゲットにしたセッションが検討されています。プログラマのみなさんにも是非積極的にご参加いただければと思います。
今回この記事を読んだ結果、頭の片隅でIPv6やアーキテクチャ、排熱のことなど、ほかのレイヤのことをなんとなく意識しながらコーディングをしていただければ幸いです。
それがきっと自分にとって1つの大きなコーディング。ということで筆をおかせていただきます。ありがとうございました。
Coding Edgeフォーラム トップページ |
Coding Edgeお勧め記事 |
いまさらアルゴリズムを学ぶ意味 コーディングに役立つ! アルゴリズムの基本(1) コンピュータに「3の倍数と3の付く数字」を判断させるにはどうしたらいいか。発想力を鍛えよう |
|
Zope 3の魅力に迫る Zope 3とは何ぞや?(1) Pythonで書かれたWebアプリケーションフレームワーク「Zope 3」。ほかのソフトウェアとは一体何が違っているのか? |
|
貧弱環境プログラミングのススメ 柴田 淳のコーディング天国 高性能なIT機器に囲まれた環境でコンピュータの動作原理に触れることは可能だろうか。貧弱なPC上にビットマップの直線をどうやって引く? |
|
Haskellプログラミングの楽しみ方 のんびりHaskell(1) 関数型言語に分類されるHaskell。C言語などの手続き型言語とまったく異なるプログラミングの世界に踏み出してみよう |
|
ちょっと変わったLisp入門 Gaucheでメタプログラミング(1) Lispの一種であるScheme。いくつかある処理系の中でも気軽にスクリプトを書けるGaucheでLispの世界を体験してみよう |
|
- プログラムの実行はどのようにして行われるのか、Linuxカーネルのコードから探る (2017/7/20)
C言語の「Hello World!」プログラムで使われる、「printf()」「main()」関数の中身を、デバッガによる解析と逆アセンブル、ソースコード読解などのさまざまな側面から探る連載。最終回は、Linuxカーネルの中では、プログラムの起動時にはどのような処理が行われているのかを探る - エンジニアならC言語プログラムの終わりに呼び出されるexit()の中身分かってますよね? (2017/7/13)
C言語の「Hello World!」プログラムで使われる、「printf()」「main()」関数の中身を、デバッガによる解析と逆アセンブル、ソースコード読解などのさまざまな側面から探る連載。今回は、プログラムの終わりに呼び出されるexit()の中身を探る - VBAにおけるFileDialog操作の基本&ドライブの空き容量、ファイルのサイズやタイムスタンプの取得方法 (2017/7/10)
指定したドライブの空き容量、ファイルのタイムスタンプや属性を取得する方法、FileDialog/エクスプローラー操作の基本を紹介します - さらば残業! 面倒くさいエクセル業務を楽にする「Excel VBA」とは (2017/7/6)
日頃発生する“面倒くさい業務”。簡単なプログラミングで効率化できる可能性がある。本稿では、業務で使うことが多い「Microsoft Excel」で使えるVBAを紹介する。※ショートカットキー、アクセスキーの解説あり
|
|