画像配信の負荷分散も比較的簡単？（その2）

http://d.hatena.ne.jp/yamaz/20060426

の続き.待ち行列理論に従うと遅延のないサービスを行うためには

サーバの単位時間のリクエスト処理能力 > ユーザの単位時間のリクエスト数

という非常に単純なことを行えばいいことになる.「なにをあたりまえのことを...」と思われるかもしれないがもうちょっと付き合っていただきたい.

ところでたいていのBlogや画像サービスのサービスURLはこうなってる.

http://ホスト名/<ユーザ名>/
http://ホスト名/id?ユーザ名
http://ホスト名/ディレクトリ名/コンテンツ名

例で言うと下記のような感じだ.

http://d.hatena.ne.jp/yamaz/
http://mixi.jp/show_friend.pl?id=128497
http://i.yimg.jp/images/search/head_050825.gif

これをみるとd.hatena.ne.jpのサーバは全部のコンテンツを参照できる必要があることがわかると思う.サービス初期のころ,はてなもmixiも結構遅かった.

それはこんな理由によるものだと思われる.


1. サービス開始時

サーバが1台しかなく,単純に全部のデータを持ってればよかった(開発者曰く,幸せだった時代).


2. アクセスが増えてきて遅くなってきた.

サーバの単位時間のリクエスト処理能力 > ユーザの単位時間のリクエスト数

を維持するためにサーバを複数台体制にして,個々のサーバのもつデータの同期をとる仕組み(DBならリプリケーション)を導入した.これでサーバを足せば足すほどアクセスに耐えられるようになった.


3. ユーザが増えてきて各サーバが保持するデータ量(記事数や画像数)が増えてきた.

これに伴い,ハードディスクのアクセスがネックになってきた.最近のモダンなOSはメモリにファイルキャッシュを持つので,これがあふれ出すと常にHDDにアクセスすることになり,非常に遅くなる. 上記の状態になると体感速度で100倍以上遅くなる.これはメモリとHDDの速度差が100倍以上あることを考えると当然だ.こうなるとサーバをいくら足してもダメで(100倍サーバを足せば何とかなるけど),メモリを積むのが正解となる.ここでも大事なのは

サーバの単位時間のリクエスト処理能力 > ユーザの単位時間のリクエスト数

になるようにすることである.

なお30万個ぐらいの静的ファイルを配信するサーバーの選び方では10kbの画像が30万個ということだったので,全部のコンテンツ総量は3GByteになる.ただこのコンテンツ全部が常に参照されていたわけではないはずだ.実際のところは2:8の法則(2割のコンテンツが8割のアクセスを占めるという経験則)により,2Gのメモリがあれば十分であったと思われる.


4. さらにアクセス数と保持データ量が増えてきた.

通常この手のサービスはIAサーバ+LinuxなどのUnixクローンで安く動かしているが,通常は4G程度までしかメモリはつめない.また実際4G以上メモリが積めても32bitOSの関係上ディスクキャッシュとして使えるメモリ量は4Gまでで,アクティブなコンテンツ量がそれ以上になるとHDDにアクセスがいってしまい遅くなってしまう.ここで性能のいいマシンに入れ替えるという選択肢が出てくるが,10倍速くメモリも積めるマシンのお値段は普通のマシンの10倍以上するし,ユーザやコンテンツの数が10倍になったらまた遅くなるので性能のいいマシンにリプレースしていくのも(金銭的な意味で)限界が出てくる.

この時点でたいていのBlogサービスや画像アップローダのユーザからは「11時ごろからまったく使えなくなる.なんとかしろ!」コールが出てくる.


ただ上記の理由でサーバを足しても焼け石に水なので,根本的なアーキテクチャを変える必要がでてくる.

(つづく)