【17-A-5】ウェブアーキテクチャの歴史と未来

ウェブアーキテクチャの
歴史と未来
株式会社ディー・エヌ・エー
奥一穂

自己紹介

氏名：奥一穂
所属：株式会社ディー・エヌ・エー
システム統括本部 IT基盤部

2011年2月17日ウェブアーキテクチャの歴史と未来 2

主な仕事

Palmscape
1997年～後に Xiino に改名
Palm OS 用ウェブブラウザ (実質世界初)
M.I.T. TR100/2002 受賞
オフラインコンテンツの配信プラットフォームを兼ねる
Webアプリケーション統合開発環境の開発
IPA 未踏 2004 – スーパークリエータ


主な仕事 (2)

前職: サイボウズ・ラボ株式会社
Japanize
Web UI の日本語化サービス
パストラック
リアルタイムアクセス解析／データマイニングサービス
Q4M
メッセージキュー (MySQLの拡張)


アジェンダ

ウェブアーキテクチャについて
ウェブの何が新しかったか、および成功した理由
技術トレンドの推移と今後について
個人的経験をベースに語ります
※会社を代表した意見ではありません


Palmscape とは?

Palm OS用ウェブブラウザ
1997年8月公開
後に Xiino に改名


Palmscape – 当初の動作環境

PalmPilot Pro
CPU: 68328 @ 16MHz
初代NeXTの1/3程度の速度
160x160ドットのJPEGデコードに3秒
ワークメモリ: 10KB強 (TCP/IPスタックロード時)
スクラッチメモリ: 最大約900KB


Palmscape – 当時のネット回線

1990年代末のインターネット
アナログモデム (〜56Kbps) or ISDN (128K)
テレホーダイ
1990年代末のモバイルインターネット
赤外線公衆電話 (64Kbps)
PHSモデム (32Kbps)
PDCモデム (9.6Kbps)
アナログモデム (〜10Kbps)


Palmscape – Palm 向けの最適化

HTMLをレンダリング用VM命令にコンパイ
ル
vs. DOMツリー生成
画像を中間サーバでフォーマット変換
JPEGより軽いフォーマットへ
端末画面のサイズにあわせる
送信タイミングをHTMLより遅らせる


Palmscape – 中間サーバによる最適化例
HTTP/1.0 200 OK
...

<HTML>
...
<UL CLASS="rectangle">
<LI><A HREF="/recruit/"><IMG SRC="/images/top/bnr/recruit.jpg" ALT="採
用情報" WIDTH="164" HEIGHT="38" EBDWIDTH="82" EBDHEIGHT="19" EBD="#1">
</A></LI>
<LI><A HREF="http://developer.dena.jp/mbga/" TARGET="_blank"><IMG
SRC="/images/top/bnr/devsite.jpg" ALT="DeNA デベロッパーサイトモバゲーオープ
ンプラットフォーム" WIDTH="164" HEIGHT="38" EBDWIDTH="82" EBDHEIGHT="19"
EBD="#2"></A></LI>
...
</BODY>
</HTML><EBDIMAGE MODE="9" NAME="1"><!--6EsZ6Evd6Esy/Czs7TIsEt9XGRNE3+
0Z7TLtEzIsKxntMu0s7RlXE+koGegAPu5qAOw/AOwsAMruPu5q7hkAVwA+7lcZV+5EAOZ

15年間でのモバイル端末の進化

概ね1,000倍
CPU: CISC @ 16MHz ⇒ RISC 〜1GHz
メモリ: 数MB ⇒ GBオーダー
回線: 〜32Kbps ⇒ 〜21Mbps
cf. ムーアの法則
半導体集積度は18ヶ月〜24ヶ月で倍増


ウェブの時代は続く

HTTP/1.1 全盛
消滅したプロトコル: gopher, nntp
ウェブメールだと不要: pop3, imap
HTTP 上に定義される新プロトコル: REST, WebDAV
HTTPng の中止
HTML の時代は続く
HTML 5 (vs. Flash)
XHTML 2 の廃案
WAP? (笑)

