何らかの業務システムを構築しようとした時に SIer に構成案を求めると、小～中規模利用で明らかに単体サーバで十分用が足りるはずなのに AP サーバと DB サーバの2台構成で提案されるという事例がよく見られます。
このような2台構成というのは SIer が作る基本構成案のセオリーとなっているようですが、
【質問1】この構成を提案される理由として、合理的な根拠にはどのようなものがあるでしょうか?
また、一般的に AP サーバは専ら CPU、DB サーバは専らメモリとディスクに高負荷をかける傾向があり、専ら使用するリソースの性格が異なるので、個々の機器の性能を上げずに無闇に2台に分割しても性能面での大幅な向上は期待できないように思われます。
つまり、
【質問2】能力1のサーバを2台用意するよりも、能力2のサーバを1台用意した方が総合的に高いパフォーマンスが期待できるのではということですが、これについても反論その他ご意見ありましたらいただけると幸いです。
8 pt / 200 pt
ツリー表示 | 新着順
t-wata
t_yamo【回答１】
実際のところは当該システムの詳細な要件を聞かなければ判断できませんが、一般には「ごく小規模で可用性があまり求められないシステムである場合は2台構成にする合理的な根拠はない」と思います。
それでも2台構成の提案が多い理由としては、
・個別の要件を吟味した結果「ごく小規模で可用性があまり求められないシステムではない」と判断した。
・「今後拡張の予定はない」という顧客の言葉が信用できなかった。
・たまたま基にした過去の提案や経験則が2台構成だった（＝台数の要件についてそんなに深くは考えていなかった）。
・「分割して統治」の思想が染みついていた（＝台数の要件についてそんなに深くは考えていなかった）。
などが微妙に絡み合っているような気がします。
自分の場合も提案前に顧客から「ごく小規模で可用性があまり求められないので台数は制限してほしい」と明示的に要望がない限りはまずはAPサーバとDBサーバを別で提案すると思います。
規模だけでなく可用性が条件に入っているのは、APサーバかDBサーバのどちらか一方に障害があった際の対応として、分離されていた方がリプレースしやすいためです。
【回答２】
リソースの利用状況によりけりだと思います。
プロセスAとプロセスBを能力1の2台に載せるか能力2の1台に載せるか（この「能力」というのはCPU/メモリ/ディスクIOなどを敢えてまとめたまま抽象化した表現です）を考えた場合、
・プロセスAとプロセスBが同種のリソース（CPU/メモリ/ディスクIO）を大きく消費する場合、1台だとリソースの利用が競合してパフォーマンスが悪化する（どちらもディスクIOが多い場合、一方が書いているときに他方が待つことになります）。
・プロセスAとプロセスBが異なるリソース（CPU/メモリ/ディスクIO）を大きく消費する場合、1台で効率的に扱うことができる（各プロセスが能力1以上のリソースを占有できるのであれば能力1の2台構成よりもパフォーマンスがよくなる）。
などと言えます（どちらも詳細を無視した少々乱暴な定義ですが）。
ですので、【質問２】に対する反論（というか設問自体への反論）としては、
・そもそも「能力」として抽象化されているものを具体化しないとパフォーマンスに関する議論はできない。
ということが言えるかと思います。
monyo>つまり、設計コスト的には、
>
> 最初から2台 ≧ 将来2台化を想定した1台 ＞ ずっと1台
>
>ですよねということなのですが、この想定が誤っていて実際には
>
> 将来2台化を想定した1台 ＞ 最初から2台 ＞ ずっと1台
>
>なのでしょうか?
当然そうです。
将来2台化を想定した1台の場合
を考える必要があります。特に増設の設計は、業務をとめる時間があまり取れない場合、かなり難易度があがります。
というわけで、コスト的には最初から2台で行う場合とは比較にならないほど検討工数が増えます。
monyo質問1で妥当だと思われる理由として、皆さんが出していないものとして、以下のようなものが思いつきます
(1) さまざまなソフトウェアを1台のサーバに集約すると、サーバ自体の構成が複雑化して、管理の難易度が上がる
たとえばマイクロソフト社でも、SQL Serverやドメインコントローラといった役割のサーバに、ほかのソフトウェアをインストールして複数の役割を持たせることは推奨していません。
理由としては、さまざまなソフトウェア間の依存関係が複雑化して、たとえばAのソフトはあるパラメータがyesであることを求めるのに、Bのソフトはnoであることを求めた時にどうするか、といった面倒な事象が発生しやすくなるということがあげられます。
また運用フェーズでトラブルが発生した場合も、いろいろと入っているサーバは切り分けの難易度がそれだけあがります。
特にDBサーバはいろいろとセンシティブなので、無用のリスクを避ける意味で、別サーバにしたほうが安全だと思います。このあたりは保険としてどの程度のコストを見込むかという話かと思います。
(2) SIer の標準構成が2台構成だから
一般論として、オーダーメイドでぴったり仕様に合致したものを作るのと、レディメイドで、若干冗長でもお仕着せの仕様のものを作るのと、どちらが安いかという話ですね。
もちろんサーバが1台より2台の方がハードウェアの価格は上がりますが、あなたの会社用にオーダーメイドで構成するためにかかる人件費と比べれば誤差の範囲でしょう。
システム構築の費用で一番かかるのは人件費です。若干オーバースペックでも、あらかじめ検証済、実績があって、個別の仕様調整や試験工数が掛からない構成があるのであれば、そちらを採用して個別検討の人件費を削減したほうが安くなります。
もちろん、ぼっているだけという可能性はありますが。
まきのっぴ> ・リソース配分について
> 利用するリソースの傾向が違うというのはそのとおり。
> ただし、それぞれ別のリソースを使用しないわけではない。
> メモリやディスク、CPU を同時利用する機会が多くなれば多いほど効率は低下する。
そうですね、単に傾向が大きく異なるだけで、一切かぶらないということはないと思います。
それによって多少効率が低下するのは当然ですが、問題は2倍以上低下しますかということです。
で、します、という話なのだとは思いますが、その理由はどのような要因によるものでしょうか?
CPU キャッシュ利用率が悪くなるとか、ヘッドシークがバカにならないということでしょうか。
(もっとも「2倍の能力」=「CPU キャッシュも2倍のものを搭載」ということですので、
それでもなお低下するかということなのですが)
> それゆえ２倍のスペックを用意したとしても等価もしくは高パフォーマンスを
> 出せるという理屈は成り立たない。
まあ、常にそうなるとは限らない、ということであればわかりますが、
平均的なケースとして考えた場合はいかがでしょう?
> スケールアウトに対して「その時に初めて DB 外出しにすれば済むのでは」との事ですが、
> １台構成を前提とすると大抵はシステム上ＤＢを容易に外出しに出来るような設計はしません。
> これは SIer の怠慢と捕らえてもかまいませんが、設計時点でそのような
> 柔軟な設計にすると（SIerの）コスト的に割に合わないです。
これは一理あるとは思います。
ただ、最初から最後まで1台でいることより設計コストが上がるというならわかりますが、
最初から2台に分割しておくことよりもコストが上がるのでしょうか?
つまり、設計コスト的には、
最初から2台 ≧ 将来2台化を想定した1台 ＞ ずっと1台
ですよねということなのですが、この想定が誤っていて実際には
将来2台化を想定した1台 ＞ 最初から2台 ＞ ずっと1台
なのでしょうか?
そうでもない限り「割に合わない」ということはないと思うのですが。
それとも、(2台を1台にまとめると発注主から SIer に支払われる設計費用が下げられて
しまうことがあり、そうなると結果的に) 割に合わない、ということなのでしょうか?
> 「AP サーバに侵入された時点で DB に SQL 投げ放題になるので実質的に変わらないのでは」
> という点に関しては明確にＮｏです。
> 適切に権限管理していれば、SQL 発行程度で操作できる内容は知れています。
確かに SQL 投げ放題とファイルシステムレベルで触り放題がイコールにはならなさそうですね。
> また、DBMS は商用製品が多く採用され、必ずしも最新のパッチを適用できるとは限りません。
> パッチの適用して問題ないかを判断するには多くのテストが必要でそのコストは顧客に跳ね返ります。
> セキュリティ屋としては DB サーバーを外部にさらすのは出来るだけ避けたいところです。
こちらは理解しがたいところです。
同一ホストで動かすわけですから、当然ながら DB を直接叩けるようなポートは
外に晒さず localhost からのみ接続可としますよね。
もし DB が外部に晒されるなら、それは AP 同居か否かとは関係ない設定不備ではないかと。
> まぁ一番気になるのは、
> 小～中規模利用で明らかに単体サーバで十分用が足りるはず
> という判断をどの様に下したのかという所ですかね。
> アプリの設計や顧客の要望次第ではあっさり１台ではまかなえない処理量になることも多いので。
例えば、完全な新規構築ではなくて、これまでも使ってきたアプリを機器老朽化に伴い新しい機械に移行する場合とか。
これまで Pentium 4 のサーバ2台で運営してきて問題なく使えてきたものを移行する先の機器として
SIer によっては4コア Xeon 2台で提案をされるような場合があるのですが、
それどう考えても2コア Xeon 1台で (ひょっとしたら Celeron DC 1台ですら) いいよね、と。
もしそうでないとしたらその理由って何なのかな、と。
…というような場合は判りやすいのでいいんですが、完全新規の場合や、
機器更新と合わせてバージョンアップや機能強化を盛り込む場合は判断に悩むところですね…
> 最近のトレンドとしては１台で済むようならそれぞれＶＭ化して
> 仮想マシンとして運用するぐらいでしょうか。
1台の物理マシン上に2つの仮想マシン・OS を上げて AP と DB に役割分担させるということでしょうか?
1台の物理マシン・物理 OS 上で AP と DB を動かすよりオーバーヘッド分損するように思われますが、
それでも敢えて分ける良い理由はどのようなものでしょうか?
また、ホスト OS に加えゲスト OS 2台と、計3台設計することになりそれこそ割に合わないような気がするのですが、
それでもなお将来必要性が発生した場合に外出しに変更しやすいということでしょうか?
b-windSIer もある程度稼ぎどころを確保しておかないといけないのと、
案件ごとに個別構成をとっていてはとても保守コストが間に合わないというのが実状な気がする。
というだけでは面白くないのでもう少し掘り下げてみる。
ただ、「明らかに単体サーバで十分用が足りる」という前提があると元も子もないのがほとんどだが。
・リソース配分について
利用するリソースの傾向が違うというのはそのとおり。
ただし、それぞれ別のリソースを使用しないわけではない。
メモリやディスク、CPU を同時利用する機会が多くなれば多いほど効率は低下する。
それゆえ２倍のスペックを用意したとしても等価もしくは高パフォーマンスを
出せるという理屈は成り立たない。
極論すれば、やはりそれぞれに特化した構成のサーバーを用意するほうが好ましい。
・想定問答集への指摘
スケールアウトに対して「その時に初めて DB 外出しにすれば済むのでは」との事ですが、
１台構成を前提とすると大抵はシステム上ＤＢを容易に外出しに出来るような設計はしません。
これは SIer の怠慢と捕らえてもかまいませんが、設計時点でそのような
柔軟な設計にすると（SIerの）コスト的に割に合わないです。
「AP サーバに侵入された時点で DB に SQL 投げ放題になるので実質的に変わらないのでは」
という点に関しては明確にＮｏです。
適切に権限管理していれば、SQL 発行程度で操作できる内容は知れています。
また、DBMS は商用製品が多く採用され、必ずしも最新のパッチを適用できるとは限りません。
パッチの適用して問題ないかを判断するには多くのテストが必要でそのコストは顧客に跳ね返ります。
セキュリティ屋としては DB サーバーを外部にさらすのは出来るだけ避けたいところです。
まぁ一番気になるのは、
小～中規模利用で明らかに単体サーバで十分用が足りるはず
という判断をどの様に下したのかという所ですかね。
アプリの設計や顧客の要望次第ではあっさり１台ではまかなえない処理量になることも多いので。
最近のトレンドとしては１台で済むようならそれぞれＶＭ化して
仮想マシンとして運用するぐらいでしょうか。
rozeruu後述の内容を記入した後で、想定問答集に気づき、拝見いたしました。
・・・単体サーバで事足りる案件には、SIerの活躍の場がないので、そうなっちゃうんでしょうねぇ。
要求仕様を固めたうえで、選択の余地をなくしておくのが良策とおもわれます。
以下、せっかくなのでご参考までに
【質問1】この構成を提案される理由として、合理的な根拠にはどのようなものがあるでしょうか?
１．可用性面
DBは、Read/Write処理があり排他制御の難易度が高いため、Active-Active構成は難しく、Active-Stanby構成
になることが多い
APは、Write処理がほとんどない場合が多く、Active-Active構成で、負荷分散もやりやすい特徴がある
以上２点より、DBとAPを分けることで、可用性と負荷分散面の向上を見込むことができます。
２．拡張性
DBは、１．の理由から台数を増やすより、個体の性能を上げるほうが処理の向上が期待できます
APは、１．の理由より台数を増やして、処理を分散させるほうが安価に、処理を向上することができます
【質問2】能力1のサーバを2台用意するよりも、能力2のサーバを1台用意した方が総合的に高いパフォーマンスが期待できるのでは
ということですが、これについても反論その他ご意見ありましたらいただけると幸いです。
少人数ユーザでの性能のみで考えると、全くもってその通りです。
しかし、同時アクセス数が100を超えてくると、AP処理がDB処理を圧迫し始めます。
一般的には、APの処理より、DB処理のほうが重要ですので、DB処理は独立させたほうがよいと思われます。
【注意点】APサーバは、一般的に、同時アクセスユーザ数分のメモリリソースを使用するので
事前に要件を確認し、キャパシティプランニングをしっかりと行いましょう。
まきのっぴ以下、【質問1】についての私の想定問答集です。
■DB サーバが高負荷だから (または AP サーバが高負荷だから)
→ 明らかに単体サーバで用が足りる規模のシステムを前提としているので、それは当てはまりません
■将来負荷が上がったときにスケールアウトし易いから
→ それは一理ありそうですが、利用するアプリは容易にスケールアウトできるような大規模利用を想定したものではありません。スケールアウトではなくスケールアップするなら単体サーバを丸ごと交換、またはその時に初めて DB 外出しにすれば済むのでは
■もし AP サーバに侵入された場合、DB サーバもまとめて乗っ取られるから
→ 同一サーバだろうと別サーバだろうと、AP サーバに侵入された時点で DB に SQL 投げ放題になるので実質的に変わらないのでは
■DBMS が CPU ライセンスなので、AP と DB を分けた方がライセンス費用を節減できる
→ 1台に集約することで CPU が2個以上になってしまう場合は確かにそれはありそうですが、CPU が2個以上も必要となるような大規模利用を想定したものではない前提とします
これ以外に何か理由が考えられる場合や、その他コメントありましたらお寄せください。
42
40
APサーバ２台、DBサーバ２台の構成を推奨しています。理由として、
ただし、上記は業務システムの性格にもよります。
例えば、
> 小～中規模利用で明らかに単体サーバで十分用が足りるはずなのに
な場合、現在のサーバの性能で将来的にも十分でスケールアウトの必要なしだと考えられるので、APサーバとDBサーバは分けなくてもよいでしょう。
また、ハードウェア故障の場合にシステムが長期間止まってもかまわない、かつ多少のデータロストが許容されるなら、APサーバとDBサーバを同居させた１台のマシンだけの構成でもよいです。