DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

AWS CloudWatchをマスターしてプロアクティブなパフォーマンス監視と最適化を実現

AWS CloudWatchをマスターして、AWSでのピークパフォーマンスを引き出しましょう。カスタムメトリクスの設定、パーセンタイル統計（P99/P95）を活用した正確なレイテンシ追跡、そしてAuto Scalingをトリガーするインテリジェントアラームの構成方法を学びます。このガイドでは、最適化された監視ダッシュボードを構築し、エンドユーザーに影響が出る前にパフォーマンスのボトルネックをプロアクティブに解決するための実践的な手順を提供します。

AWS CloudWatchをマスターしてプロアクティブなパフォーマンス監視と最適化を実現

AWS CloudWatchは、多くのAWSインシデントの謎を解く鍵となります。遅いチェックアウトフロー、突然スロットリングされるLambda関数、接続を使い果たすRDSデータベース、増え続けるSQSキューなど、これらすべての手がかりはメトリクスとログに残ります。難しいのはCloudWatchを有効にすることではありません。難しいのは、ユーザーから何かが壊れていると知らされる前に行動できるシグナルを選択することです。

優れたCloudWatch監視は、プラットフォームの症状とアプリケーションの動作を結びつけます。CPU、メモリ、I/Oも重要ですが、チェックアウトの失敗、キューの経過時間、支払いのレイテンシ、1分あたりの成功ジョブ数も同様に重要です。

AWS CloudWatchのコアコンポーネント

CloudWatchは、時系列データ（メトリクスと呼ばれる）を収集し、それをアラームを使用してしきい値に対して評価するシステムで動作します。このデータはダッシュボードで可視化され、ログとイベントによって補完されます。

1. メトリクス：監視の基盤

メトリクスは、時間経過に伴って追跡される数値測定値です。すべてのAWSサービスは、標準メトリクス（例：EC2 CPU使用率、S3リクエスト数）を自動的に公開します。しかし、真のパフォーマンス監視には、デフォルトを超えた対応が必要です。

標準メトリクスとカスタムメトリクス

  • 標準メトリクス： AWSサービスによって自動的に収集されます。解像度はサービスと設定によって異なります。多くの一般的なサービスは1分間隔のメトリクスを公開しますが、一部の基本設定や古い設定では5分間隔を使用します。
  • カスタムメトリクス： ユーザー自身が公開するデータで、アプリケーション固有のパフォーマンス指標を測定するためによく使用されます。

AWS CLIを使用したカスタムメトリクスの公開：

put-metric-dataコマンドを使用して、カスタムメトリクスを公開できます。これは、アプリケーションの応答時間、キューの深さ、またはビジネスクリティカルな運用ステータスを監視するために重要です。

aws cloudwatch put-metric-data \
    --metric-name "CheckoutLatency" \
    --namespace "MyApp/ECommerce" \
    --value 150 \
    --unit "Milliseconds" \
    --region us-east-1

メトリクスの粒度

CloudWatchのカスタムメトリクスは、標準解像度または高解像度にできます。高解像度のカスタムメトリクスは1秒単位で保存でき、より短い期間でアラームを設定できるため、変動の激しいシステムに役立ちます。ただし、ボリュームが増え、アラームが増えるとコストが増加する可能性があるため、選択的に使用してください。

2. アラーム：しきい値に基づくアクションのトリガー

アラームは、OK、INSUFFICIENT_DATA、ALARMの3つの状態間を遷移します。アラームは、指定されたしきい値が定義された期間数にわたって違反された場合にアクションをトリガーします。

パフォーマンスアラームの設定

効果的なパフォーマンスアラームは、単なる事後対応の障害ではなく、先行指標に焦点を当てます。たとえば、EC2 CPU使用率の監視は良いですが、Tファミリーインスタンスの**BurstBalance**メトリクスを監視すると、使用率が100%に達する前に将来のスロットリングを予測できます。

例：高レイテンシアラームの設定

カスタムCheckoutLatencyメトリクスが、3回連続の1分間の平均で500msを超えた場合、アラームをトリガーし、SNSトピックに通知します。

aws cloudwatch put-metric-alarm \
    --alarm-name "HighCheckoutLatencyAlarm" \
    --alarm-description "P95レイテンシが500msを超えた場合に警告" \
    --metric-name "CheckoutLatency" \
    --namespace "MyApp/ECommerce" \
    --statistic Average \
    --period 60 \
    --threshold 500 \
    --evaluation-periods 3 \
    --datapoints-to-alarm 3 \
    --comparison-operator GreaterThanThreshold \
    --actions-enabled \
    --alarm-actions arn:aws:sns:us-east-1:123456789012:PerformanceAlertsTopic

ベストプラクティス：パーセンタイル（p99、p95）の活用 レイテンシを監視する場合、Averageのみに依存しないでください。少数ではあるが問題のある遅いリクエストのグループが、一見正常に見える平均値の中に隠れてしまう可能性があります。テールレイテンシが重要な場合は、P99やP95などの統計を使用してください。

3. ダッシュボード：システムヘルスの可視化

ダッシュボードは、関連するメトリクスを1つの画面にまとめます。効果的なダッシュボードは、対象者（例：運用、開発、経営陣）に合わせて調整されます。

パフォーマンス最適化ダッシュボードの構築

パフォーマンス最適化のための適切に構造化されたダッシュボードは、関連するメトリクスをグループ化する必要があります。

  • システムヘルスパネル： CPU使用率、ネットワークイン/アウト、ディスク読み取り/書き込みIOPS（EC2/EBS用）。
  • アプリケーションパフォーマンスパネル： カスタムレイテンシメトリクス（P99）、エラー率（HTTP 5xxカウント）、リクエストスループット。
  • コスト/効率パネル： 実行中のインスタンス数、Reserved Instance使用率、EBSボリューム使用率（未使用のストレージを特定するため）。

CloudWatchダッシュボードは、テキスト注釈、メトリクス算術式（例：効率比率の計算）、さらにはCloudWatch Logs Insightsクエリ結果の埋め込みなど、複雑なウィジェットをサポートしています。

自動化されたパフォーマンス最適化のためのCloudWatch

監視データは、アクションを促進する場合にのみ価値があります。CloudWatchアラームは、自動化された最適化ワークフローを開始するための主要なメカニズムです。

Auto Scalingとのアラーム統合

最も強力な最適化手法の1つは、CloudWatchアラームを使用してAWS Auto Scalingグループ（ASG）を駆動することです。これにより、キャパシティが需要に正確に一致し、過剰プロビジョニング（コスト削減）と過小プロビジョニング（パフォーマンス低下）を防ぎます。

例：キューの深さに基づくスケールアウト

CPUのみに依存するのではなく、処理待ちのバックログに基づいてスケーリングします。SQSキューの場合、ApproximateNumberOfMessagesVisibleメトリクスにアラームを作成します。アラームがALARM状態になると、Auto ScalingアクションをトリガーしてEC2インスタンスをASGに追加します。

設定のヒント： スケーリングポリシーには、平均使用率メトリクス（例：平均CPUを60%に維持）を維持するように設定されたTarget Tracking Scalingを使用してください。これにより、AWSが動的にスケーリングを管理できるようになり、通常は静的なステップスケーリングよりも推奨されます。

詳細調査のためのログ活用

パフォーマンスの問題が発生した場合、CloudWatch Logsは根本原因分析に不可欠です。

  • 集中ログ管理： すべてのアプリケーションとサービス（VPCフローログ、Lambdaログ、ECS/EKSコンテナログ）をCloudWatch Logsにストリーミングするように設定します。
  • Log Insights： Log Insightsの強力なクエリ言語を使用して、大量のログをすばやく検索します。たとえば、2秒以上かかったすべてのリクエストを検索するには：
fields @timestamp, @message
| filter @message like /duration: \d{4,}/ 
| parse @message "*duration: *ms*" as duration
| filter as_number(duration) > 2000
| sort @timestamp desc
| limit 50

CloudWatch監視のベストプラクティス

CloudWatchから得られる価値を最大化し、パフォーマンスを最適化するには：

  1. サービス制限の監視： AWSサービス割り当て（例：実行中のLambda同時実行数の最大値、アカウントで使用可能な最大EBS IOPS）にアラームを設定します。割り当てに達すると、明確なアプリケーションエラーなしにパフォーマンスが完全に停止します。
  2. ベースラインパフォーマンスの確立： 最適化する前に、ピーク時とオフピーク時のシステムを監視して、正常がどのようなものかを定義します。これにより、無関係なノイズに基づいてアラームを設定することを防ぎます。
  3. 比率のためのメトリクス算術の使用： CloudWatch内で直接効率比率を計算します。たとえば、（総エラー数 / 総リクエスト数）* 100 で障害率の直接的なパーセンテージを取得し、複数の個別メトリクスを扱う必要をなくします。
  4. コスト管理： カスタムの高解像度メトリクスはコストが高くなります。慎重に使用してください。重要な急速に変化するシステム（ロードバランサーなど）にのみ1分間隔の解像度を使用します。デフォルトの5分間隔の解像度は、ほとんどのバックエンドサービスで十分です。
  5. タグ付け戦略： 監視対象のすべてのリソース（EC2、RDS、Lambda）に一貫性のあるタグが付けられていることを確認します。これにより、環境固有のフィルタリングされたダッシュボードやアラーム（例：Env: Prod、App: CheckoutService）を作成できます。

ダッシュボードをインシデントに合わせる

CloudWatchダッシュボードは、プレッシャーのかかる状況下で誰かが意思決定を行うのに役立つものであるべきです。ダッシュボードがシステムに多くのメトリクスがあることを証明するだけの場合、障害時に役立ちません。

Webアプリケーションの場合、最初の画面をシンプルなパスを中心に構築するのが好きです。トラフィックが入り、アプリケーションがそれを処理し、依存関係が応答し、ユーザーが成功するか失敗するか。これは通常、次のウィジェットが互いに近くに配置されることを意味します：

  • ロードバランサーまたはAPI Gatewayからのリクエスト数とエラー数。
  • 同じエントリポイントのP95またはP99レイテンシ。
  • アプリケーションレベルの成功および失敗メトリクス。
  • ECS、EKS、Lambda、またはEC2のCPU、メモリ、タスク数。
  • 遅いリクエストを説明する一般的なRDS、DynamoDB、Redis、SQS、または外部依存関係メトリクス。

正確なサービスは変わりますが、形状は同じままです。チェックアウトレイテンシが急上昇した場合、トラフィックが急増したのか、エラーが増加したのか、データベースのレイテンシが上昇したのか、ワーカーが遅れているのかを確認したいと思います。それらの手がかりを1か所にまとめてください。

明確なラベルなしに本番、ステージング、開発を混在させるダッシュボードは避けてください。インシデント中に、誰かが最終的に間違ったグラフを読むことになります。環境が明らかになるディメンション、タグ、命名規則を使用してください。

パーセンタイルを注意深く使用する

パーセンタイルはレイテンシに役立ちます。なぜなら、平均はユーザーの苦痛な体験を隠してしまうからです。ほとんどのリクエストが100msで完了しても、少数のグループが8秒かかる場合、平均はまだ許容範囲に見えるかもしれません。パーセンタイルグラフは、ロングテールを可視化します。

ただし、パーセンタイルは魔法ではありません。意味をなすには十分なトラフィックが必要であり、トラフィックの少ないサービスではノイズが多くなる可能性があります。1時間に数回実行される小さな内部ジョブの場合、P99よりも最大期間や明示的な障害メトリクスの方が有用な場合があります。安定したトラフィックがあるパブリックAPIの場合、P95とP99は監視する価値があることがよくあります。

アラームを作成するときは、CLIコマンドが実際に意図した統計を使用していることを確認してください。パーセンタイルアラームの場合は、--statistic Averageではなく、--extended-statistic p95またはp99を使用します：

aws cloudwatch put-metric-alarm \
  --alarm-name "HighCheckoutP95Latency" \
  --metric-name "CheckoutLatency" \
  --namespace "MyApp/ECommerce" \
  --extended-statistic p95 \
  --period 60 \
  --threshold 500 \
  --evaluation-periods 5 \
  --datapoints-to-alarm 3 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:PerformanceAlertsTopic

datapoints-to-alarm設定は重要です。5期間中3つを必要とすることで、1分間のノイズでページングされることなく、持続的な問題を捕捉できます。重要なシステムの場合は、推測ではなく実際の過去のトラフィックを使用してこれを調整してください。

AWSメトリクスの横にアプリケーションメトリクスを配置する

AWSサービスのメトリクスは、プラットフォームが何を見ているかを示します。アプリケーションメトリクスは、ユーザーが何をしようとしているかを示します。両方が必要です。

たとえば、ECSサービスは、支払いプロバイダーがタイムアウトしているためにチェックアウトが壊れている間、正常なCPUとメモリを示す場合があります。アプリケーションがPaymentAuthorizationFailure、CheckoutCompleted、またはPaymentProviderLatencyなどのメトリクスを公開しない限り、CloudWatchはそれを認識しません。

優れたカスタムメトリクスは、通常、ビジネスアクションに関連付けられています：

  • LoginSucceeded と LoginFailed
  • OrderCreated
  • PaymentAuthorizationLatency
  • QueueJobProcessed
  • ImportRowsFailed

ディメンションは有用に保ちますが、爆発的に増やさないでください。Service、Environment、Regionは通常問題ありません。すべてのユーザーID、リクエストID、またはURLパスのディメンションは、高カーディナリティのコストを生み出し、データの使用を難しくする可能性があります。詳細なリクエストごとの調査には、ログとトレースの方が適しています。

CloudWatch Embedded Metric Formatは、構造化JSONログをすでに記述している場合に便利です。これにより、同じイベントからログとメトリクスを出力できるため、アプリケーションの計装が簡素化されます。トレードオフはコストとボリュームです。構造化ログは強力ですが、ノイズの多いログはすぐに高価になります。

症状と原因を中心にアラームを構築する

よくある監視の間違いは、原因のみにアラームを設定することです：CPU高、メモリ高、ディスクキュー高。これらは有用ですが、必ずしもユーザーが影響を受けていることを意味するわけではありません。もう1つの間違いは、症状のみにアラームを設定することです：エラー率高、レイテンシ高、注文失敗。これらはユーザーが影響を受けていることを示しますが、理由は説明しません。

実用的なセットアップでは、両方を使用します：

  • 症状アラームはサービス所有者にページングします：エラー率高、レイテンシ高、成功した注文なし、キュー経過時間増加。
  • 原因アラームは診断をサポートします：データベースCPU、スロットリングされたDynamoDBリクエスト、Lambda同時実行、バーストバランスの枯渇、ディスク容量不足。
  • キャパシティアラームは早期に警告します：Auto Scalingが最大値に近い、サービス割り当てに近づいている、キュー backlog がワーカーの処理能力よりも速く成長している。

すべてのアラームが同じチャネルに同じ緊急度でページングする場合、人々はそのチャネルを信頼しなくなります。警告アラームは誰かを起こさずに表示できるようにし、ユーザーへの影響またはほぼ確実なユーザーへの影響のためにページングを予約してください。

検索だけでなく質問のためにLogs Insightsを使用する

CloudWatch Logs Insightsは、チームが繰り返し尋ねる質問のためにクエリを保存する場合に最も役立ちます。例：

fields @timestamp, status, path, durationMs
| filter status >= 500
| stats count() as errors by path
| sort errors desc
| limit 20

fields @timestamp, requestId, customerId, durationMs
| filter durationMs > 2000
| sort durationMs desc
| limit 50

fields @timestamp, @message
| filter @message like /ThrottlingException|Rate exceeded/
| sort @timestamp desc
| limit 100

これらのクエリはトレースに取って代わるものではありませんが、初動対応には十分な速さです。ランブックやダッシュボードのテキストウィジェットに保存して、システムが遅いときに次の担当者が構文を覚えていなくても済むようにしてください。

可視性を向上させながらコストを見直す

CloudWatchは、チームが高解像度のカスタムメトリクスを有効にしたり、すべてのログを永久に保持したり、独自のメトリクスディメンションをあまりにも多く作成したりすると、高額になる可能性があります。パフォーマンス監視は、予期しない請求書を作成するべきではありません。

保持期間は意図的に設定してください。本番アプリケーションログは、開発のデバッグログよりも長い保持期間が必要な場合があります。セキュリティログと監査ログには、独自のルールがある場合があります。詳細なサービスの場合は、CloudWatchに到達する前に、ノイズの多い情報ログをフィルタリングまたはサンプリングすることを検討してください。

メトリクスについては、実行できるアクションに一致する解像度から始めてください。サービスが安全にスケーリングするのに数分かかる場合、1秒メトリクスは応答を改善しない可能性があります。レイテンシスパイクを即座に捕捉する必要がある場合、その狭いシグナルに対して高解像度メトリクスは価値がある可能性があります。

有用な最初のCloudWatchセットアップ

新しい本番サービスの場合、堅実な最初のパスは次のとおりです：

  1. トラフィック、レイテンシ、エラー、飽和、依存関係の健全性を含むダッシュボード。
  2. エラー率高、レイテンシ高、トラフィックが予想される場合の成功トラフィックなし、キュー経過時間、および該当する場合はディスク容量不足のアラーム。
  3. 主要なユーザーアクションのアプリケーションメトリクス。
  4. リクエストIDと、ルート、ステータス、期間、依存関係でフィルタリングするのに十分なフィールドを持つ構造化ログ。
  5. 遅いリクエスト、5xxエラー、スロットリング、失敗したバックグラウンドジョブのための保存されたLogs Insightsクエリ。
  6. ノイズの多いアラーム、不足しているアラーム、CloudWatchコストの毎月のレビュー。

CloudWatchは、ユーザーが苦情を言った後にのみ誰かが開くダッシュボードではなく、チームの運用方法の一部になったときに最も効果的に機能します。インシデント中に尋ねる質問から始めて、それらの質問を中心にメトリクス、アラーム、ログを形成してください。