前回、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)を利用します。