Amazon CloudWatch Logs を Amazon S3 にエクスポートする方法について、2つの構成を検討しました。
それぞれの構成にどのようなメリットや課題があったのか考察しておりますので、AWSでのログ収集の仕組みを考える際の参考になれば幸いです。
背景
コスト等の観点から、CloudWatch LogsのS3への保管を検討する方もいらっしゃると思います。
CloudWatch LogsをS3にエクスポートする手段は複数あり、今回は以下の要件に基づいて検討しました。
・日次で定期的に処理を実施したい
・保存先S3のファイル名に日付を入れるなど、カスタマイズしたい
①EventBridgeとLambdaによる日次エクスポート
まず、EventBridgeを使ってLambda関数を日次で実行し、CloudWatch LogsをS3にエクスポートする方法についてです。
構成図
概要
EventBridgeで起動されたLambdaは、必要なタグ付けやエクスポート後のS3のディレクトリ作成を管理し、指定したログをエクスポートします。
シンプルな構成で、設計や構築が比較的容易のため、この方式の導入を検討される方も多いと思います。
課題
Lambdaで全てのロググループを一括で処理しようとしましたが、以下の制約にぶつかりました。
CreateExportTask APIの制限
同一アカウントでエクスポートタスクの並列実行ができないため、リソース制限エラーが発生。
Each account can only have one active (RUNNING or PENDING) export task at a time.
Lambdaの時間制限
実行時間が15分を超えるとタイムアウトする。
関数タイムアウト：900 秒 (15 分)
CreateExportTask APIの制限への対応として、sleep関数を用いて処理が終了するまで待機する構成をとるなどしました。しかし、エクスポート対象のロググループの数が多い場合にはLambdaの最大実行時間を超過してしまいました。
②Step Functionsによる構成
次に、①の課題を解消するためにStep Functionsを導入した構成を紹介します。
構成図
概要
検証①からの主な変更点は、Step Functionsを使って各ロググループを個別に処理するLambdaを実行する構成にしたことです。
加えて、エラーハンドリング機能としてSNSを使用し、エラー時に即座に対応できるよう通知の仕組みを導入しました。
結果として、エクスポート対象のロググループの管理が容易となり、エクスポートの並列処理を避け、Lambdaのタイムアウトの問題も解消することができました。
＜Step Functions構成イメージ＞
※Lambdaをエクスポート対象のロググループの個数分設定する
※Describe-export-task APIにてエクスポート処理のステータスを確認する（処理がCOMPLETEになるまで待機する）
※Lambdaにてエラーが発生した場合、SNSでメール通知する
課題
Step Functionsでステップごとに処理ができるため、エクスポート対象のロググループの増減にも柔軟に対応可能となりました。しかし、エクスポート対象が多い場合、処理が複雑になり、構成に不備があった際に気づきにくくなるという新たな課題も感じました。
まとめ
AWS環境でCloudWatch LogsをS3にエクスポートする方法について、2つの構成を検討しましたが、以下のような特徴があることを確認しました。
| 構成案 | Lambdaによる構成 | LambdaとStep Functionsによる構成 |
| 概要 | EventBridgeを使ってLambda関数を日次で実行し、CloudWatch LogsをS3にエクスポートする。 | EventBridgeとLambdaの間にStep Functionsを導入する。Step Functionsにて各ロググループを個別に処理するLambdaを実行し、CloudWatch LogsをS3にエクスポートする。 |
| メリット | シンプルな構成であるため、設計や構築が容易である。 | エクスポート対象のロググループの増減にも柔軟に対応可能である。 |
| 課題 | CreateExportTask APIの制限やLambdaの実行時間の制限を受ける可能性がある。 | エクスポート対象が多い場合、処理が複雑になり、構成に不備があった際に気づきにくくなる可能性がある。 |
最後に
CloudWatch LogsをS3にエクスポートするにあたり、APIの制約やLambdaの時間制限など、設計時に考慮すべき多くの条件があることを実感しました。
Step Functionsについて、②の検証を行うにあたり初めて使用しましたが、デザインエディタを用いることで直感的にフローを作成できることを知りました。
また、Step Functionsは、様々なサービスとの連携がサポートされています。
今回は①で利用したLambdaを活用する方向で②の構成を検討しましたが、Lambdaで記述したエクスポート処理と同様のことをStep Functionsのみで完結させる方式も考えられると思います。
よって、ログの転送処理だけではなく、複数のサービスを組み合わせたシステムを構築する際や、Lambdaのランタイムの制限などで実装が難しい際にはStep Functionsを活用していくメリットがありそうです。
CloudWatch LogsをS3にエクスポートする作業の必要性は今後も続くと考えており、今回の検討を選択肢の一つとして、多様なパターンを考慮しつつ、柔軟にシステム設計をしていきたいです。