- PR -

WEB+DBサーバー構築について

1|2 次のページへ»
投稿者投稿内容
kuro
会議室デビュー日: 2003/06/27
投稿数: 11
投稿日時: 2003-06-27 13:59
現在、Apache+Tomcat+MysqlのWEB+DBサーバーの構築を検討しています。
LinuxOS上にこれらを運用し、JSP/ServletとMysqlを連携したシステムを
作ろうとしています。

以上のようなシステムを想定した場合、私の知る限りでは一般に
WEB/JSPコンテナサーバーとRDBMSサーバーを物理的に別々に立てて
運用している場合が多いように思います。
今回のシステムで考えられる負荷としては、アクセス数は数百から数千/日、
データベース件数は数万件から数十万件を扱うことになると思うのですが、
このような場合でも、2台以上のマシンを用意して運用した方が良いのでしょうか？

これからの暑い夏の季節、特に常時稼動サーバーの信頼性が不安なのですが、
その辺も含め参考のご意見をいただきたいです。
本会議室の趣旨と違っていたらごめんなさい。
よろしくお願いします。
御爺庵
常連さん
会議室デビュー日: 2002/02/06
投稿数: 33
お住まい・勤務地: 大阪府
投稿日時: 2003-06-27 14:23
アクセス件数や、DBのレコード数がどう伸びていくか。
この予測によるのでは無いかと思います。
kuro
会議室デビュー日: 2003/06/27
投稿数: 11
投稿日時: 2003-06-27 15:49
アクセス件数はなかなか予測しづらいのですが
劇的に増えるということは無いと思います。
DBのレコードの件数に関しては一日1000弱ずつ増えていくのでは、
と考えています。

本システムに求められるのは、パフォーマンスよりもむしろ
24時間365日止まることなく稼動し続けていることなので、
安定性を重視したいのですが・・・
サーバースペックも悩みどころです。
この辺を見極める指針のようなものは存在するのでしょうか？
taku
ぬし
会議室デビュー日: 2002/11/12
投稿数: 918
お住まい・勤務地: 墨田区→中野区
投稿日時: 2003-06-27 16:31
引用:

本システムに求められるのは、パフォーマンスよりもむしろ
24時間365日止まることなく稼動し続けていることなので、
安定性を重視したいのですが・・・

　一台のサーバーで上記のようなシステムを動作させることは不可能です。
それはどんな性能の良いサーバーを使っても、
絶対に止まらないわけでは無いからです。
ＷＥＢサーバー、ＡＰサーバー、ＤＢサーバーを最低でも２台ずつ必要ではないですか？
Astmild
常連さん
会議室デビュー日: 2003/06/09
投稿数: 30
お住まい・勤務地: 大田区
投稿日時: 2003-06-27 19:03
常時稼動をさせる時、何が不安かで対策も変わって来ると思います。

①ハードウェア
　・少しの間なら止まってもいい→ホットスタンバイ、コールドスタンバイ等にする。
　　（この場合、パフォーマンスが許せば１台で運用することも可能かもしれません。）
　・絶対に止まってはいけない→takuさんがおっしゃられたように複数台用意し、
　　フェールソフト構成にする。

②ソフトウェア
　信頼性が高い製品を採用するかどうかを検討する。
　（最近はダウンを検知したら自動で再起動するAPサーバも売ってますね。）

③システム
　同じシステムを違う設計・アルゴリズムで構築したものを用意しておく。
　（コピーの場合、切り替えた次の瞬間に 同じ状況が再現されて落ちる可能性があるため）

どんな対策をするかは、どこまで信頼性を求めるかによると思います。
会社員
ベテラン
会議室デビュー日: 2003/01/21
投稿数: 50
投稿日時: 2003-06-27 22:32
あんまり関係ないんですが、MySQLよりPostgreSQLかOracleのほうがいいんじゃないかなーと思います。
kuro
会議室デビュー日: 2003/06/27
投稿数: 11
投稿日時: 2003-06-27 23:21
引用:

一台のサーバーで上記のようなシステムを動作させることは不可能です。
それはどんな性能の良いサーバーを使っても、
絶対に止まらないわけでは無いからです。
ＷＥＢサーバー、ＡＰサーバー、ＤＢサーバーを最低でも２台ずつ必要ではないですか？

おっしゃるとおりですね。
個人的にはRAIDのミラーリングで十分では、と思っていたのですが、
より完璧なミラーリングのためにはバックアップサーバーが必要なのかもしれません。

引用:

常時稼動をさせる時、何が不安かで対策も変わって来ると思います。

①ハードウェア
　・少しの間なら止まってもいい→ホットスタンバイ、コールドスタンバイ等にする。
　　（この場合、パフォーマンスが許せば１台で運用することも可能かもしれません。）
　・絶対に止まってはいけない→takuさんがおっしゃられたように複数台用意し、
　　フェールソフト構成にする。

②ソフトウェア
　信頼性が高い製品を採用するかどうかを検討する。
　（最近はダウンを検知したら自動で再起動するAPサーバも売ってますね。）

③システム
　同じシステムを違う設計・アルゴリズムで構築したものを用意しておく。
　（コピーの場合、切り替えた次の瞬間に 同じ状況が再現されて落ちる可能性があるため）

どんな対策をするかは、どこまで信頼性を求めるかによると思います。


私がもっとも不安に感じているのは、1番のハードウェア(特に熱暴走)です。
恥ずかしながらコールドスタンバイという言葉は知らなかったのですが、
RDBMSサーバーのコールドスタンバイというのは可能なのですか？
WEBサーバーならともかく、RDBMSサーバーは常に更新されるものなので、
感覚的に「コールド」にはできない気がするのですが・・・
このあたりの具体的な実装方法などの情報をきちんと調べて勉強したいのですが、
何かお勧めの書籍やHPなどはありませんでしょうか？
私の常読している雑誌などではあまりこういった内容が無いもので・・・
是非、教えていただきたいです！

引用:

あんまり関係ないんですが、MySQLよりPostgreSQLかOracleのほうがいいんじゃないかなーと思います。

具体的にはどういった理由でそう思われるのでしょうか？
個人的な印象としては、
Oracle :高機能、重い、高価
PostgreSQL:高機能、重い(vacuum等)、安い
MySQL :必要最低限の機能、軽い、安い

といった感じで、今回は必要な機能としてトランザクションぐらいしかないと思い、
MySQLにしようかと思っています。Postgresも検討中なのですが、要求される
スペックとvacuumによるテーブルロックを考えると悩んでしまいます。
もし間違った解釈をしておりましたら、正しく直していただければ幸いです。
yamamoto
会議室デビュー日: 2003/05/16
投稿数: 14
お住まい・勤務地: 福岡
投稿日時: 2003-06-27 23:45
> スペックとvacuumによるテーブルロックを考えると ...
現在の PostgreSQL では、vacuum時にロックしませんよ。
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）