データベース分散

データベース分散

mixi アプリを含めた多くのWebサービスの場合、データの書き込みより読み出しの方が圧倒的に多いことが常です。たとえば総ネギ振り回数の表示はネギ振りカウンタの全ユーザーに対して行いますが、実際にネギを振る、すなわちネギ振り回数の更新を伴うリクエストを行うユーザーは数％ほどしかいません。

そこで、Webサービスのデータベースでは、Master-Slave構成が取られることがよくあります。

Master- Slave構成とは、データーベースサーバーを複数立ち上げ、1つのサーバーをMasterとしてレプリケーションで複数のSlaveサーバーと同期させる構成のことです。この構成では、更新系のクエリーを1つのMasterに振り、参照系のクエリー（SELECT）を複数のSlaveにふることで、沢山ある参照系のクエリーを複数のSlaveサーバーでさばけるようになります。こうすることで、参照が増えてもSlaveサーバーを増やすだけで良くなるのです。データベースの構成としては基本的なものなのでぜひ導入しましょう

スケーリング

負荷が高まった場合などにサーバーの処理能力を向上させるには、スケールアップとスケールアウトという二つの考え方があります。スケールアップとは、サーバーをより性能の高いものに置き換えることを言います。スケールアウトとは、サーバーを追加して全体の処理能力をあげることを言います。一般的に、スケールアップよりもスケールアウトが重視されます。それはサーバー1台あたりの処理能力というのは限界があるためです。

ここまでやってきて更新系と参照系のサーバーを分ける構成になってきていると思います。これらはすべて参照系が更新系よりも負荷が高いという分析から、参照系をたくさん並べられるようにしたのです。これらはすべて、サーバーを追加するだけで処理能力が上がる構成にするためです。

サービスの特性によっては、更新系が大量になる場合もあります。データ量が膨大になってくるとインデックスすらメモリに乗り切らなくなり、さらに別の分散方法が必要になります。そういった場合はSarding(mixi ではlevel2分散と呼ばれている）という構成を導入し、データを複数のサーバーに分散するのがいいでしょう。負荷が特定の時間に突発的に上がるような場合は、Q4Mを導入して時間軸方向に分散する方法もあります。以下のエントリーが参考になるかもしれません。
→「mixiの年末年始対策 日記投稿システムの改善（mixi Engineers’ Blog）」

さらに膨大な数のサーバーが必要になる前にクラウドを導入するのもよいでしょう。最近はクラウドっぽいサービスも増えていますが、本当のクラウドの魅力はなんといっても迅速なサーバー（インスタンス）の追加です。朝はアクセスが少ないからサーバーも少なく、夜はたくさんアクセスがあるからサーバーも増やすといった運用もできます。実際にサーバーを買ってしまうと、想定していた負荷よりも低かったり、アプリ自体のアクセス数が減ってしまった場合にそのコストが無駄になっちゃいますよね。クラウドは、本当に流行るかどうかわからない実験的なサービスや、期間限定のアプリや、流行り廃りが早い一発ネタアプリに向いていると言えます。ソーシャルアプリは新しいプラットフォームで負荷の想定が難しいため、積極的にクラウドを利用するのが良いでしょう。