CDP:Scale Upパターン

提供:AWS-CloudDesignPattern
移動: 案内, 検索
寄贈したアーキテクト

動的なサーバーのスペックアップ/ダウン

目次

解決したい課題

 一般的に、稼働後に必要なサーバーリソースをシステムの開発段階で見積もることは難しい。

 もし稼働後にサーバーリソースが不足すれば、機能を十分に提供できなかったり、バッチ処理が締め切りまでに間に合わなかったりすることになる。逆にサーバーリソースが過剰であれば、不要な投資を行うことになり、実際は損失が発生していることになる。

 システム稼働後にサーバーリソースを自在に変更することが望まれるが、サーバーリソースは物理的なマシンスペックに依存するので難しい。

クラウドでの解決/パターンの説明

 クラウドでは、仮想サーバーのスペック(CPU、メモリーサイズなど)を必要に応じて切り替えることが可能である。仮想サーバーを起動した後でもスペック変更が行える。

 稼働後にリソース不足に陥った場合、従来は物理サーバーを交換してOSを再インストールすることが必要だったが、クラウドでは必要ない。ひとまず仮想サーバーを起動してシステムを稼働し、リソース利用量を確認しながらサーバースペックを変更すればよい。

実装

(手順)

  • EC2インスタンスを起動し、システムを構築する。
  • vmstatやリソースモニター、CloudWatchなどでリソース利用量を把握し、スペック不足(または過剰)な場合は、一旦EC2インスタンスを停止し、AWS Management ConsoleのChange Instance Typeメニューからインスタンスタイプを変更後、再度起動する。

構造

6wNg0ISJczU5Pz1m-67127.png

利点

  • システムの設計・開発時に、厳密にサーバースペックを見積もらなくてもよい。
  • リソースが不足してシステムが止まり、顧客にサービスを提供できないといった機会損失を減らせる。
  • リソースが過剰だと判断できれば低スペックに切り替えられるので、費用面で無駄を省くことができる。

注意点

  • サーバースペックを変更するときは、EC2インスタンスを一旦停止する必要がある。その際、数十秒~数分(サーバーのディスク量や設定によって変わる)のオフライン状態が発生する。
  • サーバースペックを変更できるといっても、インスタンスタイプの上限を超えることはできない。従って、最も処理性能の高いインスタンスタイプを選んでもリソース不足の場合は、Scale Outパターンを採用したり、キャッシングやAWSの別サービスで代替することを検討したりする必要がある。

その他

  • 処理のピークが予測できれば、それに合わせて自動的にサーバースペックを変更することもできる。例えば、月末に負荷の重い締め処理を行う場合、そのタイミングだけ高スペックに変更し、それ以外のときは低スペックにするようなスケジュールを組むことができる。
  • 処理待ちが大量に発生したとき、一時的にサーバースペックを変更してその場をしのぎ、アプリケーションやデータベースのパフォーマンス改善を施してから、サーバースペックを元の状態に戻すという使い方もできる。特にアクセス数が読めないコンシューマー向けサービスで、DBサーバーなどのスケールアウトが難しい部分によく利用される。
  • Scale Outパターンを参照
個人用ツール
名前空間
変種
操作
CDPメニュー
ツールボックス