1日に1,000万のリクエストとmySQLクエリを処理するには、どのようなサーバーが必要ですか？

Question

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

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

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

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

TomTom · Accepted Answer

安いデスクトップ？

数学に入りましょう。

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

それを2倍にして（ピーク負荷）、クエリが十分に単純で、実際にどれほど複雑であるかがわからない場合、安価なクアッドコアデスクトップで処理できる負荷について説明します。

1か月あたり5000 GBはささいなことです-真剣に、同じ数学が適用されます。
それは208GB /日に分解されます
それは8GB /時間に分解されます
それは148MB /分に分解されます
これは、2,5MB /秒、25Mビットに分解されます。ピークの場合は2倍-50Mビット、どのホスティングセンターの場合も問題ありません。ただし、費用がかかります。
2000 GBをハードディスクに保存します。つまり、RAID内の2x2000 GBのハードディスクですか？それ以外の場合：データベース用であり、には多くの複雑なIOがあり、数十枚のディスクと73GB 15.000RPMのLOTの間の任意のものですSAS RAID 10のディスク（約60ディスク））必要なI/Oを取得するために-この質問は、データアクセスパターンに関する詳細情報がないと答えられません。
実行PHPおよびMySQL-私の携帯電話はそれを行うことができます;）問題はアプリケーションがどれほど複雑かです。 MySQLはここでは受け入れられる解決策かもしれませんし、そうでないかもしれません、ところで。 -より多くのテストが必要になります。一部の人々がまだ他のより大きな商用データベースを使用している理由があります。
専用サーバーまたはVPSにはどのCPU/Ramが必要ですか？

これはロジックに依存すると言えます（PHP部分の計算量、賢さ、またはプログラマーの不足、およびその他の多くの質問）。

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

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

バックアップ？
緊急時対策はありませんか？つまり、サーバーが停止します。つまり、交換が構成されている間、サイトが何日間もダウンしても大丈夫ですか。

uesp · Answer

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

TomTomが述べたように、多くの場合、アプリケーションの設計と実装に依存するため、正確な仕様を指定することは困難/不可能です。私または他の誰かにXリクエスト/秒を与えるハードウェアは、あなたにはうまく機能しないかもしれません。
ローエンドの専用MySQLサーバー（Intel Core2 Duo E4600 2.40 GHz、4 GB RAM）を使用しており、CPUアイドル率が90％で、平均100リクエスト/秒（1日あたり1000万近く）に対応しています。構成へのいくつかの基本的な調整を除いて、読み取りは重いため（+ 95％読み取り）、アクティブなレコードセットはメモリに簡単に格納できるため、うまく動作しています。サーバーの量を選択するときは、アクティブセットのサイズを考慮してくださいRAMこれは大きな違いを生む可能性があります。データベースのサイズとアクティブなレコードセットのサイズの違いを理解してください。たとえば、私のデータベースの合計は約7GBですが、アクティブセットはたった数百MBです。
同様に、1日あたり約100万件のリクエストに対応する同様の仕様のApacheサーバーを使用しており、平均で約95％のCPUアイドル率があります。リクエストは非常に単純な地図データAJAXクエリとより複雑なMediaWikiページの組み合わせです。
特定のアプリケーションのベンチマークは、必要なものを正確に判断するための良いスタートです。見積もりを下回る必要はありませんが、お金と労力を浪費する可能性があるため、見積もりを立てすぎると同様に悪い結果になることがあります。
平均リクエストレートだけでなく、ピークレートも考慮してください。リクエストレートは日、週、月によって大幅に変化する可能性があるため、平均レートをほとんど処理できないサーバーは望ましくありません。たとえば、週末のピーク時のトラフィックは、平日の最短時間の3〜4倍になります。どの程度変化するかは、アプリケーションとユーザーベースによって異なります。
データベース/ HTTPリクエストをキャッシュできますか？これにより、キャッシュできる量に応じて、ハードウェアがより安く/より少なくなり、リクエストレートが大幅に向上します。
将来の成長に備えて、後でではなく今すぐスケーリングオプションを検討してください。最適なオプションは、最小限のハードウェアから始めて必要に応じて簡単に拡張できる水平スケーリングを使用することです。
アプリケーション層の適切な設計は、その最終的なパフォーマンスに大きな影響を与える可能性があります。インデックスのないテーブルでの不正なSQLクエリは、適切に設計されたクエリよりも桁違いに遅い場合があります。同様に、設定が不十分なApache/MySQLサーバーは、正しく設定されている場合よりも何倍も遅くなる可能性があります。