ウェブサイト及びDBサーバの負荷が高い状況への対策方法をお教えください

質問

御世話様です。

今、ある新サイト構築をシステム開発会社へ外注しているおります。

で、Webサーバ１台（仮に、「マシンＡ」とします）、DBサーバ１台（仮に、「マシンＢ」とします）という構成です。

ですが、ホームページにアクセスしたときの表示速度が異常に悪く、
また、ＤＢサーバの負荷も高く（バックエンドでCSVからDBへの取り込みを定期的(cron)で行っているため）、
「負荷分散」をしているとのことです。

で、「負荷分散」として具体的にやっていることは、
「マシンＡ」上の必要なファイル郡を「マシンＢ」にもコピーし、
サイトにアクセスした人によって、ランダムに「マシンＡ」と「マシンＢ」へと、
アクセス先を振り分けているとのことです。

ですが、マシンＢにあたった人は、前述のようにマシンＢの負荷がそもそも高いので、
やはり、ホームページの表示速度が遅くなってしまうとのことです。

「で、マシンをもう１台増設したほうがいいかもしれない」と言っています。

--
自分は、あまりシステム開発（特にネットワーク関連）には詳しくないのですが、
かなり矛盾しているように思われます。気のせいでしょうか？

「ホームページにアクセスしたときの表示速度」が遅いといっても、
ＳＱＬ文が無駄に長いものになっているため、ＤＢの負荷が高くなっているんじゃないの？とも思うのですが。

正直、システム開発会社の言っていることも、
正確なことを言っていない可能性が高いです。
（でも、諸事情により、システム開発を他の会社に変えるということはできません）

こういった状況の場合、本来は、具体的に、どのように負荷の対策をはかるべきなのでしょうか？

以上、お助け願えれば幸いでございます。

回答No.3

dekopa- · ベストアンサー

負荷が重いと分かっているDBサーバーに負荷を移してどうするんでしょう？駄目な会社ですね。

1.そもそもWebサーバーの何が重いのか？
2.DBサーバーの負荷が大きいのは何故か（CSV取り込み＝重いではないです。処理が適切なら負荷も下がります）
3.表示速度が遅いのは何が原因か？（Webサーバーは本当に負荷が大きいのか？全部DBサーバーから引っ張ってきていないか？）

下手な対策をするまえに、原因を究明するのが先です。
チューニング、障害対策の基本です。

お礼

お礼が大変遅くなりまして申し訳ございません。

以下、インライン返信にて失礼いたします。

＞1.そもそもWebサーバーの何が重いのか？
＞2.DBサーバーの負荷が大きいのは何故か（CSV取り込み＝重いではないです。処理が適切なら負荷も下がります）
＞3.表示速度が遅いのは何が原因か？（Webサーバーは本当に負荷が大きいのか？全部DBサーバーから引っ張ってきていないか？）

そうですね、問題点の切り分けをすべきですね。
ただ、これを外注先にいまの時点で言うと、かえってテンパルと思うんですよね・・・。

ＰＭの分際で３日くらいインフルエンザ（ほんとかよっ）で仕事できてなかったらしいですから。
仮にそうだとしても、ドキュメント管理ができていれば、他の人がプロマネをできるはずなんですが・・・。

＞下手な対策をするまえに、原因を究明するのが先です。
＞チューニング、障害対策の基本です。

了解しました。
ありがとうございました。

回答No.2

bardfish

文章を読む限り、負荷分散を考慮しすぎて全く違うアプローチをした「典型的な失敗例」のように思えます。

「バックグラウンドでCSVの取り込み」なんて愚の骨頂というか…
普通こういうのは日次バッチでしょう。
データベースの最適化もチープなんでしょうね。きっと。

質問者様側から性能要求書を提示し、開発ベンダには性能評価テストを要求し、要求している性能に満たない場合は支払いしないような契約を結んで、システム再構築を依頼した方が幸せかも知れません。

開発ベンダに任せっきりだと、必要のない出費をする羽目になるのでクライアント側としても勉強して費用以上のシステムを納品してもらうよう努力してください。

