読者です 読者をやめる 読者になる 読者になる

Queueベースのアーキテクチャについて

http://satoshi.blogs.com/life/2008/09/post-1.html

以下の手順で進めるのが、今のところの定石な気がします。

  • Level2分散(機能別+ID(ユーザークラスタ)別)をやって同期で処理する
  • Level2分散でもwriteの処理が追いつかなくて、かつユーザーへのレスポンスにリアルタイム性が求められない部分は非同期でQueueにいれて、writeを平準化することでDBのwrite負荷を平準化する

Queueのシステムとして、Gearman, TheShwartz, Q4Mがあると。Gearmanは落ちるからだめで、若干メッセージが失われてもよければ、daemontoolsと組み合わせて使う。信頼性をベースに考えるとTheShwartzかQ4Mになると。

TheShwartzでpollして遅延する部分があるが、Q4Mだとqueue_waitでTheShwartzよりもリアルタイム性で話ができると。また、Pathtraqでの運用実績とkazhuhookuさんがやってるからということで、mixiで採用したのはQ4Mだったと。

Queueベースのアーキテクチャの話は、kazeburoさんの話が、とてもよくまとまってますね。Queueベースのアーキテクチャについて、これ以上よくまとまったtechnical talkはみたことがないなぁと。
http://www.nicovideo.jp/watch/sm4430223

運用上のtipsとか、

も含めて、話されているのでとてもためになるなぁと。

Queueの話ではないですが、Level2分散の話として、「IdManagerでMySQLのautoincrementで、ある一定以上の同時アクセスでデッドロックする問題を解決する方法」など、運用してみないとわからない話まで触れられているので、その点も貴重ですね。

Level2分散については、Live JournalのBackendの話とか、はてな、KLabでのLVSの話もとても参考になります。ユーザー数に応じてスケールさせるにはLevel2分散まではどっちにしても必要なので、どこもやってますね。

Level2分散部分を作るまではよくても、実際に運用を低コストでまわせるようにするまでは大変だろうなぁと思います。ただ、それでも最近は内部が透けてみえるようなレベルでアーキテクチャや運用のtipsが公開されているので、本当に素晴らしい時代ですね。素晴らしい話が色んなところに散らばっているので、1回自分のためにまとめておきたいなと。