7.2キャパシティプランニングとスケーラビリティ

サービスの利用者が増えれば、いずれ現在のサーバー構成では処理しきれなくなります。あわてて増強するのではなく、将来の負荷を見積もり、いつ・どう拡張するかを事前に計画しておくのがキャパシティプランニングです。拡張の方向性には大きく2通りがあり、どちらを選ぶかでシステム設計そのものが変わります。

7.2.1スケールアップ／ダウンとスケールアウト／イン

• スケールアップ（垂直拡張）＝1台のマシンの性能を強化する（CPU・メモリ・ストレージの増強）。逆に減らすのがスケールダウン。実装が単純な一方、性能には物理的な上限があり、増強中はダウンタイムを伴うことが多い。
• スケールアウト（水平拡張）＝同種のマシンを台数で増やすことで処理能力を上げる。逆に減らすのがスケールイン。理論上の上限が高く、1台の追加・削除がサービス全体を止めないのが利点だが、後述のステートレス構成が前提になる。

7.2.2ステートレス構成と自動化

• ステートレス構成＝サーバー自身が状態（セッション情報など）を保持しない設計。セッション情報は特定サーバーに固定せず外部（共有ストア）に置き、DBも各Webサーバーから共有アクセスできるよう分離しておく。これによりどのリクエストがどのサーバーに届いても同じ結果が返り、サーバーの追加・削除（スケールアウト・イン）が自由になる。
• 新規マシンを迅速かつ均一に用意する仕組みとして、構成管理ツール（Ansible等・設定を自動で適用）や仮想マシンイメージ（あらかじめ必要なソフトを組み込んだテンプレート）を使い、マシン再構成の手作業を排除する。台数を増減しても構成のばらつき（構成ドリフト）が起きないことが水平拡張の実務上の生命線となる。
• リクエストを複数台へ振り分ける手段として、ロードバランサ（アプリ層で分散・死活監視や重み付けが可能）とDNSラウンドロビン（DNSが同一名に複数IPを順番に返す・単純だが死活監視ができず障害ノードへも振り続けるおそれ）がある。

典型的な失敗パターンから理解を深めましょう。あるWebアプリが「ログインセッションをアプリサーバーのメモリ上に保持」していたとします。この状態で単純にサーバーを2台に増やす（スケールアウトする）と、あるリクエストがサーバーAで処理されログインし、次のリクエストがロードバランサによってサーバーBに振られると、Bはそのセッションを知らずログアウト状態に見えるという不具合が起きます。これがまさに「ステートレスでないためスケールアウトできない」典型例です。解決策は、セッションをRedis等の共有ストアへ外部化し、どのサーバーが応答してもセッション内容を参照できるようにすることです。同様に、各サーバーがローカルにしかない設定ファイルを個別に持っていると、台数が増えるたびに手作業で設定を複製する羽目になり、構成のばらつき（ドリフト）が事故の温床になります。ここで構成管理ツール（Ansible の Playbook で全ノードへ同じ設定を冪等に適用）や、あらかじめアプリ込みで焼き込んだ仮想マシンイメージから新規ノードを即座に複製する方式が効いてきます。キャパシティプランニングでは、現在のピーク負荷・成長率・スケールアウトに要するリードタイム（新規ノードの起動から実際にトラフィックを受けられるまでの時間）を見積もり、閾値に達する前に増強を開始できるよう計画します。

7.2.3この節のまとめ

• スケールアップ/ダウン＝垂直（1台強化・上限あり）／スケールアウト/イン＝水平（台数増減・高拡張性）
• スケールアウトの前提はステートレス構成（セッション・DB外部化）＋構成管理ツール／VMイメージで均一なマシン再構成＋ロードバランサ／DNSラウンドロビンで分散