S3のコスト削減に成功した話 〜カギはバッチウィンドウ〜
こんにちは!POSグループのhktです。
こちらの記事は、「S3のコスト削減に失敗した話」の後編になります。
もしまだ前編をご覧になっていない方は、ぜひ読んでみてください。
さて、前編では、S3のコストを調査したところ、最も費用がかかっているのがPutObject
であることが判明しました。
今回は、S3のコストを削減するために、PutObject
の実行回数を減らすことはできないか検討しました。
PutObjectの実行回数を減らしたい
POSグループが運用するAWSアカウントでは、ログデータをS3に保存するために、Kinesis Data StreamsをトリガーとするLambda関数が稼働しています。
具体的には、以下のような構成になっています。HandsPOSアプリからKinesis Data Streamsにログデータが送信され、Kinesis Data StreamsからLambda関数へと送信されます。Lambda関数は、受け取ったログデータを加工・圧縮して、S3にファイルをアップロード(PutObject
)します。
このLambda関数は、約1秒ごとに呼び出されており、1回の呼び出しでPutObject
が複数回実行されていました。S3にアップロードされたファイルを実際に見てみると、中には1オブジェクトに1行しかログデータが書き込まれていない…なんてこともありました。
そこで解決策として、PutObject
の実行回数を減らすために、ある程度ログデータをまとめてPutObject
することはできないかと考えました。
バッチウィンドウを使用する
でも、ある程度ログデータをまとめてPutObject
するには、具体的にどうしたらいいのだろう…
Lambda関数のコードを修正すればいいのかな…
Lambda関数の前後に、何か他のAWSサービスを繋ぎ込めばいいのかな…
そんなことを考えていると、ある日、こんな記事を見つけました。
AWS Lambda では、開発者がコスト最適化のために Lambda 呼び出しを微調整できる新機能、バッチウィンドウのサポートを開始しました。この機能により、Kinesis データストリームおよび DynamoDB ストリームからのデータを処理する際、バッチ処理動作を詳細にコントロールできます。
(中略)
バッチウィンドウを使用すると、各呼び出しで関数に渡されるレコードの平均数を増やすことができます。これは、呼び出し回数を減らしてコストを最適化したい場合に役立ちます。AWS Lambda が Kinesis および DynamoDB イベントソースのカスタムバッチウィンドウをサポート開始
なるほど、「バッチウィンドウ」を使えば、Lambda関数の呼び出し回数を減らすことができるのか…
バッチウィンドウについて調べてみると、ざっくり以下のような説明になります。
- バッチウィンドウとは、Lambda関数を呼び出す前に、Kinesis Data Streamsからデータ(以下、レコード)を収集する最大時間のこと。
- すなわち、ある程度レコードを溜めてからLambda関数が起動するようになる。
- バッチウィンドウを設定することで、最大300秒間レコードをバッファリングするようにイベントソースに指示することができる。
Amazon Kinesis で AWS Lambda を使用する – AWS Lambda
現行のLambda関数は、バッチウィンドウの値が 0 (デフォルト)に設定されていたため、レコードが溜まらないうちに早急に呼び出されていたのでした。
バッチウィンドウを使うことで、ある程度ログデータをまとめてからPutObject
する、すなわちPutObject
の実行回数を減らすということを簡単に実現できそうだと思いました。
実践
検証用のLambda関数のバッチウィンドウを0〜300の間で変更してみたり、気になることをAWSサポートへ質問したりした後、実際にバッチウィンドウを0から60に変更しました。
これで、60秒間レコードを溜めてからLambda関数が起動するようになるはずです。
すると…
以前は約1秒ごとに起動していたLambda関数の呼び出し回数が減っていました!
そして1か月後…
PutObject
のコストが4割ほど減っていました!
おまけ
バッチウィンドウと似たような言葉として「バッチサイズ」があります。
バッチウィンドウと同様に、バッチサイズを使うことでも、Lambda関数の呼び出し回数を調整することができます。
- バッチサイズとは、Kinesis Data Streamsから送信されるレコードの最大件数のこと。
- バッチサイズを設定することで、最大10,000件レコードをバッファリングするようにイベントソースに指示することができる。
Lambda のイベントソースマッピング – AWS Lambda
最後に
バッチウィンドウを使用することで、システム構成やLambda関数のソースコードに手を加えることなく、Lambda関数の呼び出し回数を抑えること、月々のS3のコストを削減することができました。
他のメンバーの方に、S3のコスト削減に対して大きな影響を与える要因がPutObjectであることを突き止めていただいたおかげで、ダイレクトにコスト削減につなげることができたのでした。
前編の記事も含め、S3のコスト削減を課題とされる方のお役に立てば幸いです。
最後までお読みいただき、ありがとうございました!