水平スケーリング
サーバーの台数を増やして処理能力を向上させるスケーリング手法
水平スケーリングとは
水平スケーリング (Scale Out) は、サーバーの台数を増やして処理能力を向上させるスケーリング手法である。垂直スケーリング (Scale Up: サーバーのスペックを上げる) と対比される。
水平 vs 垂直
水平と垂直の違いを以下にまとめる。
| 観点 | 水平 (Scale Out) | 垂直 (Scale Up) |
|---|---|---|
| 方法 | 台数を増やす | スペックを上げる |
| 上限 | 理論上無限 | ハードウェアの上限 |
| コスト | 台数に比例 | 容量に比例 |
| 可用性 | 1 台が落ちても継続 | 単一障害点 |
| 複雑さ | 分散システムの課題 | シンプル |
AWS サービスのスケーリング
AWS サービスのスケーリングを以下に示す。
| サービス | スケーリング方式 |
|---|---|
| Lambda | 自動水平スケーリング (同時実行数) |
| DynamoDB | 自動水平スケーリング (パーティション) |
| ECS | Auto Scaling (タスク数) |
| EC2 | Auto Scaling Group |
| Aurora | リードレプリカの追加 |
Lambda の水平スケーリング
Lambda の水平スケーリングを図で示す。
リクエスト 1 → Lambda インスタンス A
リクエスト 2 → Lambda インスタンス B
リクエスト 3 → Lambda インスタンス C
→ リクエスト数に応じて自動的にインスタンスが増加
→ 台数の管理は不要 (ただし増やせる速度と総量には AWS 側の上限がある)
台数を自分で決めなくてよいだけで、無制限に増えるわけではない。2026 年 8 月時点の公式ドキュメントでは、1 つの AWS アカウントがリージョンごとに使える同時実行数はデフォルトで全関数あわせて 1,000 で、それ以上はクォータ引き上げの申請が必要になる。増え方にも速度の制限があり、オンデマンド同時実行で動く関数は 10 秒あたり 500 同時実行、または 10 秒あたり 5,000 リクエスト/秒のうち先に到達する側までしか一気に伸びない。秒間数千リクエストが一斉に立ち上がる設計では、この速度制限を超えた分がスロットリングされる。自動でスケールするから何も考えなくてよいのではなく、想定ピークの同時実行数を先に見積もってクォータと突き合わせておく。
水平スケーリングの前提条件
水平スケーリングにはいくつかの前提がある。プロセス内に状態を持たないステートレス設計、セッションやファイルを外部ストレージに保存する共有ストレージ、同じリクエストを複数回処理しても同じ結果になる冪等性、リクエストを均等に分散するロードバランシングだ。
ステートレス設計
ステートレス設計のコード例を示す。
// ❌ ステートフル: プロセス内にセッションを保存
const sessions = new Map(); // Lambda インスタンスごとに異なる
// ✅ ステートレス: 外部ストレージに保存
const session = await db.get({ TableName: 'sessions', Key: { id: sessionId } });
DynamoDB の水平スケーリング
DynamoDB の水平スケーリングを図で示す。
パーティションキー: userId
→ ハッシュ値でパーティションに分散
→ パーティション数が自動的に増加
→ 各パーティションが独立して処理
❌ ホットパーティション: 1 つのキーにアクセスが集中
✅ 均等な分散: ユーザー ID のように分散するキー
コスト比較
コスト比較を図で示す。
垂直: t3.micro → t3.xlarge → t3.2xlarge
約 $7.6/月 → 約 $121/月 → 約 $243/月 (サイズ 1 段ごとに約 2 倍)
水平: t3.micro × N 台
約 $7.6/月 × 2 = 約 $15/月, × 4 = 約 $30/月 (台数に比例)
上の金額は 2026 年 8 月時点の米国東部 (バージニア北部) の Linux オンデマンド料金を月 730 時間で換算した目安で、リージョンや購入方式が変われば額も変わる。押さえておきたいのは金額そのものより増え方だ。同じインスタンスファミリーの中ではサイズを 1 段上げるごとにメモリと料金が倍になり、料金もほぼ正確に倍になる。単位性能あたりの単価は垂直と水平でほとんど差がなく、垂直が指数関数的に高くつくという説明は少なくとも同一ファミリー内では当たらない。垂直の本当の制約はコストの伸び方ではなく、ファミリーの最大サイズという天井、サイズ変更に停止を伴うこと、1 台構成ゆえにその 1 台の障害が全停止になること、の 3 点にある。一方で水平側も増えるのは計算資源の料金だけではなく、ロードバランサーやデータストアへの接続数、監視する台数も一緒に増える。
理論と実装の両面から学ぶなら関連書籍が参考になる。
この記事は役に立ちましたか?
関連用語
関連する記事
インフラ / クラウド本ガイド - AWS や Docker を本で学ぶ
クラウドインフラ、コンテナ、IaC を学べる技術書の選び方と学習順序を紹介。インフラ本の賞味期限問題と公式ドキュメントとの使い分けも解説します。
チーム開発 / マネジメント本ガイド - 技術リーダーが読むべき本
チーム開発、1on1、技術マネジメントを学べる技術書の選び方を紹介。メンバー時代からマネージャーまで、段階別の読書ロードマップを解説します。
技術書の読む順番戦略 - 複数冊を組み合わせて理解を加速させる
技術書を 1 冊ずつ読むのではなく、複数冊を戦略的に組み合わせることで、1 冊では届かない理解の深さと広さに達する方法を解説します。