サイトアイコン IT & ライフハックブログ｜学びと実践のためのアイデア集

Amazon CloudWatch設計ガイド：Google Cloud、Azureと比較する監視とログの実務

greeden

Amazon CloudWatchを導入しても、収集するデータと異常時の行動が決まっていなければ、監視画面と通知が増えるだけです。

先に利用者へ届けたい品質を決め、その品質を測るメトリクス、原因を調べるログとトレース、対応を始めるアラームを順に設計します。

この記事では、CloudWatchの基本をGoogle CloudとAzureのサービスに対応づけ、監視基盤を実務で組み立てる順序を解説します。

Amazon CloudWatchが担う役割

Amazon CloudWatchは、AWS上のリソースとアプリケーションから運用データを集め、可視化、検索、通知、自動処理につなげるオブザーバビリティサービスです。

オブザーバビリティとは、システムの外から得られるデータを使い、内部で何が起きているかを調べられる状態を指します。

監視対象には、Amazon EC2の設計、Amazon RDSの設計、AWS Lambdaの設計などが含まれます。

これらは別々の機能ですが、障害対応では一つの流れとして使います。

アラームで異常を知り、メトリクスで影響範囲を確かめ、ログとトレースで原因候補を絞り、復旧後の推移をダッシュボードで確認する流れです。

三つのクラウドを同じ設計軸で比べる

製品名を一対一で覚えるより、運用上の役割で対応づけると比較しやすくなります。

次の表は大まかな対応関係であり、各サービスの機能範囲や料金体系が同じという意味ではありません。

監視機能の役割と各クラウドの主なサービス
役割 AWS Google Cloud Azure
メトリクス CloudWatch Metrics Cloud Monitoring Azure Monitor Metrics
ログ CloudWatch Logs Cloud Logging Azure Monitor Logs
アプリケーションの追跡 CloudWatchのアプリケーション監視機能、X-Ray Cloud Trace Application Insights
検索と分析 CloudWatch Logs Insights Logs Explorerなど Log Analytics
通知 CloudWatch Alarms Alerting Azure Monitor Alerts
可視化 CloudWatch Dashboards Cloud Monitoringのダッシュボード Dashboards、Workbooks

マルチクラウドでは、共通の設計軸を持ちながら、クラウド固有の監視機能も残す方法が現実的です。

全体状況を共通画面で確認し、詳細な調査は各クラウドのネイティブ機能で行うという役割分担にできます。

SLIとSLOから監視項目を決める

監視設計は、取得できるメトリクスを並べる作業から始めません。

利用者が困る状態を定義し、それを数値でどのように捉えるかを決めます。

SLIは品質を測る指標

SLI（Service Level Indicator）は、サービス品質を測る指標です。

HTTPリクエストの成功率、応答時間、ジョブの完了率などが該当します。

p95応答時間は、観測したリクエストの95％が収まる応答時間を表します。

平均値だけでは一部の遅いリクエストが見えにくいため、利用者が感じる遅さを捉える指標として使えます。

SLOは品質の目標

SLO（Service Level Objective）は、SLIに対して定める目標です。

たとえば「90日間のHTTP成功率を99.9％以上にする」「p95応答時間を500ミリ秒未満にする」という形で表します。

これらの数値は説明用の例であり、実際の目標は利用者への影響、現在の実績、復旧体制を踏まえて決める必要があります。

インフラ指標と利用者指標を分ける

CPU使用率や空き容量は原因候補を探すためのインフラ指標であり、成功率や応答時間は利用者への影響を捉える指標です。

CPU使用率が高くてもサービスが正常な場合はあり、CPU使用率が低くても外部依存先の障害でリクエストが失敗する場合があります。

緊急通知には利用者指標を優先し、インフラ指標は原因調査や予兆の確認に使うと、行動につながらない通知を減らせます。

メトリクスを三つの種類に分ける

AWSサービスが提供するメトリクス

EC2、RDS、Lambda、ロードバランサー、SQSなど、多くのAWSサービスはCloudWatchへメトリクスを送ります。

代表例は、EC2のCPUUtilization、RDSのDatabaseConnections、LambdaのErrors、SQSのApproximateNumberOfMessagesVisibleです。

利用できる指標、収集間隔、料金条件はサービスと設定で異なるため、設計時には対象サービスの最新仕様を確認します。

アプリケーション固有のカスタムメトリクス

注文成功数、ログイン失敗数、バッチ処理時間など、事業やアプリケーションに固有の値はカスタムメトリクスとして送信できます。

