開発者がリリースしたばかりのアプリが、数千人のユーザーが「開始」をクリックした瞬間に動作が重くなるのを目の当たりにすることがあります。その減速の原因は、コードのバグであることは稀です。実際には、サーバーのCPUとRAMがリソースを奪い合っているのです。このボトルネックは、ページの読み込み時間の増大、タイムアウト、あるいは完全なクラッシュとして現れ、ユーザーエクスペリエンス、収益、そしてブランドへの信頼を損ないます。

なぜ検証環境で順調に動いていたサーバーが、本番環境で停止してしまうのか

開発段階では、一人の開発者が数件のリクエストを送るだけなので、サーバーのリソースはほとんどの時間アイドル状態（待機状態）です。しかし、アプリがライブ公開されると、すべての訪問者がリクエストを生成します。そのリクエストには、2つの主要な要素が必要です。

  • CPU (central processing unit) – すべてのループ、関数、計算を実行するプロセッサです。一度に調理できる料理の数が限られているシェフだと考えてください。1つの注文なら即座に提供されますが、100の注文が来ると、シェフの作業スピードは同じでも、食事を待つ客の時間は長くなります。
  • RAM (random-access memory) – リクエストを処理している間にCPUが必要とするデータの、一時的な保存場所です。これは、シェフが各料理の材料を置いておくデスクのようなものです。デスクがいっぱいになると、スペースが空くまでシェフは新しい注文を受けることができなくなります。

数千人のユーザーが同時にログインすると、各リクエストが独自のCPU時間とRAMの領域を占有します。サーバーが持つ有限なリソースのプールがリクエスト間で分割されるため、待ち行列（キュー）が膨れ上がります。サーバー自体が遅くなったわけではなく、各リクエストの待ち時間が増加したのです。

「もっと大きなマシンを買えばいい」という誘惑

よくある最初の反応は、マシンをアップグレードすることです。これは**垂直スケーリング（vertical scaling）**と呼ばれる手法です。CPUコア数を増やしたり、RAMを増設したりすることで、容量を改善することは可能です。例えば、4コアから16コアへ、あるいは8GBから64GBへと増やすことで、コードを変更することなく、急激なトラフィックの増加を吸収できます。

しかし、垂直スケーリングには明確な限界があります。

  • 物理的な限界 – すべてのマザーボードには、搭載できるコア数やメモリ量に限りがあります。
  • 収穫逓減 – コアやギガバイトを追加するごとにコストは以前よりも高くなりますが、それに対するパフォーマンスの向上幅は小さくなっていきます。
  • 単一障害点 – もしその巨大なサーバーがダウンすれば、サービス全体が消失してしまいます。

こうした制約があるため、ストリーミングプラットフォームや検索エンジン、Eコマースサイトといった業界の巨人たちは、単一の巨大なマシンに頼る手法から脱却しています。

代替案：多くの小さなマシンに負荷を分散させる

より高いタワーを建てる代わりに、運用者は適度なサイズのサーバーを複数追加し、トラフィックを共有させます。この**水平スケーリング（horizontal scaling）**というアプローチにより、各マシンを快適なパフォーマンス範囲内に保ち、垂直アップグレードによる指数関数的なコスト増加を回避できます。

多数のマシンを調整するには、**ロードバランサー（load balancer）**が必要です。これは、すべての着信リクエストを受け取り、最も空き容量のあるサーバーに転送するソフトウェアまたはハードウェアです。ロードバランサーはクライアントから複雑さを隠蔽します。ユーザーの視点からは、サイトは依然として単一のエンドポイントであるように見えます。

また、水平スケーリングはレジリエンス（回復力）ももたらします。もし一つのノードがクラッシュしても、ロードバランサーは単にトラフィックを他の健全なノードへとルーティングするため、サービスを維持し続けることができます。

マシンを追加し始める際に注意すべきこと

  • ステートレスな設計（Stateless design） – リクエストが特定のサーバーのメモリ内にのみ保存されたデータに依存してはいけません。そうでなければ、ユーザーが、必要なコンテキスト（文脈情報）を持っていない別のノードに飛ばされてしまう可能性があります。共有キャッシュやデータベースを使用することで、この問題は解決できます。
  • ヘルスチェック（Health checks） – ロードバランサーは、故障したサーバーを迅速に検出し、そこへのトラフィック送信を停止できなければなりません。
  • オートスケーリング・ポリシー（Auto-scaling policies） – 多くのクラウドプラットフォームでは、しきい値（CPU使用率、リクエストのレイテンシなど）を定義して、インスタンスを自動的に起動またはシャットダウンさせ、コストを需要に合わせることができます。

反論：垂直スケーリングは終わったわけではない

小規模なチームやトラフィックの少ないアプリにとって、単一の強化されたサーバーが最もシンプルで安価な解決策になることもあります。トラフィックの急増が予測可能な場合（例：予定された製品発表など）、大量の新しいインスタンスを準備するよりも、一時的な垂直アップグレードの方が実用的な場合もあります。

重要なのは、「より大きなマシン」という手法が比例した価値を提供しなくなるタイミングを見極め、分散化に向けた計画を立て始めることです。

まとめ

リリース後のサーバーの低速化は、通常、コードの欠陥ではなく、リソース競合の問題です。CPUサイクルやRAMスロットには限りがあり、大量のリクエストが同時に到着するとそれらはキューに溜まり、レスポンスタイムが長くなります。垂直スケーリングによって多少の余裕は生まれますが、すぐに物理的および経済的な限界に突き当たります。ロードバランサーの背後に小規模なサーバーを追加していく水平スケーリングは、トラフィックの増加に対して、より安価でレジリエンスの高い手法となります。キューが長くなっていることに気づいた瞬間こそ、コアを数個増やすだけで十分なのか、それとも多くのマシンに負荷を分散し始めるべきなのかを評価すべきタイミングです。

出典: dev.toの記事 “Why Servers Slow Down – CPU, RAM and the hidden cost of every request.”