CloudWatchダッシュボードを利用してオートスケール環境の稼働状態を可視化してみた

はじめに

AWSチームのすずきです。

Webアプリの実行環境としてオートスケール管理のEC2、RDS、ELBを利用するLAMP構成のシステムで、 CloudWatchダッシュボードを利用した、AWSリソースの稼働確認を試みる機会がありましたので、 紹介させていただきます。

環境

構成図

オートスケール設定

• スケジュール設定を利用して、システムが利用されない夜間帯にスケールイン、EC2稼働数を抑制する設定としています。

• 日中はターゲットの追跡スケーリングを利用、ELB配下の1台のEC2あたりのリクエスト数、CPU負荷を一定以下に保つ設定としています。

CloudWatchダッシュボード

• ELB、EC2、RDSの稼働状態を確認できるダッシュボードを作成しました。

ELBリクエスト数

RequestCount

• ELBに到達したリクエストの合計数をAZ毎に表示します。
• MultiAZ構成の各AZが均等に利用されている事を確認します。

HealthyHostCount, UnHealthyHostCount

• ELBのヘルスチェックに成功、失敗したインスタンス数を表示します。
• 「UnHealthyHostCount」が複数発生した場合、オートスケールのログより対象EC2インスタンスを特定し、CloudwatchLogsなどに退避したアプリログより稼働状態を確認します。

RequestCountPerTarget

• ELB配下のEC2インスタンス1台あたりのリクエスト処理数を表示します。
• 今回のシステムでは、オートスケール(スケールアウト)を発動させる閾値として「RequestCountPerTarget」を主に利用しています。
• オートスケールが間に合わず1台あたりのリクエスト数が急騰し、ELBレスポンスのレイテンシ悪化などが生じていた場合、スケジュールによるオートスケールの最小稼働数の増強を手配します。

ELBエラー数

HTTPCode_ELB_5XX_Count

• ELBが戻した5XXエラー件数を監視します。
• 一定以上のエラーが測定された場合、ELBなどのアクセスログからエラー原因を確認します。
• 今回のシステムでは、アクセスログのローテーションに伴うhttpdの再起動によりELBとEC2間のKeepAliveが切断で発生したものが大半であった為、少数の発生は静観としました。
• 急激なアクセス集中でELBの性能調整が間に合っていない場合、AWSサポートにELBの暖気申請を手配します。

TargetConnectionErrorCount

• ELBとEC2間の接続が確立しなかった件数を監視対象とします。
• リソースが枯渇したEC2が、ELBからのリクエストに応答ができない状況の発生を検出します。

HTTPCode_Target_5XX_Count

• EC2のWeb、アプリサーバで発生した5XXエラー件数を監視します。
• EC2上のアプリや、DB疎通不良などに起因する動作異常を検出するため監視対象とします。
• 一定以上の件数が発生した場合アクセスログを確認、不正アクセスなどでシステム影響が懸念される場合、AWS WAFのカスタムルールなどによる対策を行います。

ELBレスポンス

TargetResponseTime(パーセンタイル)

• ELB配下のEC2の応答時間をパーセンタイル値で監視します。
• 今回の環境では、90、95パーセンタイル値を一定範囲に収める事を目標として、EC2の台数、RDSのスペックを調整しました。
• 99パーセンタイル値は性能低下の前兆を捉えるために利用します。

オートスケール

NetworkIn, NetworkOut

• オートスケール配下のEC2、1台あたりのネットワーク転送量を監視します。

CPUUtilization

• オートスケール配下のEC2、1台あたりのCPU使用率を監視します。

CPUUtilization, NetworkOut (sum)

• オートスケールを発動させる閾値として、CPU使用率、ネットワーク転送量の適正比較のため、それぞれの合計値を求めています。

CPUCredit

• T2、T3インスタンスを採用する環境の為、CPUクレジットを監視します。
• CPUCreditBalance が穏やかな右肩上がりとなるよう、EC2台数を調整しました。

EC2

• EC2の処理超過、DB、外部APIのスループット低下などに起因するEC2のボトルネックを、CloudWatch エージェントを利用したカスタムメトリックを利用して監視します。

新しいCloudWatch Agentを有効化したEC2オートスケール環境をCloudFormationで設定してみた

RDS

DatabaseConnections

• DB接続数の急騰が発生していない事を監視します。

Latency

• DBアクセスの遅延が一定範囲内である事を監視します。

DBLoad

• RDSのインスタンスタイプ、vCPU数の過不足を判断する目安として監視します。

• 「DBLoad」は、パフォーマンスインサイトを有効化する事で利用可能となるメトリックです。

Amazon RDS Performance Insights Metrics

Aurora MySQLでPerformance Insightsがサポートされました

FreeableMemory, FreeLocalStorage

• メモリやローカルストレージのリソース枯渇によるDB影響が生じる事を回避するため、監視対象としました。

まとめ

CloudWatch ダッシュボードを利用する事で、複数のAWSリソースのメトリックを効率よく確認可能となります。

今回紹介させて頂いた項目以外にも、負荷テストや、稼働後に発生したインシデント調査などでシステム固有のボトルネックが特定できた場合、 関連する項目をダッシュボードに追加してご活用ください。

CloudFormation

今回紹介したCloudWatchダッシュボードを再現するテンプレート、以下の記事で紹介させて頂いています。

CloudFormationを利用してCloudWatchダッシュボードを設置してみた