[Elastic Beanstalk] 拡張ヘルスモニタリングを試してみた

2015.08.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

AWSチームのすずきです。

先日のAWSのアップデートにより、Elastic Beanstalkのアプリケーション監視機能が強化されました。

拡張ヘルスモニタリング機能により、 ヘルスチェックの監視間隔の短縮(1分→10数秒毎)、ヘルスチェックステータスの詳細化(3段階→7段階)に加え、 専用の監視エージェント(EC2のAmazonLinuxにインストール)による、 CPU利用状況、空きディスク容量、アプリケーションの応答状況などの確認も可能となりました。

今回Elastic Beanstalk管理下のアプリケーション環境で、拡張ヘルスモニタリングを試す機会がありましたので、 その内容について紹介します。

参考

事前準備

IAM設定

  • Elastic Beanstalkの拡張ヘルスモニタリングに必要なIAM権限設定を行います。

Elastic Beanstalk Service Role

  • AWSにより提供される監視システム、Elastic Beanstalk サービスで利用する権限を定義します。
  • 今回、Elastic Beanstalkの「新規アプリケーションの作成」→「アクセス権限」→サービスロール:「新しいロールの作成」で生成したロールを利用しました。

eb-new-healthcheck-01

eb-new-healthcheck-02

  • 「新しいロールの作成」で生成される「aws-elasticbeanstalk-service-role」には、以下のポリシーが付与されます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticloadbalancing:DescribeInstanceHealth",
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus",
"ec2:GetConsoleOutput",
"ec2:AssociateAddress",
"ec2:DescribeAddresses",
"ec2:DescribeSecurityGroups",
"sqs:GetQueueAttributes",
"sqs:GetQueueUrl",
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeAutoScalingInstances",
"autoscaling:DescribeScalingActivities",
"autoscaling:DescribeNotificationConfigurations"
],
"Resource": [
"*"
]
}
]
}

Elastic Beanstalk Instance Profile

  • Elastic Beanstalk により起動するEC2インスタンスに付与するIAMロールを設定します。
  • 今回の検証環境では、EC2インスタンスには、ポリシー「PowerUserPolicy」が付与済であったので、こちらをそのまま利用しました。
  • Elastic Beanstalkの「新規アプリケーションの作成」でも、拡張ヘルスモニタリングに必要なIAM権限(cloudwatch:PutMetricData)を有すロールは生成されます。

プラットフォームの更新

  • 拡張ヘルスモニタリングの利用には、バージョン2.0.0以降のAMIが必要です。
  • 今回のアプリケーション環境、PHP 5.6の「v1.4.6」から、最新リリース「64bit Amazon Linux 2015.03 v2.0.0 running PHP 5.6」への更新を実施しました。

設定と確認

拡張モニタリングの有効化

  • AWSコンソールのElastic Beanstalk のダッシュボード画面より、設定対象の「設定」画面を開きます。
  • 「ヘルス」の設定画面を開きます。

eb-new-healthcheck-05

  • 「Health Permissions」として、「aws-elasticbeanstalk-service-role」を選択します。
  • 適切なサービスロールが指定されなかった場合、拡張モニタリングのヘルスチェックが失敗し、デプロイに失敗します。
  • ヘルスレポートのシステムタイプとして、「拡張」を指定します。
  • 拡張モニタリングで監視対象とするメトリックスを指定します。
  • 今回「Instance」の情報としてCPU関連を指定、「Environment」は全てのメトリックスを対象としました。

eb-new-healthcheck-06

  • 拡張モニタリングで指定したメトリックスは、Cloudwatchのカスタムメトリックスとして登録されます。
  • カスタムメトリックスは、無償枠の10 メトリックスを超過すると、1メトリックスあたり月額0.5$の課金対象となります。特にEC2台数が多い場合、インスタンス指定の監視項目は精査する事をお奨めします。
  • 拡張モニタリングを有効にし、設定を反映すると監視エージェントが有効化したEC2インスタンスへの入替が発生します。

モニタリング結果の確認

  • AWSコンソールのElastic Beanstalk のダッシュボード画面より、設定対象の「モニタリング」画面での確認が可能です。
  • 拡張モニタリングの結果は、「概要」「グラフの追加」より、「リソース」、「Cloudwatchメトリックス」を指定する事で表示されます。

Environment

  • Rootファイルシステム使用率が確認出来るようになりました。
  • アプリケーションの応答時間について、パーセンタイル表示が可能になりました。これまでの平均値、最大値では拾いにくい性能傾向が把握出来るようになりました。
  • アプリケーション応答時間は、httpd、nginxのアクセスログ(監視エージェント用の専用ログが追加されます)が集計対象となり、ELBのメトリックより詳細な情報が期待出来ます。

eb-new-healthcheck-18-Enhanced-1

  • インスタンスの稼働ステータスについて、より細かい区分で拾える様になりました。

eb-new-healthcheck-19-Enhanced-2

各Instance

  • CPU使用率の詳細とロードアベレージの確認が可能になりました。
  • IOwait, System, Userの各値が確認できる事で、CPU利用率が上昇原因をつかみやすくなりました。

eb-new-healthcheck-20-Enhanced-1

eb-new-healthcheck-21-Enhanced-dev-1

ベーシックモニタの結果

  • 拡張モニタリングを利用しない場合でも、AutoScallingGroupと、ELBのCloudwatchの以下のメトリックによる監視が行われています。

AutoScallingGroup

eb-new-healthcheck-14-basic-as1

eb-new-healthcheck-15-basic-as2

ELB

eb-new-healthcheck-16-basic-elb1

eb-new-healthcheck-17-basic-elb2

パーセンタイルグラフ

  • EC2のインスタンスタイプの違いによる、パーセンタイルグラフの結果は以下の通り。
  • Webサーバの性能判定に役立つ情報が得られます。

c4.large

  • 稼働時間帯 〜13:45
  • ApplicationLatencyP75:0.9前後
  • ApplicationLatencyP90〜99.9:2.0〜3.0
  • 75%のリクエストはレスポンス1秒以下。
  • 99.9%のリクエストレスポンス3秒以下。 eb-new-healthcheck-24-pt-c4

m3.medium

  • 稼働時間帯 15:00〜17:00
  • ApplicationLatencyP75:2.0〜3.0
  • ApplicationLatencyP99:6〜8
  • ApplicationLatencyP99.99:7.5〜10
  • レスポンスに2秒以上を要したリクエスト25%存在。
  • 1%のリクエストは6〜10秒と大幅悪化、サーバ性能不足と考えられます。

eb-new-healthcheck-07-pt-m3

t2.medium

  • 稼働時間帯 17:00〜
  • ApplicationLatencyP75:1.0前後
  • ApplicationLatencyP90〜99.9:2.0〜3.0
  • c4.large環境とほぼ同等の傾向で、サーバ性能は十分と判定。

eb-new-healthcheck-25-pt-t2

まとめ

今回紹介させて頂いたElastic Beanstalkの拡張モニタリング、Cloudwatchのカスタムメトリックスの実費のみで利用する事が可能です。 V2.0.0以降のプラットフォーム(AMI)への更新が可能な環境であればその導入は簡単に行う事ができ、インスタンスへのSSHログイン頻度を抑制できる効果も期待できます。

また、今回新たに確認出来るようになったパーセンタイルのグラフ情報は、サービス品質の判定に効果的と考えられますので、是非お試しください。