質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.58%

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

解決済

回答 5

投稿

  • 評価
  • クリップ 2
  • VIEW 836
退会済みユーザー

退会済みユーザー

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

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • 退会済みユーザー

    2018/11/28 18:05

    複数のユーザーから「プログラミングに関係のない質問」という意見がありました
    teratailでは、プログラミングに関して困っていることがないと思われる質問を推奨していません。
    「質問を編集する」ボタンから編集を行い、具体的に困っている理由や解決したいことを明確に記入していただくと、回答が得られやすくなります。

  • 退会済みユーザー

    2018/11/29 09:42

    複数のユーザーから「やってほしいことだけを記載した丸投げの質問」という意見がありました
    「質問を編集する」ボタンから編集を行い、調査したこと・試したことを記入していただくと、回答が得られやすくなります。

回答 5

checkベストアンサー

+3

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+1

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/11/28 17:25

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

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

    キャンセル

  • 2018/11/28 17:38

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

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

    キャンセル

  • 2018/11/28 17:58

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

    キャンセル

  • 2018/11/28 21:04

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

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

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

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

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

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

    キャンセル

+1

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

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

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

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

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

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/11/28 17:21

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

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

    キャンセル

  • 2018/11/28 17:49

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

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

    キャンセル

0

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/11/28 17:22

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

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.58%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る