CDP:Scale Outパターン

(Difference between revisions)
Jump to: navigation, search
(解決したい課題)
(実装)
Line 17: Line 17:
  
 
== 実装 ==
 
== 実装 ==
* 仮想ロードバランサの配下に、Webアプリケーションサーバとしての仮想サーバを水平に複数並べる。
+
* ELBの配下に、WebアプリケーションサーバとしてのEC2を水平に複数並べる。
* 仮想サーバを増加させるために元となるマシンイメージを作成しておく。
+
* EC2を増加させるために元となるAMIを作成しておく。
* 仮想サーバ数を増減させるトリガーとなる条件を定義する。仮想サーバの平均CPU 負荷、ネットワーク流量、セッション数、仮想ディスクのレイテンシ等が良く使われる。
+
* EC2数を増減させるトリガーとなる条件を定義する。EC2の平均CPU 負荷、ネットワーク流量、セッション数、EBSのレイテンシ等が良く使われる。
* そのメトリクスをシステム監視サービスを使って監視し、一定の条件を満たすとアラームをあげるように設定する。
+
* そのメトリクスをCloudWatchを使って監視し、一定の条件を満たすとアラームをあげるように設定する。
* アラームを受けた際に、オートスケールが仮想サーバ数を増減させるための設定を行う
+
* アラームを受けた際に、Auto ScalingがEC2数を増減させるための設定を行う
* 上記の設定を完了することで、例えば、平均CPU負荷が70%以上の状態が5分以上続いた場合に、アラームがあがり特定のマシンイメージをもとに、サーバが2台追加される、ということが可能になる。
+
* 上記の設定を完了することで、例えば、平均CPU負荷が70%以上の状態が5分以上続いた場合に、アラームがあがり特定のAMIをもとに、EC2が2台追加される、ということが可能になる。
 +
 
 
== 構造 ==
 
== 構造 ==
 
https://cacoo.com/diagrams/6wNg0ISJczU5Pz1m-67124.png
 
https://cacoo.com/diagrams/6wNg0ISJczU5Pz1m-67124.png

Revision as of 06:20, 15 April 2012

Contents

解決したい課題

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

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

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

実装

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

構造

6wNg0ISJczU5Pz1m-67124.png

利点

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

注意点

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

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

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

その他

寄贈したアーキテクト

Ninja of Three

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox