クラウドの「スケールアウト vs スケールアップ」——水平・垂直スケーリングの設計

サービスが成長すると、サーバーが処理できるリクエスト数の上限に近づき始める。この問題への対処法として「スケーリング」が必要になる。スケーリングには大きく2つのアプローチがある。サーバーのスペックを上げる「垂直スケーリング（スケールアップ）」と、サーバーの台数を増やす「水平スケーリング（スケールアウト）」だ。どちらを選ぶかはシステムのアーキテクチャ、コスト、可用性要件によって大きく異なる。

垂直スケーリング（スケールアップ）

垂直スケーリングは既存のサーバーのリソースを増強する方法だ。CPUのコア数を増やす、メモリを追加する、SSDをより高速なものに換える、といった操作が該当する。クラウド環境では、EC2インスタンスのインスタンスタイプを t3.medium から m5.xlarge に変更するといった操作だ。

垂直スケーリングの利点

設定変更だけで対応できる場合が多く、アプリケーションコードの変更が不要な点が最大の利点だ。データベースのように状態を持つコンポーネントは水平スケーリングが複雑になるため、まず垂直スケーリングを検討するのが合理的だ。小規模なサービスや、突発的なトラフィック増加への短期対応としても有効だ。

垂直スケーリングの限界

ハードウェアの物理限界: CPUのコア数もメモリ容量も物理的な上限がある。最大構成のインスタンスに到達してしまえば、それ以上スケールできない。

コストの非線形性: リソースを2倍にしてもコストが2倍以上になるケースがある。最上位の高スペックインスタンスは割高になる傾向がある。

単一障害点: 1台のサーバーに依存しているため、そのサーバーに障害が発生するとサービス全体が停止する。可用性の向上には別途冗長化設計が必要だ。

停止時間: インスタンスタイプの変更にはサーバーの再起動が必要な場合が多く、ダウンタイムが発生する。

水平スケーリング（スケールアウト）

水平スケーリングは同スペックのサーバーを複数台並べることでキャパシティを増やす方法だ。ロードバランサーがトラフィックを各サーバーに分散し、どのサーバーへリクエストが割り当てられても同じ結果を返す必要がある。

水平スケーリングのための設計原則

水平スケーリングを実現するには、アプリケーションが「ステートレス」でなければならない。これが最も重要な設計上の要件だ。

ステートフルなアプリケーションの問題: ユーザーAのセッション情報がサーバー1のメモリに保存されている場合、次のリクエストがサーバー2に割り当てられると「セッションが見つからない」という問題が発生する。

ステートレス設計の実現方法:

• セッション情報のRedis外部化: セッションをRedis（またはMemcached）に保存することで、どのサーバーがリクエストを処理してもセッション情報にアクセスできる
• JWT（JSON Web Token）の活用: 認証情報をサーバー側のセッションではなくJWTとしてクライアントに持たせることでステートレス化できる
• ファイルアップロードの外部ストレージ化: ユーザーがアップロードしたファイルをローカルディスクではなくS3等のオブジェクトストレージに保存する

オートスケーリング

クラウドの水平スケーリングの真の価値は、オートスケーリングにある。CPU使用率やリクエスト数などのメトリクスを監視し、閾値を超えたら自動的にインスタンスを追加し、負荷が下がれば削除する仕組みだ。

AWSのAuto Scaling Groups、Google CloudのManaged Instance Groups、AzureのVirtual Machine Scale Setsがこれに該当する。予測されるトラフィックパターン（昼間に多く夜間に少ない等）に合わせてスケジュールベースのスケーリングも設定できる。

水平スケーリングの課題

データの整合性: 複数のサーバーが同じデータベースを参照する場合、書き込みの競合やキャッシュの整合性問題が発生する可能性がある。

分散トランザクション: 複数サーバーにまたがる処理でACIDを保証するには複雑な仕組み（2フェーズコミットやSagaパターン）が必要だ。

デバッグの複雑さ: 複数のサーバーにログが分散するため、問題の調査が難しくなる。分散トレーシング（Jaeger、Zipkin等）の導入が重要になる。

AI推論サービスへの適用

LLMや画像生成モデルの推論サービスは特殊なスケーリング要件を持つ。

GPU制約: 大規模モデルの推論にはGPUが必須で、GPUインスタンスは高コスト。需要に応じた動的なスケーリングでコストを最適化する必要がある。

モデルのロード時間: LLMのモデルは数GB〜数十GBのサイズで、GPUへのロードに数十秒かかる。オートスケーリングで新しいインスタンスを追加しても、すぐに使用可能にならない「ウォームアップ問題」がある。これに対しては最小インスタンス数を0にせずに一定数を常時稼働させる設定や、コンテナイメージにモデルをビルドインする手法が採られる。

バッチ処理 vs リアルタイム処理: 低遅延が必要なリアルタイム推論と、スループット優先のバッチ推論では最適なスケーリング戦略が異なる。

スポットインスタンスの活用: 非同期処理やバッチ推論にはスポットインスタンス（AWS）や事前予約インスタンスを使うことでコストを大幅に削減できる。ただしスポットインスタンスは中断される可能性があるため、チェックポイント機能が必要だ。

実践的なスケーリング判断フレームワーク

スケールアップとスケールアウトを選択する際の実践的な考え方を整理する。

1. まずスケールアップを試みる: データベースや、ステートフルでスケールアウトが困難なコンポーネントは垂直スケーリングが現実的
2. アプリケーション層はスケールアウト設計を優先: ステートレス設計を維持し、水平スケーリングの恩恵を最大限受ける
3. ボトルネックを測定してから判断する: 問題がCPU不足なのか、メモリ不足なのか、ネットワーク帯域なのか、DBの応答速度なのかを計測し、適切な対策を選ぶ

---

まとめ

垂直スケーリングはシンプルだが物理限界と単一障害点という制約がある。水平スケーリングは理論上無制限の拡張が可能だが、ステートレス設計とセッション管理の外部化が前提条件となる。クラウドのオートスケーリングを活用することでトラフィックに応じた動的なキャパシティ調整が可能になる。AI推論サービスでは、GPUインスタンスのコストとモデルのウォームアップ時間という特有の課題があり、最小インスタンス数の設定やスポットインスタンスの活用が重要な最適化戦略となる。スケーリングの選択はアーキテクチャ設計の根幹であり、サービス初期から意識して設計することが望ましい。