最速配信研究会 このページをアンテナに追加 RSSフィード Twitter

2006-06-22 画像配信の負荷分散も比較的簡単?(その5) このエントリーを含むブックマーク このエントリーのブックマークコメント

画像配信の負荷分散も比較的簡単?(その4) のつづき.

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


画像配信の負荷分散も比較的簡単?(その3)にて下記のようなコメントをいただいた.

アクセスが特定の画像に集中した場合には問題が出ると思うのですが

どのように対応したらよろしいでしょうか?

例えばある画像が1枚某ブログにウプされて

2ちゃんのいろんなスレに画像への直リンクURLが貼り付けられて祭りになり

1台の画像鯖に負荷が集中しさばききれなくなった場合、

先生の方法ではいくら鯖を増設しても負荷は分散されないし

アクセスが集中している画像鯖だけ別にDNATやmod_proxy+mod_rewriteとかその他の方法との併用で

負荷分散はできますけど祭りが起きるたびに毎回毎回特定鯖だけネットワークに手を加えるのも

めんどくさいと思うのですがこの辺はどのようにしているのでしょうか?』

当時担当していた画像配信サーバは1日に数10億程度のHTTPアクセスをさばいてた.

また9/11のテロ以来,突発的な事件に対して真に対応できるメディア→インターネット

というコンセンサスができつつあって,「落ちる」はもとより「アクセスが遅い」

ということすら社会的に許されなくなっていた.加えて


「どんな事情があってもダウン及びユーザへの迷惑は許さん.金はいくらかけても

いいから言い訳無用で画像サーバは死守せよ.でもAkamaiは禁止ね(w」


という社長の命により,サーバは平時ピーク時の2倍以上のアクセスがきても耐えられる台数を

投入していた(台数はナイショ).なのでどんな祭りも日常の誤差範囲内のアクセスで収まり,

特に上記のコメントに対する対策は何もしていなかったというのがその答えになる. 

(おしまい).

..

..

..

..

..

..

では全く答えになってないと思われるので,もうちょっとまじめに答えることにする(ゴメンナサイ).

さて本題に入る前に祭りがおきてアクセスが不能になる状態というのがどういう状態なのかを考えてみよう.

今までのエントリで何度何度も書いているが,

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

を保つというのがとても大事であることを思い出していただきたい.実際のところユーザのリクエスト数が

サーバの処理能力のたった0.01%しか超えていなかったとしても「*その状態が定常的に続くのならば*

待ち行列がどんどんたまる形になり,最終的にはレスポンスは極端に悪くなる.

どうもこのあたりが感覚的に理解されていないようで,


「サーバから返事が返ってくるのに10倍かかるようになった」

→「えぇっ!?サーバのパワーを10倍にしなきゃダメなの???」


ということは全くない.繰り返すが


ユーザのリクエストがマシンの性能に対して0.01%でも

上回ればそれが定常的に続く限りはサーバのレスポンスは限りなく遅くなる.」


ということなのだ.なので実際のところ定常的に一定アクセスをうけているところならばパフォーマンスを

2,3割アップさせれば対策として十分というケースも少なくない.しつこいようだが,

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

を維持するというのがとても重要で,上記状態を「*定常的に*」維持する限りはレスポンスタイムは

一定になるということをくれぐれも忘れないでいただきたい.

また2,3割のパワーアップ程度ならばOSやhttpdのチューニングで十分対応できる.私はFreeBSDしか

詳しくないが,素のFreeBSD+apacheならパラメータチューニングでパフォーマンスは2倍程度は軽く

あがるので検討してみたらいいと思う(パフォーマンスチューニングに関しては話がこれまた長くなるので割愛).


「うちはチューニングはもう既にカリカリにやっててもうパフォーマンスが上がる余地はない.

こういうケースはどうすればいいのか?」


という意見もあるだろう(質問者のほんとに知りたいことはこれだろう)。

これに関してももちろん方法はある.

(つづく)