スケールアップ

Scale-up

アプリ開発

サーバー自体のCPUやメモリなどの単体スペック（物理的または仮想的なリソース）を増強し、システム全体の処理能力を底上げする手法です。アクセス増加や高負荷な処理に耐えるためのインフラ拡張アプローチの一つとして用いられます。

🐾 猫で例えると？

画面いっぱいに近づいたアメショを「一台を大きくする」イメージに重ねています。もちろん写真の見かけが大きくなっても猫の能力は増えません。実際のスケールアップでは、CPU、RAM、I/Oなど不足している資源を増やします。

システムの負荷が高まった際の対処法には、大きく分けて「スケールアップ（垂直スケール）」と「スケールアウト（水平スケール）」の2種類があります。今回のアメショのように「1台のサーバーをムキムキに強くする」のがスケールアップで、サーバーの台数を横に増やすのがスケールアウトです。

一台のDBなどを増強する方法は、構成を大きく変えずに容量を増やせる場合があります。ただし単一スレッドの計算へCPUコアだけを足しても、速くならないことがあります。待ちの原因を測ってから、増やす資源を選びます。

クラウドでは機器を交換せずにサイズ変更できる場合がありますが、対応する種類、空き容量、停止、料金などの条件があります。変更時間は構成次第で、必ず数分で完了するとは限りません。

EC2のEBS-backedインスタンスを停止して種類を変える場合の手順例です。実行コマンドではなく、先に確認すべき工程を示しています。

1. CPUアーキテクチャ、ドライバー、ストレージなどの互換性を確認
2. 対象インスタンス、リージョン、影響する利用者を確認
3. データ保存と停止手順を実施
4. 停止完了を待って、対応するインスタンスタイプへ変更
5. 起動後に接続先、アプリ、監視を確認
6. 変更前後の待ち時間と費用を比較

このEC2の方法では停止が必要です。一方、スケールアップという概念全体が常に同じ停止条件を持つわけではなく、サービスや資源により異なります。停止に伴う一時ストレージやIPアドレスへの影響も事前に確認します。

インフラ設計において、スケールアップを効果的かつ安全に活用するためのポイントです。

単一障害点（SPOF）への対策： 1台の超高性能なサーバーに依存しすぎると、それがダウンした時の被害が甚大になります。寂しがり屋の茶トラがアメショの不在に泣き出してしまうように、依存システム全体が止まらないようバックアップ機（コールドスタンバイなど）の用意が必須です。
停止条件と復旧時間を確認： 対象サービスの仕様に従って計画します。単に深夜を選ぶのでなく、利用時間帯、バッチ、バックアップなどとの重なりを確認します。
効果と費用を比較： 料金の増え方は製品ごとに異なります。クエリ改善などと比べ、処理時間や容量がどれだけ改善したかを測り、必要以上のサイズを維持しないようにします。

ドアップのアメショの迫力は、1台を強くするスケールアップのイメージです。ただし増強する資源がボトルネックと一致していなければ、期待したほど改善しません。CPU・メモリなどの使用状況と費用、変更時の停止の有無を確認して判断しましょう。