デブサミ回顧録・Mixiのスケールアウト術

かなりのご無沙汰だったのですが、実は新たな
サービスを始めるために裏で悪戦苦闘しています。

その苦戦の過程は別のブログに収めているのですが
ちょっと内緒。4月過ぎたら公開します。

そんな中、先月はデベロッパーサミットに参加してきました。

１つはMixiのバタラさんのサーバスケールアウトの話。

バタラさんは2005年にも別のカンファレンス（YAPC::Asia 2006 Tokyo）
でも同様の講義を行っています。

それによると
・パフォーマンス拡張には2通りあって、スケールアップとスケールアウトがある
・サーバのパワー自体を拡張するスケールアップには限界がある
（CPUでもXeon3.5Ghz×２、メモリも最大4GBぐらいか）
・サーバの数だけパフォーマンスが上がるスケールアウトは一般的ニーズに
　合致する（スモールスタートできるし）
てな感じで、具体的なスケールアウトの手法についてはWEBサーバとDBサーバで

それぞれテクニックがあるらしいので覚えている範囲で書き連ねてみます。

[WEBサーバ]
・静的コンテンツと動的コンテンツで若干対応法が違う
・ただし、基本はキャッシュ機能を利用する
・静的コンテンツはキャッシュのヒット率が良く、コンテンツ更新度は低い
・キャッシュサーバとオリジンサーバ（コンテンツの元になるサイト）の組み合わせ
・キャッシュサーバが増えるとオリジンサーバは負荷が上がる
・解決するために多断層キャッシュサーバをさらにクラスタ化するという方法で
　負荷分散を行う
・動的コンテンツはキャッシュのヒット率が悪く、コンテンツ更新度は高い
・ロードバランサで単純に負荷分散しただけでは動画や画像アップロード
　するとそこがボトルネックになってしまう
・これを解消するために機能に応じてクラスタ化する（アップロード用の
　セグメントを作る）
・加えて共有メモリを利用する
・共有メモリはノードワイドとシステムワイドがある
・ノードワイドは一つのサーバ内でプロセス間でメモリを共有
・システムワイドは複数サーバ間でメモリを共有（memcached）
・スピードはノードワイドが有利
・スケーラビリティはシステムワイドが有利

[DBサーバ]
・DBサーバのスケールアウト戦略は基本レプリケーションとデータ分散
・最初はマスタースレーブで更新はマスター、参照はスレーブという
　オーソドックス戦法
・問題点はレプリケーションのクラシック問題と更新数が増えた場合
・対処法としてデータをいくつかに分散してそれぞれ別DBにする
・メール用、掲示板用、…とそれぞれに別DBに分散させる
・DBの分散できる数に限界があるので、さらにパーテショニングキーを
　使っての分散処理を検討
・プライマリキーなどをHashで分散させる
・たとえばノード数で割った余りというアルゴリズムベースで分散させると
　サーバを増やした時にノードIDがずれてしまう
・これを回避しようとするとノード数を倍に増やしていかなくてはいけなくなる
・動的にパーティションマップを更新するマネージャーベースの
　手法ならノード数を倍増やす必要はなくなる
・マネージャベースはノードを管理するDBを別に用意する手法
といった話でスケールアウトのシナリオについて教えてくれました。

残念だったのは全く質問の場を与えてもらえなかったこと。

結局細かいところはわからずじまいでした。

これと前後してAmebaの名村さんにMySQLのスケールアウトとクラスタリングの
話をしたのですけど、上記のマスタースレーブ方式でもかなりのパフォーマンス
は出せるらしいとのこと。

当面はこの方式で様子を見ようかと思ってます。

次回はPlaggerの話を。

ではでは。