CloudWatch Metricsでは、名前空間、メトリクス名、ディメンションを組み合わせて系列を識別します。

ディメンションの値を細かく増やすと系列数も増えやすいため、調査に必要な分類だけを採用します。

ログから作るメトリクス

CloudWatch Logsのメトリクスフィルターを使うと、条件に合うログを数値として数え、グラフやアラームへつなげられます。

たとえば、支払い失敗を示すログの件数を数えれば、失敗が増えたことを検知できます。

ただし、ログの表記が処理ごとに異なると正しく集計できないため、状態コードやイベント名を一定の形式で記録します。

CloudWatch Logsを調査しやすく保つ

CloudWatch Logsでは、ロググループの中にログストリームが作られます。

ロググループはアプリケーションや用途のまとまり、ログストリームはインスタンスや実行環境など、ログを発生させた単位として考えると整理しやすくなります。

収集経路を選ぶ

Amazon VPCの設計で扱う通信記録など、種類の異なるログを一つのグループへ混在させると、権限、保持期間、検索範囲を分けにくくなります。

サービス、環境、用途を基準にロググループを分け、命名規則を先に決めます。

保持期間と長期保管を分ける

保持期間は、障害調査、監査、セキュリティ確認など、ログを残す目的から決めます。

すべてのログを同じ期間だけ残すと、不要な保存コストが生じる一方、必要な証跡を早く失うおそれがあります。

CloudWatch Logs内の保持期間を用途別に設定し、長期保管が必要なデータはS3などへの保管方法を別に設計します。

継続的なアーカイブにはサブスクリプションを検討し、S3へのエクスポートタスクは特定期間のデータを書き出す用途として使い分けます。

アラームを対応手順と一緒に設計する

CloudWatch Alarmは、メトリクスが指定した条件を満たしたときに状態を変え、通知や自動アクションにつなげます。

しきい値だけでなく、評価期間、何回の違反で通知するか、データが欠けたときの扱いまで含めて条件を決めます。

「CPUUtilizationが80％を超えた状態が5分続く」「5xxエラー率が1％を超える」といった値は設定例であり、どのシステムにも共通する推奨値ではありません。

通知レベルと運用上の扱いの例
レベル 利用者への影響 対応
情報 直ちに影響しない変化 ダッシュボードや定期レビューで確認する
警告 影響が広がる可能性がある 営業時間内の調査や作業チケットにつなげる
重大 SLO違反または明確な利用者影響がある 担当者を呼び出し、復旧手順を開始する

通知には、対象サービス、影響を確かめる画面、最初に行う確認、担当チームを添えます。

受信した人が行動を選べない通知は、しきい値を調整するだけでなく、監視目的そのものを見直します。

ダッシュボードは利用者ごとに分ける

一枚のダッシュボードへすべてのグラフを詰め込むと、異常時に見るべき場所が分かりません。

画面を見る人と、その人が下す判断を決めてから項目を選びます。

同じ指標でも、担当者には詳細な時系列が必要であり、事業責任者には影響の有無と継続時間が必要です。

ログ、メトリクス、トレースを結びつける

複数のサービスを通るリクエストでは、メトリクスだけを見ても遅延箇所を特定できません。

リクエストIDやトレースIDをログへ含め、メトリクス上で異常が始まった時間帯から、関連ログとトレースへ移れるようにします。

AWSではCloudWatchの各機能とX-Ray、Google CloudではCloud Monitoring、Cloud Logging、Cloud Trace、AzureではAzure MonitorとApplication Insightsを組み合わせる考え方です。

根本原因分析（RCA）は、目に見えたエラーだけを直すのではなく、エラーを生んだ条件と経路を特定する作業です。

時刻、サービス名、環境名、リクエストを識別する値が揃っていると、三種類のデータを行き来しやすくなります。

監視コストを設計段階で管理する

監視費用は、収集量、保存量、検索量、メトリクスの系列数、解像度、アラームやダッシュボードの構成などで変わります。

料金項目と無料利用枠は変わる可能性があるため、固定額や「標準だから無料」といった前提を設計根拠にしません。

  1. 目的のない収集を止める：取得するメトリクスとログごとに、使う判断または調査を記録します。
  2. ディメンションを絞る：調査で使わない分類を増やさず、メトリクス系列の増加を抑えます。
  3. ログ量を用途別に把握する：本番、検証、監査などを分け、保持期間を個別に設定します。
  4. 高い時間解像度を限定する：短い間隔でなければ見つけられない事象だけに使います。
  5. 定期的に棚卸しする：使われていないアラーム、ダッシュボード、ロググループを確認します。