Q. なぜウェブなのか?


ウェブ以前のプロトコル

プロトコルとアプリケーションが結合
メール: SMTP/POP3/IMAP4
ネットニュース: NNTP
ファイル転送: FTP
Gopher: ファイル検索
…


ウェブのプロトコルはアプリケーション中立

HTTP – 「リソース」の転送プロトコル
「リソース」が何かは規定しない
cf. Representational State Transfer (REST)
HTML – ハイパーテキスト言語
何を記述するものかは規定しない
⇩
通信プロトコルやマークアップ言語の変化を
待たずに、アプリケーションが進化可能

Q. 「より良い」プロトコルが普及しないのは、
どうして?


HTTP/1.x は（実は)効率的なプロトコル

HTTP はテキスト+バイナリ混在プロトコル
ヘッダは可読性の高いテキスト
コンテンツは CPU 負荷の低いバイナリ
ただしバイナリ長をテキストで表現
Content-Length, chunked エンコーディングのバイト数
cf. SMTP は古典的テキストプロトコル
メッセージの終わりは CR LF . CR LF を探索して検出

仕様が明確で実装が容易かつ普及してい
るため、新しいプロトコルの提案は困難
専用プロトコルの衰退

進化を続ける HTML

「ウェブ前」を彷彿とさせるタグは非推奨に
<DIR>, <ISINDEX>, <LISTING>, …
インタラクティブ性
Dynamic HTML (DOM操作), XHR
構造と体裁（デザイン）の分離
CSS
そして HTML 5 へ


ここまでのまとめ

なぜ「ウェブの時代」なのか
HTTP + HTML = アプリケーション中立な基盤技術
可読性・互換性と効率性を兼ね備えた HTTP
進化を続ける HTML


ウェブ技術の変遷


ウェブ技術の変遷

「ウェブ技術」のトレンドは4期に分類可能
マスコミ期 (Yahoo! 等)
ブログ期 (livedoor blog 等)
ソーシャル期 (Mixi 等)
リアルタイム期 (Twitter 等)
時期毎に注目技術が変化
今はソーシャルとリアルタイムの中間あたり?


マスコミ期

代表サイト例: Yahoo!
機能: 多数の読者に同一の情報を配信
静的配信が基本の時代
コア技術:
httpd
一部差替 (テンプレート, Edge-side Includes)
技術指標:
httpd の同時接続数・バンド幅


マスコミ期 (2)

Better FTP + Gopher としての利用
パフォーマンスに劣るものの、静的ファイルの配信な
ら ftp + HTML でも実現…できなくは…ない
当時のトピック:
SIMTEL20 (cdrom.com 等) の転送量が 417GB/日
を記録 – 1998年7月
ファイルアーカイブの運用は、今でも興味深い話題
cf. ftp-admin.blogspot.com
スケールアップの生きた教科書
アクセスの多いファイルを移動平均で抽出してSSDに載せる等


ブログ期

代表サイト例:
アメーバブログ, livedoor blog, はてなダイアリー, …
画像や動画共有サイトも: Flickr, YouTube, …
機能: エンドユーザーが不特定多数に発信
変化:
ウェブ経由での入力
「アプリケーションサービス」の時代
ホームページ作成ソフト ⇒ ブログサービスへの移行
データセットの増大

ブログ期 (2)

コア技術:
オープンソース RDBMS
大量のデータを構造化して管理 (≠集計)
over HTTP な分散ファイルシステム
mogilefs 等
memcached
RDBMS に入れづらい「ホット」（高頻度にアクセスされる
データ）をキャッシュ
シャーディング (水平分散)
一定数のユーザ毎に異なるデータストアを利用


ブログ期 (3) – キャッシュのデータ一貫性問題

RDB とキャッシュのデータ一貫性維持が難
しい
そもそもキャッシュを使う理由は RDB の同時接続数
あるいは qps の上限が低いから
HandlerSocket plugin for MySQL (or mycached)
は両者の問題を解決
⇩
キャッシュ不要

※よりアプリケーションよりの非正規化されたキャッシュが必要な場合は別途検討が必要


