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

この先は有料会員の登録が必要です。今なら有料会員(月額プラン)が2020年1月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら