AWS CloudWatchカスタムメトリクス徹底解説！効果的な作成と活用戦略

AWS CloudWatchカスタムメトリクスを活用したモニタリング戦略

カスタムメトリクスで実現する詳細モニタリング

AWS CloudWatchの標準メトリクスは、EC2インスタンスのCPU使用率やネットワークトラフィックなど、基盤レベルの重要な指標を提供しますが、これだけではアプリケーション固有の挙動やビジネスロジックに関する詳細な状態を把握することは困難です。例えば、Webサービスの特定のAPIにおけるトランザクション数、データベースの同時接続数、アプリケーション内の特定処理の実行時間、S3バケット内のオブジェクト数、あるいは支払いシステムの処理成功率といった数値は、標準メトリクスでは取得できません。

カスタムメトリクスを導入することで、これらのアプリケーション固有の数値を可視化し、監視対象とすることが可能になります。これにより、システムの安定稼働を維持するための性能劣化の予兆を早期に検知したり、潜在的な問題を特定してサービス品質の向上に繋げたりできます。特に、ユーザー体験に直結するレスポンスタイムの悪化や、ビジネスに影響を及ぼすエラーレートの増加といった事象を、迅速に把握し対応するためにカスタムメトリクスは不可欠です。

標準メトリクスだけでは見過ごされがちな「隠れた問題」を発見し、よりプロアクティブな運用を実現するために、自社のサービスに合わせたカスタムメトリクス戦略を策定することが、安定したITサービスの提供に直結すると言えるでしょう。

監視戦略を設計するための重要要素

効果的なカスタムメトリクス戦略を立てる上で、最も重要な要素の一つが「名前空間（Namespace）」と「ディメンション（Dimension）」の設計です。名前空間はメトリクスの論理的なコンテナとして機能し、例えば「MyApp/WebServer」や「BillingService/Payments」のように、サービスやコンポーネントごとにユニークな名前を定義することで、メトリクスを整理しやすくします。これにより、同じメトリクス名（例えば「Errors」）であっても、異なるアプリケーションからのものとして明確に区別できます。

ディメンションは、メトリクスデータをさらに細分化し、特定のコンテキストで分析するためのキーと値のペアです。例えば、「InstanceId: i-xxxxxxxxxxxxxxxxx」や「Environment: Production」、「ApiName: GetProductInfo」といったディメンションを設定することで、特定のEC2インスタンスからのエラー数や、本番環境の特定APIのエラー数をピンポイントで監視できます。どのようなディメンションを設定するかによって、取得できるデータの粒度や分析のしやすさが大きく変わるため、事前に監視したいデータの目的と分析粒度を明確に定義することが極めて重要です。

適切な名前空間とディメンションの設計は、後続のアラーム設定やグラフ表示の柔軟性、そして最終的な問題解決までのスピードに直接影響を与えます。将来的な拡張性も考慮し、汎用性と具体性のバランスを取った設計を心がけましょう。

コストとメリットを考慮した戦略的導入

カスタムメトリクスの導入は、システム監視の品質を飛躍的に向上させますが、同時にコストの側面も十分に考慮する必要があります。Amazon CloudWatchのカスタムメトリクスには、毎月10件までの無料利用枠が提供されていますが、これを超過した分については従量課金が発生します。料金体系は段階的であり、件数が増えるにつれて課金額も増大する可能性があるため、闇雲に多くのメトリクスを作成することは、予期せぬコスト増を招くリスクがあります。

したがって、カスタムメトリクスを導入する際は、システムの重要度、監視の緊急性、そしてコスト対効果を慎重に検討し、本当に必要なメトリクスを厳選することが求められます。例えば、ビジネスに直接影響を与える主要なトランザクション数や、障害発生に直結するリソース枯渇の兆候など、優先度の高い指標から導入を進めるのが効果的です。また、高解像度メトリクス（60秒未満の間隔で取得されるデータ）は、より細かい粒度での監視を可能にしますが、その分データ量やAPIリクエスト数が増加し、コストが高くなる傾向にあります。リアルタイム性が求められる重要なメトリクスにのみ適用するなど、メリハリのある運用を心がけましょう。

導入前にチーム内で「何を監視するべきか」「どのような情報を得たいか」「許容できるコストはどれくらいか」といった議論を十分に行い、コストとメリットのバランスが取れた戦略を策定することで、カスタムメトリクスの価値を最大限に引き出すことができます。

出典：Amazon CloudWatch の料金

実践！カスタムメトリクス作成の具体的なステップとデータ送信

CloudWatch Agentを利用したOSメトリクス収集

OSレベルのメトリクス（メモリ使用率、ディスクI/O、プロセス数、TCP接続数など）をCloudWatchカスタムメトリクスとして収集する最も一般的な方法は、CloudWatch Agentを利用することです。CloudWatch Agentは、EC2インスタンスやオンプレミスサーバーにインストールするソフトウェアで、OSのさまざまなデータを自動的に収集し、CloudWatchへ送信してくれます。これにより、標準メトリクスでは不足するOSの詳細な情報を得ることが可能になります。

具体的なステップとしては、まず監視対象のサーバーにCloudWatch Agentをインストールします。次に、Agentの設定ファイル（通常は/opt/aws/amazon-cloudwatch-agent/bin/config.json）を編集し、収集したいメトリクス、収集間隔、名前空間、ディメンションなどを定義します。例えば、メモリ使用率を「MyServer/OS」という名前空間で、インスタンスIDをディメンションとして毎分収集する設定を記述します。設定が完了したらAgentを起動し、CloudWatchコンソールでカスタムメトリクスが正しく表示されているかを確認しましょう。

AgentはYAML形式の設定ファイルからJSON形式のAgent設定ファイルを生成するウィザードも提供しており、初心者でも比較的簡単に設定ファイルを生成できます。これにより、各サーバーのOSの状態を詳細に把握し、リソース不足やパフォーマンス低下の予兆を早期に検知できる体制を構築できます。

PutMetricData APIによるアプリケーションからの送信

アプリケーション固有のビジネスロジックに関連するメトリクスを収集する場合、AWS SDKを通じてPutMetricData APIを直接呼び出す方法が効果的です。この方法は、例えば、特定のWeb APIへのリクエスト成功数やエラー数、データベースへのクエリ実行時間、ユーザーのログイン試行回数、カートに追加されたアイテム数など、アプリケーションが「認識している」数値を直接CloudWatchに送信するのに適しています。これにより、アプリケーション内部の挙動をきめ細かく可視化し、ビジネスパフォーマンスへの影響を監視できます。

実装の基本的な流れは、まず使用しているプログラミング言語のAWS SDKをアプリケーションに組み込みます。次に、メトリクスを送信したいロジックの箇所で、PutMetricDataメソッドを呼び出します。この際、メトリクス名、値、タイムスタンプ、単位（Count, Bytes, Millisecondsなど）、そして名前空間とディメンションを指定します。例えば、PythonのBoto3 SDKを使用する場合、cloudwatch.put_metric_data()関数を使って、MetricDataパラメータにメトリクスの詳細をリスト形式で渡します。

このアプローチの利点は、非常に柔軟性が高く、アプリケーションのどのような数値でもカスタムメトリクスとして送信できる点です。ただし、メトリクスの送信頻度が高すぎるとAPIリクエスト数が増え、課金対象となる可能性があるため、適切な送信間隔や集計ロジックをアプリケーション側で考慮することが重要です。また、送信元のアプリケーションに適切なIAMロールまたは認証情報を付与する必要があります。

Embedded Metric Format (EMF) でログから効率的にメトリクスを生成

大規模な分散システムやサーバーレスアーキテクチャ（AWS Lambdaなど）において、多数のカスタムメトリクスを効率的かつコストを抑えて生成したい場合、Embedded Metric Format (EMF) が非常に有効な手段です。EMFは、構造化されたJSON形式でログを出力する際に、そのログの中にメトリクスの定義を埋め込むことで、CloudWatch Logsが自動的にカスタムメトリクスを抽出・生成する仕組みです。これにより、アプリケーションが直接PutMetricData APIを呼び出す手間を省き、ログを処理するオーバーヘッドを低減できます。

EMFを使用する利点は多岐にわたります。まず、ログとメトリクスが連携しているため、異常なメトリクスが検出された際に、その原因となったログイベントに簡単にアクセスできます。また、メトリクスの送信はログエージェント（CloudWatch Agentなど）やLambdaのサービス連携によって行われるため、アプリケーション開発者はログ出力のコードを書くだけで済み、メトリクス送信ロジックを個別に実装する必要がありません。これにより、開発効率が向上し、メトリクス定義の一貫性を保ちやすくなります。

EMF形式のログは、特定のJSONスキーマに従って記述します。例えば、_awsというキーの下にCloudWatchMetricsオブジェクトを配置し、名前空間、メトリクス定義、ディメンションなどを指定します。Lambda関数でPythonやTypeScriptを使用する場合、AWSが提供するLoggerライブラリを活用することで、簡単にEMF形式のログを出力できます。この方法は、特にLambdaの実行時間分布、特定のビジネスイベント数、エラー発生時の詳細情報などを効率的に収集する際に、非常に強力なツールとなります。

ユースケース別カスタムメトリクス活用例と推奨設定

Webアプリケーションのパフォーマンス監視

Webアプリケーションの安定稼働とユーザー体験の向上には、パフォーマンスの詳細な監視が不可欠です。CloudWatchカスタムメトリクスは、標準メトリクスでは捉えきれないアプリケーション層のパフォーマンス指標を可視化するのに役立ちます。例えば、特定のAPIエンドポイントごとの平均応答時間、90パーセンタイル応答時間、5xxエラーの発生回数、リクエスト処理のキューイング時間などをカスタムメトリクスとして収集できます。

推奨される設定としては、まず各APIパスをディメンションとして設定することで、どのAPIがパフォーマンスボトルネックになっているかを特定しやすくします。例えば、ApiName: /products/{id}やApiName: /orderといったディメンションを利用します。また、エラーメトリクスについては、ErrorCode: 500やErrorType: DBConnectionFailedのようなディメンションを追加することで、エラーの具体的な原因や種類を瞬時に把握できます。これにより、問題発生時に影響範囲を限定し、迅速な対応が可能になります。これらのメトリクスに対して、応答時間が一定の閾値を超えた場合やエラーレートが急増した場合にアラームを発動するよう設定することで、ユーザーが体感する前に問題を検知し対応する体制を構築できます。

アプリケーションサーバーのメトリクス（例: スレッドプール使用率、セッション数）もCloudWatch Agent経由で収集し、OSレベルのリソースとアプリケーションのパフォーマンスを総合的に監視することで、より多角的な分析と問題解決に繋がります。

データベースの状態とリソース利用率監視

データベースは多くのアプリケーションのバックボーンであり、その健全性はサービス全体の安定性に直結します。AWS RDSなどのマネージドサービスでは多くのメトリクスが提供されますが、特定のユースケースではカスタムメトリクスが必要となる場合があります。例えば、データベースの接続プール利用率、特定の重いクエリの実行時間、レプリケーションラグの詳細な監視、アプリケーションからのコネクション確立失敗回数などが挙げられます。

これらのメトリクスを収集することで、データベースのパフォーマンスボトルネックを早期に発見し、例えばコネクションプールの枯渇によるアプリケーションエラーや、長時間のクエリによるスループット低下といった問題を予防できます。推奨設定としては、データベースの種類（例: DBEngine: MySQL）、データベースインスタンスID、そしてアプリケーションからの接続元の識別子などをディメンションとして設定すると良いでしょう。これにより、どのデータベースインスタンスの、どのアプリケーションからの接続に問題があるかを迅速に特定できます。

特に、自己管理型のデータベース（EC2上のPostgreSQLなど）を使用している場合は、CloudWatch Agentを用いてOSレベルのメトリクス（例: ディスクI/Oレイテンシー、空きメモリ）に加え、データベースのログパーサーなどを用いてカスタムメトリクス（例: Slow Query Count）を収集することが、安定運用の鍵となります。これらのメトリクスに対するアラームは、データベースのパフォーマンス低下が顕在化する前に対応できるよう、適切な閾値を設定することが重要です。

サーバーレスアーキテクチャ (Lambda) の詳細監視

AWS Lambdaをはじめとするサーバーレスアーキテクチャは、その特性上、インフラの管理はAWSに任せられますが、アプリケーションのパフォーマンスやコスト効率を最適化するためには、詳細な監視が不可欠です。Lambdaの標準メトリクスは、実行回数やエラー数を提供しますが、個々の関数の処理時間の内訳、外部API呼び出しのレイテンシー、コールドスタートの発生回数、メモリ使用量の詳細といった情報はカスタムメトリクスとして収集するのが効果的です。

サーバーレス環境でカスタムメトリクスを収集する最も推奨される方法は、Embedded Metric Format (EMF) の活用です。Lambda関数内でEMF形式のログを出力することで、自動的にCloudWatch Logsからカスタムメトリクスが生成されます。例えば、関数の実行中に特定の処理にかかった時間をミリ秒単位で記録したり、外部API呼び出しのステータスコードを記録したりすることで、関数のパフォーマンスボトルネックを特定できます。

推奨設定としては、関数名やバージョンをディメンションとして設定することで、特定の関数のデプロイ状況とパフォーマンスの関連性を追跡しやすくします。また、コールドスタート発生回数をカスタムメトリクスとして監視することで、プロビジョニングされた同時実行数などの設定が適切かどうかの判断材料になります。これらの詳細なメトリクスを活用することで、Lambda関数の実行効率を最大化し、コストを最適化しながら、より応答性の高いサーバーレスアプリケーションを構築できるようになります。

