この記事でできること
- 各種検証
はじめに
前回に引き続きライフサイクルについて記載します。前回記事はライフサイクルについての基礎でしたが、本記事ではライフサイクルの検証をしてみたいと思います。
ライフサイクルの各種検証
ライフサイクルや各種オプションの動作を検証します。
削除(有効期限切れ)対象の判定は9:00(UTC 0:00)が基準
以下の図のように9/29 9:00の前後でファイルを作成しました。これらのファイルに対しライフサイクルルールで2日後に削除と設定しました。
08:58生成のファイルの削除日 ⇒ 10/1 9:00
(実際にはバージョニングが有効のため削除マーカ生成日)
09:04生成のファイルの削除日 ⇒ 10/2 9:00
(実際にはバージョニングが有効のため削除マーカ生成日)
見てのとおり削除日が1日違います。これは9:00を基準としてその時点で2日経っているファイルが削除対象となるため、09:04作成ファイルは10/2 9:00の削除となります。
バージョニング資源もオブジェクト利用料の対象
これは当たり前と言えば当たり前なのですが、裏での大量保存に気付かない可能性もあるので取り上げます。
見てのとおり見た目上は何も保存されていないように見えます。
しかしストレージレンズによると3.2KB使用しているとのこと。
そこで「バージョンの表示」をONにすると・・
合計3KBオブジェクト数6個、とストレージレンズの結果と合致しています。
余談ですがオブジェクトサイズの平均は正直意味がないですね。削除マーカーは必ず生成されるので削除された実オブジェクトの1/2で平均が計算されます。上のキャプチャのとおり、実オブジェクトは全て1KBなので平均は1KBと表示してほしいところです・・
オブジェクトの非現行バージョンを完全に削除の挙動
上記のバージョン表記ONで表示されたオブジェクトを削除するオプションを実行してみます。
見てのとおり「削除マーカー」のみが残ります。よく考えてみたらそうか・・でも不便だな、というのが正直な感想です。
ここで「有効期限切れのオブジェクト削除マーカーまたは不完全なマルチパートアップロードを削除」というオプションが生きてくるわけですね。でも常識的に、バージョニングされたオブジェクトも含め全て削除されたらそのマーカーは要らなくない!?と思いました・・。
そして削除マーカーには課金が発生します。個人アカウントの数個数十個の削除マーカーなら気にする必要はありませんが、大規模なシステムだと塵も積もれば・・となります。
削除マーカーには、Amazon S3 でのストレージに対して最小限の料金が発生します。削除マーカーのストレージサイズは、削除マーカーのキー名のサイズと同じです。キー名は Unicode 文字のシーケンスです。キー名の UTF-8 エンコードにより、名前の各文字に対して 1 ~ 4 バイトのストレージがバケットに追加されます。削除マーカーは、S3 標準ストレージクラスに保存されます。
削除マーカーの操作
有効期限切れのオブジェクト削除マーカーまたは不完全なマルチパートアップロードを削除の挙動
上述の結果より削除マーカーを削除するオプションを選択。するとまさかの結果。
オブジェクトの有効期限切れと削除マーカーの削除は同一のライフサイクルルールには設定できないとのこと。
削除マーカーの仕様なのかと最初は思い調べましたがおそらくですが「同じルールに同居できない」という作り手側の仕様(制限)です。
上記の根拠として、同一バケットに対し別のライフサイクルルールを作成した場合問題なく設定できました。
ちなみに削除マーカーの削除条件は「現行バージョンが削除」かつ「非現行バージョンも有効期限切れ(≒削除)」です。
当該ライフサイクルルールをONにして、翌朝9:00過ぎに確認したところ無事削除されました。
さいごに
AWSユーザはS3利用がほぼ必須だと思いますが、意外と分かりづらい(読みづらい?)S3ライフサイクルの検証について纏めました。実務でもS3利用は当たり前だと思うので参考になれば幸いです。