2025年6月04日·1 分
なぜ水平スケーリングは垂直スケーリングより難しいのか
垂直スケーリングはCPUやRAMを増やすだけで済むことが多い。一方、水平スケーリングは調整、パーティショニング、整合性、運用作業を必要とする――なぜ難しいのかを解説します。
垂直スケーリングはCPUやRAMを増やすだけで済むことが多い。一方、水平スケーリングは調整、パーティショニング、整合性、運用作業を必要とする――なぜ難しいのかを解説します。
スケーリングとは「落ちずにより多くを処理する」ことです。その「より多く」は例えば：
人がスケーリングについて話すとき、多くは次のどれか／複数を改善しようとしています：
多くは一つのテーマに帰着します：スケールアップは「単一システム」感を保つが、スケールアウトはシステムを独立した複数のマシンの協調に変える—そしてその協調の部分で難易度が爆発的に上がります。
垂直スケーリングは一台のマシンを強化することです。基本的なアーキテクチャは保ちつつ、サーバー（またはVM）をアップグレードします：CPUコア増加、RAM増、より高速なディスク、ネットワーク帯域の向上など。
大きなトラックを買うようなもので、運転手は一人、車両は一台のままですが、より多くを運べます。
水平スケーリングはマシンやインスタンスを追加し、処理を分割することです — 多くの場合ロードバランサの背後で動かします。一台の強いサーバーの代わりに、複数のサーバーが協調して動きます。
これは複数のトラックを使うようなもので、より多くを運べますが、スケジュールやルーティング、調整を考えなければなりません。
一般的なきっかけ：
チームはまず速いためスケールアップを行い、単一マシンが限界に達したり高可用性が必要になったときにスケールアウトします。成熟したアーキテクチャでは通常、ボトルネックに応じて大きなノードと多数のノードを組み合わせます。
垂直スケーリングはシステムを一箇所に保つため魅力的です。単一ノードではメモリやローカルな状態の単一の真実源があることが多いです。一つのプロセスがインメモリキャッシュ、ジョブキュー、セッションストア（メモリ内にセッションがある場合）、一時ファイルを所有します。
一台のサーバーだと運用は単純です：
スケールアップでは馴染みのあるレバーを引くだけです：CPU/RAM追加、高速ストレージ、インデックス改善、クエリや設定のチューニング。データの分散方法や複数ノードで「次に何が起きるか」を合意させる設計をやり直す必要はありません。
垂直スケーリングは「無料」ではありません — ただし複雑さが局所化されます。
いずれ限界に達します：借りられる最大インスタンス、収益逓減、または高額なコストカーブ。さらに冗長化を入れていなければ、一台が死ぬかメンテナンスされるとシステムの大部分が停止するリスクが高まります。
スケールアウトすると「サーバーが増える」だけではありません。独立した複数のアクターが増え、それぞれがどの仕事をいつどのデータで処理するか合意しなければなりません。
一台では調整は暗黙です：単一のメモリ空間、単一プロセス、状態を見るべき一箇所。多数のマシンでは調整が機能として設計されます。
一般的なツールやパターン：
調整バグはきれいなクラッシュのようには見えません。多くは次のような現象です：
これらは本番負荷、デプロイ、あるいは部分障害（ノードが遅い、スイッチがパケットを落とす、ゾーンが一時的に落ちる）で初めて顕在化することが多いです。見た目は大丈夫でも、実際に負荷をかけると破綻します。
スケールアウトでは多くの場合、すべてのデータを一か所に置けません。複数マシンに分割（シャード）して並列で保存・提供します。ここでの問題は「このレコードはどのシャードにあるのか？」にすべての読み書きが依存することです。
レンジパーティショニングは順序付きキーでデータをグループ化します（例：ユーザーA〜Fはシャード1、G〜Mはシャード2）。直感的で範囲クエリに向く一方、負荷が偏ると一つのシャードがボトルネックになります。
ハッシュパーティショニングはキーをハッシュしてシャードに分散します。トラフィックは均等になりやすいですが、関連レコードが散らばるため範囲クエリが難しくなります。
ノードを追加したらそのキャパシティを使いたい＝一部データを移動する必要がある。ノードを削除したら（計画的でも障害でも）他のシャードが引き継ぐ。リバランスは大量の転送、キャッシュのウォームアップ、一時的な性能低下を引き起こす可能性があります。移行中に古い読み取りや誤ルーティングを防ぐ必要もあります。
ハッシュを使っても実際のトラフィックは均一ではありません。著名人のアカウント、人気商品のページ、時間帯に依存したアクセスパターンが特定シャードに負荷を集中させます。1つのホットシャードがシステム全体のスループットを制限します。
シャーディングは継続的な責務を生みます：ルーティングルールの維持、マイグレーションの実行、スキーマ変更後のバックフィル、クライアントを壊さずにスプリット／マージを計画することなど。
スケールアウトではアプリを複数コピーして動かすことになります。難しいのは「状態」です：アプリがリクエスト間や処理中に「覚えている」ものすべて。
ユーザーがサーバーAでログインして次のリクエストがサーバーBに行ったら、Bはそのユーザーを認識できるか？
キャッシュは高速化しますが、複数サーバーでは複数のキャッシュが存在します。問題点：
多くのワーカーがいるとジョブが二度実行される可能性があります。対策としてはキュー、リース／ロック、または冪等なジョブロジックが必要です。
単一ノード（または単一のプライマリDB）では通常明確な「真の状態」があります。スケールアウトするとデータやリクエストが複数マシンに散るため、全員を同期させ続けることが常に問題になります。
最終的整合性はスケール時により高速で安価なことが多いが、驚くようなエッジケースを生む。
よくある問題：
失敗を完全に排除することはできないが、ダメージを小さくする設計は可能：
サービス横断のトランザクション（注文＋在庫＋支払い）は複数のシステムが合意する必要がある。途中で一つが失敗したら補償アクションや慎重な記録が必要。ネットワークやノードが独立して失敗する環境での全か無かの振る舞いは難しい。
正確である必要がある領域（支払い、口座残高、在庫数、座席確保）では強整合性を使う。分析やレコメンドのような非批判的データは最終的整合性で許容されることが多い。
スケールアップでは多くの呼び出しが同プロセス内の関数呼び出しで完結するため高速で予測可能です。スケールアウトでは同じ操作がネットワーク呼び出しになり、レイテンシ、ジッタ、失敗モードが増えます。
ネットワーク呼び出しには固定オーバーヘッド（シリアライズ、キューイング、ホップ）と変動オーバーヘッド（輻輳、ルーティング、ノイジーネイバー）がある。平均遅延が許容範囲でも、テールレイテンシ（遅い上位1〜5%）がユーザー体験を支配することがある。
帯域やパケットロスも制約になります：高リクエスト率では小さなペイロードが積み重なり、再送が静かに負荷を増やします。
タイムアウトがないと遅い呼び出しが積み上がりスレッドが詰まります。タイムアウトとリトライがあると回復できるが、リトライが負荷を増幅してしまうことがある。
一般的な失敗パターンはリトライ嵐です：バックエンドが遅くなりクライアントがタイムアウトしてリトライ、リトライでさらに負荷が増え、バックエンドがさらに遅くなる。
安全なリトライには通常：
複数インスタンスではクライアントがどこに送るかを知る必要があり、ロードバランサやサービスディスカバリ＋クライアントサイドバランシングを使います。これによりヘルスチェック、コネクションドレイン、不均衡なトラフィック、半壊インスタンスへのルーティングといった可動部品が増えます。
過負荷の伝播を防ぐためにバックプレッシャ（有界キュー、サーキットブレーカー、レート制限）が必要です。目的は遅延を広げてシステム全体の事故につなげるよりも、失敗を速やかに予測可能にすることです。
垂直スケーリングは故障が比較的単純です：大きな機械が故障すると影響は明白です。
水平スケーリングでは数学が変わります。多数ノードでは「一部のマシンが不健康で他は正常」という状態が普通になります。システムは「稼働」しているがユーザーはエラーや遅延、不一致を体験する――これが部分障害であり、これを設計前提にする必要があります。
スケールアウト環境ではサービスが他サービスに依存します：DB、キャッシュ、キュー、下流API。小さな問題が波及することがあります：
キューが詰まり、キャッシュがミスし、下流APIが叩かれる。
部分障害に耐えるために冗長化を入れる：
可用性は上がるがエッジケース（スプリットブレイン、古いレプリカ、クォーラムが取れない状況での判断）も増える。
よく使うパターン：
単一マシンでは「システムの物語」は一箇所にあります：ログもCPUグラフも一つ。水平スケーリングではその物語が散らばります。
各ノードを増やすごとにログやメトリクス、トレースが増えます。集めるのが難しいわけではなく、相関させるのが難しいのです。チェックアウトエラーはウェブノードから始まり二つのサービスを呼び、キャッシュに当たり特定のシャードから読み取る――手がかりが異なる場所やタイムラインに残ります。
問題は選択的に発生することが増えます：あるノードだけ設定が悪い、あるシャードだけホット、あるゾーンだけ遅い。デバッグは「たまたま動くことが多い」ためランダムに感じられます。
分散トレーシングはリクエストに追跡番号を付けるようなものです。相関IDはその番号で、サービス間を渡りログに含めることで一つのIDからエンドツーエンドの旅程を見られるようにします。
コンポーネントが増えるとアラートも増えます。チューニングしないとアラート疲れになります。狙いはアクションにつながるアラートで、次を明確にすること：
容量問題は障害より先に現れることが多い。CPU、メモリ、キュー深度、コネクションプール使用率など飽和指標を監視してください。もし一部のノードだけで飽和が見えるなら、負荷分散やシャーディング、設定差分を疑いましょう。
スケールアウトではデプロイは「一台置き換える」作業ではなくなります。多数のマシンに渡る変更を調整しつつサービスを可用に保たねばなりません。
水平デプロイではローリング更新（徐々にノードを置き換える）、カナリア（少量のトラフィックを新バージョンに流す）、ブルー/グリーン（2つの完全環境間で切替）の手法を使います。これらはブレード半径を減らしますが、トラフィックシフト、ヘルスチェック、コネクションドレイン、進行基準（次に進むための“十分に良い”の定義）などの要件を増やします。
段階的デプロイ中は旧バージョンと新バージョンが混在します。これにより混在許容が必要になります：
APIは後方／前方互換を持つ必要があります。DBスキーマ変更は可能な限り増分に（nullableカラム追加→データ移行→必須化の順）。メッセージフォーマットはバージョン化して古いイベントも消費できるようにします。
コードのロールバックは容易だがデータのロールバックは難しい。マイグレーションでフィールドを削除・書き換えると古いコードはクラッシュしたりレコードを誤処理する。"拡張→収縮" のマイグレーション戦略が推奨されます：まず両方のスキーマをサポートするコードをデプロイ、データを移行、最後に古い経路を削除。
多数ノードでは設定管理がデプロイの一部になります。1台のノードだけ古い設定や間違ったフラグ、期限切れの認証情報を持つとフレーキーで再現しにくい障害を生みます。
水平スケーリングは一見安く見えることがあります：小さなインスタンスが多数、単価は低い。しかし総コストはコンピュートだけではありません。ノードを増やすとネットワーク、監視、調整、整合性維持にかかる時間も増えます。
垂直は支出を少数のマシンに集中させることが多く、パッチ適用、エージェント、ログ輸送、メトリクス収集の対象が少なくて済みます。
スケールアウトでは単位当たりの価格は低くても、次のようなコストが発生します：
スパイクに安全に対応するために分散システムはしばしば遊休を抱えます。複数の階層でヘッドルームを確保するため、無駄なアイドルキャパシティに課金されることがあります。
スケールアウトはオンコール負荷を増やし、成熟したツール群を必要とします：アラート調整、ルンブック、インシデント訓練、教育。チームは所有範囲（誰がどのサービスを担当するか）や障害時の調整にも時間を割きます。
その結果、「単位当たりは安い」が人件費、運用リスク、そして多くのマシンを一つのシステムのように振る舞わせるための作業を含めると総コストは高くなることが多いです。
スケールアップ vs スケールアウトの判断は単に価格の問題ではありません。ワークロードの性質とチームが吸収できる運用複雑さの量に依存します。
ワークロードから始めてください：
一般的で合理的な道筋：
多くのチームはステートレスなアプリ層を水平スケールしつつ、データベースは垂直（または軽いクラスタリング）に保つことでシャーディングの痛みを減らしつつウェブキャパシティを迅速に増やします。
堅牢な監視・アラート、テストされたフェイルオーバー、負荷試験、繰り返し可能なデプロイと安全なロールバック手順が整っているならスケールアウトに近づいています。
多くのスケーリングの痛みは単なる「アーキテクチャ」の問題だけでなく、運用ループ：安全に反復し、信頼してデプロイし、計画と現実が食い違ったときに素早くロールバックする能力に起因します。
ウェブ、バックエンド、モバイルシステムを構築していて、迅速に進めながらコントロールを失いたくないなら、Koder.aiはプロトタイプ作成とローンチを速め、スケールの判断を支援します。チャットを通じてアプリを構築するヴァイブコーディングプラットフォームであり、エージェントベースのアーキテクチャを採用しています。実際にできることの例：
Koder.aiはAWS上でグローバルに動作するため、レイテンシやデータ転送の制約に応じた複数リージョンへのデプロイもサポートできます。マルチゾーン／マルチリージョン可用性がスケーリングストーリーの一部になる場面で有用です。
垂直スケーリングは単一のマシンを大きくする（CPU/RAM/ディスクを増やす）ことを意味します。水平スケーリングはマシンを増やして処理を分散させることです。
垂直はシステムが「一つのシステム」のまま振る舞うため単純に感じられ、水平は複数のシステムが調整・一貫性を保つ必要があるため複雑になります。
複数のノードが存在すると、明示的な調整が必要になるからです：
単一マシンではこれらの分散システム問題の多くが暗黙的に回避されます。
多数のマシンを一つのシステムのように振る舞わせるために費やす時間とロジックのことです：
各ノードが単純でも、負荷や障害時の全体挙動は理解しにくくなります。
シャーディング（パーティショニング）はデータを複数ノードに分割するため、次のような課題があります：
またマイグレーションやバックフィル、シャードマップの維持といった運用負荷も増えます。
アプリがリクエスト間や処理中に「覚えている」もの全般を指します（セッション、インメモリキャッシュ、一時ファイル、ジョブの進行状況など）。
水平スケールではリクエストが別のサーバーに飛ぶため、共有ストア（RedisやDB）を使うか、スティッキーセッションなどのトレードオフを受け入れる必要があります。
複数のワーカーが同じジョブを取得できると二重処理が起きます（重複請求や二重メール送信など）。
一般的な対策：
強整合性は書き込み成功後、すぐにすべてのリーダーが最新値を見るという保証です。最終的整合性は更新が徐々に伝播するため短時間古い値を読むことがあります。
支払い、残高、在庫のような正確性が必須の領域は強整合性を、分析やレコメンデーションのように多少の遅延が許される領域は最終的整合性で運用することが多いです。
分散システムでは呼び出しがネットワーク越しになるため、遅延やジッタ、失敗モードが増えます。
主要な対応：
部分的障害は一部のコンポーネントが遅い／壊れている状態を指し、スケールアウト環境ではこれが「通常」の状態になります。システム全体は稼働していてもユーザーはエラーや遅延を体験します。
対策としてはレプリケーション、クォーラム、マルチゾーン配置、サーキットブレーカー、グレースフルデグラデーションなどがあります。
多くのサーバーにまたがると証跡が分散します：ログ、メトリクス、トレースが別々のノードに残るため、調査の文脈が欠けやすくなります。
実務的な対処：