最速配信研究会

http://d.hatena.ne.jp/yamaz/20060509の続き.

初めての方は画像配信の負荷分散も比較的簡単？（その1）からどうぞ.

Googleはimages.google.com 1つで1,187,630,000(11.8億!)の画像を保持している(ように見える).1つの画像が10KBだったとしても12.5TBの画像を保持していることになる.

GoogleがこんなことができてるのはGoogleFileSystemがあるからだ.

http://labs.google.com/papers/gfs.html

GoogleFileSystemは簡単に言うとデータバックアップ機能つきの分散NFSのようなものだ.

GoogleFileSystemに関しては上記URLのPDFに詳しいので,そちらを参照してほしいが,基本的な考え方は今まで負荷分散の考え方となんら変ることはない.つまり

1. コンピュータは1つの仕事をさせるのには十分早い

2. よって戦略としては1台のサーバの仕事量を固定して,負荷が増えてもサーバを足すだけでいいようなアーキテクチャにすればいい.*1

ということでGFSでは1台が受け持つ画像容量が一定数を超えないように適度にサーバを追加してるんだろうと思う.

images.google.com <-> GFS sever群

images.google.comは結局のところGFSという巨大なバックエンドサーバに画像の問い合わせをしてるということだ.これはつまりフロントでHTTPアクセスを受けるサーバ自体は画像を保持しないということなので,(サーバさえ足せば)事実上いくらでも画像が保持できるということになる.

普通の人は当然GFSを持ってないけれど,それと類するようなものなら簡単に作れる.つまり,

1. バックエンドサーバとしてd[0..99].hatena.ne.jpのようなサーバを準備する.

2. フロントのd.hatena.ne.jpはユーザ名から問い合わせるバックエンドサーバを決定してデータを取得する(apacheのmod_proxyを改造するかURL解釈の別の部分に割って入るモジュールを作れば簡単).

3. 各バックエンドサーバが保持するデータ量が増えたらバックエンドサーバを足してまた分散させる.

4. フロントサーバは当然バックエンドサーバをかねてもいい.

実際のところ某所ではバックエンドサーバが吹っ飛んだ時点でデータがなくなるのは困るので,バックエンドサーバは実際にデータを保持しているマスタサーバのデータのプロキシキャッシュサーバとして稼動させていた.

フロントサーバ <-> バックエンドサーバ(キャッシュ) <-> マスタサーバ

こうすることによりマスタサーバにどれだけデータ量があってもバックエンドサーバ側に蓄えるキャッシュ量を適度に保つことができる.

細かいノウハウなどはかなりはしょったが,静的な画像に関しても上記なようにすることでおおむね無限にスケールできる.なので本エントリはここでいったん締めようと思う.あと1台のサーバのパフォーマンスをあげつつパフォーマンスを適度に保つ方法(というか考え方)についてはまた別エントリで述べようと思う.

(ひとまず終わり)

(コメントで質問を受けたので,もうちょっとだけ続くのじゃ)

ツイートする