それで、私は最新の Stackoverflow ポッドキャスト (エピソード 19 ) を聞いていました。Jeff と Joel は、Web サイトの成長に合わせてサーバー ハードウェアをスケーリングすることについて少し話しました。Joel が言ったことから、最初のいくつかのステップは非常に標準的です。
しかし、彼らは次に来るものについてはあまり話しませんでした. ウェブサーバーを追加しますか? 別のデータベース サーバーですか? 冗長性のために、この 3 台のマシンのクラスターを別のデータセンターに複製しますか? ハードウェア部門のここから Web スタートアップはどこへ行くのでしょうか?
「平均的な」Web アプリケーションをサポートする適切な設定は、次のように展開される可能性があります。
この時点で、現在の状況を評価すると、より適切なスケーリング パスを決定するのに役立ちます。たとえば、読み取り負荷が高く、コンテンツがあまり頻繁に変更されない場合は、キャッシングを重視し、専用のフロントエンド キャッシュを導入することをお勧めします。たとえば、Squidを使用して不要なデータベース読み取りを回避します。通常はアプリケーションでキャッシュの一貫性を維持します。
一方、コンテンツが適度に頻繁に変更される場合は、おそらくより広範なソリューションを好むでしょう。アプリケーション サーバーとデータベース スレーブをさらにいくつか導入して影響を軽減し、 memcachedなどのオブジェクト キャッシングを使用して、揮発性の低いコンテンツがデータベースにヒットするのを回避します。
ほとんどのサイトでは、これでおそらく十分ですが、世界的な現象になった場合は、地域のデータセンターにハードウェアを配置し、地理的負荷分散などのトリックを使用して、訪問者を最も近い「クラスター」に誘導することを検討することをお勧めします。 "。その時点までに、本当に細かい調整ができるエンジニアを雇えるようになるでしょう。
おそらく、私が考えることができる最も有益なスケーリングのアドバイスは、あまりにもすぐに心配することを避けることです。人々が使いたくなるようなサービスを開発し、アプリケーションを適度に堅牢にすることに専念してください。初期の簡単な最適化のいくつかは、データベースの設計がかなり堅実であること、およびインデックスがセットアップされていることを確認することです。また、データをキャッシュする方法をブラウザーに指示するキャッシュ制御ヘッダーをアプリケーションが発行することを確認してください。設計の早い段階でこの種の作業を行うと、特にキャッシュの一貫性の問題に対処するために全体をやり直す必要がない場合に、後でメリットが得られます。
私がお伝えしたい 2 番目に重要なアドバイスは、他の Web サイトで機能するものが自分にも適していると思い込んではならないということです。ログを確認し、トラフィックを分析し、アプリケーションをプロファイリングします。ボトルネックがどこにあるかを確認して解決してください。
Joel は、同じセットアップで 2 番目のデータセンターを追加し、ユーザーをそれぞれにランダムに割り当てることについて言及しました。データへの変更はログに記録され、ある場所から別の場所に送信されるため、両方の場所にすべてのデータが含まれます。
Web 2.0 Expo での Cal Henderson (Yahoo) による Scalable Web Architectures Common Patterns & Approaches の講演は非常に興味深いものでした。動画があると思ったのですが、見つかりませんでした。しかし、ここにスライドがあります：
http://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches
特定の次のステップは、Web サーバーのクラスター (Web ファーム) と、データベース サーバーのクラスター化されたシステム (レプリケーションまたは Oracle RAC など) です。
キャッシングと .Net の使用に興味がある場合は、エンタープライズ ライブラリのアプリケーション キャッシング ブロックを調べてください (もちろん、これを上記の他のポイントと一緒に使用してください)。