ログ設計
アプリケーションのログを構造化・分類し、効果的なデバッグと監視を実現する設計手法
オブザーバビリティ運用
ログ設計とは
ログ設計は、アプリケーションのログを構造化・分類し、効果的なデバッグと監視を実現する設計手法である。「何をログに出すか」「どの形式で出すか」を事前に設計する。詳細は「ロギング」を参照。
構造化ログ 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 で出力するとコスト増とノイズの原因になる。エラーを握りつぶすと障害の検知が遅れる。非構造化ログは検索・分析が困難になる。機密情報の出力はセキュリティリスクを生む。
理論と実装の両面から学ぶなら関連書籍が参考になる。