必要となるwebサーバーのスペックを理論的に予測する方法が知りたい

Question

昨今のクラウドサービスでは取り敢えず開発してデプロイして負荷が高くなったらサーバーを上位のものにしたり負荷分散したりしますよね？
これって取り敢えずやってみて負荷が多くなったらスペックを上げようという行き当たりばったりな方法に思えるのですが、そうではなくこのくらいのアクセスでこのくらいの負荷がかかるのでこのくらいのスペックのサーバーが必要だという様な事を言語選定の段階、設計段階から理論的に予測する方法は無いのでしょうか？
それができないと設計段階で負荷が高そうだからC等の速い言語を選定するみたいなことが出来ませんよね？
世の中の開発会社はどのようにしてるんですか？ただの経験則ですか？

Answer 1

「スペックを理論的に計算したい」と私も良く言われたことがありますが、十数年調べたり勉強した限り「きちんとした計算式は無い」です。

同じことを実現したとしてもOSやミドルウェアが異なれば必要リソースは変わってきます。
なので実際の構成を作成し「実測」と「経験値」で「おおよそのスペック」を算出することが多いです。

Answer 2

予測するために、実際のアクセスを想定した負荷試験を行えば良いと思います。
その結果でアクセスに耐えうる構成を見出しプロダクションリリースすれば、想定内であれば問題は発生しにくいです。

運用では想定外の事象も多く発生しますが、まずはこの程度で良いと思います。

クラウドはオンプレと違いスペックが不足していたら気軽にスケールできますし、
過剰リソースを無理に割り当てなくてもいいのではないでしょうか。

Answer 3

クラウドを使うとき以外は今でもそうしていると思います。

あなたの思う、理論と経験則のどちらになるか分かりませんが、現行システムを参考にするか、サンプルプログラムを作って負荷を掛けて数値を取るかして、サーバー構成を検討します。
クラウドでなければ、サーバーを数年間買い換えずに済むように大きめにサイジングするので、多少ぶれても、５年後の買い換えが３年後に早まるとかでしょうか。
言語選定に影響する事はないと思いますが。言語はどちらかというとそれ以外の要因で決まる。

Comments

[退会済みユーザー]

＞現行システムを参考にするか、サンプルプログラムを作って負荷を掛けて数値を取る
私的には前者は経験則で後者は実験かつ経験則です。
私は理論が欲しいんですよ

>言語選定に影響する事はないと思いますが。言語はどちらかというとそれ以外の要因で決まる。
言語は負荷に大して関係ないということ？それ以外の要因ってなんでしょうか？

[maisumakun]

> 私は理論が欲しいんですよ

逆にお伺いしますが、何のためにですか？

[moonphase]

横から失礼します。
理論は前提条件を決めて、ご自身で考えることではないでしょうか。
それが合ってる合ってないはともかく、faoさんとその関係者が納得すればそれで良いと思います。
違うサービスや違う経験してきた人の意見がまとまるわけもありませんし、プログラミングに関する質問とも思えません。

[otn]

> 言語は負荷に大して関係ないということ？それ以外の要因ってなんでしょうか？

そんなことはありませんが、人の要因の方が大きいでしょう。
少なくとも、「本当はA言語で開発したいが、それだとサーバーハードのコストが高く付くので、より小さいサーバーで同じ性能が出るB言語にしよう」というケースはあるにせよ、多くないと思います。
トータルコスト（プログラムのメンテナンスをする期間まで含めた）の問題です。

> 私は理論が欲しいんですよ

どんなイメージでしょうか？

仮に実測不要な理論が出来たとして、CPUモデルやOS、各種ソフトのバージョンに依存することになるので、理論を作るコストがペイしないでしょう。
つまり、
・モデル作成→実測→本番状況の推定
の方が、
・理論作成→計算(?)
よりもコストが低い。作成した理論が正しいことの保証には実測が必須ですが、実測が理論通りじゃなければ理論を修正することになります。何回繰り返せば理論が完成するのか先が見えない投資です。

誰かが理論を作ってくれて、皆がそれをそのまま利用というのは、困難です。
例えばOSカーネルのバージョンが上がったら、理論作り直しか、少なくとも理論に影響しないという検証が必要です。CPUの世代が変わっても同じ事が言えます。DBMSのバージョンにも依存します。
理論を作った人は、それを売る（サイジング見積もりサービスを売る）事になるでしょうね。事業として成り立ちそうな気がしませんが。

Answer 4

Webサーバーの場合最初に限界が来るのはメモリ。
メモリから同時アクセス数上限が決まるので大体の目安は分かる。
同時アクセス数≒月間PVが増えたらメモリの多いインスタンスに上げたり複数台にしたりする。

メモリ以外が問題になるならそれなりに特殊なので必要もない段階から気にしなくていいこと。

Comments

[退会済みユーザー]

>Webサーバーの場合最初に限界が来るのはメモリ。
>メモリから同時アクセス数上限が決まるので大体の目安は分かる。
これは経験則ですか？

Answer 5

そうではなくこのくらいのアクセスでこのくらいの負荷がかかるのでこのくらいのスペックのサーバーが必要だという様な事を言語選定の段階、設計段階から理論的に予測する方法は無いのでしょうか？

一般公開するサービスであれば「このくらいのアクセス」の予測がまず困難かと思います。予測を誤れば、何かでバズって想定を上回るアクセス殺到→落ちる、ということも見受けられます。「行き当たりばったり」に見えるオートスケールのほうが、そのような状況には柔軟に対応できます。

それができないと設計段階で負荷が高そうだからC等の速い言語を選定するみたいなことが出来ませんよね？

Webサービスの開発は文字列で溢れていますが、C言語は文字列の扱いが極端に貧弱なので、Webサービスを開発する上ではほぼ選択肢とはなりません。

Comments

[退会済みユーザー]

別にオートスケール自体を否定しているわけではありません。
アクセス数と負荷の関係を事前に知っておきたいというだけです。
このくらいアクセスがあったらこのくらいまでオートスケールするだろうというように。

別にC言語にこだわっている訳ではありません。
ただの例です。
PythonよりJavaにしておこうでも良いです。

[maisumakun]

どれだけリソースがあろうとも、「いちばん負荷がかかる箇所」ですべてが制限されます。それがどこになるかということすら、けっこう想定外の場所で訪れることもあります。

計算上「これだけ来ればキャパオーバー」ということは見積もれても、現実にはそのはるか手前で、想定外の負荷がかかって制約されてしまうものです。