ビジネスドメインの拡大を実現する バクラクシリーズでのモノレポ開発

バクラクシリーズは複数製品を提供し、更にプロダクト間での連携をその強みの1つにしています。2023年からはそのような単一製品ではなく複合した製品開発を行う会社が、コンパウンドスタートアップと認知されるようになってきました。
このセッションでは、バクラクでの必要な箇所での連携を想定したアーキテクチャとプロダクト機能の標準化を提供するためのモノレポでの開発について発表します。

https://event.shoeisha.jp/devsumi/20240215/session/4833

Transcript

1. © 2024 LayerX Inc. ビジネスドメインの拡大を実現する バクラクシリーズでのモノレポ開発 Developers Summit 2024 2024/02/16
2. 2 © 2024 LayerX Inc. 自己紹介 中川佳希 （ナカガワ ヨシキ） 大学在学中に複数企業でインターンを経験し、2013年に株式会社エウレカに新卒入社。 その後フリーランスを経て、2020年6月に LayerX にジョイン。 プロダクトチームのテックリードや開発チーム横断組織である Enabling Team を経て、 2024年1月にバクラク事業部CTOに就任。 ミッションとして、開発チーム横断でのテクノロジーマネジメント、開発から顧客へのデリバリまでオペレーション マネジメントの責務を持つ。 Blog: 開発観点からプロダクト価値を最大化する〜バクラク新CTOのミッション〜
3. 3 © 2024 LayerX Inc. 株式会社LayerX 「すべての経済活動を、デジタル化する。」をミッションに掲げ、 法人支出管理サービス「バクラク」や企業内業務のデジタル化を支援するサービスを提供しています。 バクラク事業 企業活動のインフラとなる法人支出 管理（BSM）SaaSを開発・提供 Fintech事業 ソフトウェアを駆使したアセットマネジメ ント・証券事業を合弁会社にて展開 AI・LLM事業 文書処理を中心とした、LLMの活用による プロセスのリデザイン
4. 4 © 2024 LayerX Inc. セッション ビジネスドメインの拡大を実現するバクラクシリーズでのモノレポ開発 バクラクシリーズは複数製品を提供し、更にプロダクト間での連携をその強みの1つにしています。 2023年からはそのような単一製品ではなく複合した製品開発を行う会社が、コンパウンドスタートアップと認 知されるようになってきました。 このセッションでは、バクラクでの必要な箇所での連携を想定したアーキテクチャとプロダクト機能の標準化を提 供するためのモノレポでの開発について発表します。

