ログ設計

アプリケーションのログを構造化・分類し、効果的なデバッグと監視を実現する設計手法

オブザーバビリティ運用

ログ設計とは

ログ設計は、アプリケーションのログを構造化・分類し、効果的なデバッグと監視を実現する設計手法である。「何をログに出すか」「どの形式で出すか」を事前に設計する。詳細は「ロギング」を参照。

構造化ログ vs 非構造化ログ

// ❌ 非構造化: 検索・分析が困難
console.log(`[ERROR] Order 123 failed: timeout after 5000ms`);

// ✅ 構造化 (JSON): CloudWatch Logs Insights で検索可能
console.log(JSON.stringify({
  level: 'error',
  message: 'Order processing failed',
  orderId: '123',
  error: 'timeout',
  duration: 5000,
  requestId: context.awsRequestId,
}));

ログに含めるべき情報

ログには、タイムスタンプ (いつ発生したか)、ログレベル (重要度の判断)、リクエスト ID (リクエストの追跡)、ユーザー ID (誰の操作か、PII に注意)、処理時間 (パフォーマンスの分析)、エラー情報 (スタックトレース、エラーコード) を含める。

ログに含めてはいけない情報

パスワード (セキュリティリスク)、アクセストークン (漏洩すると不正アクセス)、クレジットカード番号 (PCI DSS 違反)、個人情報 (GDPR / 個人情報保護法) はログに出力してはならない。

CloudWatch Logs Insights

-- エラーの集計
filter level = 'error'
| stats count() as errorCount by error
| sort errorCount desc

-- 遅いリクエストの特定
filter duration > 3000
| fields @timestamp, orderId, duration
| sort duration desc

相関 ID (Correlation ID)

// API Gateway → Lambda A → Lambda B の呼び出しチェーンを追跡
const correlationId = event.headers['x-correlation-id'] ?? crypto.randomUUID();

console.log(JSON.stringify({
  correlationId,
  message: 'Processing order',
}));

// 下流の Lambda にも correlationId を渡す
await invokeDownstream({ ...payload, correlationId });

ログの保持とコスト

dev 環境は 7 日 (コスト削減)、prod 環境は 90 日 (障害調査に十分)、監査ログは 1 年以上 (コンプライアンス) を目安に保持期間を設定する。

ログのアンチパターン

全てを DEBUG で出力するとコスト増とノイズの原因になる。エラーを握りつぶすと障害の検知が遅れる。非構造化ログは検索・分析が困難になる。機密情報の出力はセキュリティリスクを生む。

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

関連用語