この記事を三行にまとめると
AWSのS3にはバージョニングという機能がありますよほどの理由がない限りは有効にしておくべき
僕のようになりたくなければ……
AWSのS3にはバージョニングという機能があります。これを有効にしておくと誤ってファイルを削除しちゃった場合に復元できたりするので、有効にしておいて損はない機能です。むしろよほどの理由がない限りは有効にしておくべきです。僕のようになりたくなければ……。
設定自体はそんなに難しくないので今日はこの機能をちょいと見ていきましょう。
編集を押すとバージョニングの設定画面が開くので「有効にする」を選択して変更を保存すればバージョニングが有効になります。
実際にバージョニングを有効にするとバケットのオブジェクト一覧のところに「バージョンの表示」というボタンが出てきます。これをONにするとファイルのバージョンを確認することができます。
「delete.txt」というファイルが削除済みのファイルです。元のファイルが一つ古いバージョンになり「削除マーカー」という新しいバージョンが追加されています。この削除マーカーを削除すると元のファイルが最新のバージョンに戻って再びURLなどで参照できる状態となります。
この古いバージョンのファイルはそれぞれが一つのファイルとして扱われるので、料金もバージョンの分だけかかることになります。東京リージョンの場合は1GBあたり0.025ドルという料金がかかるので、例えば1GBのファイルに対して10個のバージョンが残っていれば料金も0.25ドルかかるという計算です。なので古いバージョンを全て残しておきたいなら別ですが、料金がかさんでいくのを避けたい場合は古いバージョンを適当なタイミングで削除した方が良いです。
古いバージョンの削除は自分でスクリプトを組んで定期的に実行しても良いんですが、S3のライフサイクルという機能を使えばS3側で削除してくれるのでそっちを使う方が楽だと思います。
バケット詳細の管理タブを開くとライフサイクルルールの項目が出てくるので、ここからルールの作成を行います。
ここで「オブジェクトの以前のバージョンを完全に削除する」にチェックを入れて日数を指定すると、ファイルを削除した日から指定した日数後に古いバージョンが削除されます。上記では「30」を入力しているのでだいたい一ヶ月後くらいに古いバージョンも消えることになります。
しかしこれだけだと古いバージョンが消えるだけなので、最新バージョンは残ることになります。上書きの場合は問題ないですが削除の場合は削除マーカーというそれ単体では何の役にも立たないバージョンが残ってしまうので、こいつも削除したい場合は「期限切れのオブジェクト削除マーカーを削除する」にもチェックを入れておく必要があります。このチェックがONになっていると削除マーカー以外の古いバージョンが全て消えた時に削除マーカーも一緒に削除されるようになります。
またライフサイクルが発動は標準時間の0時頃にまとめて起こるみたいです。日本時間の場合は午前9時ですね。日数の計算もこの時間を基準に行うらしいので、ファイルの削除された時間が午前9時前か9時以降かでライフサイクルの発動のタイミングも一日ずれるようです。
ちょっとややこしいですが、例えばファイルを削除したのが10月1日の午前8時頃の場合は発動が30日後の10月31日の午前9時となりますが、10月1日の12時頃に削除した場合は11月1日の午前9時が発動のタイミングとなります。
詳細についてはこの辺りに書かれています。
ライフサイクルルール: オブジェクトの存在時間に基づく
このバージョニングという機能は結構前から存在しているのですが、僕はつい最近までこの機能の便利さとかをよく分かってなかったので、まあ別にやらんでも良いだろうと思ってました。そのせいでうっかりミスもやらかしてしまいました。
バージョニングを有効にする前は間違って削除しちゃった場合のことを考えてバックアップ用のバケットを用意してそっちに同じファイルをコピーするみたいなめんどうなことをやってたんですが、いろいろとファイルの管理が複雑になっていく中でうっかりバックアップを取りきれていないみたいな状態が発生してしまいまして、しかもよりによってそのバックアップのないファイルがシステム側のミスでうっかり消えてしまうという事態が発生し……あとはお察しな感じです。
幸いあまり大事にはならずに済んだのですが、こりゃもっとちゃんと障害対応しとかにゃならんぞと思いまして、それでバージョニングを有効にしました。
個人的には料金がかさむこと以外は特にデメリットがないので、あえてバージョニングを無効にしておく必要はない気がします。どうしてもコストが気になるという場合はライフサイクルを短くしておけば良いだけですしね。
設定自体はそんなに難しくないので今日はこの機能をちょいと見ていきましょう。
バケット作成時に有効にする
バージョニングはバケット作成時に有効にすることもできます。新規にバケットを作成する時「バケットのバージョニング」という項目があるので、これを有効にすればOKです。無効で作成しても後から有効にすることはできるので大丈夫です。既存のバケットを有効にする
すでに作成済みのバケットのバージョニングを有効にしたい場合はバケットの詳細画面から「プロパティ」のタブを開くとバージョニングの項目があるので、そこの編集ボタンから設定を変更すればOKです。編集を押すとバージョニングの設定画面が開くので「有効にする」を選択して変更を保存すればバージョニングが有効になります。
実際にバージョニングを有効にするとバケットのオブジェクト一覧のところに「バージョンの表示」というボタンが出てきます。これをONにするとファイルのバージョンを確認することができます。
「delete.txt」というファイルが削除済みのファイルです。元のファイルが一つ古いバージョンになり「削除マーカー」という新しいバージョンが追加されています。この削除マーカーを削除すると元のファイルが最新のバージョンに戻って再びURLなどで参照できる状態となります。
ライフサイクルについて
上記のようにバージョニングを有効にするとファイルをうっかり削除してしまってもバケットから完全には削除されず、古いバージョンとしてそのまま残ります。ファイルを上書きした場合も同様で、上書きした分だけ前の状態のファイルが古いバージョンとして残ります。GitHubの履歴みたいなもんです。この古いバージョンのファイルはそれぞれが一つのファイルとして扱われるので、料金もバージョンの分だけかかることになります。東京リージョンの場合は1GBあたり0.025ドルという料金がかかるので、例えば1GBのファイルに対して10個のバージョンが残っていれば料金も0.25ドルかかるという計算です。なので古いバージョンを全て残しておきたいなら別ですが、料金がかさんでいくのを避けたい場合は古いバージョンを適当なタイミングで削除した方が良いです。
古いバージョンの削除は自分でスクリプトを組んで定期的に実行しても良いんですが、S3のライフサイクルという機能を使えばS3側で削除してくれるのでそっちを使う方が楽だと思います。
バケット詳細の管理タブを開くとライフサイクルルールの項目が出てくるので、ここからルールの作成を行います。
ここで「オブジェクトの以前のバージョンを完全に削除する」にチェックを入れて日数を指定すると、ファイルを削除した日から指定した日数後に古いバージョンが削除されます。上記では「30」を入力しているのでだいたい一ヶ月後くらいに古いバージョンも消えることになります。
しかしこれだけだと古いバージョンが消えるだけなので、最新バージョンは残ることになります。上書きの場合は問題ないですが削除の場合は削除マーカーというそれ単体では何の役にも立たないバージョンが残ってしまうので、こいつも削除したい場合は「期限切れのオブジェクト削除マーカーを削除する」にもチェックを入れておく必要があります。このチェックがONになっていると削除マーカー以外の古いバージョンが全て消えた時に削除マーカーも一緒に削除されるようになります。
またライフサイクルが発動は標準時間の0時頃にまとめて起こるみたいです。日本時間の場合は午前9時ですね。日数の計算もこの時間を基準に行うらしいので、ファイルの削除された時間が午前9時前か9時以降かでライフサイクルの発動のタイミングも一日ずれるようです。
ちょっとややこしいですが、例えばファイルを削除したのが10月1日の午前8時頃の場合は発動が30日後の10月31日の午前9時となりますが、10月1日の12時頃に削除した場合は11月1日の午前9時が発動のタイミングとなります。
詳細についてはこの辺りに書かれています。
ライフサイクルルール: オブジェクトの存在時間に基づく
このバージョニングという機能は結構前から存在しているのですが、僕はつい最近までこの機能の便利さとかをよく分かってなかったので、まあ別にやらんでも良いだろうと思ってました。そのせいでうっかりミスもやらかしてしまいました。
バージョニングを有効にする前は間違って削除しちゃった場合のことを考えてバックアップ用のバケットを用意してそっちに同じファイルをコピーするみたいなめんどうなことをやってたんですが、いろいろとファイルの管理が複雑になっていく中でうっかりバックアップを取りきれていないみたいな状態が発生してしまいまして、しかもよりによってそのバックアップのないファイルがシステム側のミスでうっかり消えてしまうという事態が発生し……あとはお察しな感じです。
幸いあまり大事にはならずに済んだのですが、こりゃもっとちゃんと障害対応しとかにゃならんぞと思いまして、それでバージョニングを有効にしました。
個人的には料金がかさむこと以外は特にデメリットがないので、あえてバージョニングを無効にしておく必要はない気がします。どうしてもコストが気になるという場合はライフサイクルを短くしておけば良いだけですしね。
