LiveJournalのアーキテクチャ

先日、mixiのお話を書いた(500万倍のスケーラビリティ)が、幸いにも多くの方からブックマークをいただく。ブックマークのコメントを眺めているとmixiのアーキテクチャはkazuhookuさんとmiyagawaさんからLiveJournalと同様なアーキテクチャだとの指摘をいただく。早速Googleで検索してみた。

LiveJournal's Backend -- A history of scalling, August 2005, Brad Fitzpatrick,
4ページ目の図を見るとmod_perlやらmemcachedやらmixiのお話のとき出てきたおなじみのコンポーネントが見える。ふむふむ。ユーザが増えてくるとDBをマスター・スレーブ構成にしてマスターに書き込みそれをreplicate（複製）する。読み込みはスレーブから行なうので、スレーブを増やせば読み込みはスケールするが、マスターへの書き込みがボトルネックになる。ふむふむ。そこで、partition（分割）だ（24ページ）。分割するとジョインができなくなるが、気にしない。user idでパーティションを決定している。一つのテーブルを複数に分けているイメージである。キャッシュはmemcachedがつかさどっている。ロードバランシングにはPerlbalを利用する。分散ファイルシステムはMogileFSである。そのほかストレージ関連のTipsとしてイメージなどblob（バイナリーオブジェクト）は通常のファイルシステムに置く。RDBMSはMySQLのInnoDBで4.xを利用する。ところによってはMyISAMも使う。

memcachedというのはRDBMSのキュエリーをキャッシュする。本来ならRDBMSがやるべき仕事のような気がするがアプリケーションに特化して高速化するというのは一つの方法である。

mixiとの違いをあえて探すとmixiの場合は複数のテーブルをジョインするがLiveJournalはしない（ように見える）。そのためにmixiは複数のテーブルをジョインするためにアプリケーション側で対処している。

というようなことを、今回初めて知った無知なおじさんである。そんな無知なおじさんにもわざわざ教えてくれる元気のいい人たちがネットワークの向こう側にいる。ありがたいことである。ブログを書いて良かったなあと思う瞬間だ。

頭の固いおじさんからみれば、複数のテーブルをジョインするために、SELECT文を2回使って、それをアプリケーションで処理すると言うのは、リレーショナルデータベースの存在を否定（？）しているようなものだから、初めからそんなことはしない。そのような「常識」に凝り固まっていて到底思いつかない。memcachedみたいなものもそれはRDBMSの仕事だろう、RDBMSがキュエリーをキャッシュしないのだったらRDBMSを直せよとか思うのだが、OSSの世界ではまったく違ったレイヤーで軽やかに解決できるのなら、それでいいではないかという割りきりがある。テーブルの水平分割も垂直分割も、データベースのスケーラビリティもOracle RACでいいじゃんという発想からは到達しないアーキテクチャである。

今回のお話は本当にいろいろな意味で勉強になった。オープンソースの技術系カンファレンスは、わたしみたいな無知なおじさんを若者が教育する機会になる。それを世界中で一番必要としているのはわたしである。だから、どーにかして実現したいなあと妄想は膨らむのである。

蛇足だけど、memcachedやそれが利用しているlibeventの性能をoprofileで計測してチューニングしたいなあという遊び心がむくむくと芽生えてきている。わたしが作ったcache pollution aware patchが生きる応用かもしれないなどと思っていたりする。

Comments

[投稿： hyoshiok]

miyagawaさんのお名前を"miyagawa"と呼び捨てにしていたのを訂正しました。ごめんなさい。