Scale Upパターン
動的なサーバーのスペックアップ/ダウン
目次[非表示] |
解決したい課題
一般的に、稼働後に必要なサーバーリソースをシステムの開発段階で見積もることは難しい。 もし稼働後にサーバーリソースが不足すれば、機能を十分に提供できなかったり、バッチ処理が締め切りまでに間に合わなかったりすることになる。 逆にサーバーリソースが過剰であれば、不要な投資を行うことになり、実際は損失が発生していることになる。 システム稼働後にサーバーリソースを自在に変更することが望まれるが、サーバーリソースは物理的なマシンスペックに依存するので難しい。
クラウドでの解決/パターンの説明
クラウドでは、仮想サーバーのスペック（CPU、メモリーサイズなど）を必要に応じて切り替えることが可能である。仮想サーバーを起動した後でもスペック変更が行える。 稼働後にリソース不足に陥った場合、従来は物理サーバーを交換してOSを再インストールすることが必要だったが、クラウドでは必要ない。 ひとまず仮想サーバーを起動してシステムを稼働し、リソース利用量を確認しながらサーバースペックを変更すればよい。
実装
AzureのRedisCacheを使用すると、世界中のキャッシュサーバー（エッジサーバー）を利用できる。
- EC2インスタンスを起動し、システムを構築する。
- vmstatやリソースモニター、CloudWatchなどでリソース利用量を把握し、スペック不足（または過剰）な場合は、一旦EC2インスタンスを停止し、AWS Management ConsoleのChange Instance Typeメニューからインスタンスタイプを変更後、再度起動する。
構造
利点
- システムの設計・開発時に、厳密にサーバースペックを見積もらなくてもよい。
- リソースが不足してシステムが止まり、顧客にサービスを提供できないといった機会損失を減らせる。
- リソースが過剰だと判断できれば低スペックに切り替えられるので、費用面で無駄を省くことができる。
注意点
- サーバースペックを変更するときは、EC2インスタンスを一旦停止する必要がある。その際、数十秒～数分（サーバーのディスク量や設定によって変わる）のオフライン状態が発生する。
- サーバースペックを変更できるといっても、インスタンスタイプの上限を超えることはできない。 従って、最も処理性能の高いインスタンスタイプを選んでもリソース不足の場合は、Scale Outパターンを採用したり、キャッシングやAWSの別サービスで代替することを検討したりする必要がある。
その他
- 処理のピークが予測できれば、それに合わせて自動的にサーバースペックを変更することもできる。例えば、月末に負荷の重い締め処理を行う場合、そのタイミングだけ高スペックに変更し、それ以外のときは低スペックにするようなスケジュールを組むことができる。
- 処理待ちが大量に発生したとき、一時的にサーバースペックを変更してその場をしのぎ、アプリケーションやデータベースのパフォーマンス改善を施してから、サーバースペックを元の状態に戻すという使い方もできる。特にアクセス数が読めないコンシューマー向けサービスで、DBサーバーなどのスケールアウトが難しい部分によく利用される。
- Scale Outパターンを参照
関連ブログ