実践で使用する上での話や開発最前線の話が聴けたため、セミナーは非常に盛況であった。筆者にとっても非常に勉強になる内容だった。セミナーの資料はBrian Aker氏のサイトから入手できるのでセミナーに参加出来なかったひとはこの資料を読んで自習して頂きたい。
が、いかんせん氏のスライドはパッと見ただけではなんとなく分かりづらいように俺は思う。なぜだろうか?それはきっと図がないからだ・・・と勝手に想像する。オトコたるもの、時には勝手な憶測で突き進むのもアリだ。ちなみにBrianのスライドはほとんど要点の箇条書きになっている。これでは解説がないと、特に新規にmemcachedやMySQLを学習している人たちには分かりづらいだろう。
というわけで氏に代わり、memcachedがどのように既存の仕組みを置き換えるかについて絵を描いてみたので以下に紹介する。(余談だがMySQL ClusterのStewert Smith氏はパラパラ漫画のようなスライドを描く。Brian氏のプレゼントはまったく毛色が違う。ギークという人種は本当に個性豊かだ。)
まずはマスター/スレーブレプリケーションを用いた負荷分散をするシステムの構成図だ。このような構成のシステムはカオスだ、とBrianは述べている。
このシステムがやっていることはこうだ。
- 全ての更新をマスターへ行う
- 複数のスレーブへレプリケーションによりデータをコピーする(レプリケーションはMySQLにおいてデフォルトで使える機能である。)
- 読み込みを任意のスレーブから行うことで負荷分散する。
ただしこの方式にはいくつか問題もある。例えば、
- 負荷が高い時などにはスレーブがマスターから遅れることがある。(レプリケーションは非同期だからだ。)
- スレーブでもマスターと同じ更新作業を行うため、それなりに良いハードウェアが必要になる。
- マスターのデータに対するほぼ完全な複製であるため、メモリやディスクの使用効率が悪い。(同じデータをディスクへ格納し、メモリ上へキャッシュを行う。)
- マスターがクラッシュした時や、スレーブにおいて不整合が起きた時の復旧が大変だ。
というわけで、システムへの投資や運用が大変であった。memcachedを使えばこのような問題を解消した上で、さらにスケールアップが可能となる。memcachedを利用するとシステムの構成は例えば以下のようになる。
このシステムの処理の流れは次のようになる。
- 更新をデータベースへ行う。
- 読み込み時には最初にキャッシュへ問い合わせを行う。
- キャッシュにエントリがなければデータベースへ問い合わせを行う。
- 問い合わせた結果をキャッシュする。
処理の流れは次のようになる。
- MySQLに対して更新を行う。
- トリガを使ってBLACKHOLEデータベースへ更新を行う。
- UDF(ユーザー定義関数)インターフェイスを用いてmemcachedへの更新を行う。
- 読み込み時にはキャッシュへ問い合わせを行う。(キャッシュミス時にはデータベースから読み込む。)
4までは前のと手順が同じだが、それ以降が異なる。
- MySQLのレプリケーション機能を使って、参照系の遠隔サイトへデータを複製する。
- トリガがBLACKHOLEデータベースへ更新を行う。
- UDFインターフェイスを通じてmemcachedへエントリの追加を行う。
- アプリケーションサーバが読み込みのためキャッシュへ問い合わせを行う。(キャッシュミス時にはデータベースから読み込む。)
図の紹介は以上となるが、具体的にどのようなコードやステートメントで実装するかについては要望があればいずれ紹介したい。とりあえず、このブログエントリがBrianのスライドを読む上で役立つことを願う。
0 件のコメント:
コメントを投稿