カスタムメトリクス運用における注意点とコスト最適化

料金体系の理解と無料枠の活用

AWS CloudWatchカスタムメトリクスは非常に強力な監視ツールですが、その料金体系を正確に理解し、適切に運用しないと、予期せぬコストが発生する可能性があります。CloudWatchカスタムメトリクスは従量課金制であり、毎月10件の無料利用枠がアカウント単位で提供されます。この無料枠を超過すると、段階的な料金が適用されるため、監視対象のメトリクス数が増えれば増えるほど、コストは増加します。例えば、10件を超え10,000件までは1件あたり月額0.30ドル、それを超える件数ではさらに低い単価が設定されています。

コストを最適化するためには、まず本当に監視が必要なメトリクスを厳選することが重要です。すべてのアプリケーションログや内部変数をメトリクス化するのではなく、システムの健全性、パフォーマンス、ビジネス上の重要度が高い指標に絞り込みましょう。定期的にメトリクスリストを見直し、不要になったものは削除することもコスト削減に繋がります。また、高解像度メトリクス（1分未満の粒度）は、APIリクエスト数も課金対象となるため、リアルタイム性が本当に必要なごく一部の重要な指標にのみ利用を限定し、基本的には標準解像度（1分以上）で十分かを検討すべきです。

CloudWatchの料金は透明性が高いものの、積算されると高額になる場合があります。AWSの料金計算ツールを活用して導入前の試算を行い、月々の予算と照らし合わせながら、無理のない範囲でカスタムメトリクスを導入・運用する計画を立てましょう。

出典：Amazon CloudWatch の料金

高解像度メトリクス利用時の考慮事項

CloudWatchカスタムメトリクスでは、通常の1分間隔のデータ収集だけでなく、60秒未満の間隔でデータを取得する「高解像度メトリクス」も利用できます。これにより、秒単位での非常に詳細なパフォーマンスの変動を捉えることが可能となり、瞬間的なスパイクやマイクロサービスの短い処理における問題特定に役立ちます。しかし、高解像度メトリクスを利用する際には、いくつかの重要な注意点があります。

まず、高解像度メトリクスは、その細かい粒度ゆえにデータ量が増加し、APIリクエスト頻度も高くなるため、標準メトリクスよりもコストが高くなる傾向があります。CloudWatch AgentやPutMetricData APIでデータを送信する際、StorageResolutionパラメータを60未満に設定すると高解像度として扱われます。したがって、高解像度メトリクスは、本当に秒単位での監視が必要な、ごく限られたクリティカルな指標にのみ適用することがコスト最適化の鍵となります。

さらに重要な点として、高解像度メトリクスは、わずか3時間しか保持されません。これは、短期間のリアルタイムな問題解決には有効ですが、それ以上の長期的なトレンド分析や履歴データの参照には不向きです。長期的な分析が必要な場合は、高解像度データをCloudWatch Logsに送り、そこから定期的に集計して標準解像度のメトリクスとして再度送信したり、S3などのストレージにエクスポートして保存したりするなどの工夫が必要です。データ保持期間の制限を理解し、用途に応じて適切な解像度を選択しましょう。

出典：メトリクスの概念 – Amazon CloudWatch

効果的なアラーム設定と運用負荷の軽減

カスタムメトリクスを導入する目的の一つは、システムの異常を早期に検知し、適切なアクションを自動的に実行することです。そのためには、効果的なアラーム設定が不可欠です。アラームを設定する際には、単に閾値を決めるだけでなく、アラームの状態変化に必要なデータポイント数や評価期間を慎重に設定することが重要です。

例えば、短時間の一過性のスパイクで不必要なアラートが大量に発生する「ノイズアラーム」を避けるためには、「5分間に3つのデータポイントが閾値を超えた場合にアラームを発動する」といった設定が有効です。これにより、一時的な揺らぎには反応せず、持続的な異常のみを検知できるようになります。また、アラームアクションとしては、Amazon SNSを通じて運用担当者に通知を送るだけでなく、Lambda関数を起動して特定の復旧処理を実行させたり、Auto Scalingグループのキャパシティを自動的に調整させたりすることも可能です。これにより、問題発生時の手動介入を減らし、運用負荷を大幅に軽減することができます。

アラーム設定は一度行ったら終わりではなく、システムの振る舞いの変化やアプリケーションの改修に合わせて、定期的に見直し、最適化していく必要があります。アラート疲労を避け、本当に重要なアラートにのみ運用チームが集中できる環境を構築するために、アラームの目的と影響範囲を明確にし、適切なアクションを設計することが、安定稼働と効率的な運用に直結します。

