本記事は Platform Engineering Advent Calendar 2023 の 25 日目の記事です。
はじめに
本記事ではナレッジワークというスタートアップの Platform Engineering について簡単に紹介します。まだまだこれから始めるという段階であり Platform Engineering が必要な背景と何をしようとしているかをお伝えします。
ナレッジワークとは
ナレッジワークは「できる喜びが巡る日々を届ける」をミッションに掲げてセールスイネーブルメントの SaaS を提供するスタートアップです。2023 年の 11 月にシリーズBで45億円の資金調達を実施して今後 3 年で 10 個の新プロダクトの開発・提供を予定しています。
Platform Group
筆者はナレッジワークの Platform Group というチームで Software Engineer をやっています。ナレッジワークでは 2023 年に Platform Engineering を行うために Platform Group というチームを立ち上げました。現在 Platform Group は大きく分けて 3 つのミッションを持っています。以下にそれぞれの目的と背景を説明します。
Platform Engineering
1 つ目は Platform Engineering で、開発者の認知負荷を下げて開発生産性や開発者体験を向上させることが目的です。ナレッジワークではこれまでワンチームで 1 つのプロダクトを開発・運用してきました。ところが、今年でプロダクトは 2 つになり、今後さらに 10 以上になります。今までは 1 つのプロダクトに対して必要なコードやツールを必要なときに積み重ねてきましたが、新しいチームやプロダクトでもそれを繰り返すことは冗長なコストになり得ます。また、今後のプロダクトはより素早く効率的な立ち上がりが求められます。マルチプロダクトの開発を進めていくために、冗長な部分の共通化や自動化、抽象化を適切に行ってチームやプロダクトを素早く効率的に立ち上げるためのプラットフォームを開発する必要がでてきました。
(ツールチェインは一部を掲載しています。要素の位置もかなり適当です)
ミドルウェア開発
2 つ目はミドルウェア開発で、複数のプロダクトが掛け合わせで顧客価値を提供できるようなプロダクト基盤を提供することが目的です。また、それをプロダクト共通基盤として新規プロダクト立ち上げの高速化・効率化も目的としています。今後ナレッジワークでは 10 以上のプロダクトを開発しますが、それぞれのプロダクトが個々で価値を生むだけではなくお客様が複数のプロダクトを利用したときの価値が掛け算となるようなプロダクト群にしたいと考えています。このようなスタートアップ戦略をコンパウンド戦略といいますが、コンパウンド戦略ではそのようなプロダクト群を支えるための基盤をミドルウェアと言います。ナレッジワークでは 10 以上のプロダクトを掛け合わせてより高い顧客価値を生むためにミドルウェアの開発を始めています。また、複数のプロダクトで共通して使えるようなミドルウェアを社内の開発チームに API や SDK として提供することでプロダクト立ち上げの高速化・効率化も狙っています。ナレッジワークではミドルウェア開発を広義の Platform Engineering と捉えています。
Site Reliability Engineering
3 つ目は SRE で、プロダクトの最も基本的な機能である信頼性を提供することが目的です。Platform Engineering とは異なる Engineering として扱われることが多く、ナレッジワークでも別物として捉えています。現在は組織規模も小さく、扱う手段や技術が重なることも多いので同じチームで総合的に優先度をつけて取り組んでいます。
SRE については本記事では一部を除き割愛します。
Principles of Product-centric Platform
ナレッジワークはプロダクトセントリックカンパニーとしてプロダクトづくりを会社運営の中心においています。Platform Group でもプロダクトセントリックなプラットフォームをつくるために Principles of Product-centric Platform という原則を定めて、上述したミッションを遂行する指針としています。
Autonomy for Teams 「チームに自治を」 開発チームが自分たちの最高速度・最高品質でプロダクトを開発・運用できるように、各チームが裁量を持って自律的に活動できるプラットフォームを目指す。
Beneficial Platform 「プラットフォームで価値を」 独りよがりで使いにくいプラットフォームや誰も使わないプラットフォームではなく、しっかりと顧客価値を生むために使われるプラットフォームを目指す。
Compound Products 「プロダクトに複利を」 複数のプロダクトを効率よく開発・運用できるだけではなく、ミドルウェアを中心としてプロダクトが相互に価値を高め合うようなプラットフォームを目指す。
現状とこれから
ナレッジワークはざっくり次のような技術スタックで構築されています。
- バックエンド、フロントエンドどちらもモノリス
- gRPC / Connect でスキーマ駆動
- Next.js による SPA と、Go による API
- インフラはほぼ Google Cloud でコンテナ・サーバーレス中心
- GitHub でモノレポ
一見シンプルに見える技術スタックですが、マルチプロダクトを見据えると様々な課題が見えてきています。本記事では課題の一部とその課題にどう取り組んでいこうとしているかを紹介します。
プロダクト分割
現在はモノリスを中心としたアーキテクチャを採用しており、複数のチームが同じコードベースの上で開発しています。マルチプロダクト化を見据えてモジュラーモノリス化されているため各チームにモジュールという単位での自治はあります。しかしチームやプロダクトごとに開発サイクルやデプロイサイクル、開発言語を変えたり、性質の異なるワークロードを扱ったりすることは困難です。
今後は各チームが自律して開発・運用できるようにそれぞれのコードベースを持ち、アプリケーションを持ち、デリバリーと運用ができるようなアーキテクチャに移行します。
バックエンドはモノリスを分割して複数のサービスが自律的に動作し、ネットワーク API で機能を提供するミニサービスとしていきます。フロントエンドは引き続き Next.js を利用しつつ垂直分割ミニフロントエンドの採用を検討しています。
本記事ではミニサービスやミニフロントエンドと表現しましたが、一般的なアーキテクチャの名前としてはマイクロサービスやマイクロフロントエンドと呼ばれます。ナレッジワークではこれらの言葉は誤解を招くことも多いので使わないようにしていて、これまでの運用経験をもとにマイクロ過ぎず、適切にマルチプロダクトを開発・運用できるようなサービス分割とアーキテクチャを目指しています。
UI コンポーネント
現在はナレッジワークプロダクトで一貫した UI を実現するために、アプリケーションとレイヤーを分けて UI コンポーネントを実装しています。しかし UI コンポーネントはフロントエンドのモノリスの中に存在しているため、新規プロダクトでコードベースが別れたときに上手く共有できないという課題があります。
今後は UI コンポーネントをモノリスから分割してライブラリ化し、各プロダクトから使いやすい形にしていきます。また、マルチプロダクト環境下でより強固な一貫性のある UI を提供できるように、デザイナーチームとも協力してデザインガイドラインや UI コンポーネントの啓蒙活動なども必要になります。
デプロイ
現在は 2 週間に 1 度すべての変更を一括して展開しています。すべての変更というのは、フロントエンド、バックエンド、データベース、インフラなどの変更を含みます。今でもビッグバンリリースとなっていてエンジニアチームの大きな負担になっていますが、プロダクトが増えるとさらに巨大なビッグバンとなります。そうなる前に各要素、各チームでデプロイをコントロールできるようにするとともに、デプロイの粒度を細かく、頻度を高くする必要があります。
このようなデプロイに関するロードマップを策定して一括リリース作業からの移行を実施します。
監視・運用
現在はこれまでは 1 つのプロダクトのみを提供していたという背景もあり、全チームを横断した輪番体制で運用しています。しかし、担当者の担当ではない部分のアラートや問合せの対応が多くなっていて運用負荷が高まっています。また、すべてのアラートや通知が 1 つの通知先に集約されているため通知がノイジーになっています。
今後は各チームで自分たちのプロダクトに関する運用をこなせるようにしていきます。そのために、必要なチームに必要な通知・アラートが届いたり、問合せフローや障害対応プロセスを整備していく必要があります。
インフラのプラットフォーム化
現在、アプリケーションを動かすコンピュートサービスとして様々なサービスが利用されています。バックエンドは Cloud Run が多いですが、一部 Cloud Functions があったり、フロントエンドは Vercel を使っていたりします。そのためデプロイや運用方法、コード基盤がばらばらです。
Cloud Functions と Vercel どちらもそれでなければいけないという特別な理由はないので、Cloud Run へ移行してコード、デプロイ、監視・運用の共通化を計画しています。
それに伴い、各チームが生の Terraform をゼロから書いたり、デプロイや監視・運用をゼロから構築しなくてもいい (必要があればしてもいい) ようなツールチェインやワークフローを整備します。
開発環境
現在、開発環境をローカルで立ち上げるまでの手順が多く複雑です。ローカル開発環境の使い方がわかりにくかったり、トラブルが多かったり、よく壊れたりして開発工数が高くなる原因ともなっています。
今後は複数のプロダクトができても簡単に開発環境を構築して、透過的に開発できるような開発環境の整備を目指しています。
おわりに
最後にお決まりですが、これらの課題を解決して一緒に Platform Engineering をしてくれる仲間を絶賛募集しています！次のページから採用情報を見たりカジュアル面談に応募したりできるので、興味がある方はぜひお気軽にご連絡ください。
もうちょい気軽に話をしたいという方は X (@nownabe) の DM で声をかけてもらっても大丈夫です！何卒何卒🙏✨
Discussion