こんにちは、Cloud Support の Rnrn です。今日はアドベントカレンダー11日目、ちょうど折り返し地点ですね🎄今日の記事では、Cloud Storage (以下 GCS) のライフサイクル管理について、まずはその概要を軽く紹介し、その後よくお問い合わせがあるつまづきやすい箇所や新しい機能を見ていきたいと思います。
ライフサイクル管理は設定できる条件の種類など情報量が多く最初は少しとっつきにくいかもしれませんが、一度設定すればあとはほったらかしでも定期的にバケットの中身が整理される大変便利な機能です。ぜひまだ使っていない方もこれを機に触れてみてください！
ライフサイクル管理とは
はじめに、まだライフサイクル管理をお使いでない人のためにざっくりとライフサイクル管理の説明をしたいと思います。すでにライフサイクルがなんたるかをご存じの方はここは飛ばしていただいて問題ありません。
ライフサイクル管理はその名の通り、オブジェクトのライフサイクルを設定する機能です。GCS のオブジェクトは通常、ユーザーがオブジェクトを作成したあとはユーザーが操作するまでそのまま初期のストレージクラスで保存され続けます。全て保存しっぱなしにしていると当然オブジェクト数に応じて料金も上がってくるので、コンスタントにオブジェクトが増え続ける場合はいらないデータを定期的にクリーンアップしたいですよね。でも、不要になったオブジェクトをこまめに自分で消し続けていくのはとても手間がかかります。
そんな時、事前にルールを設定することで、条件を満たしたタイミングでオブジェクトのストレージクラスの変更や削除を実施してくれるのがライフサイクル管理機能です。もしここまで読んで興味が湧いたらぜひ公式ドキュメントでより詳しい情報に目を通してみてください 👀
ストレージクラス変更料金でよくある誤解
ここからは、ライフサイクルの運用にあたって注意しておくと良い点をいくつか解説していきます。ライフサイクル管理のオペレーション内容としてオブジェクトのストレージクラスの変更が設定できますが、クラス変更の料金形態は特にご質問をいただくことが多い箇所です。内容としては簡単なので、以下の太字の部分をしっかりと覚えて帰ってもらえればと思います。
ライフサイクルルールであるオブジェクトのストレージクラスの変更が行われると、１オブジェクトにつき１クラス A オペレーションが発生したことになり、クラス A オペレーション料金が発生します。この時、クラス A オペレーション料金は移動先のストレージクラスを基準に計算されます。
公式料金表 と同じ例になりますが、1000 オブジェクトを Standard Storage から Coldline Storage に変更したとすると、1000 クラス A オペレーションとしてカウントされ、Coldline Storage のクラス A オペレーションレートで課金されます。
この点について、移動前のクラスのレートで料金が発生するという誤解をよく見かけます。特に長期間に渡って使っていて非常に多くのオブジェクトがある GCS バケットにライフサイクル管理を初めて設定したときは、大量のオブジェクトにライフサイクルによるオペレーションが発生することがあります。そうなると料金がどのクラスを基準に発生するかはコストに大きく影響を与えてくるため、ぜひこのポイントはおさえてほしいところです。
早期削除料金でよくある誤解
これは厳密にはライフサイクル管理によるコストというよりはストレージクラスに関連するコストになりますが、GCS には早期削除という概念があります。スタンダード以外のストレージクラスではオブジェクトを最低限 X 日保存しなければならないという制約があり、それに満たない期間でオブジェクトが削除された場合は追加料金が発生するというものです。
ここで誤解が発生しやすいのは以下２点です。
1. 削除のオペレーション以外では早期削除料金は発生しません
例えば最小保存期間が 30 日である Nearline Storage に 5 日前に作成したオブジェクトをライフサイクルで Coldline Storage に変更しても、早期削除料金はかかりません。オブジェクトが削除されていないからです。注意点として、GCS においてオブジェクトは不変であるため、一見削除を伴わないように見える移動・名前変更のオペレーションでも実際にはオブジェクトは一旦削除されて再作成されており、早期削除に該当することがあります。
2.保存期間はすべての場合においてオブジェクトの作成日時から計算されます
これは、途中でストレージクラスの変更が発生しても影響はなく、削除時点で設定されているストレージクラスの最小保存期間とオブジェクト作成日時からの経過時間を照らし合わせて判断されます。また、オブジェクトのバージョニング を有効にしている場合は各バージョンオブジェクトごとにそれぞれの作成日時を起点に計算されます。あくまで非現行バージョンになった日時とは異なることに注意しましょう。
Age条件でよくある誤解
ライフサイクル管理では Age という条件を設定することができます。早期削除料金のところで触れた保存期間の計算と同様に、これはオブジェクトの作成日時から計算されます。
例えばこのルールをコンソールで設定すると、以下のように「オブジェクトが更新されてから N 日以上 (N+ days since object was updated)」という表示が出てきますが、この時オブジェクトの更新とはオブジェクトデータそのものの更新、つまりは作成日時を指しています。なお、コンソールから同名オブジェクトを上書きアップロードした場合も内部的にはオブジェクトが新しく作成されていることになるので作成日時は更新されます。
反対に、ストレージクラスの変更といったメタデータの更新があっても、作成日時には変更がないため Age の計算で使われる最終更新からの日時には影響がないことに留意してください。同様に、ライフサイクルルールを設定した日時もこの計算には関与しないため、古いオブジェクトが多いバケットに Age 条件のルールを設定すると、初回は非常に多くのオブジェクトがオペレーション対象となることがありえます。
これがどんな時に重要になるかというと、例えば作成後 30 日経過した Nearline Storage をオブジェクトを Colidline Storage に移し、その後更に 30 日経過したら Archive Storage に移したいというルールを設定したい時です。上記の通り Age はストレージクラスの変更日時とは関係なく、また 2022 年現在ストレージクラス変更日時から経過した時間を取得できる条件はないため、このルールは Age を用いて「Age 30 日+ で Coldline Storage に変更」「Age 60 日+ でArchive Storageに変更」を設定する必要があります。
最後に、これは早期削除料金での注意点と同じですが、オブジェクトのバージョニング を有効にしている場合は、非現行バージョンになった日時ではなく、各バージョンオブジェクトの作成日時を起点としてそれぞれの Age が計算されます。
自動でいい感じにやってほしいあなたに: Autoclass
最後に、細かい条件にこだわりはないので定期的にストレージクラスをいい感じに変更してくれたらいいのになぁという方に朗報です。2022 年 11 月 8 日に Autoclass という機能が登場しました。なお、現時点では Autoclass はバケットを作成したタイミングのみで設定可能となるため、既存のバケットには適用できません。
Autoclass はオブジェクトの最終アクセス日時を基準に、アクセスされていないオブジェクトを徐々に Nearline → Coldline → Archive に変更していきます。この変更基準は最小保存期間を違反しない期間で設定されているため、Autoclass に管理されているバケットではオブジェクトを削除しても早期削除料金が発生することはありません。手動で削除するにしても、ライフサイクルで削除するにしても早期削除について考える必要がなくなるので気が楽ですね。
公式ドキュメントではどのようなユースケースに適しているかなどより詳しい情報を紹介しているので、利用を検討している方はぜひこちらもご確認ください。また、14日のアドベントカレンダーでも Autoclass について紹介しています！
まとめ
ライフサイクルは少し複雑な部分もありますが、しっかり要点を抑えて運用すると非常に便利な機能です。たくさんのオブジェクトが集積されてから整理をしようとすると、手動でやるのはもちろん、ライフサイクルのルールの検討にあたっても本当にこの条件で消してしまって大丈夫なデータ群だろうかという確認が大変になってしまいます。ですので、今はあまりオブジェクトの数がないバケットでも早めに設定しておくことをおすすめします。もし記事に紹介した以外で疑問点などがあればぜひコメントを残していってくださいね！それでは残りのアドベントカレンダーもどうぞお楽しみに⛄
Discussion