非機能要件対応でCloudWatch LogsのS3エクスポートを担当したら、最も簡単だと思っていた方法が意外と大変だった話

少し前、非機能要件の対応でCloudWatch Logsの定期S3エクスポートを設計・構築、リリースまで行ったところ、様々な知見を得たので、それをご共有します。

Transcript

1. 非機能要件対応で CloudWatch LogsのS3エクスポート を担当したら、最も簡単だと思っていた方法が意外と大変だった話 2026年9月16日 JAWS-UG朝会（20分LT） 三与木 輝
2. 自己紹介 非機能要件対応でCloudWatch LogsのS3エクスポートを担当 したときに多くの知見を得たので、共有します。 都内IT企業勤務の社会人2年目エンジニア 業務領域 AWSを使用したインフラの設計・構築 たまにバックエンド開発 （Lambda等） 三与木 輝 25卒（歴史学科卒） 新卒2年目インフラエンジニア 2 / 40 好きなAWSサービス DynamoDB 保有資格 2026 Japan AWS Jr. Champion 2026 Japan All AWS Certifications Engineer IPA ネットワークスペシャリスト IPA 情報処理安全確保支援士試験合格 LPIC-3、など
3. CloudWatch LogsからS3のエクスポートって、 すごく簡単そうに見えて、意外と考慮事項が多くて、 大変なんですよね。
4. 目次 4 / 40 01 対応した具体的な非機能要件について 02 CloudWatch LogsからS3にエクスポートするいくつかの選択肢 03 どのような構成をとったか 04 結構色々と落とし穴があったこと 05 運用についても考える
5. 1. 対応した具体的な非機能要件について 2. CloudWatch LogsからS3にエクスポートするいくつかの選択肢 3. どのような構成をとったか 4. 結構色々と落とし穴があったこと 5. 運用についても考える 5 / 40
6. 対応した具体的な非機能要件は下記の2つです。本日は2つ目の対応 の話をさせてください。 01 ジャーナルログを365日間保持する 対応策：CloudWatch Logsの保持期間を365日に設定 02 障害調査用・監査用にログをアーカイブする 対応策：365日で削除される前にS3へ定期退避 こっちの対応が大変でした 6 / 40 出典 CloudWatch Logs User Guide
7. 1. 対応した具体的な非機能要件について 2. CloudWatch LogsからS3にエクスポートするいくつかの選択肢 3. どのような構成をとったか 4. 結構色々と落とし穴があったこと 5. 運用についても考える 7 / 40
8. CloudWatch LogsからS3へエクスポートする方式は大きく分けて、 「リアルタイム」と「バッチ」の2種類あります。 Kinesis Data Streams Kinesis Data Streamsの後段処理は省略 ほぼリアルタイム 取り込み後すぐに継続配送 CloudWatch Logs サブスクリプションフィルター Amazon Data Firehose バッチ Amazon S3 指定した期間をまとめてS3へ退避 期間を指定して定期退避 今回 8 / 40 保持期間365日に達するより前にアーカイブすることになるので、リアルタイム方式は過剰として バッチ方式を採用しました。 出典 CloudWatch Logs Subscriptions / S3 Export
9. バッチ方式も代表的には、大きく分けて２つほどの構成が考えられます。 Step Functionsを使用して待機、状態確認、再試行をワークフローで表す方法 A EventBridge Scheduler Step Functions LambdaとSQSでゴリゴリ開発する方法 B EventBridge Scheduler Lambda SQS FIFO Lambda 最初にEventBridge Schedulerがあり、そこからStep FunctionsもしくはLambdaを使用して、 CloudWatch LogsをS3へエクスポートするAPIであるCreateExportTask APIを叩く構成となります。 ここでStepFunctionsやSQSを入れた通り、後述しますが基本的に状態を管理する構成が必要となります。 9 / 40 出典 AWS Step Functions / CloudWatch Logs
10. 今回は、個人的な利用経験が豊富だと言う理由で、Lambda＋ SQS FIFOの方式を採用しました。 A EventBridge Scheduler Step Functions EventBridge Scheduler Lambda B SQS FIFO Lambda 今回は個人的な経験回数からもこちらを採用しました →ただ、今思うとStepFunctionsを利用した方が丸かったかも、、 （隣の芝生は青い） 10 / 40
11. 1. 対応した具体的な非機能要件について 2. CloudWatch LogsからS3にエクスポートするいくつかの選択肢 3. どのような構成をとったか 4. 結構色々と落とし穴があったこと 5. 運用についても考える 11 / 40
12. 今回とった構成の全体像です。ここから個別に解説します。 12 / 40
13. 1. 対応した具体的な非機能要件について 2. CloudWatch LogsからS3にエクスポートするいくつかの選択肢 3. どのような構成をとったか 4. 結構色々と落とし穴があったこと 5. 運用についても考える 13 / 40
14. 実装してみると、下記の通り落とし穴が5つありました 14 / 40 01 最初にいらないログを取得してしまう問題 02 Lambdaの実行時間15分制限問題と、Active ExportTaskが1件だけの問題 03 CreateExportTask APIでは直接Glacier Instant Retrievalへ移動できない問題 04 S3ライフサイクルは128KB未満だと移動されない問題 05 保持期間をいつ設定するか問題
15. まずは、対象ログを選ぶ部分です 1 15 / 40 2 3 4 5
16. 1つ目の落とし穴は「最初にいらないログを取得してしまう問題」です 1 2 3 4 5 そのまま渡すと describe_log_groups() 要件に含まれないログ（保持期間設定無のログなど） もキューへ入ります。 ↓そこで、、 対象を絞ります retentionInDays（保持期間） == 365 対象だけをSQS FIFOへ渡します。 →今回の要件上、365日保持期間を設定したロググループのみを取得する構成にすることで、S3へのアーカイブの 対象を固定しました。これによって、保持期間を設定していない無関係なロググループが勝手にエクスポートされて コストが跳ね上がる現象を防止します。 16 / 40 出典 DescribeLogGroups
17. 次は、SQSとLambdaでエクスポートを進める部分です。 1 17 / 40 2 3 4 5
18. 2つ目の落とし穴は「Lambdaの実行時間15分制限問題」と、 「アクティブなExportTaskはアカウント・リージョンごとに1件問題」です 1 15 1 2 3 4 5 Lambda 分 皆さんご存知の通り、Lambdaの 1回の呼び出しは最大900秒です。 Active ExportTask 件 アカウント・リージョンごとの上限です。 （クォータ制限） ロググループを並列に処理できず、直列のみ実施可能となり、かつ一気に対象のロググ ループを投入するとLambdaの15分上限を超える可能性があります。 18 / 40 出典 Lambda Timeout / CloudWatch Logs Quotas
19. 容量別で実際にエクスポート時間を測定した結果は、下記のようになりました。 ブレがあるのが個人的に怖いですね。 1 2 3 4 Lambdaの上限 15分 1GB 58.318秒 3GB 2分24.975秒 5GB 3分25.245秒 10GB 9分26.079秒 20GB、初回 13分07.302秒 20GB、2回目 14分26.862秒 30GB、初回 12分50.980秒 30GB、2回目 10分10.051秒 0分 19 / 40 5分 10分 15分 5
20. そこで、まずSQSを挟んで1ロググループにつき1回Lambdaを起動することで、 少しでも一回でエクスポートされる容量を減らしました。 1 2 3 4 5 SQSを挟んでLambdaを2つ利用 Lambda①はCloudWatch Logsから ロググループを取得しつつSQSに渡します。 Lambda②はSQSから1ロググループあたり1 回起動されるようにすることで、 エクスポートされる容量を減らす設計 にしました。 20 / 40 出典 Amazon SQS FIFO / Lambda
21. 追加情報として、CreateExportTask APIでのCloudWatch Logsから S3へのエクスポートはLambda自身が行うわけでは無いというものがあります 1 2 3 4 5 Lambda Taskを起動する 次の呼び出しで状態を確認する CloudWatch Logs 非同期ExportTaskを続ける ログ本体をS3へ出力する →つまりTaskを1度起動すれば、AWSバックボーンネットワークでエクスポートが行われるので、 Lambdaが終了しても、CloudWatch Logs側のExportTaskは続きます。 21 / 40 出典 CreateExportTask API Reference
22. なので、SQSで再試行を10回にして、実質150分の待機時間を持たせる構成を 採用することができました。これは個人的に助かりました。 1 2 3 今回の設定 約15分 × 10回 ≈ 150分 →MaxReceiveCountを10にすることで、エクスポート待機時間を最大150分まで 持たせました。この値は現場のログ量によって変わってくるものです。 22 / 40 出典 SQS DLQ 4 5
23. 監視設定も大事で、10回で完了しなければDLQへ送り、SNSで 通知するようにもしています。 1 2 3 4 通知する条件 DLQにエクスポート依頼の メッセージが入ったとき 通知を受ける人 開発者・運用担当者 通知後の対応 Taskの状態、対象期間、S3への 出力を確認し、再処理の要否を 判断する 23 / 40 出典 Amazon SQS DLQ / CloudWatch Alarm 5
24. 次は、S3ライフサイクルで移動する部分です 1 24 / 40 2 3 4 5
25. 3つ目の落とし穴は「CreateExportTask APIでは、 直接Glacier Instant Retrievalへ移動できない問題」です 1 2 3 4 5 CreateExportTask request 指定可能 destination （出力先S3バケット） 指定可能 destinationPrefix （保存先のプレフィックス） 指定項目なし ストレージクラス （例としてGlacier Instant Retrieval） こちらの通り、 ストレージクラスを直接指定する項目がありません。 →まずS3へ出力し、そのあとでS3ライフサイクルを使って移行することでコスト削減します。 25 / 40 出典 CreateExportTask / Amazon S3 Lifecycle
26. 4つ目の落とし穴は「S3ライフサイクルでは128KB未満が移動されない問題」です 1 2 3 4 5 128KB未満は、既定では ライフサイクル移行の対象外 →サイズフィルターを指定すると、 移行対象に含めること自体は可能ですが、、 ↓ S3 Glacier Instant Retrievalの ストレージ料金は、1ファイル最低128KB 実サイズ 料金計算上のサイズ 10KB 128KB 実サイズは変わらないのに、料金上は128KBで計算され てしまい、加えて移行リクエスト料金も発生します。 26 / 40 →この通り、S3ライフサイクルで移行されない小さいファイルは、無理やり移行すると割高に なる場合があります。そもそもS3 GIRへの移行はコスト削減目的なので、本末転倒になり得ま す。 出典 Amazon S3 Lifecycle / Glacier Storage Classes
27. 最後は、保持期間とS3への退避を考える部分です 1 赤枠の部分を 27 / 40 次のスライドで拡大します。 2 3 4 5
28. 5つ目の落とし穴は「保持期間365日をいつ設定するか問題」です 1 2 3 4 5 【変更前】無期限保持 700日前 365日前 今日 700日分のログを保持 保持期間を365日に変更 【変更後】365日の保持期間設定 700日前 古い335日分が削除対象 365日前 今日 直近365日分を保持 保持期間は、ログの発生日時を基準に判定されます。 →システムの運用が365日より前からあり、ログが存在する場合、365日以前のログは 問答無用で消えてしまいます。これは場合によっては大問題になり得る危ない落とし穴です。 28 / 40 出典 CloudWatch Logs Retention
29. そこで先に初回退避を終え、そのあとで保持期間を365日に 設定することでこの落とし穴を回避しました。 時間帯 1日目・リリース日 2日目・完了確認日 1 2 3 4 3日目以降 360日前を日時退避開始(自動) 毎日0時 日中 保持期間は 無期限のまま 業後・夜間 デプロイ＋ 初回退避（手動）を実施 （稼働開始〜360日前） TaskとS3出力を確認 完了後、保持期間を365日に変 更 →これで日次退避が自動で行 われるようになる 日次処理の 結果を確認 →初回退避で稼働開始から360日前までを退避させるために、Lambda② の中に特定のイベントを手動で渡すとエクスポートされるプログラムを 組み込みました 29 / 40 出典 CloudWatch Logs Retention 5
30. 1. 対応した具体的な非機能要件について 2. CloudWatch LogsからS3にエクスポートするいくつかの選択肢 3. どのような構成をとったか 4. 結構色々と落とし穴があったこと 5. 運用についても考える 30 / 40
31. S3にアーカイブしたログは、もともとの要件通り障害調査で検索でき るようにする必要があります。 CloudWatch Logsから削除された期間のエラーを調査したい。 S3に保管したログ Athenaで検索 よって、この3ステップを行いました。 01 テーブルを 定義する 31 / 40 02 調査クエリを 書き換える 03 保存済みクエリを 用意する
32. 01 テーブルを 定義する 32 / 40
33. Glueクローラーでテーブルを自動検知できれば楽だったのですが、今 回のログは期待どおりにテーブル化できませんでした。 当初の想定 今回の結果 Glueクローラーで S3上のログを 自動検出する 期待した列定義に なりませんでした。 今回のログ形式・保存先に対する結果です。 →そこで、ログの保存形式に合わせて、Athenaのテーブルを定義しました。 33 / 40 出典 AWS Glue / Athena
34. ログの保存形式に合わせて、 Athenaのテーブルを定義しました S3上の ログファイル 既存のテーブル作成画面（DDL部分） 外部テーブル log_line 検索用ビュー 日時・メッセージなどの列 外部テーブル S3上のログを、 テーブルとして参照する log_group・dt ロググループと日付で 調査範囲を限定する 検索用の列 ログ形式に合わせて 日時やメッセージを取り出す 34 / 40 出典 Amazon Athena CREATE TABLE
35. 02 調査クエリを 書き換える 35 / 40
36. Logs Insight側に置いてあるいつもの調査クエリも、 Athenaでも使えるように書き換える必要があります。 例）エラーを新しい順に100件確認する。 CloudWatch Logs Insights QL fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 100 Athena SQL SELECT event_time, message FROM archived_cloudwatch_logs_view WHERE message LIKE '%ERROR%' ORDER BY event_time DESC LIMIT 100; →結構たくさんの調査クエリがある場合は、それぞれを書き換える作 業が発生します。 36 / 40 出典 CloudWatch Logs Insights QL / Athena SQL
37. 03 保存済みクエリを 用意する 37 / 40
38. さきほど書き換えたクエリをAthena側で入力し、「保存済みのクエ リ」に登録することでいつでも調査を始められるようにしました。 これで、障害時にSQLを一から作成せず、 対象の期間やリクエストIDを指定して調査を始められます。 38 / 40 出典 Amazon Athena Saved Queries
39. 比較用に、ExportTaskの完了待ちを、Step Functionsでも作ってみまし た。正直こっちの方が見やすく、かつシンプルに感じます。 比較用の試作 Wait 完了確認までの 待機を表します。 Choice 実行中・完了・失敗で 処理を分けます。 実行すれば、実行履歴で 経由した状態を確認できます。 SQSで行っていた再確認の流れを、Step Functionsの状態遷移として表した試作です。 割と不慣れだったものの、数時間で作れてしまいました。 39 / 40 出典 AWS Step Functions
40. LambdaとSQSでいつも通り開発すれば終わる、と思って始めたら、意 外と多くの制約があり、考慮すべき事項が盛りだくさんでした。 実装面 直列制御、クォータ制限、Lambdaの実行時間制限、失敗通知（DLQ）、 エクスポート所要時間、再試行回数、S3ライフサイクルの仕様 リリース作業 過去ログの退避を終えてから、保持期間を変更するという作業順番と、 それに適したプログラムにしておくこと 運用 S3にアーカイブ後も、Athenaで自力でテーブルを定義することで、調 査できる環境を整えておくこと とはいえ、今回の経験でAWSの仕様だけでなく、移行手順や運用設計等 多くの知見を得ることができたので、全く後悔はしておりません！笑 40 / 40