9. インスタンスサイズの拡張と縮小
2026/04/22 公開
クラウド環境ではハードウェアの物理リソースはCSPによって管理されており、導入後にサーバー性能や台数の拡張・縮小が柔軟に可能である。クラウド移行時にコストが想定より高くなる原因の多くは、オンプレミス時代のサイジング方式をそのままクラウドに持ち込むことによる過剰構成にある。クラウドの特性を踏まえた適切なサイジングの継続的な見直しは、クラウドのコスト最適化において最も即効性の高い取り組みの一つである。
ただし、スケールアウト（台数の拡張）を活用するためにはアプリケーションが複数台構成やステートレスに対応している必要があり、オートスケーリングの導入にはアプリケーション側の対応が必要となる場合がある点に留意が必要である。
9.1 オンプレミスのサイジング方式のクラウド移行
以下に、オンプレミス環境で一般的に実施されているサイジング方式ごとの移行方針を示す。
表9-1 サイジング方式別クラウド移行方針
| サイジング方式検討ポイント | クラウド移行時の対応 | 説明 |
|---|---|---|
| 最大負荷を見越した初期サイジング | 廃止検討 | オンプレミスでは導入後のリソース変更が困難なため、最大負荷を見越した過剰なサイジングが一般的であった。クラウドでは導入後にインスタンスサイズの変更が可能なため、導入時は必要最低限のサイズから始め、運用の過程で見直すことを推奨する。 クラウドにおける初期サイジングのポイントについては、コスト最適化アプローチガイドの「3. コスト最適化アプローチ（クラウド利用経費）」を参照のこと。 |
| スケールアップ・スケールダウン（インスタンスサイズの変更） | 設定のみで対応可能 | クラウドの仮想マシンサービスおよびデータベースサービスでは、インスタンスサイズ（CPU・メモリ・ストレージ性能）を後から変更できる。導入時は必要最低限のサイズを選択し、負荷状況に応じてサイズを変更する運用とすることでコストを最適化できる。 なお、インスタンスサイズ変更時にダウンタイムが発生するサービスについては、冗長環境を活用したダウンタイムの極小化を検討する。 |
| スケールアウト・スケールイン（手動による台数の増減） | 追加作業あり | クラウドの仮想マシンサービスおよびデータベースサービスのリードレプリカでは、稼働台数を後から変更できる。導入時は必要最低限の台数から始め、負荷に応じて台数を増減する運用とすることでコストを最適化できる。 |
| スケールアウト・スケールイン（オートスケーリングによる台数の増減の自動化） | 設計変更が必要 | 仮想マシンサービスおよび一部のデータベースサービスでは、負荷に応じて台数を自動で増減するオートスケーリング機能が提供されている。オートスケーリングを活用することで運用負荷を抑えながらコストを最適化できる。 なお、仮想マシンはスケールイン時に削除されるため、アプリケーションのデータやログ等の必要な情報を仮想マシンのストレージに保持しない設計にすること、およびパッチ適用は個々の仮想マシンではなくマスターイメージの更新で行う運用への見直しが必要である。 |
| キャパシティ計画（長期的なリソース見通し） | 廃止検討 | クラウドではリソースの拡張・縮小が柔軟に可能なため、長期的なキャパシティ計画の重要性は大幅に低下する。定期的な負荷状況の確認とインスタンスサイズの見直しに置き換えることを推奨する。 |
9.2 クラウド環境で新たに必要なサイジング設計
クラウド環境への移行にあたっては、オンプレミス環境にはなかった以下のサイジング設計を新たに検討する必要がある。
表9-2 クラウド環境で新たに必要なサイジング設計
| 項目 | 説明 |
|---|---|
| インスタンスサイズの継続的な見直し | クラウドではインスタンスサイズを後から変更できるため、導入時のサイジングが最適でなくても運用の過程で見直すことができる。定期的に負荷状況を確認し、過剰なリソースを抱えていないかを継続的に見直すことでコストを最適化する。 詳細は「継続的運用経費最適化（FinOps）ガイド」を参照。 |
| ダウンタイムを考慮したスケールアップ設計 | インスタンスサイズの変更時にダウンタイムが発生するサービスについては、冗長環境（負荷分散対象の他Webアプリケーションサーバーやデータベースのスタンバイ環境等）を活用したダウンタイムの極小化を設計段階で検討する。 |
| オートスケーリングのスケールイン設計 | オートスケーリングを導入する場合、スケールアウト（台数増加）だけでなくスケールイン（台数削減）の条件も適切に設定することでコストを最適化できる。スケールイン時は稼働中のインスタンスが削除されるため、セッション情報等が失われないようアプリケーション側の設計もあわせて確認する。 |
| オートスケーリングの上限設定 | オートスケーリングを導入する場合、DoS攻撃等による意図しない過剰なスケールアウトを防ぐため、台数の上限を適切に設定する。あわせてコスト監視を導入し、異常なコスト増加を早期に検知できる仕組みを整備する。 |
| リザーブドインスタンス・節約プランの活用 | 常時稼働が必要なサーバーについては、従量課金よりも割引率の高い長期継続割引プランの活用を検討することでコストを最適化できる。 詳細は「コスト最適化アプローチガイド」の「3.3 稼働時間の調整」や、「継続的運用経費最適化（FinOps）ガイド」の「4.3.3 長期継続割引の利用」を参照。 |
9.3 オートスケーリング導入時のアプリケーション設計ポイント
オートスケーリングを導入する場合、インフラ設定だけでなくアプリケーション側の設計変更が必要となる場合がある。主な設計ポイントを以下に示す。
（1）セッション管理
オートスケーリングによってサーバーの台数が増減する場合でも、稼働を継続する各サーバーでセッション情報を共有できるよう、セッション情報はサーバーの外部（マネージドなデータベースサービス等）に保持する必要がある。セッション情報をサーバー外部に保持することでスティッキーセッションが不要となり、ロードバランサーがリクエストをどのサーバーにも振り分けられるようになる。なお、セッション情報は認証状態を示す情報のような最低限のものに限定することが望ましい。
参考として、各CSPで利用可能なセッション管理サービスは以下のとおりである。
表9-3 セッション管理サービス一覧
| 種別 | AWS | Google Cloud | Azure | OCI |
|---|---|---|---|---|
| インメモリ | Amazon ElastiCache | Cloud Memorystore | Azure Cache for Redis | OCI Cache |
| キーバリュー | Amazon DynamoDB | Cloud Firestore | Azure Cosmos DB | NoSQL Database |
| リレーショナル | Amazon RDS | Cloud SQL | Azure Database | Autonomous Database等 |
（2）ファイル管理
処理の中間結果やアップロードされたファイル等は、サーバーの外部（オブジェクトストレージ等）に保存する必要がある。スケールインによってサーバーがシャットダウンされた場合でも、ファイルに継続的にアクセスできるようにするためである。詳細は8章を参照。
9.4 参考資料
9.4.1 コスト最適化
コスト最適化の観点で、関連文書も参考として提示する。