CDP:Scale Outパターン

From AWS-CloudDesignPattern
Revision as of 06:27, 15 April 2012 by Cdpadmin (Talk | contribs)
Jump to: navigation, search

Contents

解決したい課題

Webサービスにおいて高いトラフィックを処理するには、高スペックのサーバが必要となる。 より高いトラフィックに対して、より高いスペックのマシンで処理するアプローチを、 スケールアップアプローチと呼ぶが、高いスペックのサーバはそのスペックが上がるにつれて 処理単位あたりコストが向上することが一般的である。 また、高スペックのサーバーにはおのずと限界があり、無制限にスペックを求めることはできない。

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

スケールアップアプローチではなく、同じようなスペックのサーバを水平に並べて処理を分散し、 より高いトラフィックが来るとサーバの台数を増やして処理するアプローチを、 スケールアウトアプローチと呼ぶ。 高いトラフィックを処理するために、仮想ロードバランサを用いて負荷を分散し、 仮想ロードバランサの配下に水平に並べた複数のWebアプリケーションサーバで処理を行う。 昨今のWebスケールなシステムにおいては、週次や日次、ときに時間単位でそのトラフィックが急激に 増減することが一般的である。クラウドでは、そのような変動が激しいトラフィック量にあわせて、 処理を担当するサーバの数を動的に変更させることが容易に可能となる。

実装

AWSにはELBと呼ばれるロードバランサー、CloudWatchと呼ばれるモニタリングツール、そしてAutoScalingと呼ばれる 自動でスケールアウト/インを行うサービスが用意されている。この三種類のサービスを利用することで負荷に応じて 自動でスケールアウトするシステムが容易に構築可能である。

  • ELBの配下に、WebアプリケーションサーバとしてのEC2を水平に複数並べる。
  • EC2を増加させるために元となるAMIを作成しておく。
  • EC2数を増減させるトリガーとなる条件を定義する。EC2の平均CPU 負荷、ネットワーク流量、セッション数、EBSのレイテンシ等が良く使われる。
  • そのメトリクスをCloudWatchを使って監視し、一定の条件を満たすとアラームをあげるように設定する。
  • アラームを受けた際に、Auto ScalingがEC2数を増減させるための設定を行う
  • 上記の設定を完了することで、例えば、平均CPU負荷が70%以上の状態が5分以上続いた場合に、アラームがあがり特定のAMIをもとに、EC2が2台追加される、ということが可能になる。

構造

6wNg0ISJczU5Pz1m-67124.png

利点

  • トラフィック量の増大にあわせて、自動的にサーバを増やすことができ、サービス継続につながる。
  • トラフィック量の増減にあわせて、自動的にサーバ数を増減させることが運用の手間が省ける。
  • トラフィック量が多くないときには、サーバ数を削減することができるのでコスト削減につながる。
  • ELBの下には、望む数のEC2を並べることができるため、スケールアップアプローチと違い、スケールの限界にあたりにくい

注意点

数分間でトラフィックが数倍になるような急激なトラフィック向上に対処できないので(サーバ数を増やす際には時間がかかる)、その際は、あらかじめサーバ数を増やしておく、スケジューリングしておくなどの方策をとる。

仮想ロードバランサがSPOFになりがちなので、その対策が必要となる。仮想ロードバランサ自体はそのものが耐障害性を持っているので心配は少ないが、必要なときには仮想ロードバランサ自体を冗長的に作ることも可能である。

HTTPセッション管理や、SSL処理などをロードバランサにもたせるのか、配下のサーバ側で処理するのか考慮が必要である 仮想ロードバランサには、スペックに応じて分散量を変える仕組みは備わっていないので、配下の仮想サーバタイプは統一しておいたほうが良い

その他

寄贈したアーキテクト

Ninja of Three

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox