STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

インフラ Sandbox という好きに「遊べる」環境をつくった話。 #STORESアドカレ

こんにちは、STORES 株式会社 CTO 室の id:hogelog です。12月、師走ですね。あれやこれやとまだ先だから大丈夫だろう、と軽い気持ちで放り込んだ仕事がたくさん集まってくるという毎年恒例の行事をしております。

インフラ Sandbox 環境をつくりました。

STORES ではサービスを提供するインフラとして AWSGCP などの IaaS を利用しています。 さて AWS と言えば 2022/12/01 現在 AWS re:Invent 2022 開催真っ最中ですね。AWS と言えば SQS, S3, EC2 だった時代も今は昔、新機能や新サービスがこれでもかというぐらいリリースされ続けています。すべてを完全に理解しようと思うと人間の限界を超えなければいけません。もちろん GCP も負けず劣らず膨大な量のサービスを抱えています。

そんな AWSGCP を用いて効率的にシステムを構築、運用するには AWSGCP を深く理解している必要があります。よくわかっている機能・サービスを使ってシステムを構築するときはさほど迷わないかもしれません。一方でよくわからない機能・サービスについてはある程度検証などをして理解する過程が必要です。

しかしプロダクトのシステムを動かしている本番の AWSGCP 環境に検証用の各種リソースを作ってしまうのは管理が若干面倒になります。検証用で作成したリソースや、連動して作成されたリソースなどを削除するのにも「いま本番稼働しているリソースに関係ないか」など確認に苦労しがちです。

また権限管理的にもエンジニア全員に本番環境でなんでもできるような権限を付与したくはありません。もちろん必要に応じて適宜検証のために権限を付与したり、IaC されたコードに Pull Request を投げるなどのことも可能です。しかし本格的な業務として取り組み始める前、業務で使うとは限らないような技術検証にそういったコミュニケーションや調整をするのは面倒です。

そこで STORES では所属エンジニア全員が好きに技術検証できるインフラ Sandbox 環境を構築しています。

Sandbox 環境のルール。

Sandbox 環境は以下のようないくつかのルールを決めています。

  • 検証作業の終わったリソースは削除すること
  • 時々 Sandbox 環境がリセットされても許容する
  • アクセス制限なしでインターネットにアプリケーションを公開しない
  • 本番環境との接続をしない

このようなルールはありますが、基本的にはそれ以外特に制限せず各位好きに使ってもらっています。利用用途もプロダクトの技術検証などに縛ってもいません。技術検証と遊びの境目は曖昧です。あたらしい技術は検証するという選択肢に上げることも難しいため、普段から積極的に遊んでもらうことを期待して環境を用意しています。

現在 Sandbox 環境としては AWSGCP、Cloudflare を用意しています。社内で利用があったり今後利用が増えていきそうなプラットフォームについて、社内調整などの手間をかけずに使える Sandbox 環境は今後も増やしていきたいと考えています。

使われています。

今年の7月ごろに構築してから、各種プロダクトの本格開発前の技術検証や遊びのために Sandbox 環境が利用されています。先日 Product Blog で紹介した Google Speech to Text を利用した文字起こしもこちらの Sandbox 環境を用いて検証されたものです。

product.st.inc

他さまざまな用途で特に大きな問題もなく利用されています。

STORES ではエンジニアに技術的挑戦を楽しめる人を求めています。

STORES エンジニアのメイン業務は STORES プロダクトの開発です。一方で STORES プロダクトを開発する中でも難しい課題はしばしば発生します。そんなときに正面から問題に向き合い課題を解決するためにも、技術の深堀りを楽しむ人を広く募集しています。

jobs.st.inc

なおこのブログ記事は STORES アドベントカレンダー1日目のエントリとして書かれました。12月は連日ブログ投稿されるので、引き続き STORES アドベントカレンダーをお楽しみください。

おしまい。