用途別の監視構成

WebまたはAPIサービス

最初に成功率と応答時間を利用者指標として置き、EC2、ロードバランサー、RDS、Lambdaなどの標準メトリクスを原因調査用に加えます。

アプリケーションログとアクセスログには、同じリクエストを追える識別子を含めます。

SLO違反を重大通知へつなげ、容量不足などの予兆は警告として別経路で扱います。

バッチ処理とデータパイプライン

リクエストの応答時間ではなく、開始件数、完了件数、失敗件数、処理時間、未処理件数を中心に監視します。

「エラーが出たか」だけでなく、「予定した時刻までに完了したか」を確認できるメトリクスが必要です。

各処理段階のログへジョブIDを付けると、失敗した入力と停止箇所を追いやすくなります。

複数アカウントとマルチクラウド

複数のAWSアカウントでは、監視用アカウントへ必要な運用データを集約する構成を検討します。

複数クラウドを横断する場合は、Grafanaなどの共通画面を置く方法がありますが、クラウド固有の詳細情報まで一律に移す必要はありません。

誰がどのログとメトリクスを閲覧できるかは、AWS IAMの権限設計と合わせて決めます。

カスタムメトリクスを送信する例

次のPythonコードは、注文作成数をCloudWatch Metricsへ送る最小例です。

実行環境には、認証情報をコードへ書かず、必要なAPI操作だけを許可したIAMロールを設定します。

from datetime import datetime, timezone

import boto3

cloudwatch = boto3.client("cloudwatch", region_name="ap-northeast-1")


def put_order_count(count: int) -> None:
    cloudwatch.put_metric_data(
        Namespace="MyApp/Orders",
        MetricData=[
            {
                "MetricName": "OrderCreated",
                "Dimensions": [
                    {"Name": "service", "Value": "web"},
                    {"Name": "env", "Value": "prod"},
                ],
                "Timestamp": datetime.now(timezone.utc),
                "Value": count,
                "Unit": "Count",
            }
        ],
    )

このメトリクスをSLOやアラームに使う前に、何を一件と数えるのか、再試行や重複をどう扱うのかを決めます。

定義が曖昧な数値は、正確に収集できても判断には使えません。

よくある失敗と修正方法

監視設計で起きやすい問題と見直す項目
問題 原因 修正方法
CPUは正常なのに利用者が操作できない インフラ指標だけを監視している 成功率、応答時間、主要操作の完了率をSLIにする
ログ検索に時間がかかる 用途の異なるログが混在し、形式も揃っていない ロググループ、命名規則、検索に使う項目を整理する
通知が無視される 受信後の行動が決まっていない 利用者影響と対応期限で通知レベルを分ける
監視費用の増加理由が分からない 収集量、系列数、保持期間の責任者が不明確 用途と費用を定期的に棚卸しする
チームごとに違う数字を見ている SLIの定義と集計条件が共有されていない 共通の定義を文書化し、共通画面から詳細画面へ分岐する

導入時のチェックリスト

  1. 利用者が困る状態を一つ選び、対応するSLIを定義する。
  2. 現在値を確認し、根拠のあるSLOと評価期間を決める。
  3. 原因調査に必要なインフラ指標、ログ、トレースを選ぶ。
  4. ロググループの分け方、命名規則、保持期間を決める。
  5. 通知レベルごとに受信者、対応期限、最初の確認手順を決める。
  6. 担当者向けと事業責任者向けのダッシュボードを分ける。
  7. 収集量と費用を確認し、不要なデータを定期的に見直す。

CloudWatch設計の結論

CloudWatchは、メトリクス、ログ、トレース、アラーム、ダッシュボードを通じて、異常の検知から原因調査までを支える基盤です。

最初に作るべきものは大量のグラフではなく、利用者への影響を表すSLI、その目標であるSLO、目標を外れたときの対応手順です。

この順序を守れば、Google CloudやAzureへ移っても、製品名に左右されず同じ設計判断を応用できます。

この記事に関連する株式会社greedenの取り組み

監視は、障害後にログを見る作業ではなく、利用者への影響を早く捉えて改善につなげる設計です。株式会社greedenは、要件定義から保守運用まで伴走するWebシステム開発を通じ、サービスに合った監視と運用の整備を支援します。

モバイルバージョンを終了