はじめに

はじめまして、テクノロジー戦略本部で内定者インターンをしている馬場です。現在、EC管理システムの開発に携わっています。

今回、EC管理システムのGoogle Cloud Storage(GCS)で管理しているオブジェクトのライフサイクルの設定を、要件定義から開発まで一貫して行いました。

その過程で経験した事業部の方へのヒアリングや、要件を満たすために試行錯誤する中で学んだことについて紹介します。

はじめに
背景
実施したこと
- GCSバケットを整理
- ライフサイクルの設定
結果
タスクを通して学んだこと
まとめ

背景

現在開発中のプロダクトではGCSを用いて様々な用途や保持期間のオブジェクトを管理しています。その中で以下の2つの課題がありました。

課題
- 1つのバケットに用途や保持期間の違うオブジェクトを一括で保持してしまっていた
- 不要になったオブジェクトが蓄積され続けていた

上記を解決するために、バケットの整理とライフサイクルの設定することになりました。

ライフサイクルとは、オブジェクト作成後の経過日数などの様々な条件を指定して、自動で削除等の操作ができる機能です。

GCSではバケット毎にしかライフサイクルを設定できません。

そのため、ライフサイクルを意識しつつ、オブジェクトのアクセス権限や用途、保持期間によって必要なバケットを分けました。

そして、それぞれのバケットに適切なライフサイクルの設定をしました。

最後に、各オブジェクトを適切なバケットに保存することで、不要なデータの蓄積を防ぐこととなりました。

実施したこと

GCSバケットを整理

バケットの整理をするにあたって、アクセス権限やライフサイクル設定を踏まえてバケットを分ける方針にしました。

まず、保存オブジェクトの種類・用途・アクセス頻度などを把握するため、チームのエンジニアの方や事業部の方にヒアリング行いました。

ヒアリング結果を踏まえ、３つのバケットを作成しました。

ライフサイクルの設定

ライフサイクルとは

GCSではライフサイクルを設定することで、オブジェクト作成後の経過日数などの様々な条件から、自動的にストレージクラスを変更したり、削除などの操作ができます。

バケット毎に設定が可能で、バケット内のオブジェクト全てにライフサイクルが適用されます。

参考
- オブジェクトライフサイクル管理
- Cloud Storage(GCS)を徹底解説 - G-gen Tech Blog(ライフサイクルマネジメント)

設定したライフサイクル

今回ライフサイクルはそれぞれ以下のように設定しました。

バケット1：30日毎にストレージクラスを下げていく。

理由
- オブジェクトは半永久的に保持する必要がある
- オブジェクト作成後、直近1ヶ月はアクセス頻度が高い
- オブジェクト作成後は、日数が経つにつれアクセス頻度は低いことが予想される

バケット2：1日経過後に削除する。

理由
- オブジェクトの作成後、一度使用したら再度使用することがない

バケット3：なし。

理由
- オブジェクトは半永久的に保持する必要がある
- オブジェクトへのアクセス頻度が常に高い

Terraformの設定コード

今回決定したライフサイクルは、Terraformを用いてGCSに反映させました。

Terraform（テラフォーム）とは、インフラ構築をコードで管理できるインフラ構成管理ツールです。

適用したコードは以下のようになりました。

参考
- Terraformドキュメント(GCS)

バケット1：30日毎にストレージクラスを下げていく。

resource "google_storage_bucket" "bucket1" {

    # 略

    lifecycle_rule {
        condition {
            age = 30
            matches_storage_class = ["STANDARD"]
        }
        action {
            type          = "SetStorageClass"
            storage_class = "NEARLINE"
        }
    }
    lifecycle_rule {
        condition {
            age = 30
            matches_storage_class = ["NEARLINE"]
        }
        action {
            type          = "SetStorageClass"
            storage_class = "COLDLINE"
        }
    }
    lifecycle_rule {
        condition {
            age = 30
            matches_storage_class = ["COLDLINE"]
        }
        action {
            type          = "SetStorageClass"
            storage_class = "ARCHIVE"
        }
    }
}

バケット2：1日経過後に削除する。

resource "google_storage_bucket" "bucket2" {

    # 略

    lifecycle_rule {
        condition {
            age = 1
        }
        action {
            type = "Delete"
        }
    }
}

