「まだまだ検証と学習のサイクルが遅い」—継続的デリバリーを支えるSREの挑戦【食べチョク開発者のこだわり】 #1

1日1回以上のリリースを続けるビビッドガーデンのプロダクトチーム。しかし「プロダクトの成長のために、SREとしてやるべきことが有り余っている」とSRE/分析の鈴木は語ります。

「食べチョク開発者のこだわり」と題して、今回は1年前と比べて流通額43倍&ユーザー数50万人突破と様変わりし続けたプロダクトについて、SREの目線でふりかえりと今後の挑戦について語ってもらいました。
（インタビュー/撮影: 平野）

鈴木 康文(SRE/分析)
新卒で株式会社エウレカにて、カップル向けアプリの開発を経験した後にマッチングアプリのバックエンド開発に従事。ITベンチャーへ転職し広告配信システムの構築に携わる。2020年7月に入社。

「教科書通りな構成」の0→1フェーズ

ーまずは、インフラの現状について伺います。いつ頃から、どのようにビビッドガーデンのインフラに関わることになったのですか？

入社して2〜3ヶ月経ったころからです。前職のDMMでもインフラを担当していたのでビビッドガーデンでもやりたいなと思ってはいましたが、当初はweb開発側の人数の都合などもあり様子を見ていました。

環境に慣れていくにつれ、元々の「インフラやりたい」という思いもありましたが、それよりも「インフラを担当していた西尾さん（リードエンジニア）の仕事を奪ったほうが組織として全体最適になるのでは」という思いが徐々に強くなりました。
そこからインフラに携わるようになり、今に至ります。

ービビッドガーデンのインフラの内情をあまり知らない状況から入社して、第一印象はいかがでしたか？ギャップなどはありましたか？

ECのインフラはあまり触ったことがなかったのですが、それほどギャップはありませんでした。スケーリングなどの部分が何もない、素のEC2が立っているだけ、といった状況は事前に想定していたので、「うん、こんな感じだよね」というか。

ーギャップは少なかったんですね。今のインフラの構成って、一言で表すとどんな感じになりますか？

「最小限で、教科書通りな構成」ですかね。
今のビビッドガーデンのフェーズを鑑みると、このシンプルな構成はいいと思います。

新しいものをどんどん試した結果、サーバーレスだなんだと複雑化して結局メンテ工数がかさむというのはよく聞く話です。
新しいものを試すチャレンジは自分自身も好きですし、明確な理由があれば全然いいと思うのですが、あくまでプロダクトを前に進めるという現フェーズではあまり複雑に絡み合っていない方がいいのかなと思います。

非連続的な成長のためにSREとしてすべきこと

ーここまで、現状の構成は非常にシンプルであるという話を聞きました。それでは、現状の構成のままだと今後直面しそうな課題はありますか？

例えばユーザー数の増加などに伴うトラフィックについては、スケールアウトすれば現状の構成で問題になることはないと思っています。ですが直近テレビで取り上げていただくことやメルマガ・通知の反響がとても良いこともあり、一時的に爆発的なトラフィックが発生することが増えてきています。それに対応するためのオートスケール等ができていないのが現状で、そこは運用上解決すべき課題だと認識しています。

それ以上に課題に感じているのはデリバリーのスピードですね。現状は食べチョクに関連する複数のコンポーネントが1つのコードベースで管理されていることもあり、場合によってはデプロイが他に引っ張られたり、待ちになるケースがあります。デリバリーする人が増えていくとそこはさらにボトルネックになりそうなので、うまく解決できるように考えているところです。

上記のような課題を元に、改めて構成と運用を再検討しなければなりません。

ーデリバリースピードを上げなければいけない理由は何ですか？

スタートアップとして非連続的に成長するために、プロダクトの改修スピードを上げていきたいからというのが一番の理由です。
トライそのものを増やして高速で仮説検証を回していきたいけれど、そのための土台が整っているとは言い難い状況なので、インフラがボトルネックにならないように改善していかなきゃいけないです。

Whyは明確、Howの質と実現するスピードを上げたい

ーインフラにおいて、直近で取り組もうと考えているものは何ですか？

まず、何か新しいことを始めるより先に優先して取り組まなければいけないのが現状を把握するための「構成のコード化」です。
ビビッドガーデンではAWSでアプリケーションを建てているのですが、構成がコード化されていないので現状どうなっているかはAWSに入らないとわからない。ナレッジを蓄積させるためにもまずはこの整理を進めて、全員が理解できるような状況を目指したいです。3Q（2021/5〜7）の最初のテーマですね。

ーまずは基盤作りということですね。その次のフェーズで取り組みたいことはありますか？

上記が最優先で、その後にデリバリースピード向上のためにEC2に立てているアプリケーションサーバーの構成をECSに持っていき、その上でデプロイパイプラインの整備とリリースの自動化をしていきたいです。
それ以外にもデータの処理基盤やダッシュボードの基盤をGCP内のCloud Pub/SubやCloud Dataflowなどを使って作っていきたい、セキュリティリスクへの対策もしていきたいなどもあります。

ーかなり沢山やりたいことがあるかとは思いますが、どれくらいのスピード感で進めていきたいですか？

まずはissue化・細分化を行った上で、これまで話したところは3Q（2021/5〜7）に終わらせたいなと思っています。となると、時間と人手が十分足りているわけではないので、チャレンジングな目標設定ではあります。

一緒に働きたいと思う人

ー人手が足りてない部分がある中で、スキル的にはどのような人と一緒に働きたいですか？

そうですね、今一番来てほしいなと思うのは課題解決のために一緒に手を動かしてくれる方です。"インフラを見る"という業務に閉じず、"プロダクトに信頼性と安定性をもたらす"というsite reliabilityな観点で、なんでもやるという気概があると非常に心強いと思っています。

一方でプロダクトを大きくするために構成を進化させる必要はあるので、もう1段上流からブレインとなってくれるような「とにかく強い」方がいてくれると心強いです。その文脈では、分析基盤やセキュリティにも明るい人だとさらなるです。

ー世の中の「インフラエンジニア」の中にはアプリケーションとちょっと離れているような人/業務もいるような気がしていますが、ビビッドガーデンはそこが結構近いように感じます。実際のところどうですか？

個人的な意見ではありますが「アプリケーションを理解した上でインフラを触って欲しい」と思います。

現状は"食べチョク"というプロダクトの開発に集中している会社なので、そこからいわゆる"インフラ業務"だけを切り離すことは難しいです。
「インフラの構成だけを考える」というマインドではなくアプリのことも理解していてほしい。これはソースコードの中身云々という話ではなくRailsのアプリケーションの特性やログをベースに構成を考えてほしいということですね。

ー最後に、スキル的なところだけでなくキャラクター的なところで「こんな人と働きたい」などはありますか？また、ビビッドガーデンでSREとして働くメリットを教えてください。

何よりも、めげない方。

SREならわかると思うのですが、インフラって本当にわけのわからない不具合・エラーで何時間も取られることがあります。アプリケーションも同じかとは思いますが、アプリケーションよりもログがよりわかりづらいと思うので、それらに対して最後まで一緒に責任を持って投げ出さずにやっていける方とぜひ一緒に働きたいです。

ビビッドガーデンのインフラは裁量が大きく、自分が思い描く構成を実現することができます。「食べチョク」は引き続き伸びる、伸ばしていかなければならないプロダクトなので、その中でSREができるのはシンプルにラッキーなことかと思います。
上がっていくトラフィックの中でSREとして可用性を担保する構成を考えて、「絶対に落ちない」堅牢なサービスを作っていけるのは、キャリアにおいてもメリットがあると思っています。

ーありがとうございました！

採用情報

株式会社ビビッドガーデンでは、現在SREを絶賛募集しています。堅牢かつ継続的なデリバリーを支えるインフラ構成を一緒に作りましょう！

気になった方は是非Wantedlyや採用担当 / エンジニアの平野のTwitter DMなどからご連絡ください！

年間40倍以上の事業成長を支える食べチョク開発組織のほとんどをお話します