Scale Outパターン
サーバー数の動的増減
目次[非表示] |
解決したい課題
Webサービスにおいて高トラフィックのリクエストを処理するには、高スペックのサーバーが必要となる。 より高いスペックのマシンを使って処理能力を高めるアプローチを「スケールアップ」と呼ぶが、この方法には課題がある。 一般に高スペックのサーバーは、スペックが上がるにつれて処理単価は高くなる。また、サーバースペックには限界があり、無制限に高いスペックにすることはできない。
クラウドでの解決/パターンの説明
同じようなスペックのサーバーを複数台並べ、高トラフィックのリクエストを処理するアプローチを「スケールアウト」と呼ぶ。 複数の仮想サーバーを起動し、ロードバランサーを用いて各仮想サーバーに負荷を分散する。 システムによっては、週次や日次、ときに時間単位でそのトラフィックが急激に増減することがある。 クラウドではそのような変動が激しいトラフィック量に合わせて、処理を担当する仮想サーバーの数を動的に変更させることが容易である。
実装
ロードバランサ―サービス「ELB」、モニタリングツール「CloudWatch」、そして自動でスケールアウトする「Auto Scaling」の三つのサービスを組み合わせることで、 負荷に応じて自動でスケールアウトするシステムを容易に構築できる。 （手順）
- ELBの配下に（Web/APサーバーとして）EC2を複数並べる。
- EC2を新たに起動するときに利用するAMIを作成しておく。
- EC2数を増減させるトリガーとなる条件（メトリクス）を定義する。EC2の平均CPU使用率、ネットワーク流量、セッション数、EBSのレイテンシーなどがよく使われる。
- そのメトリクスをCloudWatchを使って監視し、一定の条件を満たすとアラームを出すように設定する。
- アラームを受けた際、Auto ScalingがEC2数を増減するように設定する。
- 上記設定を完了することで、例えば「平均CPU使用率が70％以上の状態が5分以上続いた場合、あらかじめ用意したAMIを使ってEC2インスタンスを2つ起動する」ということが可能になる。 もちろん、状況に合わせてサーバー数を減らす（スケールインさせる）ことも可能である。 スケールインさせる場合は、ELBのConnection Draining機能を利用すると、処理中のリクエストが完了するまでインスタンスの登録解除をしないようにできるため、 利用者の影響を最小限に抑えてスケールインが実施できる。
構造
利点
- トラフィック量の増大に合わせて自動的にEC2インスタンスを増やすことができるので、サービス継続につながる。
- トラフィック量が多くないときにはEC2インスタンスを削減できる(スケールインと呼ぶ)のでコスト削減につながる。
- トラフィック量の増減に合わせて自動的にEC2インスタンスを増減させられるので、運用の手間が省ける。
- ELBの配下に必要な数のEC2インスタンスを並べることができるので、スケールアップと比べると処理能力の限界は極めて高い。
注意点
- 数分間でトラフィックが数倍になるような急激なトラフィックの変動には対処できない。 EC2インスタンスの増加を必要と判断して実際に増やすまでに時間がかかるからである。 こういうケースでは、特定の日時になるとEC2インスタンスを増やすようにスケジューリングしておく。 あらかじめ余分なEC2インスタンスを用意して負荷に耐えるようにしておき、その後、不要な分のEC2インスタンスを削減する。
- サーバー台数を増加させるスケールアウトと、減少させるスケールインは併用して用いられることが多いが、 スケールアウトとスケールインを自動制御するとサーバー台数が波打ってしまい無駄に利用料金を増加させてしまうことがあるので注意が必要である。 例えば、スケールアウトは自動化するがスケールインは手動にする、もしくは、スケールアウトは条件を緩くするがスケールインは条件を厳しくする、などの手段がとられる。
- HTTPセッション管理やSSL処理などをELBに任せるのか、配下のサーバーで処理するのかを考慮する。
- ELBにはスペックに応じて分散量を変える仕組みは備わっていないので、配下のEC2インスタンスタイプは統一したほうがよい。
- Web/APサーバーレイヤーのスケールアウトに比べ、DBサーバーレイヤーのスケールアウトは一般に難しい。リレーショナルデータベースのパターンを参照する。
- 耐障害性を高めるためにも、複数のAZに分散してスケールアウトさせたほうがよい。Multi-Datacenterパターンを参照。またこの際、Cross-Zone Load Balancing機能を利用すると、各AZのEC2に均等に負荷を分散する事が出来る。
- 新たに起動したEC2に最初にSSH接続する場合、ログイン時にホストの認証のためにフィンガープリントの確認が対話的に行われる場合があり、その場合、外部からのSSHを利用した自動処理などが機能しなくなってしまう場合があるため注意する。
- EC2内のミドルウェア/アプリケーションのアップデートが必要な場合は、Auto Scalingで起動する元となるAMIもアップデートする必要がある。
その他
- スケールアウトさせる際のファイル共有に関しては、Clone Serverパターン、NFS Sharingパターン、NFS Replicaパターンを参照。
- セッション管理に関しては、State Sharingパターンを参照。
- ある時刻にスケールアウトさせたい場合は、Scheduled Scaleoutパターンを利用する。
- AWS Elastic Beanstalkでは、このパターンがすでに実装されているため、トラフィックが増加すると適切にスケールアウト、スケールインが行われる。
関連ブログ