【GCS】なんでもかんでも突っ込んじゃえ。ライフサイクルの魅力とは
えっこんなファイルも、あんなファイルも!!
そう、Google Cloud Storage に保存すれば、よしなに解決してくれます。
こんにちは。
クラウドソリューショングループ新人のokawa.mです。
今回はGoogle Cloud Storage(以降GCS)のライフサイクルについて書かせて頂きます。
GCSとは
Google Cloud Platform(GCP)が提供しているオンラインストレージサービスです。
GCSは個人でもよく利用させて頂いているサービスです。いつもお世話になっております。
用語の確認
GCSを利用する為には用語の理解をする必要があります。
- バケット
- データを格納するコンテナ
- 地理的なロケーションや、ストレージクラスの設定が可能
- オブジェクト
- GCSに保存する個々のデータ
- ストレージクラスの設定が可能
ストレージクラス
Cloud Storage には、Multi-Regional Storage、Regional Storage、Nearline Storage、Coldline Storage の 4 つのストレージ クラスがあります。
ストレージクラスは何も考えずに決めてしまうと、余計にお金がかかってしまうので注意です。
ストレージ クラス | 使用例 | 料金(GB あたり/月)* |
---|---|---|
Multi-Regional Storage | 世界中から頻繁にアクセスされるデータの保存 | $0.026 |
Regional Storage | 日本(特定の地域)から頻繁にアクセスされるデータの保存 | $0.020 |
Nearline Storage | 頻繁にアクセスすることが予想されないデータ(月に 1 回程度)の保存 | $0.010 |
Coldline Storage | 頻繁にアクセスすることが予想されないデータ(年に 1 回程度)の保存 | $0.007 |
ストレージクラスの詳細につきましては、公式ページをご確認くださいませ。
ライフサイクル
オブジェクトの有効期間の設定、古いバージョンのアーカイブ、コスト管理を用意するためにのストレージクラスのダウングレードなど、一般的な作業をサポートするために提供されています。
ライフサイクルは、バケット毎にライフサイクルの設定が可能です。
ライフサイクルで出来ること
例えば、以下のような設定ができまます。
- 1年以上経過したオブジェクトのストレージクラスをダウングレード
- 2013/1/1より前に作成されたオブジェクトの削除
- バージョニングが有効になっているバケット内の各オブジェクトを最新のバージョン3つの維持
ライフサイクルには条件が5種類あり、条件に応じた操作が2種類あります。
この条件と操作の組み合わせでライフサイクルを管理します。
以下詳細となります。
ライフサイクルの条件
- Age(年齢)
- 経過期間が期間以上のすべてのオブジェクトに適用
- CreatedBefore(作成日)
- 日付(UTC)以前に作成されたすべてのオブジェクトに適用
- IsLive(ライブ状態)
- バージョニングされたオブジェクトのみに適用
- MatchesStorageClass(ストレージクラス)
- 選択したストレージクラスのいずれかを含むすべてのオブジェクトに適用
- NumberOfNewVersions(新しいバージョン)
- バージョニングされたオブジェクトのみに適用
- 新しいバージョンがN個以上存在すると、オブジェクト条件が一致
ライフサイクルの操作
- Delete(削除)
- オブジェクトの削除
- SetStorageClass
- オブジェクトのストレージクラスの変更
使用例
私は個人的なレガシーサーバのログや、バックアップファイルはほとんど
GCSに保存するよう設定しています。
以下にレガシーサーバのファイルをGCSに保存、一定期間後削除する例を紹介します。
流れとしては以下の通りです。
- gcloudコマンドをインストール
- gcloud init(認証)
- バケットの作成
- 作成したバケットにライフサイクルを設定
- バケットにファイルをアップロード
- アップロードを自動化
1. gcloudコマンドをインストール
サーバにgcloudコマンドをインストールします。
gcloudコマンドのインストール方法はプラットフォームごとに違うので、公式ページを参照してください。
https://cloud.google.com/sdk/docs/#deb
2. gcloud init(認証)
以下のコマンドで、認証を行います。
gcloud init
3. バケットの作成
GCPの管理画面から作成可能ですが、今回はコマンドを使用した設定例を紹介します。
GCSの操作を行うにはgsutilコマンドを使用します。
gsutilコマンドはgcloudコマンドをインストールした際に一緒にインストールされています。
以下のコマンドでバケットの作成を行います。
# ストレージクラス: regional # ロケーション: asia-east1 gsutil mb -c regional -l asia-east1 gs://{設定対象のGCSバケット名}
4. 作成したバケットにライフサイクルを設定
こちらもGCPの管理画面から設定可能となります。
gsutilコマンドを使用する場合は、ライフサイクルの設定を記述したJSONファイルを作成します。
JSONファイルは以下のように記述可能です。
{ "lifecycle": { "rule": [ { "action": { "type": string(), "storageClass": string }, "condition": { "age": integer, "createdBefore": date, "isLive": boolean, "matchesStorageClass": [ string ], "numNewerVersions": integer } } ] } }
https://cloud.google.com/storage/docs/json_api/v1/buckets#resource-representations
今回は1日経過したファイルを削除するライフサイクルの設定例を記述します。
{ "lifecycle": { "rule": [ { "action": { "type": "Delete" }, "condition": { "age": 1 } } ] } }
以下設定を行うコマンドです。
gsutil lifecycle set lifecycle.json gs://{設定対象のGCSバケット名}
また、設定の確認は以下のコマンドを使用します。
gsutil lifecycle get gs://{設定対象のGCSバケット名}
今回の例だと以下がレスポンスされます。
{"rule": [{"action": {"type": "Delete"}, "condition": {"age": 1}}]}
* ライフサイクルの設定は反映されるまで、最大24時間かかります。
5. バケットにファイルをアップロード
以下のコマンドでアップロードが可能です。
gsutil cp ファイル名 gs://{設定対象のGCSバケット名}
ライフサイクルが設定されていれば、アップロードしてから、1日で削除されているはずです。
6. アップロードの自動化
毎回手動でアップロードをするのは大変です。
以下にcronを使用し、自動化する例を紹介します。
# cronの設定がある場合 # crontabのバックアップを作成 crontab -l > /tmp/crontab.backup # cronの設定がない場合 touch /tmp/crontab.backup # 毎朝5:00に自動でGCSにアップロードする設定をバックアップに記述 # ファイル名は自動的に探すのが一般的 # {ファイル名}: `ls -1t {バックアップファイルのみ存在するディレクトリ}/ | head -n 1` など echo "0 5 * * * gsutil cp {ファイル名} gs://{設定したバケット名}" >> /tmp/crontab.backup # バックアップから設定を上書き cat /tmp/crontab.backup | crontab
おわりに
GCSのライフサイクルはあまり目立ってないですが、かなり便利です。
皆さまにライフサイクルの魅力が伝わったのなら幸いです。