ログ集約
分散システムの複数サービスから出力されるログを一元的に収集・検索・分析する仕組み
ログ集約とは
ログ集約 (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 クエリ |
理論と実装の両面から学ぶなら関連書籍が参考になる。