🔰

ベンチャー企業でのSRE活動を振り返る(後編)

はじめに

フェズアドベントカレンダー16日目の記事となります。
フェズでSREをしている三井です
この記事は ベンチャー企業でのSRE活動を振り返る(前編) の続きとなっています
2021年7月にフェズに入社して、SREとしてどんな事をやってきたのがちょっとしたTipsと共に振り返りつつご紹介しようと思います
 

プロダクト開発と共通化

前編でご紹介したようなデータ基盤の整備がそれなりに終わった頃、データを利用したプロダクトの開発が活発化してきました
それまでPoC的な位置づけのプロダクトが本格的にローンチを迎えたり、複数の新規プロダクトの開発が始まりました
※全てではないですが、フェズのプロダクトについては こちら の記事で紹介しているのでご興味のある方は覗いてみてください
元々インフラエンジニアをやっていた事もあり、基本的にクラウドの設計や構築は私が担当しました
そして、やはり複数プロダクトの運用をすると共通化をしたくなるのが世の常です

Opsコードの共通化

開発されたプロダクトは勿論それぞれで機能が異なりますが、クラウドの設計や運用に関しては似た部分が多くあります
フェズでは、クラウドはGoogle Cloudで構築されている事が多く、IaCにはTerraformを利用しています
他にも、CI/CDのワークフローはGithub Actions、モニタリングはDatadog、といった感じです
このあたりを共通コード化して各リポジトリから利用できるようにする事で、構築速度とメンテナンス性の向上が期待できます
Github ActionsとTerraformの例を簡単に紹介します

Github Actions

Github Actions には各Providerが公式に用意してくれている便利なアクションがあります
※例えばGoogle Cloud関連のものは こちら
ただ、中にはこれらを組み合わせたり独自のアクションを作りたいケースもあります
アクション自体はコードを書いて集約用のリポジトリにPushすればOKなのですが、問題はそれを各リポジトリからどうやって利用するかです
marketplace にアクションを登録すれば利用できそうですが、、、
marketplaceへの登録や更新の手間を省いて、社内privateリポジトリに閉じた形で共通アクションを利用したい。。。
ということで、以下のような形にしてみました
やってる事はシンプルで
actions/checkout を使ってアクションを管理しているリポジトリをチェックアウトして実行しているだけです
1点注意が必要なのは、実行中のリポジトリ以外のprivateリポジトリを実行するには Personal Access Token の指定が必要です
Tokenの発行が不要な を使いたいところですが、こちらは権限が足りずチェックアウトができません
※詳しくは公式ドキュメントをご参照ください

Terraform

Terraformにはmoduleといって、複数のリソースをまとめてテンプレートのように管理できる仕組みがあります
こちらも 公式や各providerが公開しているもの がありますが、独自のmoduleを作成したいケースがあります
ということで、privateリポジトリに閉じた形で複数リポジトリから利用できるようにしてみました
※この方法は 公式 にも書いてます
作業者のローカルPCから実行する場合は、該当のリポジトリをCheckoutする事ができればこれで実行できます
フェズでは、Github ActionsからTerraformを実行しているケースがあるのですが
その場合はGithub Actionsと同様に Personal Access Token を指定してチェックアウトのURLを置換する事で実行が可能です

クラウドのセキュリティ

プロダクトが並行して開発されていく中で、やはり気になるのはセキュリティです
フェズのようなベンチャーでは人的リソースに限りがあり、それぞれのプロダクトにセキュリティ担当を貼り付ける事は難しいです
かと言って、専門知識のない開発チームに完全に任せてしまうとセキュリティに問題のある構成や設計になってしまうリスクがあります
 
そこで、Google Cloud のセキュリティサービスである Security Command Center を導入しました
SCCに関しては以前この開発ブログでも取り上げたので、この記事では詳しくは割愛します
ご興味ある方は是非ご覧いただければと思います 🙇
Security Command Center でガードレールを作る
フェズでSREをしている三井です SREを名乗っていますが、実際はクラウドのアカウント管理やセキュリティ等、開発チームがプロダクトを適正に提供するための基盤を整備する事もミッションとしています 今回は、その中でもフェズのプロダクトにおいてメインで利用しているGoogle Cloudのセキュリティ施策についてご紹介します フェズでは、プロダクトの大部分がGoogle Cloudで稼働しています 特に、BigQueryを中心にしたデータ基盤には顧客からお預かりしたデータが存在しています そこでデータを安全に管理するために、クラウドのセキュリティが担保されている状態を可視化し不適切な設定を検知できる仕組みを検討する事にしました という事で、導入したサービスが Security Command Center (以下、SCC)です Google Cloud 環境をスキャンして、構成ミスや脆弱性などのセキュリティ&リスクを管理してくれるプラットフォームです ※Google Cloud 環境で組織 (Organization) を構成していることが利用の前提条件です 現時点で以下のようなサービスが提供されています (今回は Security Health Analytics を中心の話になります ) 上記の通り、スタンダードは基本無料で利用できるのですが、プレミアムに関しては以下のような記述になっています Security Command Center のプレミアム ティアは、1 年間または複数年の固定料金サブスクリプションでご利用いただけます。 Google Cloud の年間費用またはコミット契約の合計が 1,500 万ドル を超える場合は、利用可能な料金オプションについて営業担当者にお問い合わせください。 Google Cloud の年間費用またはコミット契約の合計額が 未満の場合、 Security Command Center Premium の年間コストは、次のうちの金額が大きい方の

今後について

"リテール産業の新たな常識をつくる" ためにフェズでは様々なプロダクトを開発しローンチしています
そして、その中核を担うのはやはりデータになります
データの信頼性が正しく担保されていない状態では、フェズの全プロダクトの価値が損なわれてしまいます
改めて、 "データの信頼性が担保された状態" がどういうもので、どう実現されるのか?
をデータ基盤チームと協力して突き詰めて行こうと考えています

まとめ

この記事のタイトルを としましたが
そもそもこの記事で紹介したような内容は と呼んでいいのかよく分からない。というのが正直なところです
 
ただ、フェズくらいの組織規模では成熟した組織に比べるといい意味で境界が曖昧になっているので
仕事の幅を狭める事なく自由に挑戦させていただいた1年ちょっとでした
悩む事も無くは無かったですが、総じて という感想です
 
勿論、ここで書いた内容や順番が100%正しかった! と言うつもりはありませんが、この記事がどなたかの参考になれば幸いです