LAMPスタックのスケーリング
月に10万ヒットを超えると、このコミュニティの人々は最大のハードルは何だと思いますか？
私の状況：大量の静的メディア（オーディオ/ビデオ/画像）がS3/CDNから提供されていますが、バックアップとしてローカルに保存されています（ただし提供されていません）。キャッシュできるものはすべてキャッシュされ、約8ギガのメモリが32に拡張可能です。
現在、約10万件のヒットを問題なく処理していますが、他の人がどのような問題に遭遇したかを知りたいと思います。メモリの問題？ディスクI/O？
ヒントをありがとう。私は関連する質問を調べました、そして彼らはそれらによく答えました、しかしただもう少しフィードバックを得たいと思いました。
最近のハードウェアは非常に安価であるため、複数のマシンが必要になる人はますます少なくなっています。 10,000ドルで購入できます。
- 16〜32GBのRAM;
- 2つのクアッドコアXeon;
- RAID5ディスクアレイ。
この種のマシンは、最もリソースを大量に消費するアプリケーションを除いて、少しでも最適化されたサイトで10,000人を超える同時ユーザーにサービスを提供できます。
基本的に、スケーラビリティには2つのアプローチがあります。
- 垂直：基本的に可能な最大のマシンを購入するので、複数のマシンは必要ありません。
- Horizontal：並列処理に適した方法で物事を行う。最も集中的なアプリケーションでのみ必要です。
StackOverflowを見てください。基本的にはWebサーバーとデータベースサーバーで実行され、月に600万回を超えるヒットがあります。
そうは言っても、スケーラビリティとは、ボトルネックを見つけて対処することです。
- データベースの速度が低下している場合は、データベースにリソースを追加するか、何らかの形式のメモリ内キャッシュを使用して負荷を軽減します。
- ディスクI/Oが問題である場合、同じことが当てはまります。
- ページフォールトが多すぎてディスクI/Oの問題が発生するまでメモリが不足している場合は、メモリを追加してください。
- アプリケーションとそのデータは、サーバー間でのパーティショニングに役立ちますか？もしそうなら、それは水平方向にスケーリングする1つの方法です。
- 帯域幅が問題で、大きなファイルを配信している場合は、おそらくCDNが答えです。
- 等々。
しかし、最終的には、月あたり10万ヒットはそれほど大きくありません。最近の典型的なWebサイトでは、実際に問題が発生する前に、月に1,000万を超える必要があると思います。ただし、悪いことをしていなければ（たとえば、データベース検索のインデックスを作成しない場合は、もちろん問題が発生しますが、ヒット数/月とは関係ありません）。
冗長性はスケーラビリティよりもはるかに大きな頭痛の種だと思います。冗長リンクの設定、システム障害のプロセスの監視、DR（ディザスタリカバリ）サイトの作成と維持、それに伴う問題（スプリットブレインクラスタリングなど）の処理などに関連する問題は、はるかに困難で面倒です。
ワニス または イカ を使用します。どちらもWebアクセラレータであり、静的メディアファイルに最適です。
スケールアウトすると、Webキャッシュ用に1台、動的コンテンツ用に1台のマシンを使用することもできます。
または、modを使用してApacheを微調整することもできます： mod_expires 、 mod_headers 、 mod_cache 、 mod_file_cache 、- mod_mem_cache 。
実行を処理するデータベースの種類に少し依存します-静的コンテンツを提供しているのか、静的コンテンツに近いのか。非常に控えめなハードウェアで、100K /月をはるかに超えて拡張できます。
フォーラムなどの複雑なデータベース駆動型サイトは、より大きな問題になる可能性があります。データベースレプリケーション、追加のキャッシュとして機能するメインWebサイトのリバースプロキシ、および追加の負荷分散されたWebサーバーを調べる必要があります。ほとんどの「重い」DB使用ソフトウェアは、memcachedなどもサポートしています。これは、一般的なリクエストでデータベースの負荷を軽減するために使用できます。
率直に言って、あなたはおそらく現在需要を過大評価していると思います-100Kは単一のマシンでの処理の範囲内です。 10Mを超えると、上記で概説したような、より複雑なソリューションを検討する必要があります。
私の個人的なアドバイスは、単一の複雑なマシンよりも常に並列マシンを優先することです。それは最終的に安価になるだけでなく、時が来れば成長する余地がはるかに大きくなります。すでに高価なハードウェアを拡張すると、25,000ドルのサーバーの領域に入ることができます。ここでは、「大金」が崩壊します。
10万ヒット/月を超えたら
なんでもない！！！月に10万ヒットを提供するのに問題がある場合は、問題が発生します。一般に、1日あたり100Kを提供するほとんどの最も愚かなシステムで問題が発生することはありません。
これはLAMP ...とCMSシステムについてです
私の状況：S3/CDNから提供される大量の静的メディア（オーディオ/ビデオ/画像）
これらの目的に非常に優れたWebサーバーがあります。lighttpd-YouTubleメディアストリーミングを提供し、nginxも優れています。
これらは、高負荷で非常に適切に拡張できる軽量のWebサーバーです。
Apacheモジュールをmod-preforkからmod-workerに切り替えることでさえ助けになります（lighttpdでさえはるかに優れています）。
結論：これらの負荷は決して高くはありません。
他の人は、10万ヒットは問題ではないと指摘していますが、あなたがそうだったというあなたのポイントを逃したと思いますすでに問題なくその数のヒットを提供しています...
コンテンツにビデオが含まれていることを考えると、ネットワーク帯域幅が最初の問題であり、大きなオブジェクトに対して十分な同時要求がある場合はI/O要求が続くことをお勧めします。データよりも多くのRAMがある場合、すべてがキャッシュに格納されると、I/Oの問題は少なくなります（ただし、サーバーのシャットダウン後にキャッシュを準備するのに時間がかかります） 。
このような要件のサイズを決定するときに指定する必要があることの1つは、ヒットの分布です。それらは1か月にわたって均等に分散されていますか、それともバースト性がありますか？たとえば、国営宝くじに関する情報をホストしているサイトでは、抽選時間後の2時間のウィンドウで毎週のトラフィックの80％以上が表示される可能性があります-2時間での100Kリクエストの80％は2.7 /秒です（4週間の月を想定）。まだ大規模ではありませんが、サイズ/複雑さまたは応答に応じてそこに到達します。あなたのサイトのビデオがDiggのフロントページなどにヒットした場合に何が起こるかなど、他の予測不可能なバーストも可能です。
私はスケーリングの人です。1つのルールがあります。パフォーマンスの問題から自分自身を購入するオプションを常に自分自身に残してください。
お金を使って修正できないものには、「解決するための固定時間」がないため、常に問題から抜け出すためのコード化/制限を試みますが、コア/サイクル/メモリ/ストレージ/帯域幅をスローするオプションを常に残してください/問題が何であれ-いつでもFedExすることができます:)
最大のハードルはおそらく
非同期操作と短期間の不整合を可能にするためにACIDやその他の強力な制約を排除する、疎結合アーキテクチャに合わせてアプリケーションを整えます。このトピックの概要については、 醸造者のCAP定理 を参照してください。
多くのノードの適切な管理に対処します。これには、パッケージ管理などの基本的なシステム管理タスク、および変更要求のテストとロールアウトが含まれます。 50台のWebサーバーがある場合、「すべてのApacheサーバーを再起動する」ことはできません。これらのタスクにいくつかの考えを持ち込む必要があります
これで最後のポイントになります。大規模なシステムで見られる影響を理解してください。 Thundering Herd はあなたが目にするものの1つです。 この記事 Audiogalaxyについては、大規模システムのいくつかの問題についても説明しています。
スケーラブルなインターネットアーキテクチャ と キャパシティプランニングの技術 は、このトピックに関する2冊の本です。
月に10万ヒットを超えると、このコミュニティの人々は最大のハードルは何だと思いますか？
問題を考えすぎ、プラットフォームを設計しすぎ、システムを複雑にしすぎています。
100k /月はなしです。その時点でのあなたの全体的な目標は、それに集中するために人間的に可能な限りあなたの時間を費やすことではありません。