スケーリング
スケーリングとは
スケーリングは、アクセスやデータの増加に合わせてシステムの処理能力を増強することです。サービスが成長すると1台のサーバーでは処理しきれなくなるため、どう能力を増やすかがインフラ設計の重要テーマになります。
増強の方向には大きく2つあり、それぞれスケールアップ(垂直スケーリング)とスケールアウト(水平スケーリング)と呼ばれます。
スケールアップとスケールアウト
| スケールアップ(垂直) | スケールアウト(水平) | |
|---|---|---|
| 方法 | サーバー1台の性能を上げる(CPU・メモリ増強) | サーバーの台数を増やす |
| 上限 | ハードウェアの限界がある | 台数を足せばほぼ無限に伸ばせる |
| 構成の複雑さ | シンプル(1台のまま) | 複雑(振り分け・状態共有が必要) |
| 障害耐性 | 1台が落ちると全停止 | 1台落ちても他の台でカバーできる |
| 向く場面 | データベースなど分散が難しいもの | Web サーバーなど同じ処理の並列化 |
スケールアウトでは、増えたサーバー群へリクエストを振り分ける [[ロードバランサ]] が必須になります。また、複数台で同じ処理を担うには「どのサーバーが受けても同じ結果になる」よう、セッションなどの状態を外部に持たせる設計が求められます。
オートスケーリング
[[クラウドコンピューティング]] の大きな利点がオートスケーリング(負荷に応じた台数の自動増減)です。
- CPU 使用率が70%を超えたらサーバーを2台追加する
- 深夜のアクセスが少ない時間帯は台数を減らしてコストを節約する
このように、あらかじめ決めたルールで自動的に増減させられます。[[Kubernetes]] にもコンテナの数を自動調整する同様の仕組みがあります。「ピークに合わせて常時大量のサーバーを持つ」無駄をなくせるのが、クラウド時代のスケーリングの強みです。
初学者向けポイント
- まずはスケールアップが手軽 — 構成を変えずに性能を上げられる。ただし限界とコスト効率の悪化が来る
- Web サーバー層はスケールアウト、データベースはスケールアップ+リードレプリカ、が定番の組み合わせ
- スケールアウト構成は [[高可用性設計]] にも直結する — 台数が増えれば1台の故障に耐えられる
- 「スケールしやすい設計」(状態を持たないアプリ、外部化されたセッション)は開発者側の責任範囲
関連技術とのつながり
- [[ロードバランサ]] — スケールアウトしたサーバー群への振り分け役として必須
- [[クラウドコンピューティング]] — オートスケーリングでクラウドの真価が発揮される
- [[Kubernetes]] — コンテナの数を負荷に応じて自動調整できる
- [[高可用性設計]] — 複数台構成は性能だけでなく障害耐性ももたらす
- [[サーバーレス・Lambda]] — サーバーの台数を管理せず、実行環境が自動で増減する増強の選択肢
- [[キャッシュ戦略]] — 増強の前に、同じ処理を繰り返さないことで負荷そのものを減らす手段
Q: スケールアウトの説明として正しいのはどれ?
- [ ] サーバー1台の CPU やメモリを増強すること
- [x] サーバーの台数を増やして処理能力を上げること
- [ ] サーバーの電源を定期的に再起動すること
解説: スケールアウト(水平スケーリング)は台数を増やす方法で、1台の性能を上げるのはスケールアップです。
Q: スケールアウト構成で必須になるものはどれ?
- [x] リクエストを複数サーバーへ振り分けるロードバランサ
- [ ] サーバー1台あたりのメモリを最大まで増設すること
- [ ] すべての通信を手動で振り分ける担当者
解説: 複数台にリクエストを分配するため、ロードバランサによる振り分けが必須になります。
Q: オートスケーリングの説明として正しいのはどれ?
- [ ] 障害が起きたサーバーを手動で交換すること
- [ ] サーバーの性能を購入時に固定すること
- [x] 負荷に応じてサーバーの台数を自動で増減させること
解説: オートスケーリングは CPU 使用率などのルールに基づき台数を自動増減する仕組みで、クラウドの大きな利点です。