1日に1,000万件のリクエストとmySQLクエリを処理するには、どのようなサーバーが必要ですか?[閉まっている]


23

私はサーバー管理の初心者であり、新しいWebサイトをホストする強力なホスティングサービスを探しています。このWebサイトは、基本的にモバイルオンラインゲームのバックエンドであり、次のことを行います。

  • 1日に最大1,000万件のHTTPS要求とmySQLクエリを処理する
  • ハードディスクに最大2000 GBのファイルを保存する
  • おそらく毎月5000 GBのデータを送受信します
  • PHPとmySQLで実行されます
  • mySQLデータベースには1,000万件のレコードがあり、各レコードには5〜10個のフィールドがあり、それぞれ約100バイトです。

これらの要件を処理するために必要なサーバーの種類が本当にわかりません。私の質問は次のとおりです。

  1. 専用サーバーまたはVPSにはどのCPU / RAMが必要ですか?
  2. この種の専用サーバーまたはVPSを提供できるホスティング会社は何ですか?
  3. クラウドコンピューティングはどうですか?Amazon EC2を調査しましたが、複雑に思えます。そして、私はRackspaceに連絡しましたが、奇妙なことに、Cloudsitesは私の要件に適していないと言われました。他のクラウドホスティング会社はあるのだろうか。
  4. 他の代替方法はありますか?

8ギガバイトのRAMを備えた2つのLinuxサーバーでこれを回避しました.mysqlはmysqlクラスターであり、DBはメモリに高速に保存されますが、良いディストリビューションを使用する場合はcpuはあまりありません。 1時間ごとにスナップショットを作成すると、障害が発生した場合に冗長性が得られます。また、mysqltunerをインストールして、インデックスなどに注意を払い、すべてを最大限に活用し、多くのインデックスを追加し、遅いクエリでログを保持できるようにしたい場合があります。トラフィックを分割するための前面のバランサー
マイナス4

クラウドサービスを使用しないのはなぜですか?Azure、Amazon、RackSpace、GoGrid、Heroku?
bbqchickenrobot

回答:


33

安いデスクトップ?

数学に入りましょう。

  • 1,000万件のリクエスト。
  • これは、1時間あたり416667リクエストに分類されます。
  • これは、1分あたり6944リクエストに分類されます。
  • これは、1秒あたり116リクエストに分類されます。

その2倍(ピーク負荷)で、クエリが十分に単純であり、それらがどれほど複雑であるかを言わなければ、安価なクアッドコアデスクトップが処理できる負荷について話します。

  • 毎月5000 GBは簡単です-真剣に、同じ計算が適用されます。
  • これは1日あたり208GBになります
  • それは8GB /時間に分解します
  • それは148MB /分に分解されます
  • これは、2.5MB /秒、25Mbitに分類されます。ピークの場合はダブル-50Mbit、ホスティングセンターの場合は些細。ただし、費用がかかります。

  • ハードディスクに2000 GBを保存します。RAIDの2x2000 GBのハードディスクですか?例外:データベース用で、複雑なIOが多数ある場合、数十枚のディスクと73GBの15.000RPM SASディスク(RAID 10(約60ディスク))の間でI / Oが必要です-これは質問は、データアクセスパターンに関する詳細な情報なしでは答えられません。

  • PHPとMySQLを実行します-私の携帯電話でそれができます;)問題は、アプリケーションがどれほど複雑かです。ここで、MySQLは許容できる解決策である場合とそうでない場合があります。-それにはさらにテストが必要です。一部の人々がまだ他のより大きな商用データベースを使用している理由があります。

  • 専用サーバーまたはVPSにはどのCPU / Ramが必要ですか?

それはロジックに依存すると言うでしょう(PHP部分の計算の量、スマートさ、プログラマーの不足、その他多くの質問)。

真剣に、これは重要な設定です。専門家に調べてもらいます。

基本的に、降りて宿題を終わらせる必要があります。このフォームでは多くの質問に答えられません。特に、あなたはあなたのデータを気にしないようです...

  • バックアップ?
  • 緊急時対応計画はありませんか?つまり、サーバーは死にます。つまり、交換が設定されている間、サイトが数日間ダウンしても大丈夫ですか?

