ログ集約

分散システムの複数サービスから出力されるログを一元的に収集・検索・分析する仕組み

運用オブザーバビリティ

ログ集約とは

ログ集約 (Log Aggregation) は、分散システムの複数サービスから出力されるログを一元的に収集・保存し、横断的に検索・分析できるようにする仕組みである。マイクロサービスや Lambda 関数が数十〜数百に増えると、個別にログを確認するのは現実的でない。ログ集約により、1 つのリクエストが複数サービスを横断する際の全体像を追跡できる。

なぜ必要か

ユーザーのリクエスト
  → API Gateway (ログ)
  → Lambda A (ログ)
  → SQS → Lambda B (ログ)
  → DynamoDB (ログ)

エラーが発生した場合、どのサービスで何が起きたかを特定するには、全サービスのログを横断的に検索する必要がある。ログ集約がなければ、各サービスのログを個別に確認する作業が発生する。

AWS でのログ集約パターン

CloudWatch Logs (標準)

Lambda、ECS、API Gateway のログは自動的に CloudWatch Logs に送信される。CloudWatch Logs Insights で SQL ライクなクエリを実行できる。

# CloudWatch Logs Insights クエリ
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 50

CloudWatch → S3 → Athena (大規模)

ログ量が多い場合、CloudWatch Logs のサブスクリプションフィルターで S3 にエクスポートし、Athena で SQL クエリを実行する。コスト効率が良い。

OpenSearch Service (全文検索)

リアルタイムのログ検索とダッシュボードが必要な場合、OpenSearch (旧 Elasticsearch) を使う。Kibana (OpenSearch Dashboards) でログの可視化が可能。

構造化ログとの組み合わせ

ログ集約の効果を最大化するには、構造化ログ (JSON 形式) が不可欠だ。

// ❌ 非構造化ログ: 検索・集計が困難
console.log('Order 123 processed for user 456 in 250ms');

// ✅ 構造化ログ: フィールドで検索・集計可能
logger.info({
  event: 'order_processed',
  orderId: '123',
  userId: '456',
  durationMs: 250,
  correlationId: 'req-abc',
});

構造化ログなら orderId = "123"durationMs > 1000 でフィルタリングできる。

相関 ID (Correlation ID)

1 つのリクエストが複数サービスを横断する際、相関 ID を全サービスのログに含めることで、リクエスト全体のログを追跡できる。

API Gateway: { correlationId: "req-abc", service: "api-gw", message: "Request received" }
Lambda A:    { correlationId: "req-abc", service: "order",  message: "Order created" }
Lambda B:    { correlationId: "req-abc", service: "payment", message: "Payment processed" }

CloudWatch Logs Insights で correlationId = "req-abc" を検索すれば、リクエストの全経路が表示される。

ログレベルの使い分け

レベル 用途
ERROR 即座に対応が必要 未処理の例外、外部サービスの障害
WARN 注意が必要だが動作は継続 リトライ発生、レート制限に接近
INFO 正常な業務イベント 注文完了、ユーザー登録
DEBUG 開発・デバッグ用 関数の入出力、SQL クエリ

理論と実装の両面から学ぶなら関連書籍が参考になる。

関連用語