バージョニングとライフサイクルを扱う

目標

バージョニングを有効にして、バージョンが溜まる過程、削除がdelete markerで表現される方式、そして、それを整理するライフサイクルルールまでを、一度に扱います。

なぜ重要なのか

バージョニングは、ミスからの復旧のためのセーフティネットですが、同時にコストの罠でもあります。毎日同じキーにログを上書きするコードにバージョニングを有効にすると、1年後に、そのキー1つに365個のバージョンが溜まります。一覧ではオブジェクト1つに見えるのに、料金は365倍です。そして、「全部消したのに料金がそのまま」という問い合わせの原因が、delete markerです。バージョンIDなしで削除すると、データはそのまま残り、印だけが1つ載ります。そのため、実務では、バージョニングを有効にする決定と、ライフサイクルルールをかける決定は、常に一緒に下されます。このラボのステップ7が、その基本セットの3つを扱います。

ステップ

バケットlab-versを作成し、バージョニングを有効にしてください。aws --profile local s3api get-bucket-versioning --bucket lab-versにEnabledが見える必要があります。
s3://lab-vers/doc.txtに、異なる内容を3回アップロードしてください。aws --profile local s3api list-object-versions --bucket lab-vers --prefix doc.txtのVersionsが3個である必要があります。
最も古いバージョンをバージョンIDで指定して、/root/vers/v1.txtにダウンロードしてください。内容が、1回目にアップロードしたものである必要があります。
バージョンを指定せずにdoc.txtを削除してください。バージョン一覧にDeleteMarkersが1つできて、全体の項目が4個になる必要があります。/root/vers/marker.txtにversions=4 has_delete_marker=trueを書いてください。
delete markerをバージョンIDで指定して削除してください。aws --profile local s3 cp s3://lab-vers/doc.txt -が、3回目の内容を返す必要があります。/root/vers/restore.txtにrestored=trueを書いてください。
/root/vers/versions.txtに、current_bytes=<n>、noncurrent_bytes=<n>、total_bytes=<n>の3行を書いてください。totalは2つの値の合計で、noncurrentは0より大きい必要があります。
/root/vers/lifecycle.jsonにライフサイクルルールを入れ、aws s3api put-bucket-lifecycle-configuration --bucket lab-vers --lifecycle-configuration file:///root/vers/lifecycle.jsonで適用してください。非現行バージョンを30日で期限切れに、期限切れのdelete markerの整理、未完了のマルチパートを7日で中止。この3つの動作がすべて入っている必要があります。aws s3api get-bucket-lifecycle-configuration --bucket lab-versの出力を、/root/vers/ilm.txtに保存してください。

参考

バージョン一覧: aws s3api list-object-versions --bucket lab-vers --prefix doc.txt。Versionsは最新が先に来て、各項目のIsLatestが、現行かどうかです。delete markerは、DeleteMarkersに別に来ます。
バージョンを指定した取得: aws s3api get-object --bucket lab-vers --key doc.txt --version-id <id> /root/vers/v1.txt
バージョンを指定した削除: aws s3api delete-object --bucket lab-vers --key doc.txt --version-id <id>(元に戻せません)
バージョンIDの形は、サーバーごとに違います(AWSは32文字ほどのランダムな文字列、このサーバーは16進文字列です)。形式を仮定せず、一覧から選んでください。
このサーバー(SeaweedFS)は、ライフサイクルルールを受け付けて保存し、返してくれます。30日の期限切れが実際に動くのは、このラボの時間内には見られないので、採点は、バケットにルールがかかっているかまでしか見ません。
よくあるミス1: バージョンIDなしで削除して、「消えた」と信じてしまうこと。データも料金もそのままです。
よくあるミス2: バージョニングだけを有効にして、ライフサイクルをかけないこと。コストが静かに蓄積します。

バケットのバージョニングを有効にする

バケットlab-versを作成し、バージョニングを有効にしてください。aws --profile local s3api get-bucket-versioning --bucket lab-versにEnabledが見える必要があります。

バケット単位の設定です。有効にしたあと、状態を照会して確認してください。

同じキーに3回書いてバージョンを溜める

s3://lab-vers/doc.txtに、異なる内容を3回アップロードしてください。aws --profile local s3api list-object-versions --bucket lab-vers --prefix doc.txtのVersionsが3個である必要があります。

内容を毎回変えておかないと、あとで区別できません。バージョン一覧を照会してみてください。

古いバージョンを読む

最も古いバージョンをバージョンIDで指定して、/root/vers/v1.txtにダウンロードしてください。内容が、1回目にアップロードしたものである必要があります。

バージョンの識別子を指定して取得します。1回目にアップロードした内容が出てくる必要があります。

削除後にdelete markerを確認する

バージョンを指定せずにdoc.txtを削除してください。バージョン一覧にDeleteMarkersが1つできて、全体の項目が4個になる必要があります。/root/vers/marker.txtにversions=4 has_delete_marker=trueを書いてください。

バージョンを指定せずに削除すると、実際には消えません。バージョン一覧に、新しい項目ができます。

delete markerを削除して復旧する

delete markerをバージョンIDで指定して削除してください。aws --profile local s3 cp s3://lab-vers/doc.txt -が、3回目の内容を返す必要があります。/root/vers/restore.txtにrestored=trueを書いてください。

印を削除すると、すぐ下のバージョンが、再び現行になります。これが、ミスからの復旧の仕組みです。

非現行バージョンの容量を計算する

/root/vers/versions.txtに、current_bytes=<n>、noncurrent_bytes=<n>、total_bytes=<n>の3行を書いてください。totalは2つの値の合計で、noncurrentは0より大きい必要があります。

一覧ではオブジェクト1つに見えますが、料金はすべてのバージョンにかかります。合計を自分で出してみてください。

ライフサイクルルールを適用する

/root/vers/lifecycle.jsonにライフサイクルルールを入れ、aws s3api put-bucket-lifecycle-configuration --bucket lab-vers --lifecycle-configuration file:///root/vers/lifecycle.jsonで適用してください。非現行バージョンを30日で期限切れに、期限切れのdelete markerの整理、未完了のマルチパートを7日で中止。この3つの動作がすべて入っている必要があります。aws s3api get-bucket-lifecycle-configuration --bucket lab-versの出力を、/root/vers/ilm.txtに保存してください。

非現行バージョンの期限切れ、期限切れの印の整理、未完了アップロードの中止の3つが、基本セットです。