こんにちは。エンジニアの岩間です。
この記事は、ギークフィード Advent Calendar 2023 第一日目の記事です!
なんとギークフィード初のアドベントカレンダーです。
パートナー企業である株式会社スカイアーチHRソリューションズのメンバーにも参加していただいています。
本記事では、「Amazon S3のライフサイクルルールを利用してGlacier Deep Archiveから以前のバージョンのオブジェクトを復元するまでの方法」をご紹介していきたいと思います。
目次
はじめに
Amazon S3を利用する際、大量のデータを効果的に管理することはクラウドストレージの鍵となります。
しかし、「ファイルのバージョンを効率的に管理したい」、「間違ってファイルを削除しても復旧したい」といった課題にぶつかったことはありませんか?
そのような状況で、Amazon S3のライフサイクルルールは強力なツールとなります。特に、Glacier Deep Archiveストレージクラスは、ストレージコストの最適化とデータのセキュアな管理に適しています。
この記事では、S3のライフサイクルルールを駆使して、Glacier Deep Archiveにアーカイブされた以前のオブジェクトを復元する方法に焦点を当て、Amazon S3をより効率的に利用する方法をご紹介していきます。
バージョニング設定をする
まずはAmazon S3のバージョニング設定を行うところからです。
※すでに設定してるよ!という方は飛ばしていただいて大丈夫です。
バージョニングを使用すると、Amazon S3 バケットに格納されているすべてのオブジェクトのすべてのバージョンを保存、取得、復元できます。バージョニングを使用すると、意図しないユーザーアクションと意図しないアプリケーション障害の両方から簡単に復旧できます。
バージョニング設定はバケット作成前、作成後どちらの状態でも設定できます。
バケット作成前の場合
1.AWSコンソールで「S3」と検索します。
2.「バケットを作成」をクリックします。
3.バケットのバージョニングの項目を「有効にする」に設定し、バケットの作成を行います。
バケット作成後の場合
1.対象のバケットの「プロパティ」タブ→バケットのバージョニングの項目の「編集」をクリックします。
2.バケットのバージョニングを「有効にする」にチェックを入れ、「変更の保存」をクリックします。
これでバージョニングの設定が完了です!
ライフサイクルルールを設定する
次に、ライフサイクルルールの設定を行います。
上記のバージョニング設定のみだと、バージョニングされたオブジェクトはS3 Standardクラスに保存されます。
コストを削減したい場合や、すべてのバージョンのオブジェクトを保存したくない場合等は、ライフサイクルルールを使用してバージョニングされたオブジェクトの保存先ストレージクラスや、保存日数、保存する世代数などを管理することができます。
たとえば、別のストレージクラスへのオブジェクトの移行、オブジェクトのアーカイブ、指定した期間後のオブジェクトの削除などができます。
サポートされていないライフサイクル移行や制約もあるので、設定前にこちらの公式ドキュメントを読みましょう。
例えば、以下の制約があります。
- 以下の移行は できません。
- S3 Intelligent-Tiering ストレージクラスを S3 Standard – IA ストレージクラスに移行する。
- S3 1 ゾーン – IA ストレージクラスを S3 Intelligent-Tiering、S3 標準 – IA、または S3 Glacier Instant Retrieval ストレージクラスに移行する。
- [128 KiB 未満のオブジェクト] – 以下の移行で、Amazon S3 は128 KiB 未満のオブジェクトを移行しません。
- S3 Standard または S3 標準 – IA ストレージクラスから S3 Intelligent-Tiering または S3 Glacier Instant Retrieval へ移行します。
- S3 Standard ストレージクラスから S3 Standard – IA または S3 1 ゾーン – IA への移行。
ライフサイクルルールはバケット作成後に設定することができます。
以下、ライフサイクルルールの設定手順です。
1.対象のバケットの「管理」タブ→「ライフサイクルルールを作成する」をクリックします。
2.ライフサイクルルールを以下のように設定します。
項目 | 設定内容 |
---|---|
名前 | 任意のライフサイクルルール名を設定 |
ルールスコープ | |
ライフサイクルルールのアクション |
・オブジェクトの最新バージョンをストレージクラス間で移動
・オブジェクトの非現行バージョンをストレージクラス間で移動
上記から任意のルールを選択
|
ライフサイクルルールの設定例
ライフサイクルルールの設定例を紹介します。
例えば、オブジェクトが非現行バージョンになってから3日後にGlacier Deep Archiveストレージに移動し、365日後に完全削除といったライフサイクルを設定したい場合です。
ストレージクラスをGlacier Deep Archiveに移行することで、オブジェクトの取り出しに時間がかかりますが、他のストレージクラスと比較して低コストで保存することができます。
1.まず「オブジェクトの非現行バージョンをストレージクラス間で移動」と「オブジェクトの非現行バージョンを完全に削除」にチェックをいれます。
2.「現行バージョンではないオブジェクトをストレージクラス間で移行する」を以下のように設定します。
項目 | 設定内容 |
---|---|
ストレージクラスの移行を選択 | 「Glacier Deep Archive」を選択 |
オブジェクトが現行バージョンでなくなってからの日数 | 3を入力 |
保持する新しいバージョンの数-オプション | Standardクラスに数世代分のオブジェクトを保持したい場合は、バージョンの数を入力します。 |
3.「オブジェクトの非現行バージョンを完全に削除」を以下のように設定します。
項目 | 設定内容 |
---|---|
オブジェクトが現行バージョンでなくなってからの日数 | 365を入力 |
保持する新しいバージョンの数-オプション | Standardクラスに数世代分のオブジェクトを保持したい場合は、バージョンの数を入力します。 |
4.以下の画像のような設定になっていればOKです。問題なければ「ルールの作成」をクリックします。
5.ライフサイクルルール作成後、ステータスがEnabledになっていればOKです。
オブジェクトの復旧
非現行バージョンのオブジェクトの復旧をしていきます。
上記手順でライフサイクルルールの設定を行ったので、S3 Standardに保存していたオブジェクトを誤って削除した場合、削除したオブジェクトはライフサイクルルールによってGlacier Deep Archiveに移行します。
オブジェクトがGlacier Deep Archiveに移行した状態から、オブジェクトを復旧したいとします。
1.AWSコンソールでS3と検索し、S3ページの左メニューの「バケット」をクリックします。
2.対象のバケット名をクリックし、復元したいオブジェクトのディレクトリにいきます。
3.「バージョンの表示」をONにして、復元したい対象オブジェクトを検索します。
4.すると、復旧したいオブジェクトのストレージクラスが「Glacier Deep Archive」に移動していることが確認できます。
削除マーカーとは?
論理削除されたことを示すフラグのことで、削除マーカー自体はデータをもちません。
削除マーカーを完全削除しても、削除マーカーに紐づいていたファイルは完全削除されません。
5.復旧したいオブジェクト名をクリックします。
6.復元を開始をクリックします。
7.下の画像のような画面が表示されるので設定をし、「復元を開始」をクリックします。
項目 | 設定内容 |
---|---|
復元されたコピーが利用可能な日数 | 復元された一時コピーオブジェクトのDL可能期間を指定 ここで指定した期間を過ぎてDLしたい場合、再度復元リクエストが必要になります |
取得階層 | 一括取得 or 標準取り出しを選択 |
8.「復元が進行中」のステータスに変わるので、しばらく待ちます。
9.しばらくすると「復元の完了」のステータスになるので、ダウンロードします。
これで誤って削除したオブジェクトを復旧し、ダウンロードに成功しました!
~番外編~
復元対象オブジェクトをStandardクラスに移動したい場合:
オブジェクトのストレージクラスをGlacier Deep ArchiveからS3 Standardに移動するためには、AWS CLIで以下のコマンドを実行します。
1 |
aws s3 cp S3 コピー元のURI コピー先のURI --storage-class STANDARD |
例
1 |
aws s3 cp s3://gf-test-blog/test/test1.txt s3://gf-test-blog/test/test1.txt --storage-class STANDARD |
まとめ
いかがでしたでしょうか?
以上、「Amazon S3のライフサイクルルールを利用してGlacier Deep Archiveから以前のバージョンのオブジェクトを復元するまでの方法」でした。
皆様の参考になれば幸いです。
- 電子工作で自作した植物の自動水やり機から土壌データをAWS IoT Coreに連携してみた - 2024-09-13
- 【ESP8266 NodeMCU】電子工作で植物の自動水やり機を作ってみた - 2024-08-14
- Amazon Bedrock APIでTypeScriptのテストコードを出力してみた - 2024-05-07
- AWS CDK × CodeBuild × CypressでE2Eテストを自動化&実行動画をS3に保存してみる - 2024-04-16
- AWS ECSでブルーグリーンデプロイメント!~デプロイメントタイプ別の動作比較~ - 2024-04-03