画像配信の負荷分散も比較的簡単?(その6)

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


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


さて前置きが長くなったが,本題に入ろう.

アクセスが特定の画像に集中した場合には問題が出ると思うのですが
どのように対応したらよろしいでしょうか?
例えばある画像が1枚某ブログにウプされて
2ちゃんのいろんなスレに画像への直リンクURLが貼り付けられて祭りになり
1台の画像鯖に負荷が集中しさばききれなくなった場合、
先生の方法ではいくら鯖を増設しても負荷は分散されないし
アクセスが集中している画像鯖だけ別にDNATやmod_proxy+mod_rewriteとかその他の方法との併用で
負荷分散はできますけど祭りが起きるたびに毎回毎回特定鯖だけネットワークに手を加えるのも
めんどくさいと思うのですがこの辺はどのようにしているのでしょうか?』

特定の画像のアクセスが多くなって遅くなるケースだが,

img1(アクセス普通)
img2(アクセス集中)
img3(アクセス普通)

という状態だと思われる.これの解決方法は単純でimg2のパワーを上げればいい.具体的には高負荷やトラブル時用のスタンバイサーバを準備しておいてDNSラウンドロビンでimg2にもう一台割り当てればいい.

前回のエントリでも述べたとおり,祭で起きるアクセス増は数%程度のサーバのパワーアップで対応できるケースが多いので、たいていは1,2台のスタンバイ機で十分である.

監視プログラムなど負荷を見て動的に上記のことをするような仕組みを作れば突発的な祭りにも十分対応できる.


「え?img2に動的に足すとか軽く言うけど,どのサーバにも画像ファイルが
万単位であってコピーしてからじゃないと投入できないんだけど?」


という人はたぶんいるだろう.これに関してはapacheのmod_proxy/mod_rewriteを利用したリバースプロキシを使えばよい.

リバースプロキシは

  1. キャッシュデータが手元にあったらそれを配信
  2. キャッシュが手元になければオリジナルサーバからデータをコピーして配信

という特徴があり,コンテンツのコピーを事前に行う必要はないので,
いきなりサーバを投入できる.

なおこの手段はDBからデータを取得するサービスには使えない.
DB系のサービスは全DBを手元に持っておかないとデータの一貫性が
保てないため,「データが手元にないときはオリジナルからデータを
とってきて配信」を実現するためにはもっと複雑なことをする必要が
あるからだ.

本エントリの「画像配信の負荷分散も比較的簡単」というのは
実際のところ

  1. 一回アップされたら基本的に変更は少ない.
  2. データ追加による他のデータへの影響はない

(DBなどはレコードが追加されたらcount(*)の結果が変わるなどの影響がある)

という静的ファイル配信の特徴とリバースプロキシの「設定が終わればいきなり投入OK」
という特性に負うところが大きいので,何にでも適用できるものではないことは心にとめて
おいていただきたい.


また全体を通してはあまり突飛なことはしておらず,読めば「なぁんだ.それだけ?」
と思った人もいると思う.全くその通りなのだが,今まで書いてきた「考え方」について
知らない人があまりに多く「サーバの大量投入」という人と地球に優しくない力業で
逃げるというケースが多いという話を聞き,本エントリ群を表に出してみた次第である.

わかっている方々におかれては生暖かく見つめていただいて,そうじゃなかった方々には
本エントリを参考に人と地球に優しい感じになってくれれば幸いである.

(おしまい)