今回は、S3 Glacier について調べたことをまとめていきたいと思います!
以前、【AWS】S3ストレージクラスを適切に使い分ける でもS3 Glacier について確認したのですが、なにやら「データモデル」だの「ボールト」だの、知らない言葉だらけだったので軽く整理しておきたいなと思いまして。
S3 Glacier のデータモデル
S3 Glacier のデータモデルには「アーカイブ(Archive)」と「ボールト(Vault)」という2つの主要概念があります。
この2つの主要リソースを補完するかたちで「ジョブ(Job)」および「通知設定」リソースも含まれます。
アーカイブ
アーカイブとは、写真や動画、ドキュメントなどの任意のデータであり、S3 Glacier におけるストレージの基本単位です。
アーカイブの特徴は以下の通り。
- アーカイブのサイズは 1 バイト以上 40 TB 以下であれば保管可能
- 一度にアップロードできるアーカイブの最大サイズは 4 GB
- 100 MB を超える場合、アーカイブをパート単位でアップロードするためのマルチパートアップロード機能の使用を検討する必要あり
- アーカイブは変更不可(アップロードと削除は可能、編集や上書きは不可)
- 各アーカイブには一意の ID とオプションの説明が割り当てられる
- 各アーカイブは一意のアドレスを持つ
(アーカイブのアドレス形式は以下の通り)
https://[region-specific endpoint]/[account-id]/vaults/[vault-name]/archives/[archive-id]
ボールト
ボールトとは、アーカイブを格納するコンテナのことです。
ボールトの特徴は以下の通り。
- ボールトに格納できるアーカイブの数に制限は無い
- 1 アカウントで、1 リージョンあたり最大 1,000 個のボールトを作成可能
- ボールトにタグを付けることで、ボールトを効果的に管理可能
- ボールトを削除するには、アーカイブが 1 つも格納されていない状態にする必要がある
- 各ボールトリソースは一意のアドレスを持つ
(ボールトのアドレス形式は以下の通り)
https://[region-specific endpoint]/[account-id]/vaults/[vaultname]
ジョブ
ジョブとは、アーカイブに対する SELECT クエリの実行や取得、ボールトのインベントリ取得を行う処理のことです。
ジョブの特徴は以下の通り。
- アーカイブやボールトのインベントリ(リスト) 取得は、S3 Glacier の非同期オペレーションであり、取得ジョブが完了した後に結果のダウンロードが可能となる
- ボールトのインベントリ取得ジョブには、ボールト名が必要
- 選択およびアーカイブの取得ジョブには、ボールト名とアーカイブ ID の両方が必要
- ジョブに対して説明を追加して、ジョブを識別することも可能
- 選択およびアーカイブ、ボールトインベントリのジョブは、ボールトに関連付けされる
- 単一ボールトに対して複数のジョブ実行が可能
- ジョブを実行すると(リクエストを送信すると)、S3 Glacier からジョブを追跡するジョブ ID が返され、下記形式の URI で一意に識別される
(ジョブのアドレス形式は以下の通り)
https://[region-specific endpoint]/[account-id]/vaults/[vault-name]/jobs/[job-id]
通知設定
ジョブの完了には時間がかかるため、S3 Glacier ではジョブの完了時に通知を行う通知設定があります。
ジョブの完了通知設定には、Amazon SNS を利用します。(ボールトごとに設定できるSNS トピックは 1 つ)
S3 Glacier のデータ取り出しオプション
「迅速」取り出し
- 1〜5 分以内 で取り出し可能
- アーカイブのサブセットが迅速に必要になった場合にデータにすばやくアクセス可能
- 最大規模のアーカイブ(250 MB 以上) は対象外
「標準」取り出し
- 3〜5 時間 で取り出し可能
- 取り出しオプションのデフォルト設定
「大容量」取り出し
- 5〜12 時間 で取り出し可能
- 最も安価な取り出しオプション
- 大量のデータ (ペタバイトのデータを含む) を 1 日以内に低コストで取得可能
ボールトアクセスポリシー
ボールトアクセスポリシーは、S3 Glacier のボールト(リソース) に直接アタッチして、ボールトにアクセスできるユーザーを指定し、それらのユーザーがそのボールトに実行できるアクションを指定できるリソースベースのポリシーです。
S3 Glacier は、各ボールトでボールトロックポリシーもサポートしており、ロックしたらそのボールトを変更することができなくなります。
ボールトロック
ボールトロックポリシーを使用して、の各S3 Glacier のコンプライアンス管理を簡単にデプロイして適用することが可能です。
ボールトロックポリシーで「write once read many」(WORM) などのコントロールを指定することで、ポリシーをロックし、今後編集できないようにします。
ボールトロックポリシーの例として「アーカイブから365日経過していないボールトの削除アクションを拒否する」や「”LegalHold” タグにより削除アクションを拒否する」ことが可能
関連するCLIコマンド
ボールトの作成からダウンロード、削除の操作に関連するCLIコマンドを抜粋してみます。
※リンク先はCLI の公式ドキュメントになってます。
- ボールトの作成 (aws glacier create-vault)
- アーカイブのアップロード(格納) (aws glacier upload-archive / aws glacier upload-multipart-part)
- ボールトのステータス確認:ボールトメタデータの取得 (aws glacier describe-vault)
- ボールトインベントリのダウンロード
- 1. 取得ジョブの開始:インベントリの取得ジョブ実行 (aws glacier initiate-job)
- (ジョブ完了を待つ)
- 2. ダウンロード (aws glacier get-job-output)
- ボールトの削除
- インベントリの取得ジョブの実行 (aws glacier initiate-job)
- 取得ジョブのダウンロード(ArchiveID の取得) (aws glacier get-job-output)
- ボールトから各アーカイブを削除 (aws glacier delete-archive)
- 改めてインベントリの取得ジョブの実行 (aws glacier initiate-job)
- (アーカイブの無い(空の)) ボールトを削除 (aws glacier delete-vault)
まとめ
今回はS3 Glacier について少しだけ掘り下げてみました。
S3 Glacier は、まだ実際に使用したことが無いのですが、【AWS】S3ストレージクラスを適切に使い分ける でも紹介したようにストレージクラスをマスターすることでかなりのコスト削減につながる一つの手段となり得るので、モノにしていきたい部分ですね。
最後まで読んでいただきありがとうございました。