📚 日記帳と図書館で理解するログの世界
Fargateのログ = 毎日書く業務日報
コンテナで動くアプリケーションは、日々の出来事（エラー、アクセス、処理内容）を記録します。
でも、コンテナは
「一時的な存在」
。再起動すると記録が消えてしまう！
そこで登場するのが
「awslogsログドライバ」
。
これは
自動で日報を書いて、図書館（CloudWatch Logs）に保管してくれる秘書
のようなもの✨
コンテナが消えても、図書館に保管された記録はずっと残ります！
🏢 オフィスで理解する！各要素の役割
Fargateコンテナ
日々の業務をこなし、その記録（ログ）を残します。でも、退職したり異動したりする（コンテナが終了する）と、デスクの書類は持っていけません。
awslogs ログドライバ
社員が仕事をするたびに、その内容を自動でメモして、すぐに図書館に届けてくれます。社員は仕事に集中するだけでOK！
CloudWatch Logs
全社員の業務日報を一元管理。後から「あの時何があった？」を調べられます。永久保存も、一定期間で破棄も選べます。
ロググループ
営業部の本棚、開発部の本棚のように、目的別に整理された保管場所。「/ecs/my-app」のような名前をつけて分類します。
ログストリーム
各社員（各コンテナ）が書く個別の日記帳。山田さんの日記、佐藤さんの日記のように、それぞれ別々に記録されます。
リテンション設定
「7日間保存」「30日間保存」「無期限保存」など、図書館に保管する期間を決められます。古い記録は自動で破棄されます。
🔄 ログが記録される流れ
ログを出力
即座に送信
検索・分析可能
コンテナが終了しても、ログはCloudWatch Logsに残り続けます！
まるで社員が退職しても、業務日報は図書館に残っているのと同じです。
🔍 ログが記録される6つのステップ
たとえ： 社員入社時に「業務日報は図書館に提出すること」と伝える
たとえ： 社員の初出勤と同時に、専属秘書も配置される
たとえ： 社員が「今日はこの仕事をしました」と口頭で報告
たとえ： 秘書が報告内容をすぐにメモして、図書館に届ける
たとえ： 図書館が日報を受け取り、適切な本棚の個人ファイルに保管
たとえ： 退職した社員の過去の業務記録も、図書館で調べられる
⚙️ タスク定義での設定方法
{
"family": "my-app",
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGATE"],
"cpu": "256",
"memory": "512",
"containerDefinitions": [
{
"name": "my-container",
"image": "my-app:latest",
// ここがログ設定の肝！
"logConfiguration": {
"logDriver": "awslogs", ← awslogsを指定
"options": {
// ロググループ名（本棚の名前）
"awslogs-group": "/ecs/my-app",
// リージョン（どこの図書館？）
"awslogs-region": "ap-northeast-1",
// ログストリーム名のプレフィックス（日記帳の名前）
"awslogs-stream-prefix": "ecs",
// オプション: ロググループを自動作成（便利！）
"awslogs-create-group": "true"
}
}
}
]
}
/ecs/アプリケーション名
のような命名規則を決めると管理しやすい！
2. awslogs-create-groupを活用：
"true" にすると、ロググループが存在しない場合に自動作成してくれます。初めて使う時は便利！
3. stream-prefixで識別：
複数のタスクを実行する場合、プレフィックスで識別しやすくなります。
📚 ロググループとログストリームの関係
本棚と日記帳の関係
📁 ロググループ = 部署の本棚
例:
/ecs/my-web-app
• Webアプリケーション全体のログをまとめる場所
• リテンション設定（保存期間）はロググループ単位
• CloudWatch Logsの料金もロググループ単位で管理
この中に複数のログストリームが入る
📔 ログストリーム = 個別のタスクの日記帳
例:
ecs/my-container/abc123def456
• 1つのFargateタスク（コンテナ）につき1つ作成される
• タスクIDが自動的に名前に含まれる
• タスクが起動するたびに新しいログストリームが作られる
• 各ログストリームは時系列順に記録される
/ecs/my-web-app
├─ ログストリーム:
ecs/container/task-1-abc123
← タスク1の記録
├─ ログストリーム:
ecs/container/task-2-def456
← タスク2の記録
└─ ログストリーム:
ecs/container/task-3-ghi789
← タスク3の記録
🎯 知っておくべき重要設定
logs:CreateLogStream
と
logs:PutLogEvents
の権限が必要です。
⭐ ベストプラクティス
やるべきこと
JSON形式でログを出力すると、後の検索・分析が超便利！
2. リテンション設定を適切に：
本番: 30〜90日、開発: 7日程度が一般的。無期限は避けよう。
3. ロググループを環境別に：
/ecs/prod/my-app
/ecs/dev/my-app
のように環境ごとに分ける。
4. メトリクスフィルタでアラート：
ERRORやCRITICALが出たら即座に通知！
注意すること
パスワード、APIキー、個人情報は絶対にログに含めない！
2. ログの出しすぎに注意：
デバッグログを本番で垂れ流すと、料金が高額に...
3. タイムゾーンに注意：
CloudWatch LogsはUTC。アプリでJSTにしても、表示はUTCです。
4. ログサイズの制限：
1イベント256KB、1リクエスト1MBまで。大きなログは分割が必要。
やってはいけないこと
ログが出ない！と慌てる前に、タスクロールの権限確認を。
2. 無制限のリテンション：
「Never Expire」にすると料金が青天井に。必ず期限を設定！
3. ログの放置：
使わないロググループが溜まると料金の無駄。定期的に整理を。
4. 本番でDEBUGログ：
ログ量が爆発してパフォーマンス低下＆料金増加のダブルパンチ！
開発環境は7日、本番でも30-90日で十分なことが多い。監査要件を確認して最短期間に。
2. ログレベルを環境別に：
開発: DEBUG OK → 本番: INFO or WARNING以上 にすると、ログ量が激減！
3. 古いログはS3へ：
90日以上のログはS3 Glacierに移動。CloudWatch Logsの1/10のコスト！
4. 不要なロググループを削除：
使わなくなったアプリのロググループは削除。少額でも塵も積もれば...
5. サブスクリプションフィルタで必要なログだけ：
全ログを別のサービスに送る前に、本当に必要なログだけをフィルタリング。
🔧 よくあるトラブルと解決法
→ タスクロールに
logs:CreateLogStream
と
logs:PutLogEvents
を追加
原因2: ロググループが存在しない
→
awslogs-create-group: true
を設定するか、手動で作成
原因3: リージョンの設定ミス
→
awslogs-region
がタスクのリージョンと一致しているか確認
CloudWatch Logsへの送信は数秒〜数十秒の遅延があります。リアルタイム性が必要な場合は、別の監視ツールも併用を。
• ログ量が多すぎないか？（本番でDEBUGログは出していない？）
• リテンションが長すぎない？
• 使っていないロググループが残っていない？
• CloudWatch Logs Insightsのクエリスキャンコストがかかっていないか？
1. ログストリームが正しいか確認（タスクIDで絞り込み）
2. 時間範囲が適切か確認（UTCなので9時間ズレに注意）
3. CloudWatch Logs Insightsでキーワード検索
4. アプリが本当にログを出力しているか確認（ローカルテスト）
💼 実践的な使い方
# エラーログを時系列で表示 fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 100 # レスポンスタイムが遅いリクエストを検索 fields @timestamp, status, duration, path | filter duration > 1000 | sort duration desc # 特定のユーザーのアクションを追跡 fields @timestamp, user_id, action, @message | filter user_id = "12345" | sort @timestamp desc # エラー発生回数を集計 fields @timestamp | filter @message like /ERROR/ | stats count() by bin(5m)
❌ 悪い例:
2024-01-15 10:30:45 ERROR User 12345 failed to login
✅ 良い例:
{
"timestamp": "2024-01-15T10:30:45Z",
"level": "ERROR",
"user_id": "12345",
"action": "login",
"status": "failed",
"ip": "192.168.1.1"
}
JSON形式なら、
user_id
や
action
で簡単に絞り込めます！
🎓 まとめ
📝 awslogsログドライバ = 自動日報提出システム
Fargateコンテナのログを、自動的にCloudWatch Logsに送信してくれる便利な仕組み。
コンテナが消えても、ログは図書館（CloudWatch Logs）に永続的に保管されます！
タスク定義に
3つのパラメータを
追加するだけ！
ログの送信から
保管まで
全て自動！
Logs Insightsで
高速に
ログ分析！
🎯 覚えておくべき3つのポイント：
1️⃣
ロググループ
= アプリごとの本棚
2️⃣
ログストリーム
= タスクごとの日記帳
3️⃣
リテンション設定
= 保存期間の設定でコスト管理
✨ これで、Fargateのログ管理はバッチリ！
コンテナが消えても記録は残る、
まるで図書館に保管された業務日報のように、
いつでも過去を振り返ることができます 📚