概要
CloudWatch Logsのログを長期保管するため、CloudWatch Logs上のログは保持期間を長くするとコストが増加する。
CloudWatch Logs→Amazon Data Firehose→S3
の構成でログ永続化を実施した。
実装自体はシンプルだったが、AWS公式ドキュメントだけでは分からないハマりポイントがいくつかあったため共有する。
なぜこの構成にしたか
検討した構成
- CloudWatch Logsのみ
- メリット
- 構成が最もシンプル
- 追加サービス不要
- デメリット
- 長期保管時のコスト増加
- メリット
- CloudWatch Logs→Lambda→S3
- メリット
- ログ変換が自由
- 改行整形やJSON変換が可能
- デメリット
- Lambda運用が必要
- 実行回数による課金
- 障害ポイントが増える
- メリット
- CloudWatch Logs→Kinesis Data Streams→S3
- メリット
- リアルタイム処理向き
- 複数コンシューマーへ配信可能
- デメリット
- 今回の要件ではオーバースペック
- コンシューマー実装が必要
- メリット
- CloudWatch Logs→OpenSearch Service
- メリット
- ログ検索が強力
- 可視化しやすい
- デメリット
- 長期保管用途としてはコスト高
- 今回は検索が要件ではない
- メリット
- CloudWatch Logs→Firehose→S3（採用）
- メリット
- サーバーレス
- S3へ直接配信可能
- 長期保管に適している
- 運用負荷が低い
- デメリット
- ログ変換は苦手
- 整形必要ならLambdaが必要
- メリット
採用理由
- 今回の目的は、ログを安価に長期保管することであり、リアルタイム分析・高度なログ検索・ログ加工は必須要件でなかったため
構成
ハマりポイント
①IAMロール作成時にエラー
AWS公式ドキュメントの設定例を参考にCloudWatch LogsからFirehoseへ連携するIAMロールを作成したところ、信頼ポリシー設定時にエラーが発生していた。
-
対応
- Principal句のServiceを変更
- Condition句の設定を見直し、ArnLikeを利用することで解消した
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
↓
"Principal": {
"Service": "logs.ap-northeast-1.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
-
学び
- AWSドキュメントの設定例ではそのまま利用できないケースがある
- CLIでの作成ではエラー発生せずIAMロール作成できてしまうので、後の作業で躓いたらIAM関連を確認する
②Firehose側の圧縮設定は不要だった
リソース作成後、圧縮されていないように見えたためFirehoseの設定からGZIP圧縮を有効化に変更した。
しかしCloudWatch LogsからFirehoseへ送信されるデータは既に圧縮済みであり、Firehose側でさらに圧縮すると確認時に扱いづらくなった。また圧縮無しでもコンソールからダウンロードすると失敗する。
-
対応
- Firehose圧縮：なし
- ファイル拡張子フォーマット：.json.gz
-
学び
- CloudWatch Logs→Firehoseの時点で圧縮されている
- Firehoseで追加圧縮する前にデータ形式を確認する
- 補足
- 圧縮なし、ファイル拡張子フォーマットなしの場合、
aws s3api get-objectコマンド使用して取得であればファイルは壊れないが、コンソール画面からダウンロードしたものは開く際にエラーになる
- 圧縮なし、ファイル拡張子フォーマットなしの場合、
③改行区切り設定が利用できなかった
S3から取得したログを見やすくするため、Firehoseの改行区切り文字を有効化しようとした。
しかしハマりポイント②同様の理由で、データが圧縮済みのため期待した結果にならなかった。
ログを整形して出力するには、
CloudWatch Logs
↓
Firehose（解凍）
↓
Lambda(整形)
↓
Firehose
↓
S3
のような構成が必要だった。（Firehoseのオプション設定で可能）
今回は要件外且つ、コマンドやエディタを使用で簡単に整形するのが可能なので対応しなかった。
-
学び
- Firehoseの改行区切り設定機能はテキストレコード向け
- ログ整形が必要な場合はLambda変換を検討する
まとめ
CloudWatch Logs→Firehose→S3構成自体は簡単だが、CloudWatch Logsから送られるデータ形式を理解していないと圧縮や変換周りでハマりやすい。
特に以下は事前に把握しておくと良い。
- CLIで作成したIAM信頼ポリシーの設定
- CloudWatch Logsは圧縮済みデータを送信する
- ログ整形にはLambda変換が必要になる