DB、クラウド－実例から学ぶmixiアプリ運用ノウハウ

データベースの見直し

前回までの対策でリクエスト数は激減、なんとかルーターが処理しきれるようになりました。次はデータベーススキーマとクエリーの見直しです。WebサービスのボトルネックとなりやすいのがDBサーバーなど、ディスクアクセスが発生するサーバーです。ネギ振りカウンタではMySQLを使用しているのですが、急ごしらえで機能拡張を繰り返していったため、恥ずかしいことにインデックスがうまく効いていないクエリーが含まれていることがわかっていました。

前回でも触れましたが、一見自明な問題に見えても思い込みで対策すると何時まで経っても一番のボトルネックにたどりつかず、対策しても対策しても遅いままという状態になってしまいます。そこで、MySQLにはスロークエリーログという遅いクエリーだけを抽出してくれる機能があるのでそれをみてみました。
→「スロー クエリ ログ（MySQL 5.1 リファレンスマニュアル）」

スロークエリーにはそのクエリーが遅いという情報が載っているだけで、その原因までは記載されていません。原因を特定するには、クエリーに対してEXPLAIN文を発行します。
→「EXPLAIN を使用して、クエリーを最適化する（MySQL 5.1 リファレンスマニュアル）」

さっそくネギ振りのスロークエリーをEXPLAIN文で確認してみたところ、やはりindexの張り忘れが多い状態でしたので、必要なカラムにindexを張りまくりました。

memcached , TT（TokyoTyrant）の活用

MySQL をはじめとしたRDBMSは機能が複雑なだけあって重いです。そこで、更新頻度の低いデータや、読み出しだけのデータに関しては、キャッシュを積極的に活用することでデータベースへの問い合わせを減らすような構成がよく取られます。そして、Webサービスで用いられる分散キャッシュシステムの代表格といえばmemcachedです。memcachedはシンプルでかつサーバーを追加するだけで性能が向上するよう設計されており、現在ではmixiを含む多くの商用Webサービスで利用されているオープンソースソフトウェアです。

memcached はインストールもとても簡単で、PHPやRuby、Perlなどで用意されているクライアントライブラリから簡単に利用できます。注意点としてmemcachedはデータをオンメモリに格納する機能のみを有したシステムなので、サーバーを再起動するなどした場合に蓄えられているデータが揮発してしまう（すべて消去される）ことが挙げられます。

memcachedはデータベースに問い合わせた結果などをメモリ上に保持しておくのによく使われます。キャッシュからデータが取得できなかった場合はデータベースに取りに行くように設計するのがいいでしょう。

アクセスが集中するデータでも消えては困るデータであれば、memcachedではなくデータを永続化できるTokyoTyrantなどのKVS(Key-Value-Store)システムを活用するといいでしょう。

TokyoTyrant はmemcachedと違いデータをファイルに保存するためデータが揮発しない上に、memcachedとほぼ同等のREAD性能を持っています。memcachedとの互換プロトコルがあるため、memcachedとの違いを意識することなく利用できると思います。

TokyoTyrantはレプリケーションはできるのですが、分散する機能をもっていないため、大量のデータを保存できません。そのため、あらかじめデータ量が決まっているコンテンツの保存に向いています。mixiではログイン時刻の記録に使用しています。

ネギ振りカウンタは総ネギ振り回数のカウント用採番システムにTokyoTyrantを使用することで、負荷を低減させています。
→「Tokyo Tyrantによる耐高負荷DBの構築（mixi Engineers’ Blog）」