Zenn
🐡

AWS学びなおし(+TF)_CloudWatch Logs

2025/03/02に公開
AWS
tech

AWS CloudWatch Logsは、アプリケーションやシステムからのログデータを収集、監視、分析するためのサービスです。サーバー、コンテナ、Lambda関数、AWSサービスなど、様々なソースからのログを一元的に集約し、リアルタイムに近い形で監視や検索、分析を行うことができます。

CloudWatch Logsの主な構成要素

  • ログイベント (Log Event): ログの1行に相当するデータです。タイムスタンプとメッセージで構成されます。
  • ログストリーム (Log Stream): 同じソースからのログイベントのシーケンスです。通常、EC2インスタンスやコンテナインスタンス、Lambda関数インスタンスごとにログストリームが作成されます。
  • ロググループ (Log Group): 関連するログストリームの集合です。アプリケーションごと、環境ごと、サービスごとなど、目的に応じてロググループを構成します。ロググループには、保持期間、メトリクスフィルタ、サブスクリプションフィルタなどの設定を適用できます。
  • メトリクスフィルタ (Metric Filter): ログイベントの内容をパターンマッチングし、一致したログイベントに基づいてCloudWatchメトリクスを生成する機能です。エラー数、特定のキーワードの出現回数などをメトリクスとして監視できます。
  • サブスクリプションフィルタ (Subscription Filter): ログイベントをリアルタイムで他のAWSサービス (Kinesis Data Streams, Lambda, Kinesis Data Firehose) にストリーミング配信する機能です。ログのアーカイブ、リアルタイム分析、セキュリティ分析などに活用できます。
  • Logs Insights: 高度なログ分析を行うためのクエリエンジンです。SQLライクなクエリ言語を使用して、大量のログデータから必要な情報を効率的に抽出、集計、分析できます。

CloudWatch Logsの主な機能とメリット

  • 集中ロギング: 複数のソースからのログをCloudWatch Logsに集約することで、ログ管理の一元化を実現し、可視性を向上させます。
  • リアルタイム監視: ログイベントはほぼリアルタイムでCloudWatch Logsに収集され、メトリクスフィルタやサブスクリプションフィルタと組み合わせることで、異常検知やリアルタイムアラートを実現できます。
  • 柔軟な検索と分析: Logs Insightsを利用することで、複雑な条件でのログ検索や集計、分析が可能になり、問題の原因特定や傾向分析を効率的に行うことができます。
  • 長期保存: ロググループごとに保持期間を設定でき、監査ログや過去のログ分析のために長期間ログを保存できます。
  • 他のAWSサービスとの連携: サブスクリプションフィルタを通じて、Kinesis Data Streams, Lambda, Kinesis Data FirehoseなどのAWSサービスと連携し、ログデータの様々な活用方法を提供します。
  • サーバーレスアーキテクチャとの親和性: Lambda関数やコンテナ環境など、サーバーレスアーキテクチャで生成されるログを容易に収集、監視できます。
  • 運用負荷の軽減: ログサーバーの構築やメンテナンスが不要になり、運用負荷を軽減できます。

【実務レベルの内容と重要事項】

CloudWatch Logsを実務で効果的に活用するためには、以下の点を考慮する必要があります。

ログ設計と運用

  • ログ設計: ログに出力する情報、ログレベル、ログフォーマットなどを事前に設計し、アプリケーション全体で統一的なログ設計を心がけることが重要です。構造化ログ (JSON形式など) を採用することで、Logs Insightsでの分析が容易になります。
  • ロググループの設計: アプリケーション、環境、サービスごとに適切なロググループを設計し、アクセス制御、保持期間、メトリクスフィルタ、サブスクリプションフィルタなどの設定を適用します。
  • ログストリームの命名規則: ログストリーム名にインスタンスID、コンテナID、関数名などの識別子を含めることで、ログのソースを特定しやすくします。
  • ログローテーション: アプリケーション側でログローテーションを適切に行い、ログファイルが肥大化しすぎないように管理します。CloudWatch Logs Agentを利用する場合は、Agent側でログローテーション設定も可能です。
  • ログのアーカイブ: 長期保存が必要なログは、S3などのストレージサービスにエクスポートすることを検討します。サブスクリプションフィルタとKinesis Data Firehoseを組み合わせることで、自動的なS3へのアーカイブが可能です。
  • パフォーマンス: 大量のログをCloudWatch Logsに送信する場合、アプリケーションのパフォーマンスに影響を与える可能性があります。非同期ロギングやバッチ処理などを検討し、パフォーマンスへの影響を最小限に抑えるように工夫します。

セキュリティ

  • アクセス制御: IAMポリシーを使用して、CloudWatch Logsへのアクセス権限を適切に制御します。ログデータの閲覧、ロググループの作成・削除、Logs Insightsの実行など、操作の種類ごとに権限を分離し、最小権限の原則を適用します。
  • ログデータの暗号化: CloudWatch Logsでは、保管中のログデータはデフォルトで暗号化されます。さらに、AWS KMS (Key Management Service) を使用して、カスタマー管理のキー (CMK) で暗号化することも可能です。
  • 監査ログ: CloudTrail を有効にすることで、CloudWatch Logsに対するAPIコール (ログイベントのPutLogEvents、ロググループの作成・削除など) を記録し、監査証跡として利用できます。
  • VPCエンドポイント: VPC内からCloudWatch Logsにアクセスする場合、VPCエンドポイント (CloudWatch Logs API) を利用することで、インターネットを経由せずにセキュアにアクセスできます。

