前回、Web・APサーバーの可用性と拡張性を高めるために、Web・APサーバーを単一サーバーから複数台構成にし、Elastic Load Balancing(ELB)を利用して、各サーバーにトラフィックを振り分ける構成に変更しました。
この構成にすることで、Web・APサーバーの負荷が高くなったとき、サーバーを追加して対応できます。
ここで、Web・APサーバーのEC2インスタンスを追加/削除するかどうかの判断はどう行えばよいでしょうか。
事後対応で手動によってスケールさせるのは良い方法とはいえません。コーポレートサイトの例で言うと、システムの処理能力が上限に達したときに、ユーザーがサイトにアクセスすると、レスポンスが遅くなったり、全くアクセスできない状況になったりします。それと並行して、監視サービスなどから管理者にアラートメールが届きますが、手動で新しいインスタンスを起動させて利用可能になるまでの間、コーポレートサイトは問題が発生したままです。
かといって、必要以上のインスタンスを起動しておくのも、コストの面で良い方法とはいえません。
望ましいのは、Web・APサーバー群の負荷の変化に応じて、自動的にインスタンスを追加/削除させることです。これを「オートスケール」といいます。
AWSでは、監視サービスの「Amazon CloudWatch」とオートスケールのサービス「Auto Scaling」を組み合わせることで実現できます。まずは、これら二つのサービスについて説明します。
仮想マシンの状態を監視するCloudWatch
AWSでWeb・APサーバー群の負荷を監視したり、しきい値に達したことを検知したりするのに使うのが、CloudWatchです。
CloudWatchは、EC2インスタンスなどのAWSリソースとAWSで実行されているアプリケーションをリアルタイムで監視するサービスです。CloudWatchによってさまざまなメトリクスのデータを収集し、リソースの状態を把握できます。メトリクスのデータは最長15カ月間保持されます。
ここでいうメトリクスとは、AWSリソースやアプリケーションの状態を表す変数です。メトリクスには、標準メトリクスとカスタムメトリクスがあります。
標準メトリクスは、ユーザーが各サービスを使い始めると、AWSが自動的かつ定期的にCloudWatchに送信するものです。設定は必要ありません。EC2インスタンスのCPU使用率やディスクの読み込み/書き込み回数、RDSインスタンスの同時接続数などがあります。EC2インスタンスの標準メトリクスは、ハイパーバイザーレベルで収集されるものです。
カスタムメトリクスは、ユーザー個別のメトリクスを収集するときに用います。例えばEC2インスタンスのメモリー使用率、スワップ使用率、ディスク使用率などです。基本的な項目に思えるかもしれませんが、いずれもハイパーバイザーレベルでは収集できないので、カスタムメトリクスの扱いになります。
CloudWatchでカスタムメトリクスを監視する場合、スクリプトなどを利用して定期的にメトリクスのデータをCloudWatchのAPIに送ります。こうすることで、標準メトリクスと同様にカスタムメトリクスを扱えます。
なおEC2インスタンスのメモリー使用率、スワップ使用率、ディスク使用率は一般的な監視項目なので、AWSがこれらのカスタムメトリクスを作成/利用するためのLinuxインスタンス用スクリプト「Amazon CloudWatch Monitoring Scripts for Linux」を公開しています。
Windowsインスタンスの場合は、EC2 Config(Windows Server 2016より前)やEC2 Launch(Windows Server 2016)を利用します。