10/29、JAWS-UG CLI専門支部S3基礎 にてライフサイクルのハンズオンを受講しましたので、参加レポートを書いていきます。
目次
イベントページ
jawsug-cli.connpass.com
S3ライフサイクル概要
- コスト最適にS3を使うためにライフサイクルを設定する。
- ライフサイクルは、指定したオブジェクトを一定期間経過後に高いストレージクラスから低いクラスへ自動的に破棄または移行させていく仕組み。
- 高いクラスから低いクラスへのみライフサイクルを設定可能。逆の設定はできない。
- ストレージクラスは、高い順に、S3・S3 STANDARD_IA・INTELLIGENT_TIERING・ONEZONE_IA・S3 Glacier・S3 Glacier Deep Archive となる。
- S3 Glacier,S3 Glacier Deep Archive はテープストレージに似ている感じ。
- S3とS3 Glacier,S3 Glacier Deep Archive のSLAは99.9%
- S3 Glacier,S3 Glacier Deep Archive は取り出しに時間がかかる。
ハンズオン
手順と構成図
手順一式はこちらです。また、今回のハンズオン構成図は以下の通りです。
コマンド
保守担当者想定のIAMユーザ作成に関するコマンド、S3バケット作成、ファイルアップロード部分のコマンドは割愛します。
S3ライフサイクルドキュメントの作成
以下、JSONファイルに書き込みます。
{
"Rules": [
{
"ID": "temporary-objects",
"Filter": {
"Prefix": "tmp/"
},
"Status": "Enabled",
"Expiration": {
"Days": 1
}
},
{
"ID": "archive-objects",
"Filter": {
"Prefix": "archive/"
},
"Status": "Enabled",
"Transitions": [
{
"Days": 0,
"StorageClass": "GLACIER"
}
],
"Expiration": {
"Days": 1
}
},
{
"ID": "short-keep-objects",
"Filter": {
"Prefix": "logs/"
},
"Status": "Enabled",
"Transitions": [
{
"Days": 30,
"StorageClass": "STANDARD_IA"
},
{
"Days": 60,
"StorageClass": "INTELLIGENT_TIERING"
},
{
"Days": 90,
"StorageClass": "ONEZONE_IA"
},
{
"Days": 120,
"StorageClass": "GLACIER"
},
{
"Days": 210,
"StorageClass": "DEEP_ARCHIVE"
}
],
"Expiration": {
"Days": 211
}
}
]
}
このドキュメントで3つのライフサイクルを定義しています。
- "ID": "temporary-objects"
- Prefix: "tmp/" に作成したオブジェクトは、作成日から1日経過したら削除される。
- "ID": "archive-objects"
- "Prefix": "archive/" のオブジェクトは、オフジェクト作成日から日が変わったらS3 Glacierに移動する。さらにもう1日経過したら削除される。
- "ID": "short-keep-objects"
- "Prefix": "logs/" のオブジェクトについて以下のように動作する。
- 30日経過：STANDARD_IAに移動する。
- 60日経過：INTELLIGENT_TIERINGに移動する。
- 90日経過：ONEZONE_IAに移動する。
- 120日経過：S3 Glacier に移動する。
- 210日経過：S3 Glacier Deep Archiveに移動する。
- 211日経過：オブジェクトを削除する。
S3バケットのライフサイクルの作成
`s3api put-bucket-lifecycle' でバケットライフサイクルを設定します。
先に作成したS3ライフサイクルドキュメントを読み込ませます。
エラーが出力されなければOKです。
aws s3api put-bucket-lifecycle-configuration \
--bucket ${S3_BUCKET_NAME} \
--lifecycle-configuration file://${FILE_S3_BUCKET_LIFECYCLE_DOC}
`get-bucket-lifecycle' でS3バケットのライフサイクルが有効であることを確認します。
aws s3api get-bucket-lifecycle \
--bucket ${S3_BUCKET_NAME} \
--query 'Rules[].Status' \
--output text
今回は３つのライフサイクルを設定したため、Enabled Enabled Enabledと表示されればOKです。
マネジメントコンソール（S3⇒バケット名選択⇒管理⇒ライフサイクルルール）からもライフサイクルを確認します。
以下のように表示されます。
各プレフィックスのライフサイクルをマネジメントコンソールから確認すると、以下のようになります。
①tmp/("ID": "temporary-objects")
②archive/("ID": "archive-objects")
③logs/("ID": "short-keep-objects")
S3オブジェクトのライフサイクル確認
s3api head-object で作成したオブジェクトの有効期限を確認します。
aws s3api head-object \
--bucket ${S3_BUCKET_NAME} \
--key ${S3_OBJECT_KEY} \
--query 'Expiration' \
--output text
①tmp/("ID": "temporary-objects")のライフサイクル
10/30に「tmp/2020-10-30.txt」というオブジェクトを作成しました。
30日に作成したオブジェクトは31日中有効、11月1日0時になって日が変わった時点で削除されます。
s3api head-object を実行して以下のように表示されることを確認します。
expiry-date="Sun, 01 Nov 2020 00:00:00 GMT", rule-id="temporary-objects"
※補足
Amazon S3 は、ルールに指定された日数をオブジェクトの作成時間に加算し、得られた日時を翌日の午前 00:00 UTC (協定世界時) に丸めることで、時間を算出します（以下公式ドキュメントより抜粋）。
そのため、単純に作成日から指定した日数が経過したら削除したり、クラスを移動したりするわけではありません。この例のように1日経過したら削除とライフサイクル設定した場合は、作成日の次の次の日の午前 00:00 UTCに削除されるという動きをします。
docs.aws.amazon.com
②archive/("ID": "archive-objects")のライフサイクル
10/30に"archive/2020-10-30.txt"というオブジェクトを作成しました。
30日に作成したオブジェクトは31日にS3 Glacierに移動、11月1日0時になって日が変わった時点で削除されます。
s3api head-object を実行して以下のように表示されることを確認します。
expiry-date="Sun, 01 Nov 2020 00:00:00 GMT", rule-id="archive-objects"
③logs/("ID": "short-keep-objects")のライフサイクル
10月30日に"logs/2020-10-30.log"というオブジェクトを作成しました。
10月30日に作成したオブジェクトは211日後の2021年5月30日に削除されます。
s3api head-object を実行して以下のように表示されることを確認します。
expiry-date="Sun, 30 May 2021 00:00:00 GMT", rule-id="short-keep-objects"
動作確認
確認が11月2日になってしまいましたが、tmp/とarchive/は削除されたことを確認できました。
※archive/ のオブジェクトがS3 Glacierに移動したことを確認しそびれました。無念…
logs/は有効期限内のため残っています（あと28日待ってはこのブログを公開するのも遅くなってしまいますので、動作確認まではしません）。
S3ライフサイクル設定の削除
ライフサイクルを削除する場合は、バケット名を指定してs3api delete-bucket-lifecycleを実行します。
エラーが表示されなければOKです。
aws s3api delete-bucket-lifecycle \
--bucket ${S3_BUCKET_NAME}
ライフサイクル設定が無効であることを確認します。
! aws s3api get-bucket-lifecycle-configuration \
--bucket ${S3_BUCKET_NAME}
以下のように表示されればOKです。
An error occurred (NoSuchLifecycleConfiguration) when calling the GetBucketLifecycleConfiguration operation: The lifecycle configuration does not exist
マネジメントコンソール（S3⇒バケット名選択⇒管理⇒ライフサイクルルール）でもライフサイクルが削除されたことが確認できます。
この後はオブジェクトの削除、S3バケットの削除、IAMユーザ周辺の削除を実施します（手順は割愛します）。
最後に
今回、動作確認の中でS3 Glacierに移動したことを確認できなかったのが心残りです。いったんブログを公開しますが、別途確認したいです。ただ、ライフサイクルの動作確認を実業務でやることになったら、その点を注意しなければならないことを知れて良かったです。実作業で確認漏れしていたら一からやり直しですしね…実際に手を動かして体感することの重要さを改めて思い知りました。
前回のバージョニングも今回のライフサイクルも、S3を適切に運用する上で理解しておくべきことだと思いました。認定試験の勉強で触れて理解したつもりでしたが、使わないと本当に忘れますね。復習できてよかったです！S3以外のサービスも適切な設計や運用を考えられるようになるためにも、できる限りサービスが持っている機能を手を動かして理解した上で使いたいと思いました。
次回もS3を使ったハンズオンで、通知とLambdaの自動実行といった実運用でも良く使いそうなハンズオンなので楽しみです。自分ができることを増やしていきたいです。
※次回のイベントページ
jawsug-cli.connpass.com