コスト

  • ログの取り込み量と保存量: CloudWatch Logsの料金は、ログの取り込み量と保存量に基づいて課金されます。ログの出力量を削減したり、不要なログをフィルタリングしたり、ログの保持期間を適切に設定することで、コストを最適化できます。
  • Logs Insightsのクエリ: Logs Insightsのクエリ実行にも料金が発生します。クエリの実行回数やスキャンするデータ量を削減することで、コストを抑えることができます。
  • データ圧縮: ログデータを圧縮して送信することで、取り込み量を削減し、コストを削減できる場合があります。ただし、圧縮・解凍処理によるアプリケーション側の負荷も考慮する必要があります。

障害対策と可用性

  • リージョン: CloudWatch Logsはリージョンごとに独立したサービスです。DR (災害復旧) 対策を考慮する場合は、複数のリージョンにログを収集する構成を検討する必要があります。
  • ログのバックアップ: 重要なログデータは、S3などのストレージサービスに定期的にバックアップすることを推奨します。サブスクリプションフィルタとKinesis Data Firehoseを組み合わせることで、自動的なS3へのバックアップが可能です。
  • モニタリング: CloudWatchメトリクスやアラームを活用して、CloudWatch Logs自身の状態 (ログ取り込みエラー、APIエラーなど) を監視し、異常を早期に検知できるようにします。

【実務でどの程度使用されるのか】

AWS CloudWatch Logsは、AWS環境を利用する企業にとって、事実上必須のサービスと言えるほど、実務で広く利用されています。特に、以下のようなケースで活用されています。

  • アプリケーションログの集中管理: Webアプリケーション、APIサーバー、バッチ処理など、様々なアプリケーションのログをCloudWatch Logsに集約し、運用監視、障害解析、性能分析などに活用します。
  • システムログの監視: EC2インスタンス、コンテナ、オンプレミスサーバーなどのシステムログ (OSログ、ミドルウェアログなど) を収集し、サーバーの状態監視、セキュリティ監視、インフラ運用などに活用します。
  • セキュリティログの分析: VPC Flow Logs、CloudTrail Logs、GuardDuty LogsなどのセキュリティログをCloudWatch Logsに集約し、セキュリティインシデントの検知、分析、対応に活用します。
  • 監査ログの保管: コンプライアンス要件 (PCI DSS, HIPAA, GDPRなど) に対応するため、監査ログをCloudWatch Logsに長期保存し、監査証跡として利用します。
  • マイクロサービスアーキテクチャにおけるログ管理: 多数のマイクロサービスで構成されるシステムにおいて、各サービスのログをCloudWatch Logsで一元管理し、サービス間の連携状況の把握や障害時の原因特定を容易にします。
  • サーバーレスアーキテクチャにおけるログ管理: Lambda関数、API Gateway、Step Functionsなどのサーバーレスサービスから生成されるログをCloudWatch Logsで収集し、サーバーレスアプリケーションの監視、デバッグ、性能分析に活用します。
  • リアルタイム監視とアラート: メトリクスフィルタやアラームを活用して、エラー数、レスポンスタイム、CPU使用率などのメトリクスを監視し、異常が発生した場合にリアルタイムでアラート通知を受け取ります。
  • ログ分析基盤: CloudWatch Logsをログ収集基盤として、Logs Insightsや他の分析ツール (Elasticsearch Service, Splunkなど) と連携し、高度なログ分析基盤を構築します。

利用規模

CloudWatch Logsは、スタートアップ企業から大企業まで、規模に関わらず幅広く利用されています。小規模なシステムであれば、基本的なログ収集・監視機能だけでも十分な効果が得られますし、大規模なシステムであれば、Logs Insights、サブスクリプションフィルタ、他のAWSサービスとの連携などを活用することで、高度なログ管理・分析基盤を構築できます。

【terraformのコードで記述する場合の基本的内容と実務レベルの内容】

基本的なTerraformコード (ロググループの作成)

resource "aws_cloudwatch_log_group" "example" {
  name              = "/aws/lambda/my-function" # ロググループ名 (Lambda関数名など)
  retention_in_days = 7                         # ログ保持期間 (日)
  tags = {
    Environment = "Production"
    Application = "MyApp"
  }
}

コード解説 (基本)

  • resource "aws_cloudwatch_log_group" "example": ロググループを定義します。
    • name: ロググループの名前を指定します。通常は/aws/lambda/関数名のような命名規則に従います。
    • retention_in_days: ログの保持期間を日単位で指定します。1, 3, 5, 7, 14, 30, 60, 90, 120, 150, 180, 365, 400, 545, 731, 1096, 1827, 3653 のいずれかの値を指定できます。null を指定すると、ログは無期限に保持されます。
    • tags: ロググループにタグを付与します。環境、アプリケーション名などをタグ付けすることで、リソース管理やコスト管理が容易になります。