ソーシャル期

代表サイト例:
GREE, Mixi, モバゲータウン
「ソーシャル」なウェブサイト
Twitter, ソーシャルゲーム系
より高頻度な更新

コア技術: フォロワーへの通知の捌き方


ソーシャル期 (2)

ブログとの違い:
書き込みが、より高頻度（特に Twitter やゲーム)
フォロワーへの通知が必要
書き込みコストはフォロワー数に依存
大規模環境（シャーディング）では、複数台のデータベース
への書込が必要
耐障害性とレイテンシの２点が問題となる
⇩
非同期書込 (ACID から BASE へ)


ソーシャル期 (3) - 非同期書込の実現手法

2種類のモデル
RDB + メッセージキュー + ワーカー
Mixi, DeNA, livedoor 等では MQ として Q4M を利用
メリット: 柔軟、複雑な処理が可能
デメリット: 要プログラミング
ワーカーを自動生成する手法も (cf. Incline)
非同期書込機能つき分散ストレージを使用
Cassandra 等
メリット: 処理の定義が簡単
デメリット: チューニング困難、複雑な処理ができない
MQ + ワーカーモデルとの併用が必要になるケースも

ソーシャル期 (4) – 図 (MQ + Worker)

Queue
Appサーバ Worker

DB
httpd Appサーバ

DB
Appサーバ


ソーシャル期 (5) – 図 (分散ストレージ)

(Queue)
Appサーバ (Worker)

(KVS)
httpd Appサーバ

(KVS)
Appサーバ
BASE 対応分散ストレージ


ソーシャル期 (6) – 最適化手法

専用サーバによる高速化
cf. Mixi の足あと機能における検討例
http://alpha.mixi.co.jp/blog/?p=185

読み込み時にフォロワーリストで絞り込む
方法 (Pull型)
MySQL におけるフォロワーリストの処理手法
http://labs.cybozu.co.jp/blog/kazuho/archives/2008/06/
mysql_direct_access.php


リアルタイム期

代表サイト例:
Twitter (Streaming), Facebook
(PC / スマートフォンの) ソーシャルゲーム
機能: 準リアルタイムコミュニケーション
PCやスマートフォンでは Comet (long-poll) が可能
一部のブラウザでは WebSockets が利用可能


リアルタイム期 (2)

いくつかのプログラミングモデルが存在
suspend & resume (Jetty Continuations, …)
suspend & push (cometd, nginx, …)
独自 httpd サーバ (イベントドリブン)
アプリロジック的には非同期書込の一種
ストレージ意外に他のクライアントへも書込
実装の選択肢は以下の２つ:
メッセージキュー + ワーカーモデル
httpd への通知プッシュ機能つき分散ストレージ
もしリリースされれば

リアルタイム期 (3) – 図

Queue
Appサーバ Worker

DB
httpd Appサーバ

DB
Appサーバ


リアルタイム期 (4) – 別解

Long polling の使用範囲が限定できるなら、
独自サーバで頑張るのも良い選択
スクリプト言語で実装しても問題ないレベル
数千クライアント程度の同時接続ならハンドリング可
能
http://labs.cybozu.co.jp/blog/kazuho/archives/2008/03/
fastr.php


まとめ

HTTP + HTML の時代は続く
ウェブの進化とともに書き込みが増加
非同期書込が重要に
キュー + ワーカーモデルの普及
RDB と NoSQL はパッケージングの違い
やっていることは同じ
自社の技術スキルとストレージソフトウェアの実装を
天秤にかけた選択をすべき


まとめ (2)

古いトレンド技術の変化をふりかえるべき
過去の事例から学べることはないか
同分野の最新の手法は何か


ありがとうございました

いっしょにウェブ技術の未来を切り拓いて
いきましょう


【17-A-5】ウェブアーキテクチャの歴史と未来

More Related Content

Viewers also liked

Similar to 【17-A-5】ウェブアーキテクチャの歴史と未来

More from Developers Summit

【17-A-5】ウェブアーキテクチャの歴史と未来