クラウドネイティブ時代のログ管理を考える

マイクロサービスアーキテクチャが主流となった今、ログ管理の重要性はかつてないほど高まっています。複数のサービスが連携する環境では、1つの障害を追跡するだけでも数十のログソースを横断的に調査する必要があります。筆者はこれまで数多くのプロジェクトでログ基盤を構築してきましたが、ツール選定で迷うチームを何度も見てきました。

本記事では、代表的な3つのログ管理ソリューション「Amazon CloudWatch」「Datadog」「Grafana（Loki）」を実務の観点から徹底比較します。それぞれの強みと弱みを理解し、プロジェクトに最適な選択ができるようになることを目指します。

Amazon CloudWatch：AWS純正の安心感

CloudWatchはAWSサービスとのネイティブ統合が最大の強みです。EC2、Lambda、ECSなどのログが自動的に収集され、追加設定なしですぐに利用を開始できます。

CloudWatch Logs Insightsの活用

CloudWatch Logs Insightsは専用のクエリ言語を使ってログを分析できる強力な機能です。以下のようにフィールドの抽出やフィルタリングが可能です。

fields @timestamp, @message
| filter @message like /ERROR/
| stats count(*) as errorCount by bin(5m)
| sort errorCount desc
| limit 20

このクエリでは、ERRORを含むログを5分間隔で集計し、エラーが多い時間帯を特定できます。障害調査の初動として非常に有効です。

CloudWatchのコスト構造

CloudWatchの料金体系はやや複雑です。取り込み量、保存量、クエリのスキャン量それぞれに課金されます。大量のログを長期保存する場合はS3へのエクスポートを検討しましょう。

# AWS CLIでログをS3にエクスポート
aws logs create-export-task \
  --task-name "daily-export" \
  --log-group-name "/ecs/my-service" \
  --from 1717891200000 \
  --to 1717977600000 \
  --destination "my-log-archive-bucket" \
  --destination-prefix "exports/my-service"

Datadog：オールインワンの観測プラットフォーム

Datadogはログ管理だけでなく、APM、インフラ監視、セキュリティ監視まで一元化できるのが大きな特徴です。特にログとトレースの相関分析は、マイクロサービスのデバッグを劇的に効率化します。

Datadogエージェントの設定例

Kubernetesでの導入は、HelmチャートでDatadogエージェントをデプロイするのが一般的です。

# values.yaml
datadog:
  apiKey: <YOUR_API_KEY>
  logs:
    enabled: true
    containerCollectAll: true
  apm:
    portEnabled: true
  processAgent:
    enabled: true
    processCollection: true

containerCollectAllをtrueにすることで、全コンテナのログを自動収集できます。ただし、この設定はログ量が膨大になりやすいため、不要なログはフィルタリングルールで除外することを強くおすすめします。

Datadogの課題：コスト

Datadogは機能が充実している反面、コストが高くなりがちです。特にログ管理は取り込み量に応じた従量課金でして、大規模環境では月額数十万円に達することも珍しくありません。ログのインデックス化を必要なものだけに絞る運用が重要です。

Grafana + Loki：OSSベースの柔軟な選択肢

Grafana LokiはPrometheusにインスパイアされたログ集約システムです。ログの全文インデックスを作らず、ラベルベースでインデックスするため、ストレージコストを大幅に削減できるのが特徴です。

LogQLによるクエリ例

# エラーログの検索
{namespace="production", app="api-server"} |= "error" | json | status_code >= 500

# レートの算出（1分あたりのエラー数）
rate({namespace="production"} |= "error" [1m])

LogQLはPromQLに似た構文を持ち、Prometheusに慣れたエンジニアであればスムーズに習得できます。Grafanaダッシュボードとの統合もシームレスで、メトリクスとログを1画面で確認できるのは大きな利点です。

3ツールの比較まとめ

• CloudWatch：AWS中心の環境で、追加コストを抑えたい場合に最適。マルチクラウドには不向き。
• Datadog：予算に余裕があり、APMやセキュリティも含めた統合観測が必要な場合に最適。導入の速さも魅力。
• Grafana + Loki：コスト意識が高く、運用チームにOSSの知見がある場合に最適。カスタマイズ性は随一。

実務での選定ポイント

筆者の経験から、ツール選定で最も重要なのは「チームのスキルセット」と「運用負荷の許容度」です。高機能なツールでも運用できなければ意味がありません。

スタートアップで素早く始めたいならCloudWatch、中規模以上でしっかり観測したいならDatadog、コストを最適化しつつ自由度が欲しいならGrafana+Lokiという判断が妥当でしょう。

また、最近のトレンドとしてOpenTelemetryの普及があります。ログ送信をOpenTelemetry Collectorで抽象化しておけば、将来的なツール切り替えのコストを大幅に下げられます。ツール選定と同時に、ベンダーロックインを避ける設計も意識しておきましょう。

ログ管理は地味ですが、障害対応の速度に直結する極めて重要な基盤です。チームの状況に合わせた最適な選択を行い、安定した運用を実現してください。