はじめに
S3のバージョン管理について、毎回調べては忘れ、調べては忘れ、を繰り返していたので備忘録もかねて記事を書こうと思います。
今回は、大きく分けて以下の２つの説明になります。
- バージョニング
- ライフサイクル
先に全体の図を貼っておきます
バージョニングとは何か？
バージョニングは、よくあるバージョン管理機能のS3版になります。
誤ってファイルを削除してしまったり、上書きしてしまったことありませんか？
開発環境であれば問題なかったりしますが、本番環境でそれが起こってしまうと問題がありますよね。
バージョニングを有効化しておけば、
1つのオブジェクトで複数バージョンを管理でき、誤って上書きなどしてしまっても復元が可能になります。
デフォルトだとバージョニングは無効なので、基本的には有効にしておくのが良いかなと思います。
※S3のセキュリティプラクティスでも、有効化が推奨されています
バージョン毎にストレージ料金が発生します。
よって、ライフサイクルを利用して不要なコストがかからないようしましょう。
なお、後述の削除マーカーにはストレージ料金がかかりません。
バージョニングの概念
バージョニングで出てくる設定について説明します
ステータス
バージョニングのステータスとしては、
- 無効
- 有効
- 停止
の3つがあり、デフォルトでは無効になります。
一度有効にすると無効にすることはできず、バージョニングを途中でやめたくなった場合は停止にする必要があります。
バージョンと削除マーカー
バージョンとしては以下の2つになります。
- 1つしかない、
現行のバージョン - 0個以上ある、
以前のバージョン
また、各バージョンにはバージョンIDと呼ばれるランダムなIDが降られます。
※最初にアップロードしたオブジェクトは、バージョンIDはnullになります。
同じパスに2回目のアップロードをすると、現行のバージョン→以前のバージョンに繰り下がり、以降アップロードするたびに繰り下がっていきます。
バージョニングが無効の場合は現行のバージョンのみなので、アップロードすると上書きされます
オブジェクトを取得する際は、バージョンIDを
- 指定しなければ最新のバージョン
- 指定すれば過去のバージョン
のオブジェクトを取得できます
バージョニングが有効なバケットに対して、削除をする際にはバージョンIDを指定する/しないで挙動が変わります。
- バージョンを指定しないで削除を実行すると、削除マーカーと呼ばれるバージョンが発行され、論理削除状態になります。
- 削除マーカーはいくつでも発行できます
- バージョンを指定して削除を実行した場合は、
- 削除マーカーのバージョンIDを指定して削除すると、論理削除が無くなるのでオブジェクトが復元されます
- オブジェクトのバージョンIDを指定して削除すると、対象のバージョンが削除されます
古いオブジェクトは以下の方法で最新として復元できます
- 削除マーカーのバージョンIDを削除する
- 対象のバージョンIDをコピーでアップロードしなおす
有効→停止にした場合
バージョニングを停止した場合は、過去のバージョンは残り、以降のアップロードでバージョンが降られなくなります。
無効にしたから大丈夫と思って、不要なオブジェクトが大量に残っていると思わぬ料金が発生するかもしれません
なので、次に説明するライフサイクルが重要になってきます。
ライフサイクルとは何か？
S3バケットのオブジェクトに対して、ライフサイクルを設定するものになります。
バージョニングで説明した通り、1つのオブジェクトに関して複数バージョンが存在する場合、それらにもストレージ料金が発生します。
基本的に最新以外は再取得することが少ないと思うので、安価なストレージに移行したり、削除することでコストが削減できます。
それらを設定するのが、ライフサイクルになります。
ライフサイクルの概念
ライフサイクルで出てくる設定について説明します
スコープ
どの範囲でライフサイクルを適用するかを設定します。
以下のどちらかになります。
- 全オブジェクト
- フィルター
フィルター
どういった条件に合致したオブジェクトへアクションを適用するかを設定します。
以下のいずれか、もしくは、以下を組み合わせたフィルターを設定できます。
- プレフィックス
- オブジェクトタグ
- オブジェクトサイズ(最小、最大)
128KB未満のオブジェクトは、移行コストがストレージ削減コストを上回る可能性があるため、デフォルトでは移行しないようになっています。
アクション
フィルターに合致したオブジェクトに対して行うアクションを設定します。
大きく分けて、移行と失効(削除)があります。
移行
移行では
- 現行のバージョンのストレージクラスの移行
- 以前のバージョンのストレージクラスの移行
がそれぞれ選択できます。
現行のバージョンのストレージクラスの移行では、
- 移行ストレージクラス：どのストレージに移行するか
- オブジェクト作成後の日数：アップロードされて何日経ったら移行するか
を設定できます。
以前のバージョンのストレージクラスの移行では、
- 移行ストレージクラス
- オブジェクトが現行バージョンでなくなってからの日数
- 保持する新しいバージョンの数：複数バージョンの内、最新の何バージョン残して移行するか
を設定できます。
ストレージクラスの移行は、ストレージ料金が低くなる方向にのみ移行出来ます。
また、移行リクエスト自体に料金が発生するストレージと発生しないストレージがあります。
失効(削除)
失効では、
- 現行のバージョンを有効期限切れにする
- 以前のバージョンの完全削除
- 期限切れの削除マーカーの削除
- 削除マーカーしかないオブジェクトを削除
- 不完全なマルチパートアップロードの削除
- 途中でマルチパートアップロードが失敗した場合に残った不完全なファイルを削除 ※コンソールから確認することは出来ない
が選択できます。
現行のバージョンを有効期限切れにするでは、
- オブジェクト作成後の日数
を設定できます。
以前のバージョンの完全削除では、
- オブジェクトが現行バージョンでなくなってからの日数
- 保持する新しいバージョンの数
を設定できます。
期限切れの削除マーカーの削除では、
- 無効/有効
のみ設定できます。
不完全なマルチパートアップロードの削除では、
- 無効/有効
のみ設定できます。
なお、現行のバージョンを有効期限切れにすると期限切れの削除マーカーの削除は併用して設定することは出来ません。
アクションの併用、ライフサイクルの複数設定
移行と失効は両方設定することが出来ますし、ライフサイクルも複数設定できます。
よくあるパターンとしては、以下のように
- 一定期間経過したら、ストレージクラスを移行してコストを削減
- 更に一定期間経過したら、不要なので削除してコストを削減
する形です。
どういったストレージクラスにするか、何日経過したら削除して良いか、などはプロジェクトの要件に沿って設定していきましょう。
ちなみに、ライフサイクルが競合した場合は、以下の画像のようなルールに従った挙動をするようです。
競合の例については、こちらをご確認ください。
Storage Lens
最後に、さらっと紹介になりますが、Storage LensというS3の機能により、S3の利用状況をダッシュボードで可視化することが出来ます。
大量に以前のバージョンが残っていないか、今各バケットでストレージ量はどのくらいか、などを確認することが出来ます。
無料のメトリクスを利用すれば、別料金がかからず利用できるので作っておいて損はないと思います！
AWS Organizationsを利用していれば、管理下の複数アカウントの利用状況を可視化できるようです
おわりに
今回はS3のバージョニングとライフサイクルについて説明しました。
小規模なシステムならそこまでコストは意識しなくてもいいかもしれませんが、大規模になればなるほどコスト削減が必要だったり、オブジェクトの管理ポリシーが厳格になったりするので、覚えておいて損はないと思います