ストレージクラスとライフサイクル｜基礎を学ぶ

このレッスンでは、要件文からS3のストレージクラスを1つに絞り込み、ライフサイクルルールで自動的に移していく設計ができるようになります。

まず要件文から

ある会社が、業務システムのログをS3に置いています。直近30日は障害調査のために毎日読みます。それ以降は監査のために保管するだけで、年に数回、法務からの問い合わせで読むことがあります。1年を過ぎたものは、5年間保管するが、読むとしても数時間待てるとのことです。運用の手間を増やさずに、最も低コストにしたいと言っています。

この文には、クラスを決める材料が全部入っています。SAAで問われるのは耐久性の桁ではなく、この読み取りです。

3つの軸だけで選ぶ

クラスの比較表を丸暗記する必要はありません。次の3つを要件文から拾えば、答えは1つに決まります。

読む頻度 — 毎日か、月に数回か、年に数回か
取り出しを何分待てるか — 即座に要るのか、数分か、数時間でよいのか
アクセス傾向が読めるか — 減っていくと分かっているのか、まったく予測できないのか

要件の読み取り	選ぶクラス
毎日読む。待てない	S3 Standard
読む回数は減るが、読むときは即座に要る	S3 Standard-IA
同上で、消えても再生成できるデータ	S3 One Zone-IA
ほとんど読まないが、読むときはミリ秒で欲しい	S3 Glacier Instant Retrieval
年に数回。数分から数時間待てる	S3 Glacier Flexible Retrieval
法定保管。取り出しは数時間から半日待てる	S3 Glacier Deep Archive
傾向が読めない	S3 Intelligent-Tiering

Intelligent-Tiering はどこで線を引くか

Intelligent-Tiering は「万能な安いクラス」ではありません。アクセス傾向をAWS側が監視して自動で階層を移す仕組みで、そのぶんオブジェクトごとの監視の費用がかかります。

ですから、傾向が読めているなら使いません。 冒頭のシナリオのように「30日で読まなくなる」「1年で保管だけになる」と分かっているなら、ライフサイクルルールで移すほうが安く済みます。Intelligent-Tiering が答えになるのは、要件文に「アクセスパターンが予測できない」「変動する」「不明」と書いてあるときだけです。ここが試験の線引きです。

ライフサイクルルールで自動化する

冒頭のシナリオは、1つのライフサイクルルールで解けます。30日でStandard-IAへ移行し、365日でGlacier Deep Archive へ移行し、保管期間の満了で失効させる、という3段の設定です。「運用の手間を増やさずに」という制約は、バッチスクリプトを書く選択肢ではなくライフサイクルを選べ、という指示だと読みます。

なお、移行の対象は現行バージョンだけでなく、以前のバージョンにも別に設定できます。バージョニングを有効にしたバケットで古いバージョンが積み上がっている、という要件では、旧バージョン向けの移行と失効を設定するのが答えになります。

要件語から構成への対応

要件文の言い回し	構成
アクセスパターンが予測できない	Intelligent-Tiering
30日後はほとんど読まないが、読むときは即座に	Standard-IA へ移行
再生成できるデータのコピー	One Zone-IA
数時間待てる長期保管、7年間	Glacier Deep Archive へ移行
運用の手間を最小に、自動で移したい	ライフサイクルルール
古いバージョンが増え続けている	旧バージョン向けの移行と失効

よくある引っ掛け

1つ目は、小さいファイルを大量にIAへ移す選択肢です。IA系のクラスには最小サイズと最小保管期間の扱いがあるため、短命で小さいオブジェクトを移すと、かえって高くつきます。「1週間で消すログ」をIAへ移す選択肢は落とします。

2つ目は、Deep Archive を即時性のある要件に当てる選択肢です。「監査で参照する」と書いてあっても、その直後に「数分以内に」とあれば Deep Archive は落ちます。取り出し時間の要件語は、保管の目的よりも優先して読みます。

まとめ

読む頻度、待てる時間、傾向が読めるか、の3軸だけでクラスは決まります
Intelligent-Tiering は「予測できない」と書いてあるときだけ選びます
「自動で移す」「運用の手間を増やさず」はライフサイクルルールの合図です
短命で小さいオブジェクトをIA系へ移す選択肢は、逆に高くなるので落とします
取り出し時間の要件語は、保管目的の言葉より優先して読みます