CDP:Scale Upパターン

From AWS-CloudDesignPattern
Jump to: navigation, search
Architect

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

Contents

解決したい課題

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

システム稼動時にサーバリソースが不足した損失の例として、システム利用者に対して満足する機能を提供することができないことや、バッチ処理が締め切りまでに間に合わないことがあげられる。逆にサーバリソースが過剰な場合も、不要な投資を行っており、実際は損失が発生している。

サーバのリソースはマシンのスペックに依存している。そこで必要なリソースに見合ったのマシンのスペックを、システム稼働後に自在に変更することが望まれるが、それはコストの面から難しい。

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

クラウドを利用する場合、仮想サーバが持つCPU、メモリ等のスペックを、必要に応じて切り替える事が可能である。一旦サーバを起動したあともスペックの変更が行えるため、従来は必要であった物理サーバの交換や、OSの再インストール作業などは必要ない。このため、ひとまずサーバを起動して設定を行い、処理を行わせておき、リソース利用量を確認しながら、サーバスペックを変更する。

実装

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

構造

6wNg0ISJczU5Pz1m-67127.png

利点

  • サーバスペックの見積もり時に、厳密にスペックを決定する必要が無く、すぐに構築作業に入れる
  • リソースが不足してシステムが止まり、顧客にサービスを提供できないといった機会損失を減らせる
  • リソースが余剰なときも低スペックに切り替えられるため、費用面で無駄を省く事が出来る

注意点

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

その他

  • 処理のピークが予測出来れば、それに合わせて自動的にサーバスペックを変更することもできる。例えば、月末に締めを行うような処理の場合は、そのときだけ高いスペックのものを用いて処理を行い、それ以外のときは、低いスペックのもので稼働させるようなスケジュールを組むことが出来る。
  • 処理があふれた際に緊急時にサーバのスペックを変更してその場をしのぎ、アプリケーションやデータベースのパフォーマンス改善をほどこしてから、サーバスペックを元の状態に戻す、という使い方もできる。特にアクセス数が読めないコンシュマー向けサービスで、DBサーバなどのScale Outが難しい部分でよく利用される。
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox