この記事でできること
- バージョニングについて
- S3ライフサイクルについて
- S3ライフサイクルの設定
はじめに
S3は事実上無制限のスケーラビリティを備えたオブジェクトストレージとなります。サーバログやCloudTrailログ等の保管場所として利用されますが、塵も積もればで予算圧迫の原因となっていることもあるでしょう。そこで今回は「ライフサイクル」について纏めたいと思います。
ライフサイクルルールは説明が若干曖昧なのと、業務環境だと気軽に試せないと思うので、いくつかのパターンを想定して検証結果を記事にします。
ライフサイクルの設定において「バージョニング」は大事な要素となってくるので、今回利用するS3バケットはバージョニングを有効化します。S3バケットの作り方、データの格納方法については以下の記事を参考にしてください。
※上記記事ではバージョニングについては触れていませんが、バケット作成のタイミングで「バケットのバージョニング」という項目があります。設定内容も有効or無効のみですので、分かりやすいかと思います。
バージョニングついて
S3はオブジェクトストレージのため、ファイルサーバのように上書きという概念がありません。そのため同名のファイルをアップロードすると、バージョニングが無効の場合ファイルが入れ替わり、バージョニングが有効の場合既存ファイルは非現行バージョンとなります。バージョニング情報の確認は「バージョン情報の表示」をONにすることで確認できます。
当たり前と言えば当たり前なのですが、バージョニングで管理されている古いファイルもS3の課金対象になります。そのため、次項のライフサイクルで管理しないと、無制限に溜まっていってしまうので注意してください。(しかも、通常「バージョンの表示」はOFFだと思うので、どれくらい溜まっているかが一目では分からない)
ライフサイクルについて
ライフサイクルは、オブジェクトをS3に格納してから一定時間後に、削除やストレージクラスを変更するというものです。重要な点として、S3ライフサイクルは一日一回 UTC 0:00(日本時刻 朝9:00)にルールを満たしているオブジェクトに対しアクションが実行されます。例えば、ルールが「1日後に削除」で日本時刻 朝9:01に作成されたファイルの場合、削除されるのはほぼ2日後となります。(作成翌日の9:00のタイミングではファイルの存在時間は23時間59分のためアクション対象外)
ライフサイクル設定のルールが満たされてから、実際にアクションが実行されるまでの間には、遅延が発生する場合があります。ただし、アクションが実行されていなくても、ライフサイクル設定のルールが満たされた段階で、請求にはすぐに変更が反映されます。
バケットのライフサイクル設定の指定
実際問題、削除タイミングを分単位で制御しようとする状況はそこまで無い気がしますが、そういった場合はLambdaを利用して定時削除するのがよいと思います。
ちなみ細かい話ですがコンプライアンス等で、ログを1年間保管、といった場合はとりあえず366日にしておけば問題ないと思いますが、365日 or 366日、かは確認するのが良いと思います。
ライフサイクル設定について
バケットに行き「管理」タブ」から、「ライフサイクルルールを作成する」をクリックすることでルールの設定画面に移ります。
ライフサイクルルールの主要な設定項目は以下の2つです。
◆ルールスコープ
ルールをバケット全体に適用するか / 特定のプレフィックスに適用するか、を決めます。特定のプレフィックスに適用を選択した場合、さらに特定のタグ値に適用したり、特定のサイズ(最大or最小)を指定したりできます。
◆ライフサイクルルールのアクション
ライフサイクルルールのアクションは、以下の5つから任意のアクションを選択します。
以下に詳細を纏めます。
・現行バージョンのオブジェクトをストレージクラス間で移動
言葉のとおり格納した最新のオブジェクトを特定の日数を以降にストレージクラスを移動する、というものです。ログなど書き換えがなく溜まっていくだけの資源に対し、有効なアクションとなります。
・オブジェクトの非現行バージョンをストレージクラス間で移動
サーバの設定ファイル等、ファイル名は同じで更新されていく資源に対し、古いファイルも残しておきたいがコストは安く済ませたい、といった要件において有効なアクションとなります。このアクションを利用する場合には、「バージョニング」の有効化が必要となります。(無効状態場合、当該アクションが発動しないだけで設定そのものは可能です。)
・オブジェクトの現行バージョンを有効期限切れにする
「有効期限切れ」という言葉のせいで現行バージョンを「削除」するオプションのように見えませんが、現行バージョン(最新バージョン)を削除したい場合は本オプションを選択することになります。
削除目的でオプション内容を詳細に記載すると・・
バージョニングが無効な場合は、このオプションを設定することで「削除」となります。
バージョニングが有効な場合、次に記載する「非現行バージョンを完全に削除」と併せて設定しないと、本当の削除にはなりません。
ややこしいことはAWSも認識しているのか、下記のような説明文(注意文)があります。
「有効期限が切れる」に対し二つの意味(削除と非現行への移行)があるのでややこしいですね。
・オブジェクトの非現行バージョンを完全に削除
バージョニングが有効のバケットは非現行バージョン(要は昔のファイル)を保持するので、そのファイルを削除するオプションになります。「オブジェクトが現行バージョンでなくなってからの日数」と「保持する新しいバージョンの数(オプション)」を設定できます。
・有効期限切れのオブジェクト削除マーカーまたは不完全なマルチパートアップロードを削除
「削除マーカー」「不完全なマルチパートアップロード」を削除するオプションとなります。
削除マーカーはバージョニングが有効なバケットにおいてオブジェクトを削除した際に付与されるもので、公式ドキュメントにおいては「削除されたかのように動作し、削除マーカーが最新バージョンとなる」と表記されています。ちなみに削除マーカーは0バイトのオブジェクトとして扱われるので、オブジェクト数としてカウントされます。
削除マーカーにより、Amazon S3 はオブジェクトが削除されたかのように動作します。＜中略＞DELETE リクエストで指定したオブジェクトは実際には削除されず、代わりに削除マーカーがオブジェクトの最新バージョンになります。
削除マーカーの使用
マルチパートアップロードは、大容量ファイルを分割して並列にS3へアップロードし最後に連結されてS3に保存する機能です。よって本オプションの「不完全な～～を削除」というのは意味が分かりやすいですね。
さいごに
今回はS3ライフサイクルの基礎について纏めました。次回記事では実際にライフサイクルを設定してみてどのように動作するかを検証してみたいと思います。
