ちょっと硬派なコンピュータフリークのBlogです。

カスタム検索

2008-05-28

勝手に図解するmemcached

先日、Brian Akerとミクシィの前坂氏によるmemcachedのセミナーがあった。

実践で使用する上での話や開発最前線の話が聴けたため、セミナーは非常に盛況であった。筆者にとっても非常に勉強になる内容だった。セミナーの資料はBrian Aker氏のサイトから入手できるのでセミナーに参加出来なかったひとはこの資料を読んで自習して頂きたい。

が、いかんせん氏のスライドはパッと見ただけではなんとなく分かりづらいように俺は思う。なぜだろうか?それはきっと図がないからだ・・・と勝手に想像する。オトコたるもの、時には勝手な憶測で突き進むのもアリだ。ちなみにBrianのスライドはほとんど要点の箇条書きになっている。これでは解説がないと、特に新規にmemcachedやMySQLを学習している人たちには分かりづらいだろう。

というわけで氏に代わり、memcachedがどのように既存の仕組みを置き換えるかについて絵を描いてみたので以下に紹介する。(余談だがMySQL ClusterのStewert Smith氏はパラパラ漫画のようなスライドを描く。Brian氏のプレゼントはまったく毛色が違う。ギークという人種は本当に個性豊かだ。)

まずはマスター/スレーブレプリケーションを用いた負荷分散をするシステムの構成図だ。このような構成のシステムはカオスだ、とBrianは述べている。


このシステムがやっていることはこうだ。
  1. 全ての更新をマスターへ行う
  2. 複数のスレーブへレプリケーションによりデータをコピーする(レプリケーションはMySQLにおいてデフォルトで使える機能である。)
  3. 読み込みを任意のスレーブから行うことで負荷分散する。
このシステムはそれなりにうまく動くので、実はこれまでかなりの実績がある。(具体的には過去にYahoo! Financeなどがこの方式を採用していた。詳細は実践ハイパフォーマンスMySQLを見て欲しい。Yahoo!の人が書いた本である。)

ただしこの方式にはいくつか問題もある。例えば、
  • 負荷が高い時などにはスレーブがマスターから遅れることがある。(レプリケーションは非同期だからだ。)
  • スレーブでもマスターと同じ更新作業を行うため、それなりに良いハードウェアが必要になる。
  • マスターのデータに対するほぼ完全な複製であるため、メモリやディスクの使用効率が悪い。(同じデータをディスクへ格納し、メモリ上へキャッシュを行う。)
  • マスターがクラッシュした時や、スレーブにおいて不整合が起きた時の復旧が大変だ。
などである。

というわけで、システムへの投資や運用が大変であった。memcachedを使えばこのような問題を解消した上で、さらにスケールアップが可能となる。memcachedを利用するとシステムの構成は例えば以下のようになる。

このシステムの処理の流れは次のようになる。
  1. 更新をデータベースへ行う。
  2. 読み込み時には最初にキャッシュへ問い合わせを行う。
  3. キャッシュにエントリがなければデータベースへ問い合わせを行う。
  4. 問い合わせた結果をキャッシュする。
当然のことながら、キャッシュへの問い合わせやキャッシュミスの処理など、アプリケーション側でのロジックの変更が必要となる。例えばブログのエントリなどでは更新後すぐにデータが必要となるので、更新と同時にその内容をキャッシュしても良い。MySQLとmemcachedを組み合わせると「更新後にその内容をキャッシュする」という処理が自動化出来る。その様子を描いたのが次の図だ。


処理の流れは次のようになる。
  1. MySQLに対して更新を行う。
  2. トリガを使ってBLACKHOLEデータベースへ更新を行う。
  3. UDF(ユーザー定義関数)インターフェイスを用いてmemcachedへの更新を行う。
  4. 読み込み時にはキャッシュへ問い合わせを行う。(キャッシュミス時にはデータベースから読み込む。)
この仕組みのメリットはデータベースへ更新を行うだけで自動的にキャッシュへの読み込みが出来る点だ。そして、次の図に示すような拡張が出来る点が真のメリットだ。


4までは前のと手順が同じだが、それ以降が異なる。
  1. MySQLのレプリケーション機能を使って、参照系の遠隔サイトへデータを複製する。
  2. トリガがBLACKHOLEデータベースへ更新を行う。
  3. UDFインターフェイスを通じてmemcachedへエントリの追加を行う。
  4. アプリケーションサーバが読み込みのためキャッシュへ問い合わせを行う。(キャッシュミス時にはデータベースから読み込む。)
実際にこのような仕組みを使うかどうかは不明であるが、こんな応用も出来ますよという例である。もし実際にこんなニッチなシステムを構築した人が居たらぜひ筆者に教えてもらいたい。その時は嬉々として本ブログにて紹介するであろう。ニッチはオタク・・・もといオトコ心をくすぐるのである。

図の紹介は以上となるが、具体的にどのようなコードやステートメントで実装するかについては要望があればいずれ紹介したい。とりあえず、このブログエントリがBrianのスライドを読む上で役立つことを願う。

0 コメント:

コメントを投稿