AWS ECSにおけるログ保存コスト削減のススメ・S3圧縮編

こんにちは。 エキサイト株式会社の三浦です。

以前、こんな記事を書きました。

tech.excite.co.jp

端的に言えば、「AWS ECSのログを保存する時、Fluent Bitをログルータとして使用すればCloudWatch以外にもログを流すことができ、適切にログの流し先を選択すればコストを削減できる」という話でした。

今回は、その中の1つである「S3にログを流す方法」について、ログ保存時に圧縮を行うことで更にコストを削減できる、というお話です。

S3におけるログ保存の流れ

Fluent Bitを使ってS3にログを保存する場合、通常は

  1. コンテナのログをFluent Bitが収集する
  2. 一定時間経過、もしくは一定サイズまでログが溜まったら、S3へ送信

となります。

この時、何も指定をしなければそのままS3へログが送られるのですが、圧縮して送ることができれば、送信するファイルサイズ・及びS3に保存されるファイルサイズが減るため、コスト削減になるという寸法です。

圧縮方法

Fluent Bitの設定ファイルの [OUTPUT] セクションにおいて、以下の3つの点を修正することでファイルを圧縮してS3に送信することができるようになります。

[OUTPUT]
    Name s3
    ...
    s3_key_format /test-$UUID.gz
    compression gzip
    content_type application/gzip

s3_key_format$UUID 変数と gz 拡張子をつける

S3へ出力するときのパス・オブジェクト名となる s3_key_format に、 $UUID 変数と gz 拡張子をつけます。

gz 拡張子をつけないと、S3上のファイルをAthena等で参照しようとする時にgzip圧縮されていると判定してくれないため、指定は必須です。 この時、明示的に $UUID 変数も入れておかないと、自動的にファイル名末尾にUUIDがついてしまい gz 拡張子を指定できないため、こちらの指定も必要になります。

compressiongzip を指定する

compressiongzip を指定することで、gzip圧縮してS3に送信してくれるようになります。

content_typeapplication/gzip を指定する

こちらは必須ではなく、指定せずとも問題はありませんが、正しい content_type を指定したほうが良いと思います。

圧縮結果

圧縮した結果、S3のファイルサイズは約1MBから約100KB程度まで下がりました。

f:id:excite-takayuki-miura:20210628142153p:plain
圧縮前

f:id:excite-takayuki-miura:20210628141804p:plain
圧縮後

さいごに

S3自体がもともと安価なため、よほどログ量が多くない限りは莫大なコスト削減になるわけではないですが、それでもストレージ料金や各種通信料金の削減にはなるかと思います。 なお注意点として、Fluent Bitのバージョンが古いと s3_key_format における $UUID 指定や compression の設定ができない可能性もあるため、新しいバージョンを使用してください。