【回答1】
実際のところは当該システムの詳細な要件を聞かなければ判断できませんが、一般には「ごく小規模で可用性があまり求められないシステムである場合は2台構成にする合理的な根拠はない」と思います。
それでも2台構成の提案が多い理由としては、
・個別の要件を吟味した結果「ごく小規模で可用性があまり求められないシステムではない」と判断した。
・「今後拡張の予定はない」という顧客の言葉が信用できなかった。
・たまたま基にした過去の提案や経験則が2台構成だった(=台数の要件についてそんなに深くは考えていなかった)。
・「分割して統治」の思想が染みついていた(=台数の要件についてそんなに深くは考えていなかった)。
などが微妙に絡み合っているような気がします。
自分の場合も提案前に顧客から「ごく小規模で可用性があまり求められないので台数は制限してほしい」と明示的に要望がない限りはまずはAPサーバとDBサーバを別で提案すると思います。
規模だけでなく可用性が条件に入っているのは、APサーバかDBサーバのどちらか一方に障害があった際の対応として、分離されていた方がリプレースしやすいためです。
【回答2】
リソースの利用状況によりけりだと思います。
プロセスAとプロセスBを能力1の2台に載せるか能力2の1台に載せるか(この「能力」というのはCPU/メモリ/ディスクIOなどを敢えてまとめたまま抽象化した表現です)を考えた場合、
・プロセスAとプロセスBが同種のリソース(CPU/メモリ/ディスクIO)を大きく消費する場合、1台だとリソースの利用が競合してパフォーマンスが悪化する(どちらもディスクIOが多い場合、一方が書いているときに他方が待つことになります)。
・プロセスAとプロセスBが異なるリソース(CPU/メモリ/ディスクIO)を大きく消費する場合、1台で効率的に扱うことができる(各プロセスが能力1以上のリソースを占有できるのであれば能力1の2台構成よりもパフォーマンスがよくなる)。
などと言えます(どちらも詳細を無視した少々乱暴な定義ですが)。
ですので、【質問2】に対する反論(というか設問自体への反論)としては、
・そもそも「能力」として抽象化されているものを具体化しないとパフォーマンスに関する議論はできない。
ということが言えるかと思います。
【回答1】
実際のところは当該システムの詳細な要件を聞かなければ判断できませんが、一般には「ごく小規模で可用性があまり求められないシステムである場合は2台構成にする合理的な根拠はない」と思います。
それでも2台構成の提案が多い理由としては、
・個別の要件を吟味した結果「ごく小規模で可用性があまり求められないシステムではない」と判断した。
・「今後拡張の予定はない」という顧客の言葉が信用できなかった。
・たまたま基にした過去の提案や経験則が2台構成だった(=台数の要件についてそんなに深くは考えていなかった)。
・「分割して統治」の思想が染みついていた(=台数の要件についてそんなに深くは考えていなかった)。
などが微妙に絡み合っているような気がします。
自分の場合も提案前に顧客から「ごく小規模で可用性があまり求められないので台数は制限してほしい」と明示的に要望がない限りはまずはAPサーバとDBサーバを別で提案すると思います。
規模だけでなく可用性が条件に入っているのは、APサーバかDBサーバのどちらか一方に障害があった際の対応として、分離されていた方がリプレースしやすいためです。
【回答2】
リソースの利用状況によりけりだと思います。
プロセスAとプロセスBを能力1の2台に載せるか能力2の1台に載せるか(この「能力」というのはCPU/メモリ/ディスクIOなどを敢えてまとめたまま抽象化した表現です)を考えた場合、
・プロセスAとプロセスBが同種のリソース(CPU/メモリ/ディスクIO)を大きく消費する場合、1台だとリソースの利用が競合してパフォーマンスが悪化する(どちらもディスクIOが多い場合、一方が書いているときに他方が待つことになります)。
・プロセスAとプロセスBが異なるリソース(CPU/メモリ/ディスクIO)を大きく消費する場合、1台で効率的に扱うことができる(各プロセスが能力1以上のリソースを占有できるのであれば能力1の2台構成よりもパフォーマンスがよくなる)。
などと言えます(どちらも詳細を無視した少々乱暴な定義ですが)。
ですので、【質問2】に対する反論(というか設問自体への反論)としては、
・そもそも「能力」として抽象化されているものを具体化しないとパフォーマンスに関する議論はできない。
ということが言えるかと思います。