【ケース】カスタムメトリクス未設定による障害発生とその改善

架空のケース: Webサービスの応答遅延と原因不明の障害

ある日、人気のあるECサイトで、ユーザーから「ページの表示が遅い」「購入手続きが完了しない」といった報告が寄せられ始めました。運用チームがCloudWatchでEC2インスタンスの標準メトリクスを確認すると、CPU使用率やネットワークトラフィックには異常な上昇は見られず、ディスクI/Oにも特段の問題は認められませんでした。データベース（RDS）の標準メトリクスも確認しましたが、CPUやメモリ使用率、コネクション数も通常範囲内で、どこにも明らかな異常は発見できません。

しかし、ユーザーからのクレームは止まらず、サービスの応答速度は明らかに低下しています。原因が特定できないまま時間が経過し、顧客満足度は低下し、売上にも影響が出始めました。結果的に、調査に数時間かかった末、アプリケーションログを詳細に解析したところ、実はデータベースの「コネクションプールが枯渇」していたことが判明しました。アプリケーションが新しいデータベース接続を確立しようとしてもできず、処理が滞留していたのです。標準メトリクスでは、データベースへの「物理的な接続数」は正常に見えても、アプリケーション内部の「接続プール利用率」までは監視できていなかったため、この問題を見逃していました。

このケースでは、標準メトリクスだけではアプリケーション層の深い問題を検知できず、原因究明に多大な時間とリソースを費やしてしまいました。サービス停止には至らなかったものの、ユーザー体験の低下とそれに伴うビジネス機会の損失は避けられませんでした。

カスタムメトリクス導入による原因特定と再発防止

前述のケースを受けて、運用チームは同様の障害再発防止策として、CloudWatchカスタムメトリクスの導入を決定しました。まず、アプリケーションエンジニアと連携し、最もクリティカルな指標として「DBコネクションプール利用率」と「主要なAPIエンドポイントの実行時間」をカスタムメトリクスとして収集することにしました。実装には、アプリケーションコードからPutMetricData APIを呼び出す方法を採用し、特定APIのパスやデータベースインスタンスIDをディメンションとして追加しました。

導入後、数日経ったある日のピーク時、設定した「DBコネクションプール利用率」メトリクスが事前に定義した閾値（例えば、80%）を超過し、直ちにアラームが発動しました。運用チームは即座にデータベースの接続数を調整する対応を施し、Webサービスの応答遅延が発生する前に問題を未然に防ぐことができました。また、「主要APIの実行時間」メトリクスを監視することで、特定のAPIだけが遅延し始めていることを早期に検知し、そのAPIの負荷分散設定を調整するといったプロアクティブな対応も可能になりました。

このように、カスタムメトリクスを導入することで、標準メトリクスでは捉えきれなかったアプリケーション内部の「隠れた問題」を可視化し、障害の予兆を検知できるようになりました。これにより、問題がユーザーに影響を及ぼす前に対応する「プロアクティブな運用」へと大きく改善され、サービスの安定性と信頼性が向上しました。

チーム体制とモニタリング文化の醸成

カスタムメトリクスの導入は、単なる技術的な施策にとどまらず、組織全体の運用文化にも深く影響を与えます。成功の鍵は、開発チームと運用チームが連携し、監視すべき指標とその意味について共通認識を持つことです。開発者は自分のコードがどのようなメトリクスを生成し、それがシステムの健全性にどう影響するかを理解する必要があります。また、運用チームはアラートを受け取った際に、どのメトリクスが何を示しているかを素早く判断できる知識が必要です。

このような連携を深めることで、より質の高いメトリクス設計が可能になり、アラートの誤検知を減らし、本当に重要な情報に集中できる環境が整います。定期的なレビュー会を設け、メトリクスの有効性やアラームの閾値、通知設定などを議論することは、この文化を醸成する上で非常に効果的です。現代のIT業界では、ITエンジニアの新規求人倍率が4.0倍（厚生労働省 / 2025年12月発表）と非常に高く、優秀な人材の確保と定着が課題となっています。効率的でストレスの少ない運用体制は、エンジニアのエンゲージメントを高め、離職率の低下にも寄与する可能性があります。

カスタムメトリクスを通じた「見える化」は、単なる監視ツールではなく、チーム間のコミュニケーションを促進し、システム改善のサイクルを加速させるための強力な手段です。全員がオーナーシップを持ってモニタリングに取り組むことで、システムの安定性と成長を支える強固な基盤が築かれるでしょう。

出典：厚生労働省