CDP:Scale Outパターン
From AWS-CloudDesignPattern
(Difference between revisions)
(→注意点) |
|||
| (13 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | {{CDP一覧}}{{NoT}} | ||
| + | サーバ数の動的増減 | ||
| + | |||
== 解決したい課題 == | == 解決したい課題 == | ||
Webサービスにおいて高いトラフィックを処理するには、高スペックのサーバが必要となる。 | Webサービスにおいて高いトラフィックを処理するには、高スペックのサーバが必要となる。 | ||
| Line 4: | Line 7: | ||
スケールアップアプローチと呼ぶが、高いスペックのサーバはそのスペックが上がるにつれて | スケールアップアプローチと呼ぶが、高いスペックのサーバはそのスペックが上がるにつれて | ||
処理単位あたりコストが向上することが一般的である。 | 処理単位あたりコストが向上することが一般的である。 | ||
| − | + | また、高スペックのサーバーにはおのずと限界があり、無制限にスペックを求めることはできない。 | |
== クラウドでの解決/パターンの説明 == | == クラウドでの解決/パターンの説明 == | ||
| Line 17: | Line 20: | ||
== 実装 == | == 実装 == | ||
| − | * | + | AWSにはELBと呼ばれるロードバランサー、CloudWatchと呼ばれるモニタリングツール、そしてAutoScalingと呼ばれる |
| − | * | + | 自動でスケールアウト/インを行うサービスが用意されている。この三種類のサービスを利用することで負荷に応じて |
| − | * | + | 自動でスケールアウトするシステムが容易に構築可能である。 |
| − | * | + | * ELBの配下に、WebアプリケーションサーバとしてのEC2を水平に複数並べる。 |
| − | * | + | * EC2を増加させるために元となるAMIを作成しておく。 |
| − | * 上記の設定を完了することで、例えば、平均CPU負荷が70% | + | * EC2数を増減させるトリガーとなる条件を定義する。EC2の平均CPU 負荷、ネットワーク流量、セッション数、EBSのレイテンシ等が良く使われる。 |
| + | * そのメトリクスをCloudWatchを使って監視し、一定の条件を満たすとアラームをあげるように設定する。 | ||
| + | * アラームを受けた際に、Auto ScalingがEC2数を増減させるための設定を行う | ||
| + | * 上記の設定を完了することで、例えば、平均CPU負荷が70%以上の状態が5分以上続いた場合に、アラームがあがり特定のAMIをもとに、EC2が2台追加される、ということが可能になる。もちろん、状況にあわせ、サーバ数を減らすことも可能である。 | ||
| + | |||
== 構造 == | == 構造 == | ||
https://cacoo.com/diagrams/6wNg0ISJczU5Pz1m-67124.png | https://cacoo.com/diagrams/6wNg0ISJczU5Pz1m-67124.png | ||
| Line 28: | Line 35: | ||
* トラフィック量の増大にあわせて、自動的にサーバを増やすことができ、サービス継続につながる。 | * トラフィック量の増大にあわせて、自動的にサーバを増やすことができ、サービス継続につながる。 | ||
| − | |||
* トラフィック量が多くないときには、サーバ数を削減することができるのでコスト削減につながる。 | * トラフィック量が多くないときには、サーバ数を削減することができるのでコスト削減につながる。 | ||
| − | * | + | * トラフィック量の増減にあわせて、自動的にサーバ数を増減させられるので、運用の手間が省ける。 |
| + | * ELBの下には、望む数のEC2を並べることができるため、スケールアップアプローチと違い、スケールの限界にあたりにくい | ||
| + | |||
== 注意点 == | == 注意点 == | ||
| − | 数分間でトラフィックが数倍になるような急激なトラフィック向上に対処できないので(サーバ数を増やす際には時間がかかる) | + | * 数分間でトラフィックが数倍になるような急激なトラフィック向上に対処できないので(サーバ数を増やす際には時間がかかる)、その際は、あらかじめサーバ数を増やしておく、スケジューリングしておくなどの方策をとる。あらかじめ余分なサーバ数を用意しておいて負荷に耐え、その後、サーバ数を削減することも良く用いられる手法である。 |
| − | + | * HTTPセッション管理や、SSL処理などをELBにもたせるのか、配下のサーバ側で処理するのか考慮が必要である | |
| − | + | * ELBには、スペックに応じて分散量を変える仕組みは備わっていないので、配下のEC2タイプは統一しておいたほうが良い | |
| − | + | * DBサーバーは、耐障害性、メンテナンスの観点からもWebサーバーとは分離して設置することが望ましい。しかし、DBレイヤのスケールアウトはWebレイヤと比べて一般的に難しい。リレーショナルデータベースのパターンを参照すると良いだろう。 | |
| − | + | * 耐障害性を高めるためにも、複数のAZに分散してスケールアウトさせたほうが良い。Multi-Datacenterパターンを参照のこと | |
| − | + | ||
== その他 == | == その他 == | ||
| + | * スケールアウトさせる際のファイル共有に関しては、Clone Server, NFS Sharing, NFS Replicaパターンを参照すると良いだろう。 | ||
| + | * セッション管理については、State Sharingパターンも参照すること。 | ||
== 寄贈したアーキテクト == | == 寄贈したアーキテクト == | ||
[[Ninja of Three]] | [[Ninja of Three]] | ||
Latest revision as of 19:35, 15 April 2012
サーバ数の動的増減
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台追加される、ということが可能になる。もちろん、状況にあわせ、サーバ数を減らすことも可能である。
構造
利点
- トラフィック量の増大にあわせて、自動的にサーバを増やすことができ、サービス継続につながる。
- トラフィック量が多くないときには、サーバ数を削減することができるのでコスト削減につながる。
- トラフィック量の増減にあわせて、自動的にサーバ数を増減させられるので、運用の手間が省ける。
- ELBの下には、望む数のEC2を並べることができるため、スケールアップアプローチと違い、スケールの限界にあたりにくい
注意点
- 数分間でトラフィックが数倍になるような急激なトラフィック向上に対処できないので(サーバ数を増やす際には時間がかかる)、その際は、あらかじめサーバ数を増やしておく、スケジューリングしておくなどの方策をとる。あらかじめ余分なサーバ数を用意しておいて負荷に耐え、その後、サーバ数を削減することも良く用いられる手法である。
- HTTPセッション管理や、SSL処理などをELBにもたせるのか、配下のサーバ側で処理するのか考慮が必要である
- ELBには、スペックに応じて分散量を変える仕組みは備わっていないので、配下のEC2タイプは統一しておいたほうが良い
- DBサーバーは、耐障害性、メンテナンスの観点からもWebサーバーとは分離して設置することが望ましい。しかし、DBレイヤのスケールアウトはWebレイヤと比べて一般的に難しい。リレーショナルデータベースのパターンを参照すると良いだろう。
- 耐障害性を高めるためにも、複数のAZに分散してスケールアウトさせたほうが良い。Multi-Datacenterパターンを参照のこと
その他
- スケールアウトさせる際のファイル共有に関しては、Clone Server, NFS Sharing, NFS Replicaパターンを参照すると良いだろう。
- セッション管理については、State Sharingパターンも参照すること。
