別のサーバーを追加するタイミング
Webアプリケーションへのサーバーの追加（または追加を検討）を開始する適切な時期はいつですか？単一のサーバー（DBおよびWeb）から複数のサーバーに移行する際の問題は何ですか？
例えば：
ほとんど DBとWebの両方に使用する1つのサーバーから開始し、DB/Webを別のサーバーに分割してから、複数のWebサーバー（セッションの問題を作成します）に移動し、場合によってはNAS DBなどの場合）.
Webアプリケーションへのサーバーの追加（または追加を検討）を開始する適切な時期はいつですか？ ...（単一のサーバーから...複数へ）
考えてみてください：最初から。
追加を開始：最初の「サーバーがビジーすぎます」エラーが発生したとき。それよりも早いのは時期尚早の最適化です。
（Webアプリがミッションクリティカルでない限り、その場合、おそらく最初から始めているわけではなく、serverfault.comコミュニティをポーリングする必要はありません。）
しかし、真剣に、現代の消費者向けWebアプリケーションの場合、「サーバーがビジーすぎる」ことは、実際には良いことになる可能性があります。 Facebook、Twitter、YouTubeを傷つけることはありません。サーバーの追加が早すぎると、アプリが期待したほど人気がなくなり、機能開発に費やされた可能性のあるお金を無駄にしてしまうという危険性があります。
あなたが実際にヒットしたウェブプロパティを持っている幸運な数少ない人の一人なら、（a）おめでとうございます、そして（b）ログファイルから平均応答時間を測定することができ、よりメトリック主導型にすることができますサーバーを追加するアプローチ。
個人的には、私は常にDBサーバーとは別のWebサーバーから始めます。
（IIS6およびSQL Serverに基づく）
- データベースは、リソース（RAM、DISK、CPU）をかみ砕いて、Webサーバーと競合するだけです。これにより、Webサーバーが応答しなくなり、データベースが「不良」に見える可能性があります。
- セキュリティ。必要以上に「エッジ」を利用するのは良い考えではありません。 DBをDMZの内側に移動し、SQLトラフィック用にファイアウォールに非標準の穴（1433ではない）を突き刺します。
- 役割の分離。これで、CPUを噛み砕いているのがDBなのかIIS）なのか、それともアプリケーションなのかがわかります。
ただし、これはすべてvmwareサーバー（実際には3ノードクラスター）で実行し、Webサーバーとdbサーバーには1つのvCPUと1GBのRAMしかありません。そして、彼らはあまり汗をかくことなく、かなり忙しい一連のWebサイト（外部およびイントラネット）をサポートします。
しかし、人気が急上昇したかどうかはわかっています（そして、いつか可能性があります発生する可能性があります！）RAMとCPU 。
実用的な注意事項：時間の経過とともにパフォーマンスを監視します。変更を追跡し、積極的に行動します。
Webアプリケーションへのサーバーの追加（または追加を検討）を開始する適切な時期はいつですか？
アプリケーションを設計するとき。複数のサーバーを使用するように設計されていないアプリケーションが多すぎて、後で恐ろしいリバースエンジニアリングを行うのを見てきました。
複数のサーバーでもテストするようにしてください。再び。多くのアプリケーションが開発/テストで正常に動作し、ロードバランサーやファイアウォールを処理できなかった、マルチキャストが考慮されていなかったなどの理由で本番環境で失敗するのを見てきました。
また、別のサーバーを追加する時期は、容量管理の統計で、別のサーバーを追加するのにかかる時間のすぐ後に容量が不足することが示されている場合です。
Cpacity統計を収集していますか？番号？次に、アプリケーション開発者やインフラストラクチャ管理者と話し合うもう1つのこと。
実際に「サーバーがビジー状態になる」まで待って、ユーザーを苛立たせることが正しいことであることに同意しません。新しいサーバーを実稼働環境に追加するのは時間のかかるプロセスになる可能性があり、エラーが発生するまで待ってから開始するのは賢明ではありません。
他の人が言っているように、質問は曖昧ですが、それに対する非常に簡単な答えが本当にあります：
現在のサーバーの制限によりコストがかかり始めたら、別のサーバーを追加する必要があります。
無料のサービスを提供している場合、サーバーを追加するインセンティブは実際にはありません。
サービスから収益を上げている場合は、費用便益分析を行うことができます。サーバーを追加するとパフォーマンスがどのように向上し、どのくらいの利益が得られるでしょうか。
実行する必要があることの1つは、既存の1サーバーアプリケーションの負荷テストを行って、一度にサポートできるセッションとユーザーの数を確認することです。それがわかれば、同じ指標を長期にわたって監視できます。数が既知の制限に近づき始めたら、展開用の新しいハードウェアの準備を開始します。既存のシステムが制限に達する前に展開できるように、追加のサーバーのリードタイムを考慮する必要があります。これは非常に一般的な概要であり、詳細はJohnAllspawの著書「TheArtofCapacityPlanning」で非常によく説明されています。
そうは言っても、データベースサーバーとWebサーバーを出発点として独自のシステムに分割し、それぞれの負荷テストを行って理論上の負荷を決定します。通常、Webサーバーが最初にボトルネックになるため、アプリケーションはスケーラビリティを念頭に置いて作成する必要があります。質問はセッションについて言及しています。使用しているプラットフォームに応じて、サーバー間でセッションを共有したり、中央データベースに保存したり、使用できなくなった場合を除いて同じユーザーを同じサーバーに誘導する負荷分散ハードウェアを使用したりする方法がいくつかあります何らかの理由で。
しかし、「いつそれを行うべきかをいつ知るか」という中心的な質問に答えるために、それはあなたが収集し、負荷テストを通じて到達した既知の制限とそれらを比較することに関するすべてです。
アプリケーションが何であるかについての詳細情報がなければ、具体的なアドバイスを与えるのは難しいですが、LiveJournalのインフラストラクチャに関するBrad Fitzpatrickによる2005年のプレゼンテーションのスライドをいくつか示します（データベースの負荷分散に重点を置いています）。
一般に、1つから複数のフロントエンドに移行することは、フロントエンドを（通常はデータベースの）バックエンドから分離するよりも注意が必要です。ただし、ロードバランサーと「スティッキー」セッションを注意深く使用すると、この移行が容易になります。
「いつ」に関しては、それを見つけるための鍵は、Web（およびデータベース）サーバーのパフォーマンスを測定することです。理想的には、現実的なトラフィック負荷のあるテストベンチで、パフォーマンスが「不十分」に陥る場所を確認します。ライブサイトの負荷が「不十分」に近づき始めたら、新しいフロントエンドを注文します。
新しいサーバーが必要になる時期と、時間の経過とともにトラフィック量がどのように増加するかが大まかにわかっている場合は、必要になる直前に新しいサーバーを展開することを目指すことができます。残念ながら、これらのことはあなたのセットアップの詳細に非常に依存しているので、私はあなたに難しい数字を与えることはできません。