お礼

お礼が遅くなりまして申し訳ございません。

以下、インライン返信にて失礼いたします。

＞「典型的な失敗例
まったくそのとおりです。

＞データベースの最適化もチープなんでしょうね。きっと。
こないだ、「ＤＢ設計書だせ」といったのですが、論理名（でしたっけ？とにかく日本語）もないし、PKEYやFKEYの情報もないし、備考もほとんど書いてないし、ER図ないし・・・という漢字です。
最適化以前の問題です；；

＞質問者様側から性能要求書を提示し、開発ベンダには性能評価テストを要求し、要求している性能に満たない場合は支払いしないような契約を結んで、システム再構築を依頼した方が幸せかも知れません。

そうですね、ただ初期リリースまで日にちがないので、とりいそぎつくるしかない状態です。今後、そうしたいと思います。
（実は、自分がこのプロジェクトにはいったのもつい最近でして。。。）

＞開発ベンダに任せっきりだと、必要のない出費をする羽目になるのでクライアント側としても勉強して費用以上のシステムを納品してもらうよう努力してください。

そうですね。もっと勉強します。

ありがとうございました。

回答No.1

kazu2296

そもそもせっかく2台構成にしているのに、そのうち1台をDBとWebサーバ機能を同居させているのがもったいないような気がします。
それに、マシンのスペックはどれくらいですか？最近のマシンであれば、1台でも相当のアクセス量に耐えられるスペックですよ。

また、ご質問では何がボトルネックになっているのかが分かりませんので、マシンを増設しても解決するかわかりません。
また、SQL文が長いのであればチューニングしたり、まずはハードを増設しなくてもできる対策があるはずです。

個人的には、
・まず、マシンAをWebサーバ専用に、マシンBをDBサーバ専用にします。
・可能ならば、「CSVからDBへの取り込み」の時間を深夜等アクセスが少ない時間に変えます。
・次にDBのSQLをチューニングします。
・それでダメなら、レスポンスタイムやCPU使用率、メモリ使用率等を測り、ボトルネックを見つけます。
・ここで、CPUやメモリの増設をします。
・それでもダメならばハード増設

こんな流れはいかがでしょうか？
しかし、その業者もダメですね。ハード増設が必要ならば、その根拠もちゃんと言えという感じですね。

お礼

お礼が大変遅くなりまして申し訳ございません。

以下インライン返信にて失礼いたします。

＞マシンのスペックはどれくらいですか？

実は、基本的にはうちの会社はサイト制作というよりもサイト運営がおもなので、スペックについては現状こまかく把握していません。

というよりも、外注のコーポレイトサイトを見たのですが、
●当初のさいとこんせぷとはあいまいでもかまいません
●それをもとに、じっくり【ヒヤリング】して、しかるべき環境やシステム開発にとりかかります。
とかいてあるんですね。

なのに、スペックについて教えてといっても放置プレイだし、
そもそもテストリリース直前なのにＤＢ設計やってる・・・
（しかも、「ER図」ってなに？状態・・・）
しかも、ＤＢ設計書が複数存在する。バージョン管理をしていない。

・・・ということでだめだめなんです。
損害賠償の可能性もあるでしょうね。
//本当は納期から大幅におくれているんです。
//プロマネのおやじも、プロマネしてなくて、「私もプログラミングしてますから」（<=ぜったいできない）とかいうし・・・。

まいっちゃったな。

＞・可能ならば、「CSVからDBへの取り込み」の時間を深夜等アクセスが少ない時間に変えます。

ものすごいデータ量があるので、（cron(or at?)）で、
１８時間くらいかかったとか・・・。

なので、教えていただいた対策をとるしかないですね。

どうもありがとうございました。

--
対応策につきまして、丁寧にご開設いただきましてありがとうございます。

プロマネの人、XSSも、SQLインジェクションも、ディレクトリトラバーサルも知らないっぽいです。

切りのいいところで、他社に発注する予定をたててます。

ありがとうございました。