5. 5 © 2024 LayerX Inc. アジェンダ ビジネスドメインの拡大を実現するバクラクシリーズでのモノレポ開発 1. バクラクのビジネスドメイン 2. Polyrepo でのスケーリング 3. Monorepo 4. Monorepo の導入 5. Monorepo で実現するアーキテクチャ 6. Monorepo 開発を支える 7. Challenges
6. © 2024 LayerX Inc. バクラクのビジネスドメイン SaaS の転換期
7. 7 © 2024 LayerX Inc. バクラクのタイムライン 2021年1月 LayerX インボイス 一般公開 2020年7月 プロダクト 開発開始 2021年4月 LayerX ワークフロー 提供開始 2021年11月 LayerX 電子帳簿保存 提供開始 2021年12月 バクラク ブランドリニューアル 2022年8月 バクラクビジネスカード 提供開始 2023年8月 バクラク請求書発行 提供開始 最初のPMFから解像度の高い近接領域へ展開
8. 8 © 2024 LayerX Inc. バクラクのビジネスドメイン
9. 9 © 2024 LayerX Inc. 〜１９９０年　 　業務パッケージソフトの利用 1990年中頃　ERPの導入 (Platform solution) 2000年〜　 　Web サービスの普及 2006年　　　　AWS がサービスを開始 2010年〜 　　クラウドコンピューティングのインフラが整い、業務アプリケーションもクラウドに 2010年中頃　SaaS (新たな Point solution) の普及 業務アプリケーションの変遷 Platform solution vs Point solution
10. 10 © 2024 LayerX Inc. pros • より組織の全体最適に向かう • 単一的な体験を提供できる • 他システムからの統合が不要 cons • 特定部署内だけでみると最適とは限らない • 導入への障壁が高い • 単一の会社やサービス、システムに依存 Point solution から Platform solution への揺り戻し Platform solution pros • 特定部署に最適なソリューション （Best-of-breed） • 小さく導入を進められる • 特定のソリューションを簡単に置き換えれる cons • 特定部署への最適なソリューションが、組織の 全体最適にならない可能性がある • 他システムと統合するには、複雑な構成になる Point solution
11. 11 © 2024 LayerX Inc. 業務アプリケーションの変遷 Platform solution vs Point solution 2010年後半　統合を試みる iPaaS （Integration Platform as a Service） の流行　　　 2020年　　　 DX （デジタルトランスフォーメーション） という言葉が普及 　　　　　　　　 　 コロナ禍、リモートワーク可能な業務環境が必要に 2021年　　　 Parker Conrad (Rippling CEO) が Compound Startup を提唱 　　　　　　　　　　共通のデータと複数プロダクトでの統合された体験を競争戦略とする 　　　　　　　　　　「アンバンドル(バラバラにする)の時代から、 　　　　　　　　　　データを中心としたリバンドル(再構築する)の時代への転換」 と説明
12. 12 © 2024 LayerX Inc. Point solution から Platform solution への揺り戻し Point solution Platform solution パッケージソフトの流通 ERP の導入 SaaS の普及 2030年 1990年 2010年 2020年 2000年 1980年 Compound Startup としての成長
13. 13 © 2024 LayerX Inc. Point Solution 型の SaaS が選ばれた背景には、導入障壁の低さやWebサービスとしての改善イテレー ションなど現場から見た使いやすさがあった。 ツールやアプリケーション毎に業務システムの提供者が異なり、 データや体験が異なることを解消し、 共通のデータを元に統合されたユーザー体験を提供する。 SaaS 普及からの転換期 バクラクはコンパウンドスタートアップを志向する
14. 14 © 2024 LayerX Inc. SaaS 普及からの転換期 バクラクはコンパウンドスタートアップを志向する 複数のプロダクトでビジネスドメインを拡大していき、企業の全部門、業務を支える SaaS となることを目指す Blog: コンパウンドスタートアップというLayerXの挑戦 | 福島良典
15. © 2024 LayerX Inc. Polyrepo からのスタート PMF (プロダクトマーケットフィット) まで
16. 16 © 2024 LayerX Inc. Polyrepo スタイルでの開発 プロダクト数 × システムコンポーネント単位 2020年　1プロダクトあたり3〜4個のレポジトリで構成 2022年　4プロダクトまで増え、レポジトリ数が20を超える 　　　　　　　Back-end は Go 　　　　　　　API は、Rest, GraphQL が存在する 　　　　　　　Front-end は TypeScript 　　　　　　　フレームワークは、Vue, React が存在する Front-end Back-end Infra 1プロダクト
17. 17 © 2024 LayerX Inc. Polyrepo スタイルでの開発 プロダクト数 4 レポジトリ数 20〜 エンジニア人数 15〜20人 トピック 1プロダクトを2〜3人で開発 DevOps/SRE 専任者をアサインしない時期もあった プロダクトに共通するような開発基盤チームもなし Shared Library は一部分のみで活発ではない ２０２２年8月
18. 18 © 2024 LayerX Inc. 共有が必要なデータについては、内部通信用の API をプロダクトから提供していた 連携するプロダクトが以下のようなユースケースを持ち、システム上での依存が発生する 1. 他プロダクトデータの参照 2. 他プロダクトデータと結合しての検索、データ出力 3. 他プロダクトからの非同期通信によるデータの作成・更新 Polyrepo スタイルでの開発 複数プロダクト間で起きる Back-end システムの依存関係 プロダクト DB Internal API API Worker DB Internal API API プロダクト Worker 作成・更新 結合 参照 プロダクト
19. 19 © 2024 LayerX Inc. 循環参照の問題点 1. 両サービス間でのデプロイ順序を定める事ができなくなる 2. 全サービスの間で一貫性のある依存の流れ、方向性がなくなる 3. 本来、依存のないサービス間にまでサービスダウンなどの影響が波及する ドメイン境界が (システムアーキテクチャ上で） 正しくない具体的な信号でもある Polyrepo スタイルでの開発 大きなドメインを持つサービス同士では、依存グラフ上での循環もうまれやすい DB Internal API API Worker DB Internal API API プロダクト Worker プロダクト 参照 作成・更新 結合 参照
20. 20 © 2024 LayerX Inc. Polyrepo スタイルでの開発 複数プロダクトのコードベース ちなみにコードベースの共通化などは、大きな課題としては挙がっていなかった 一定の重複するコードを許容すれば、メリットもある • 他チームに影響を与えずにスピーディに開発できる • ライブラリの依存解決などが不要 • 共有コードベースのオーナー不在でメンテされない状態などは発生しない
21. © 2024 LayerX Inc. Monorepo Not just “code colocation”
22. 22 © 2024 LayerX Inc. Microservices や多くの構成要素を持つシステムをビルド、デプロイしていく為のコード管理方法 1. コード共有、再利用を行える 2. コードベースの標準化に取り組める 3. アプリケーション起動に必要な依存関係を集約できる 4. システム連携部分の変更が容易になる 5. ビルド、テストからシステム全体の合意とみなせる 6. CI/CD の共通化が行える 7. システム全体としての変更差分が git 上で追いやすい 8. チーム同士の連携を行いやすい Monorepo コードベースを１つのレポジトリに集約する Infrastructure Front-end Back-end Complicated Subsystem
23. 23 © 2024 LayerX Inc. Not just “code colocation” 多様な役割のコードベースが含まれ、それらが明確な関係を持っている 1. システムコンポーネント間のブリッジを行う 2. システムコンポーネント間での契約に相当する 3. 同種のシステムコンポーネントで共有される 4. 他のコンポーネントから依存される 5. 独立したコンポーネントとして動く Infrastructure Front-end Back-end Complicated Subsystem Configuration, Deployment Project, Shared Library Schema Tool Service Dependency
24. © 2024 LayerX Inc. Monorepo の導入 開発体制とその相性
25. 25 © 2024 LayerX Inc. 1つのレポジトリで1プロダクトを構成するのではなく、 より小さなビジネスドメインにフォーカスしたリソースカットでレポジトリを構成する Polyrepo から Monorepo へ 2022年 Back-end 複数のビジネスドメインを区別された形で含める Front-end スモールスタートで含める Infrastructure デプロイ設定、Terraform などの IaC も含める Subsystem ML 系は含めない
26. 26 © 2024 LayerX Inc. Directory Layouts ルートディレクトリ配下は、言語ごとに分ける • モジュール管理など言語が持つエコシステムや CI/CD の記述を容易にする アーキテクチャ上の各コンポーネントはディレクトリで表現され、その内部に実装を閉じる • Microservices ではサービスの一覧性を高めるグルーピング用のディレクトリ階層を設ける • サービスのディレクトリはフラットに並び、階層によるサービス依存関係の表現などは行わない Monorepo go web(TypeScript) pkg services packages apps ServiceA ServiceB GraphQL WebappA terraform
27. 27 © 2024 LayerX Inc. Monorepo での開発体制 ２０２２年9月〜 トピック 1プロダクトを2〜4人で開発 （ここは変わらず） プロダクト開発を支える DevOps 専任者を常にアサイン プロダクト開発のパフォーマンス向上を目的にした Enabling team が発足
28. 28 © 2024 LayerX Inc. Team Topologies Four fundamental topologies にならった開発チームへ Stream-aligned team ビジネスドメインにおける一連のフロー（機能を開発・リリース・運用）を担当する Enabling team Stream-aligned team とコラボレートし、障害を取り除き、システムや組織に 必要な機能の発見やその技術の伝搬も担う Complicated Subsystem team 専門知識を要するシステムの開発や運用に携わる Platform team チームによるデリバリを加速するための社内サービス （X-as-a-Service） を提 供するよう振る舞う
29. 29 © 2024 LayerX Inc. Monorepo での開発体制 ３ core interaction modes 1. 決められた期間内で共同での作業を行う (Collaboration) 2. 「サービス」として開発、提供して、他のチームが利用する (X-as-a-Service) 3. 新しい仕組みを可能にして伝搬する (Facilitating) ▪ Stream-aligned team ▪ Enabling team ▪ Complicated Subsystem team ▪ Platform team https://teamtopologies.com/key-concepts
30. 30 © 2024 LayerX Inc. • 相互のチームが同じコードベースから始められる • Enabling team: コンテキストスイッチが小さい • Enabling team: 仕組みを伝搬するためコストが小さい • Platform team: 「サービス」提供するためのコストが小さい Monorepo での開発体制 チーム間の相互作用における Monorepo の相性の良さ Infrastructure Front-end Back-end Complicated Subsystem
31. © 2024 LayerX Inc. Monorepo で実現するアーキテクチャ レイヤの責務
32. 32 © 2024 LayerX Inc. Monorepo で実現するアーキテクチャ API Gateway Pattern をアーキテクチャに採用 Gateway は全プロダクト Front-end の Single entry point • Front-end に GraphQL を公開 • Front-end に Microservices API を公開しない • 内部通信は Protocol Buffers を利用 1. Gateway -> Microservices 2. Microservice -> Microservice monorepo 内で N個のプロダクトを構成可能に
33. 33 © 2024 LayerX Inc. Front-end 表示に関わるリソース解決 (Resolver) を一手に引き受ける • リソースの集約表現 • リレーションの解決 責任分界点： ビジネスロジックを持たせない • Operation (ユーザー入力から出力を生成する) には干渉しない • 必要な API 呼び出しのみを行う Monorepo で実現するアーキテクチャ GraphQL Gateway レイヤ
34. 34 © 2024 LayerX Inc. Monorepo で実現するアーキテクチャ Microservices レイヤ Microservices とその API を設計することは、ドメインモデリングすることと同義 ビジネス上で核心となる Entity と副作用がある Operation (ユーザー入力を受けて出力を生成する) に 必要な API を定義することがこのレイヤーでの最大の関心事 ※ 副作用の例) データベース上のデータを変更する、他サービスの取得ではない API を利用する リソースカットで切られた Microservices である以上、そのサービス境界がトランザクションの境界となる ※ 全てのサービスのローカルトランザクションを合意させる方法 (2Phase Commit, Saga) には、常に困難 や制約がある ドメインモデリングを通して、顧客と対話するための重要な構成要素を明らかにしていく必要がある 依存関係もその過程で明らかになっていく
35. 35 © 2024 LayerX Inc. Monorepo で実現するアーキテクチャ 爆速開発を支えるバクラクチームとアーキテクチャのつくり方 リソースカットへの変更
36. © 2024 LayerX Inc. Monorepo 開発を支える more effortless
37. 37 © 2024 LayerX Inc. Monorepo で実現したい開発 Stream-aligned team がよりビジネスドメインに集中できる環境をつくる プロダクトの機能拡張、新しいビジネスドメインを実装する際の障壁を取り除く 1. Code Generation 新しいサービスに必要となる足回りのコードを生成する 2. System Foundation すぐに利用可能なシステム的な基盤を提供する 3. Developer Experience 開発者環境でのアプリケーション起動を容易にする
38. 38 © 2024 LayerX Inc. 1. Code Generation GraphQL (TypeScript) Protobuf による Schema-First • github.com/proto-graphql/proto-graphql-js Protobuf 定義から、以下のコードが生成される • Protobuf で定義されたオブジェクト ◦ TypeScript 上コードでのオブジェクト定義も可能だが、重複は推奨しない • Microservices 用の gRPC クライアント ◦ 用意されたクライアントで、API の呼び出しが容易に
39. 39 © 2024 LayerX Inc. Protobuf による Schema-First • github.com/connectrpc/connect-go Protobuf 定義から、以下のコードを生成 • Go Server/Client • Custom Options 定義からのインタセプター 1. Code Generation Microservices (Go)
40. 40 © 2024 LayerX Inc. Database Schema-First • github.com/xo/xo Database スキーマから、以下のコードを生成 • １テーブルを表す Go Struct • IDなど特定のカラムに対して、独自の型定義を持たせる 1. Code Generation Database (Go)
41. 41 © 2024 LayerX Inc. jsonnet で独自のサービス定義ファイルを記述してコード生成を行う • Microservices 単位で記述する ◦ gRPC 以外の HTTP サーバーにも対応 • Generator は Go で実装している サービス定義から、以下のようなコードを生成 • ORM 設定から、初期化コードを生成 • Database 設定から、マイグレーション設定 (GitHub Actions) を生成 • デプロイ設定 (GitHub Actions) を生成 • サービスデプロイ環境用のインフラコード (Terraform) を生成 • サービスの監視設定を生成 • サービスカタログ(backstage) を生成 1. Code Generation Others (Go) connectService { name: “TokenService”, owner: “id” }
42. 42 © 2024 LayerX Inc. 2. System Foundation Gateway Gateway は全プロダクト Front-end の Single entry point • ユーザーからの認証 • ユーザーからの認証後は、Microservices 間で利用するトークンの生成も行う ◦ Microservices 側では、共通規格でトークンの認証を行う
43. 43 © 2024 LayerX Inc. 2. System Foundation Events Infra AWS EventBridge を利用したイベント処理基盤 イベントの宣言的な定義から、ルーティングするコードを 自動生成する AWS 環境用には、ルーティング設定用の Terraform コードを生成する イベントメッセージ自体も Protobuf で定義する
44. 44 © 2024 LayerX Inc. 2. System Foundation Others 特定のプロダクトに依存せずに利用できるシステムを Portfolio にまとめて管理 サービスで実現したい機能をショートカットして実装 出来るように助け、またバクラクグローバルで標準化 された体験を提供することを目的にしている
45. 45 © 2024 LayerX Inc. main のコードは、CI 上のビルド/テストをパスしてい るおり、統合システムとして合意が取れている状態 最新状態で常にローカルビルドが可能 専用プロセスマネージャーからの起動も可能で、 ターミナルウィンドウ1つで管理出来る Blog: エンジニアオンボーディングを改善するツール の紹介 | suguru 3. Developer Experience 開発者PCから、アプリケーションが起動出来る
46. © 2024 LayerX Inc. Challenges
47. 47 © 2024 LayerX Inc. Challenges Polyrepo との比較 monorepo.tools では、Polyrepo の課題を解決している例として、以下が挙げられている 1. No overhead to create new projects 2. Atomic commits across projects 3. One version of everything 4. Developer mobility しかし、Monorepo に対しての理解や専門的な運用、ツールも求められる なによりも運用を行うチームの存在は必須
48. 48 © 2024 LayerX Inc. Build time and Tools コードベースは常に成長を続ける Monorepo は多くのメリットがある一方で、 大きな懸念としてコードベース全体をどう構成し、 より短時間でビルドするかがある monorepo.tools では各々のワークスペースに 適したビルドツールの比較情報を提供 ※ 現在はビルドを行うマシン性能での解決のみで、 特定のツール導入には至っていない
49. 49 © 2024 LayerX Inc. Monorepo はデファクトではない 開発者が日常的に使うツールでのサポートが充分ではない場合もある e.g.) GitHub Pull Requests 一覧、Actions 内の Workflows 一覧や結果は、 数の多さから視認性や検索性の観点で利用体験から落ちることになる 現在デプロイなどは、CLI コマンドを開発して提供している
50. 50 © 2024 LayerX Inc. Atomic Commits への誤解 Atomic Commits とは？ Monorepo ではシステム間の連携箇所に変更を加えることが容易になる 1コミットにその変更全てを含めて、main ブランチに取り込むことが可能 しかし、コミットヒストリー上で Atomic Commits を実現していても、 分散システムとしてデプロイされる場合には生存している古いアプリケーションとの互換性が必要 main ブランチ上ではビルドが壊れることはなく、デプロイ時に Microservices の契約における 構造的破壊を意図せず行ってしまう場合がある
51. 51 © 2024 LayerX Inc. Schema File Breaking change Detector GraphQL schema.graphql GraphQL Inspector Protobuf proto/* buf breaking Database db/migrations/* atlas migrate lint Atomic Commits への誤解 Compatibility for deployments Monorepo であるかに関わらず、新しいバージョンのソフトウェアをデプロイする際には、 協調するソフトウェア間でのインターフェイスの互換性を持つことが求められる これは Schema として静的解析が可能なため、CI 上でチェックを行っている
52. © 2024 LayerX Inc. Summary
53. 53 © 2024 LayerX Inc. Achievements プロジェクト立ち上げ スピード monorepo 環境が整った状態では、ほぼコストゼロ コードジェネレーターにより、デプロイまでセットアップに必要なファイルが生成 される コードベース共有 monorepo 下にあるパッケージはすぐに利用できる ビジネスドメイン境界 Protobuf の定義から、明確に区切られる データベースの共通結合パターンは許しておらず、データへのアクセスには必ず API が利用される （Database-per-service） ローカル開発 monorepo をクローンするのみ 必要なコードベース、ツールすべてが手に入る ビジネスロジックの開発に集中
54. 54 © 2024 LayerX Inc. Collaboration 同じ場所、monorepo 内でコラボレートする レポジトリをまたぐようなコンテキストスイッチがない X-as-a-Service 社内「サービス」の提供側としては、monorepo 内ではディレイなしで提供可能 Facilitation チームを助ける仕組みの伝搬や他のレポジトリへの適用漏れが起きない Achievements ビジネスロジックの開発を加速させる
55. 55 © 2024 LayerX Inc. おわりに 今後も monorepo とともにドメインの拡大を進める