webのシステムを開発し、ユーザが増えていったときのことを考えて、負荷分散を検討しています。
たとえば、「ユーザが増えていったらサーバを増やせばいい」というような対処法を取れるようにするための方法はどのような方法がありますか?
ロードバランサーのような処理をするサーバを1つ用意して、webサーバ1,2,3,4、DBサーバ1,2,3,4,5,6のように増やしていくことは現実的には、何をどう検討すればいいのでしょうか?
また費用の面ではおおよそどのくらい検討すべきものでしょうか?
WEBサーバーとDBサーバーでは一般的に手法が異なります。
WEBは処理を行い、DBはデータ管理を行うからです。
WEBはロードバランサーを入れておけば後で増やせます。200万位でしょうか。
DBはOracleのReal Application Clustersのような、水平分散の機構を持つソフトを選定するか、UNIXサーバーのように、CPUを沢山搭載できる機種を選定すると良いと思います。
こちらは数千万を覚悟した方が良いです。
http://www.soi.wide.ad.jp/iw2001/slides/11/11-1/
比較的分散が容易なのは Web サーバーのほうです。
大抵の情報はDBに入っているでしょうから、あとはユーザーのログイン情報などの、いわゆるセッション情報をどうするかだけ決めればいいです。
セッション情報もDBに持ってしまえばWebサーバーは何も情報を持っていないのでどれに振り分けても同じですし、ロード場欄サーによっては URL やHTTPヘッダ情報から同じユーザーを常に同じサーバーに割り当ててくれる機能を持っている場合もあります。
反面DBの分散は簡単ではなく、状況に応じて随時考えていく必要があります。また、ほとんどの場合プログラム側での対応も必要です。
プログラム側からはシンプルに見えるのはDBのレプリケーションですが、Oracle の RAC に代表されるようにDBの管理や障害対応が非常に高度かつ複雑化する欠点があります。
また、大抵のレプリケーションは検索処理の分散には役に立ちますが、更新処理は結局すべてのDBで行わなければならないため分散になりません。
第2の手段としては目的毎にDBを分ける。
たとえば「はてな」を例にするとアカウント情報・人力検索・ダイアリーをそれぞれ別のDBに格納する等です。
当然アプリケーション側でその都度接続するDBを考慮しなくてはいけませんし、ほとんどのDBは複数DBにまたがったトランザクションをサポートしていません。
さらに分割しないといけないばあい、データのパーティ初任具が行われます。
たとえば、人力検索の質問ID末尾が奇数の質問と偶数の質問を別のDBに配置する等です。
このばあいDB分割のアルゴリズムを適切に考えるか、別途分割対応表を持っておく必要があります。
以上のように単に何かを用意すれば済むと言う話ではないので費用に関しては一概に言えませんが、ほとんどは開発費・保守費用になるでしょう。
あとはDBやアプリケーションサーバーに何を使っているかによります。
感覚的な例ですが自分なら、最低でも数百万レベルを想定します。
大変詳しい説明ありがとうございます。
なんとなく内容も理解できました。
機能ごとにDBを切り分けることは考えているのですが、それでも増えていったら対応しきれないなと思っていました。
DBが、クラスターかレプリケーション機能が必要
WEBサーバーはDBへ整合性のあるアクセスする設計
ローカルにデータを持たない設計(ステーツレス設計)
ロードーバランサーは、負荷によるが最終的にはハードウェア
DB価格:
1.商用ソフトであればライセンス費用
2.SMP構成であれば
CPU・RAM・DISK →設計次第
3.クラスター構成
→初期費用高額、追加費用はDBの台数比例
3.レプリケーション構成
→費用はDBの台数比例
WEBサーバ:
必要な台数の費用
ロードバランサー:
必要な台数の費用
その他:
高速ネットワーク
==========================================
J2EEサーバ、スケーラビリティと可用性の「現実」
http://h50146.www5.hp.com/products/software/oe/hpux/developer/co...
ロードバランサー
http://www.keyman.or.jp/search/30000009_1.html
スケーラビリティーを考慮した インターネットサーバーの構築
ありがとうございます。
そんなにかかるんですね。
WEBとDBサーバで違うことも知りませんでした。
ありがとうございます。