実務レベルのTerraformコード (メトリクスフィルタ、アラーム設定、IAMアクセス許可、モジュール化)

# モジュール定義 (cloudwatch-logsモジュール)
module "cloudwatch_logs" {
  source = "./modules/cloudwatch-logs" # モジュールディレクトリ

  log_group_name      = "/aws/ecs/my-service"
  retention_in_days   = 30
  metric_filters = [ # メトリクスフィルタ設定
    {
      name          = "ErrorCount"
      pattern       = "[timestamp=*Z, level=ERROR, message]" # エラーログのパターン
      metric_transformation = {
        name      = "ErrorCount"
        namespace = "MyApp"
        value     = "1"
      }
    }
  ]
  alarms = [ # アラーム設定
    {
      name              = "HighErrorRateAlarm"
      metric_name       = "ErrorCount"
      namespace         = "MyApp"
      statistic         = "Sum"
      period            = 60 # 評価期間: 60秒
      evaluation_periods = 5  # 評価回数: 5回
      threshold         = 10 # しきい値: 10
      comparison_operator = "GreaterThanThreshold"
      alarm_actions     = [aws_sns_topic.alarm_topic.arn] # SNSトピックARN
    }
  ]
  policy_statements = [ # ロググループへのアクセス許可 (IAMポリシー)
    {
      actions = ["logs:PutLogEvents"]
      principals = [
        {
          type        = "Service"
          identifiers = ["ecs-tasks.amazonaws.com"] # ECSタスクからのログ送信を許可
        }
      ]
    }
  ]
}

# SNSトピック (アラーム通知先)
resource "aws_sns_topic" "alarm_topic" {
  name = "my-app-alarm-topic"
}

# モジュールディレクトリ構成例
├── modules
│   └── cloudwatch-logs
│       ├── main.tf
│       ├── variables.tf
│       └── outputs.tf
├── main.tf
├── variables.tf
└── outputs.tf

コード解説 (実務レベル)

  • モジュール化: module "cloudwatch_logs" でCloudWatch Logs関連のリソースをモジュール化しています。これにより、コードの再利用性、可読性、保守性が向上します。
  • メトリクスフィルタ: metric_filters で、エラーログを検知するメトリクスフィルタを定義しています。pattern でログイベントのパターンを指定し、metric_transformation でメトリクスの名前、名前空間、値を定義します。
  • アラーム設定: alarms で、エラー率が高い場合にアラームを発報するCloudWatchアラームを定義しています。metric_name, namespace, statistic, period, evaluation_periods, threshold, comparison_operator などのパラメータを設定します。alarm_actions で、アラーム発報時に実行するアクション (SNSトピックへの通知など) を指定します。
  • IAMアクセス許可: policy_statements で、ロググループへのアクセスを許可するIAMポリシーを定義しています。ECSタスク (ecs-tasks.amazonaws.com) からのログ送信 (logs:PutLogEvents) を許可しています。
  • SNSトピック: アラーム通知先のSNSトピック (aws_sns_topic.alarm_topic) を定義しています。
  • モジュールディレクトリ構成: モジュールごとにディレクトリを分け、main.tf, variables.tf, outputs.tf を配置することで、Terraformコードを整理しています。

実務におけるTerraformコードの重要事項

  • ロググループ名の命名規則: ロググループ名を体系的に管理するための命名規則を策定します。アプリケーション名、環境名、サービス名などを組み合わせて、一意で分かりやすいロググループ名を付けるようにします。
  • ログ保持期間の最適化: ログの利用目的、コンプライアンス要件、コストなどを考慮して、ログ保持期間を最適化します。不要なログを長期間保存しないようにすることで、コストを削減できます。
  • メトリクスフィルタの活用: メトリクスフィルタを積極的に活用し、重要なメトリクスを抽出し、監視やアラートに利用します。正規表現やJSONPathなどを活用して、複雑なログパターンにも対応できるようにします。
  • アラームの適切な設定: アラームのしきい値、評価期間、評価回数などを適切に設定し、不要なアラーム発報を避け、本当に必要なアラームだけを発報するように調整します。
  • IAMポリシーの最小権限: IAMポリシーは必要最小限の権限のみを付与するように設計します。ログ送信に必要な権限、ログ閲覧に必要な権限、ロググループ管理に必要な権限などを分離し、最小権限の原則を適用します。
  • DR環境への対応: リージョンを跨いだDR環境を構築する場合は、Terraformで複数のリージョンにCloudWatch Logsリソースを定義し、ログのレプリケーションやフェイルオーバーなどの対策を検討する必要があります。
  • テスト: Terraformコードの変更を適用する前に、terraform plan で変更内容を確認し、必要に応じて terraform apply を実行する前にテスト環境で検証することを推奨します。

上記はあくまで基本的な例であり、実際のシステム要件に合わせてTerraformコードをカスタマイズする必要があります。Terraform Registryで公開されているCloudWatch Logsモジュール (例: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cloudwatch_log_group) を参考にすることも有効です。

Discussion