スケーリング

概要

スケーリングとは、利用者やデータ量の増加に合わせて、システムの処理能力を引き上げていくことです。サービスが成長すると、最初は余裕だった サーバ がやがて悲鳴を上げます。レスポンスが遅くなり、ピーク時にはエラーが返り始める——そのときに取れる手段が「スケーリング」であり、その手段には大きく二つの方向があります。

一つは、サーバそのものをより強力な機械に替える垂直スケーリング（スケールアップ）。CPU を増やし、メモリを積み、より速いディスクにする方向です。もう一つは、同じ役割のサーバの台数を増やす水平スケーリング（スケールアウト）。1台で捌けないなら10台で分担しよう、という方向です。

「スケーラビリティ（拡張性）」という言葉は、単に今速いかどうかではなく、「負荷が10倍・100倍になったとき、資源の追加だけで追随できる設計になっているか」を指します。設計段階でこの性質を織り込めるかどうかが、成長するサービスの命運を分けます。

なぜ生まれたか

Web 以前のシステムは利用者数がほぼ固定で、必要な性能を見積もって機械を買えば済みました。ところがインターネットのサービスは、利用者が一晩で何倍にもなりえます。テレビで紹介された瞬間、セールの開始時刻、SNS でのバズ——負荷は予測を裏切って跳ね上がります。

当初の答えは垂直スケーリングでした。しかし1台の機械の性能には物理的な上限があり、上位機ほど価格が非線形に跳ね上がり、そして何より「その1台が壊れたら全部止まる」という単一障害点の問題が残ります。Google や Amazon が示したのは逆の道でした。安価な普通のサーバを大量に並べ、故障を前提に設計する。この水平スケーリングの思想が、クラウドコンピューティング の「必要なときに必要な台数を借りる」モデルと噛み合い、現代の大規模システムの標準になりました。

詳細

垂直と水平の使い分け

垂直スケーリングの利点は単純さです。アプリケーションを一切変更せずに性能が上がり、分散に伴う複雑さがありません。小〜中規模のシステムや、分散が難しい RDBMS では今でも第一選択です。欠点は上限があること、費用対効果が悪化していくこと、機械の交換に停止を伴いがちなことです。

水平スケーリングは、理論上は台数に比例して能力を伸ばせ、1台の故障がサービス全体の停止にならない冗長性も同時に得られます。その代わり「複数台で正しく分担する」ための設計コストを支払います。大規模サービスが水平を志向するのは、上限のなさと可用性の両方が理由です。

水平スケーリングの前提: 分散とステートレス化

台数を増やすには、まずリクエストを各サーバへ振り分ける入口が必要です。それが ロードバランサ で、ヘルスチェックによって故障したサーバを自動的に分散対象から外す役割も担います。

もう一つの前提が「どのサーバに当たっても同じ結果になる」こと、つまりアプリケーションのステートレス化です。ログイン状態などの セッション 情報をサーバのメモリに置いてしまうと、次のリクエストが別のサーバに振られたときに「ログインしていない」ことになってしまいます。そこでセッションは Redis のような共有ストアに外出しするか、JWT のようにクライアント側へ持たせます。「状態をサーバから追い出す」ことが、水平スケーリングの設計上の合言葉です。

ボトルネックは移動する

アプリケーションサーバを並べても、全員が同じデータベースに書き込むなら、次に詰まるのは DB です。ボトルネックは解消されるのではなく移動する、というのがスケーリングの実感的な法則です。DB 側の打ち手としては、読み取り専用の複製（リードレプリカ）への読み書き分離、キャッシュ による読み取り負荷の吸収、データを複数の DB に分割するシャーディングなどが段階的に投入されます。シャーディングは強力ですが、トランザクション が複数 DB をまたげなくなるなど複雑さの代償が大きく、最後の手段に近い位置づけです。水平分割を最初から前提にした NoSQL が選ばれる場面もあります。

オートスケーリングと現実の落とし穴

クラウドでは、CPU 使用率やリクエスト数に応じて台数を自動増減させるオートスケーリングが使えます。負荷の波に合わせて夜間は縮小し、ピーク時だけ拡大する、といった費用最適化が可能です。ただし実務での落とし穴は自動化そのものより手前にあります。負荷の原因を特定せずに台数を増やすと、遅い SQL や外部 API 待ちのような「増台では解決しない問題」に金だけを注ぐことになります。まず 監視 と ログ でボトルネックを特定し、インデックス の追加やキャッシュのような安い打ち手を先に検討する。スケーリングは常に「計測してから」が鉄則です。

スケールしない自由もある

最後に、すべてのシステムが水平スケーリングを必要とするわけではありません。ステートレス化や分散設計には確かなコストがかかり、社内システムや初期のプロダクトでは、1台の強いサーバと丁寧なチューニングのほうが総合的に安いことも多いのです。「将来必要になるかもしれない」だけで分散の複雑さを先払いしない、というのも立派な設計判断です。