以下に今回使用した操作・条件をまとめました。

ライフサイクルの操作

Delete
- オブジェクトの削除
SetStorageClass
- オブジェクトのストレージクラスの変更
- ストレージクラスの変更は、最小保存期間が大きいものへの変更しかできない

ストレージクラス

ストレージクラスは各オブジェクト固有のメタデータです。

オブジェクト固有であるため、オブジェクト毎にストレージクラスの設定が可能です（バケット毎に統一しなくて良い）。

また、バケットのデフォルトストレージクラスはStandardクラスです。バケットのデフォルトストレージクラスの変更も可能です。

アクセス頻度の目安を参考に、オブジェクトに適切なストレージクラスを設定することで、保存コストを抑えることが出来ます。

ストレージクラス	Standard	Nearline	Coldline	Archive
保存コスト	高い			低い
アクセスコスト	低い			高い
最小保存期間	なし	30日	90日	365日
アクセス頻度目安	頻繁、短期保存	月一	四半期に一	年一

最小保存期間とは

ライフサイクルの条件

今回使用したライフサイクルの操作の発火条件は以下の2点です。

Age
- 作成日時からの日数
MatchesStorageClass
- 指定したストレージクラスと一致

結果

今回バケット整理をしたことで、保存するオブジェクトの性質に応じて適切に管理を行うことができるようになりました。

また、現在開発中のプロダクトでは、ライフサイクルによって開発の過程で作成されるオブジェクトの蓄積を防ぐこと、保存コストを抑えることができました。

今後の開発・リリースに向けて、バケット整理とライフサイクルの設定がさらに活きてくると思います。

タスクを通して学んだこと

今回、要件定義から開発までの一通りの経験から、タスクの進め方や事業部側の方とのコミュニケーションでは以下の3つのことが大切であると学びました。

課題や目的などのゴールから逆算し、足りない情報を明確にすること
根本の課題や目的を見失わないこと
技術的な話は必要なことだけ噛み砕いて分かりやすくすること

課題や目的などのゴールから逆算し、足りない情報を明確にすること

タスクに着手してすぐの段階で、まずライフサイクルの条件・操作などを調査しました。事業部側の方とのミーティングで調査結果や設定例を共有し、「どんなライフサイクルの設定がいいでしょうか？」と自分の意見や提案をせず投げてしまいました。

これでは、事業部側の方の負荷が増えてしまいます。何より、何も意見などを踏まえずに提案をすることは、自分の自律性や成長には繋がっていかないです。

課題を技術で解決するために、どのような情報が足りないかを考えた上で、ヒアリングを通じて引き出すべきでした。

そのため、現状の課題や要件から何の情報が足りていないのかを整理しました。また、どのような条件で削除・ストレージクラスの変更などの操作を行うべきかの予想を立て、事業部側の方にヒアリングを行いました。

根本の課題や目的を見失わないこと

事業部側の方とのコミュニケーションでは、解決したい課題や目的を見失わないことが重要です。エンジニアは、ヒアリングで相手のニーズや意図を探ります。その上で、エンジニア視点の意見や提案ができるよう、知識を組み合わせて柔軟に考えることが大切だと感じました。

技術的な話は必要なことだけ噛み砕いて分かりやすくすること

エンジニアと事業部側の人では専門領域や前提知識が違い、技術的なことを伝えるのは難しいです。しかし、技術的な話が必要な場面もあり、分かりやすく要点だけを噛み砕いて説明しなくてはいけないです。本当に必要な技術的な話以外は、混乱する原因にもなるので見極めが大事だと感じました。

ヒアリング結果を踏まえて要件を満たすライフサイクルを考え、以下のように設定しました。

まとめ

インターンの内にインフラを業務レベルで触れられたこと、事業部側の方との要件定義から関われたことで多くの学びや成長を感じることができました。インターンという立場ですが、重要なタスクを任せて頂き、期待に応えられるよう責任感を持ってやり切りました。肩書きに関係無くチャンスをいただける会社だと改めて感じました。

最後に、Buysell Technologiesではエンジニアを募集しています。興味がある方はぜひご応募ください！

＜24新卒＞【テクノロジー戦略本部】フルスタックに成長したい方を募集しています！