お返事をありがとうございます。PHPはシンプルで、主な負担はmySQLにあると思います。WindowsでWAMPを使用してラップトップ(Core2 Duo)でmySQLクエリをテストしました。mySQLに10ミリオンのレコードがある場合、各クエリの平均コストは0.1秒です。mysqlクエリの処理でQuad Coreがどれほど強力ですか?
カルビン

2
クアッドコアを忘れてください。あなたのラップトップはIOで沈みます-そしてIOはデータベースが限られている場所です。ハードディスクが1枚、つまり低速で堅牢(latop)です。サーバーは、高速な(ただし堅牢ではない)複数のハードディスクを使用します。私はMSのクアッドコアSQL Serverを使用し、CPUを最大化せずに単純な選択(1つの選択が1つのバッチ)で1秒あたり500バッチ以上を処理できます-しかし、可能性のあるディスクサブシステムで多くのディスクアクティビティを取得あなたの30倍以上の速さです(まだ印象的ではありません)。ディスクが限界です。さらに適切なプログラミング。
トムトム

1
sslトラフィックは暗号化/復号化する必要があります。バランサーでそれをオフロードし、通常のhttpサーバーへのリバースプロキシを行うことができます。これにより、遅延が抑えられます。ハードウェアで暗号化することもできます。...... en.wikipedia.org/wiki/SSL_acceleration 予算がデータベースに関係ない場合ramsan.com/success/ccpgames.htm
Unix Janitor

7

役に立つかもしれない私の経験をいくつか追加するには:

  • TomTomが述べたように、その多くはアプリケーションの設計と実装に依存するため、正確な仕様を提供することは困難/不可能です。私または他の誰かにXリクエスト/秒を与えるハードウェアは、あなたにとってうまく動作しないかもしれません。
  • ローエンドの専用MySQLサーバー(Intel Core2 Duo E4600 2.40 GHz、4 GB RAM)があり、CPUアイドル率が90%で平均100リクエスト/秒(1日あたり1,000万回近く)を処理します。構成の基本的な調整以外に、読み取りが重く(読み取りが95%以上)、アクティブなレコードセットがメモリに簡単に格納されるため、正常に実行されます。サーバーRAMの量を選択するときは、大きな違いが生じる可能性があるため、アクティブセットのサイズを考慮してください。データベースのサイズとアクティブなレコードセットのサイズの違いを理解してください。たとえば、データベースの合計は約7GBですが、アクティブセットはおそらくわずか100MBにすぎません。
  • 同様に、1日あたり約100万のリクエストを処理する同様の仕様のApacheサーバーがあり、CPUアイドル率は平均で約95%です。リクエストは、非常に単純なマップデータAJAXクエリと、より複雑なMediaWikiページが混在しています。
  • 特定のアプリケーションのベンチマークは、必要なものを正確に判断しようとする際の良い出発点です。見積もりを下回ることは望ましくありませんが、お金と労力の浪費の可能性があるため、見積もりを上回ることは同じくらい悪いことです。
  • 平均リクエストレートだけでなく、ピークレートも考慮してください。リクエストレートは日、週、月ごとに大幅に変化する可能性があるため、平均レートをほとんど処理できないサーバーは必要ありません。たとえば、週末のピーク時は、週の最低時間の3〜4倍のトラフィックを得ることができます。どの程度変化するかは、アプリケーションとユーザーベースによって異なります。
  • データベース/ HTTPリクエストをキャッシュできますか?これにより、キャッシュできる量に応じて、ハードウェアの価格を安くしたり少なくしたりして、リクエストレートを大幅に上げることができます。
  • 将来ではなく、将来の成長のためのスケーリングオプションを検討してください。最適なオプションは、最小限のハードウェアで開始し、必要に応じて簡単に拡張できる水平スケーリングを使用することです。
  • アプリケーション層の適切な設計は、最終的なパフォーマンスに大きな影響を与える可能性があります。インデックスのないテーブルでの不適切なSQLクエリは、適切に設計されたものよりも桁違いに遅くなる可能性があります。同様に、適切に構成されていないApache / MySQLサーバーは、正しくセットアップした場合よりも何倍も遅くなる可能性があります。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.