この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
コンバンハ、千葉（幸）です。
S3 のライフサイクルやバージョニング、使ってますか？
私は「あぁそれね、4年くらい前に完全に理解しましたよ」という気分でいたのですが、いざ きちんと思い出そうとすると 90分ほどかかってしまいました。
3歩あるくと大抵のことを忘れる私としては、都度 90分かけて思い出すわけには行きません。今後は 3分くらいで思い出せるよう、まとめてみることにします。
まとめ
- バージョニング はバケット単位で設定する
- ステータスは以下のいずれか
- 無効
- 有効
- 停止
- 「以前のバージョン」のオブジェクトは復元できる
- 削除マーカーによる論理的な削除という状態が生まれる
- ステータスは以下のいずれか
- ライフサイクルはスコープを限定可能で、ルールを複数設定できる
- 選択できるアクションは以下
- 現行のバージョンのストレージクラスの移行
- 以前のバージョンのストレージクラスの移行
- 現行のバージョンの失効
- 以前のバージョンの完全削除
- 期限切れの削除マーカーの削除
- 不完全なマルチパートアップロードの削除
- ライフサイクルルールは既存のオブジェクトにも適用される
- 選択できるアクションは以下
2021/11/24 追記
ライフサイクルにおいて、「経過日数」だけでなく「オブジェクトのバージョン数」も指定できるようになりました。はぇー。
Amazon S3 のバージョニングとは
バージョニングにより、単一のオブジェクトの複数のバージョンを保持できるようになります。操作ミスによる削除に対しても、簡単に復旧できる手段を提供してくれます。
バージョニングの設定はバケット単位で行われ、以下のいずれかのステータスを持ちます。
- 無効
- 有効
- 停止
デフォルトではバージョニングは無効
S3 バケット作成時に明示的に有効化しない限り、バージョニングは無効となっています。
その場合、全てのオブジェクトは現行のバージョンとして扱われます。バージョン ID は採番されず、 null が設定されます。
当然ですが、現行のバージョンのオブジェクトを削除すると、完全に削除された状態となります。
（ちなみに図中の青字で「スタンダード」と書いてあるのは、ストレージクラスを表しています。この記載が活きてくるのは次章のライフサイクルの話になってからなのですが、気が急いて書いてしまいました。）
バージョニングを有効化すると
バージョニングを有効化することで、以前のバージョンという概念が生まれます。
各オブジェクトは以下を持つことになります。
- 一つの「現行のバージョン」
- 0個以上の「以前のバージョン」
「以前のバージョン」のオブジェクトが発生するケースとしては大まかに以下があります。
- 同一キー（名称）のオブジェクトが Put された
- 「現行のバージョン」のオブジェクトが削除された
- ライフサイクルによる有効期限切れ含む
バージョン数の上限については特に定められていません。（さすがに数百万まで行くとレスポンスに影響は出るようです。）
バージョニングを有効にしたバケットへの Amazon S3 PUT または DELETE オブジェクトリクエストに対して受信される HTTP 503 Slow Down レスポンスの数が著しく増加した場合、バケットに数百万のバージョンが存在するオブジェクトがある可能性があります。
しれっと図に出てきた「削除マーカー」については後で触れます。
以前のバージョンの復元
「以前のバージョン」のオブジェクトは、以下のいずれかで「現行のバージョン」に復元できます。
- コピーする
- 自身より新しいバージョンを削除する
コピーする
特定のバージョンと同じ内容を持つオブジェクトが新たに Put され、「現行のバージョン」となります。コピー後のオブジェクトのバージョン ID は新たに採番されます。
コピー元のバージョンはそのまま維持されるので、同じ内容を持つ複数のバージョンが同居することになります。
自身より新しいバージョンを削除する
特定のバージョン（最古でないもの）が削除されると、それより古いバージョンが繰り上がります。「現行のバージョン」を削除すれば、「以前のバージョン」の中で最も新しいものが「現行のバージョン」に返り咲きます。
マネジメントコンソールではこう見える
2021年3月現在の UI では、S3 バケット内のオブジェクトの詳細画面でバージョン構成が確認できます。
ここから特定のバージョンのコピーや削除が可能なほか、ダウンロードすることもできます。
削除マーカーによる論理的な削除
現行のバージョンが削除マーカーの場合、そのオブジェクトは論理的な削除として扱われます。削除マーカーは、オブジェクトに対する削除リクエストに応じて Amazon S3 が独自に作成するものです。
「論理的な削除」は「完全な削除」と異なり、「削除マーカー自体を削除」することで「以前のバージョン」のオブジェクトを復元させることができます。
削除マーカーを削除する際はバージョン ID の指定が必要で、指定なしにオブジェクトの削除リクエストを実行すると別の削除マーカーが挿入されます。
現行のバージョンが削除マーカーの際、コピーによる復元は実施できません。
コンソールではこう見える
2021年3月現在の UI では、バージョニングが無効なオブジェクトを削除しようとすると以下の確認画面が表示されます。
「完全に削除」される旨が注意喚起されます。
バージョニングが有効もしくは停止の場合、削除時の確認画面はこのようになります。
削除マーカーが作成される旨について表示されるほか、「完全に削除」という表現でないことが分かります。
バージョニングの停止
バージョニングを一度有効化すると、再度無効化することはできません。できるのは停止というステータスに遷移させることです。
バージョニングを停止すると、それまでのバージョン構成は維持されたまま以下の挙動となります。
- 新規で追加されるオブジェクトバージョンのバージョン ID は null となる
- 追加されるのが削除マーカーであったとしても同様
- 既存の「現行のバージョン」のバージョン ID が null の場合、上書きされる
- 既存の「現行のバージョン」のバージョン ID が null でない場合、既存のものが「以前のバージョン」に繰り下げされる
各バージョンにかかる料金
忘れてはいけないのは料金の観点です。
図において水色のオブジェクトになっている部分は、（つまりは削除マーカー以外の任意のバージョンは、）すべて通常通りのストレージ使用量に応じた料金がかかります。
論理的な削除状態のオブジェクトも、「以前のバージョン」には料金が発生しているというのは要注意ポイントです。
削除マーカーにもごく微量（よっぽどのことがない限り 1ドルにも満たない）の料金が発生するのですが、詳細はライフサイクルの項で取り上げます。
Amazon S3 のライフサイクル とは
ライフサイクルルールを設定することによって、オブジェクトに対して自動的にアクションを実行できます。
バージョニングがバケット単位で適用されたのに対し、ライフサイクルは以下手段で対象をフィルタリングし、スコープを定められます。全体に適用することもできます。
- プレフィックス（平たく言えばフォルダ）
- オブジェクトタグ（キーと値の組み合わせ）
一つのバケットに複数のライフサイクルルールを設定することもできます。同一のスコープを持つ異なるライフサイクルルール、というものも設定できます。
ライフサイクルルールのあれこれ
ライフサイクルルールを作成すると、その設定は既存のオブジェクトにも適用されます。ライフサイクル設定の有効化、無効化はほぼリアルタイムで適用されますが、全体に適用されるまでに数分間程度の遅延が発生する場合があります。
また、ライフサイクルルールによるアクションは翌日の午前0:00（UTC）のタイミングで行われます。一部遅延が発生するケースもあるそうなので考慮しておきましょう。
ライフサイクルによるアクションは、大きくは以下に分かれます。
- 移行アクション
- 失効アクション
移行アクション
移行アクションは、オブジェクトのストレージクラスを移行するものです。
バージョニング が無効のバケットであれば「現行のバージョン」のみ、有効もしくは停止のバケットであればそれに加えて「以前のバージョン」を対象として設定できます。
それぞれ対象のバージョンが発生してからの経過日数に応じて、ストレージクラスを移行させることができます。
格納してから一定期間経過したら、よりストレージ使用料の低いストレージクラスに移行させる、というのはよく聞くパターンですね。
ストレージ移行パス
ストレージクラスを移行させる際に、移行元と移行先の組み合わせは以下のように限定されています。
ストレージ料金が低くなる（その代わり取り出しの料金が高くなる）方向にのみ移行ができます。逆方向には移行できませんのでご注意ください。
また、128 KB 未満の小さなオブジェクトだと移行のメリットが出ない、最低 30日間のストレージ料金が発生する、などの制約がある組み合わせもあります。念頭においておきましょう。
ストレージクラスの選択については以下もご参考ください。
ストレージクラス移行にかかる料金
ストレージクラスによっては、ライフサイクルにより移行する際のリクエストに料金が発生するものがあります。
大量のオブジェクトの移行が見込まれる場合には気にしておくといいでしょう。
失効アクション
失効アクションは、オブジェクトを有効期限切れにするものです。平たく言えば削除を行います。
こちらも現行のバージョンと以前のバージョンを対象とできます。
現行のバージョンを有効期限切れにする
イメージとしては手動で削除を行う場合と変わりありません。
バージョニングが無効なバケットであれば完全に削除されますし、そうでなければ削除マーカーが「現行のバージョン」になります。
「現行のバージョン」が削除マーカーであった場合に、ライフサイクルによりそれが削除されて「以前のバージョン」が繰り上げされる、ということは起こりません。
以前のバージョンを完全に削除する
こちらも手動での削除と特に変わりありません。
それぞれのバージョンが「以前のバージョン」となってからの経過日数に応じて、順次完全に削除が行われていきます。
その他のアクション
ここまで見てきたアクションの他にも、以下を選択できます。
- 期限切れの削除マーカーの削除
- 不完全なマルチパートアップロードの削除
これらはスコープが「オブジェクトタグ」の場合には選択できません。つまり、「バケット全体」か「特定のプレフィックス」がスコープの場合のみ選択できます。
期限切れの削除マーカーの削除
やんごとなき事情で以下状態になった場合、それは期限切れの削除マーカーと呼ばれます。
- 「以前のバージョン」が 0個
- 「現行のバージョン」が削除マーカー
削除マーカーはコンテンツを持たないため、ストレージ利用の料金はほとんどかかりません。オブジェクトキーのサイズに応じて微量の課金が発生します。
例えばfuga.pngであれば 8バイトですので、その分の料金がかかります。標準ストレージクラスだと 1GBあたり0.02ドル程度かかりますので計算すると……、まぁそのくらいの料金が発生します。
料金の観点ではほとんどインパクトはありませんが、不要な情報が残り続けるのはよろしくありません。大量に残っているとリストする際のレスポンスにも影響を及ぼすでしょう。
「期限切れの削除マーカーの削除」アクションによりそれらを削除することが可能になります。ただ、「現行バージョンの失効」アクションと併用はできません。「現行バージョンの失効」アクションの内容と重複するからです。
ピンポイントで期限切れの削除マーカーの削除のみが必要となった際に使用するといいでしょう。
不完全なマルチパートアップロードの削除
これまで見てきたものとは少し毛色が異なるアクションです。
S3 に大きなサイズのオブジェクトをアップロードする際に、マルチパートアップロードという手段を用いることができます。
一つのファイルを細かく分割してアップロードするのですが、そこで失敗が発生すると、一部のファイルが不完全なマルチパートアップロードとして残り続けることになります。そのオブジェクトに対しても料金は発生します。
これはマネジメントコンソールから参照することも削除することもできません。そこに向けたお手軽な対応として、「不完全なマルチパートアップロードの削除」アクションを活用できます。
具体的な使用例は以下に詳しいですので、あわせてご参照ください。
おまけ
ここまで見てきた「以前のバージョン」「削除マーカー」「未完了のマルチパートアップロード」など、自分の環境では不要に発生していないかな……？と気になった方がいるかもしれません。
それ、Storage Lens で見れますよ。
特に設定をしなくてもデフォルトでダッシュボードを作ってくれているので、ささっと確認してしまいましょう。
私も戯れに覗いてみたら削除マーカーがべらぼうに存在していて少しびっくりしました。
Storage lens については以下を参照してください。
終わりに
S3 のバージョニング とライフサイクルについておさらいしました。
これであれば、今後は 3分で思い出せそうです。まぁ書くのに 300分くらい掛かったので、元を取るために高速に忘れたり思い出したりを繰り返そうと思います。
皆さんもおさらいをしたい時はまた訪れてください。このブログは、あなたの帰りをいつでもいつまでも、ここで待ち続けています。
以上、千葉（幸）がお送りしました。
0
