背景
株式会社モリサワでは分析のためのツールの一つとしてAthenaを利用しています。
Athenaでクエリを実行した結果はCSVファイルとしてS3に格納されます。クエリの実行結果を永続化しておく必要はないため、一定期間後にファイルを削除するようにライフサイクルを設定していました。そのため当該バケットは一時的なデータ置き場の感覚で利用しており、ストレージはほとんど利用していない認識でした。
S3の料金と使用している容量が一致しない
S3の費用削減のためにStorage Lensのダッシュボードをみていると、ほとんどストレージを使用していないはずのバケットで大量に使われていました...。ただ実際にCLIで
aws s3 ls example-bucket --recursive --sum
としてストレージ使用量を求めたところ、その1%以下しか利用されていません。請求自体はStorage Lensの方の数字でされているようだったので原因と対策を調査していました。
不完全なマルチパートアップロードによる差異
結論から述べると原因は不完全なマルチパートアップロードです。S3に大きいファイルをアップロードする場合はマルチパートアップロードが推奨されています。マルチパートアップロードなんて利用していないと思われる方もいるかも知れませんが aws s3 cp などでファイルをアップロードした際にファイルサイズに応じて自動的にマルチパートアップロードが適用されています。この不完全なマルチパートアップロードのオブジェクトはストレージの課金対象である一方で aws s3 ls の対象ファイルではなく、その差異が生じていました。不完全なマルチパートアップロードがどれぐらいあるかはStorage Lensのダッシュボードから確認することが可能です。
マルチパートアップロードを開始して、1つまたは複数のパートをアップロードした後は、マルチパートアップロードを完了するか停止しない限り、アップロードしたパートのストレージに対する課金を停止できません。マルチパートアップロードを完了または停止した後でのみ、Amazon S3 はパートのストレージを解放して、パートのストレージに対する課金を停止します。
下記より引用
ライフサイクルの設定による不完全なマルチパートアップロードのファイルの削除
ライフサイクルにおいて特に設定しない場合は、期日がきても不完全なマルチパートアップロードのオブジェクトは削除されません。そのためCloudFormationで設定するときは
Bucket:
Type: AWS::S3::Bucket
LifecycleConfiguration:
Rules:
- Id: example_rule
Status: Enabled
AbortIncompleteMultipartUpload:
# 1日で削除する場合
DaysAfterInitiation: 1
のようにして AbortIncompleteMultipartUpload を設定しましょう。コンソール上では以下のように不完全なマルチパートアップロードの削除が設定されていればOKです。
すぐにでも消したい場合は aws s3api abort-multipart-upload を利用して以下のように削除が可能です。
aws s3api abort-multipart-upload \
--bucket your-bucket-name \
--key your-object-key \
--upload-id your-upload-id
ライフサイクルの設定後、ストレージ使用量が99%減に
まとめ
不完全なマルチパートアップロードは普段意識することなくコンソールやCLIからも確認することは少ないと思います。特に今回のケースのようなデータの一時的な置き場の場合、使用量についてもあまり気にしていませんでした。 最近S3の料金が高いと感じる場合は、不完全なマルチパートアップロードのオブジェクトがどれぐらいあるかや一度ライフサイクル設定について確認してみてはいかがでしょうか？
Discussion