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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2 © 2024 LayerX Inc. 自己紹介中川佳希（ナカガワヨシキ）大学在学中に複数企業でインターンを経験し、2013年に株式会社エウレカに新卒入社。その後フリーランスを経て、2020年6月に LayerX にジョイン。プロダクトチームのテックリードや開発チーム横断組織である Enabling Team を経て、 2024年1月にバクラク事業部CTOに就任。ミッションとして、開発チーム横断でのテクノロジーマネジメント、開発から顧客へのデリバリまでオペレーションマネジメントの責務を持つ。 Blog: 開発観点からプロダクト価値を最大化する〜バクラク新CTOのミッション〜

Slide 3

Slide 3 text

3 © 2024 LayerX Inc. 株式会社LayerX 「すべての経済活動を、デジタル化する。」をミッションに掲げ、法人支出管理サービス「バクラク」や企業内業務のデジタル化を支援するサービスを提供しています。バクラク事業企業活動のインフラとなる法人支出管理（BSM）SaaSを開発・提供 Fintech事業ソフトウェアを駆使したアセットマネジメント・証券事業を合弁会社にて展開 AI・LLM事業文書処理を中心とした、LLMの活用によるプロセスのリデザイン

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

7 © 2024 LayerX Inc. バクラクのタイムライン 2021年1月 LayerX インボイス一般公開 2020年7月プロダクト開発開始 2021年4月 LayerX ワークフロー提供開始 2021年11月 LayerX 電子帳簿保存提供開始 2021年12月バクラクブランドリニューアル 2022年8月バクラクビジネスカード提供開始 2023年8月バクラク請求書発行提供開始最初のPMFから解像度の高い近接領域へ展開

Slide 8

Slide 8 text

Slide 9

Slide 9 text

9 © 2024 LayerX Inc. 〜１９９０年　　業務パッケージソフトの利用 1990年中頃　ERPの導入 (Platform solution) 2000年〜　　Web サービスの普及 2006年　　　　AWS がサービスを開始 2010年〜　　クラウドコンピューティングのインフラが整い、業務アプリケーションもクラウドに 2010年中頃　SaaS (新たな Point solution) の普及業務アプリケーションの変遷 Platform solution vs Point solution

Slide 10

Slide 10 text

10 © 2024 LayerX Inc. pros ● より組織の全体最適に向かう ● 単一的な体験を提供できる ● 他システムからの統合が不要 cons ● 特定部署内だけでみると最適とは限らない ● 導入への障壁が高い ● 単一の会社やサービス、システムに依存 Point solution から Platform solution への揺り戻し Platform solution pros ● 特定部署に最適なソリューション（Best-of-breed） ● 小さく導入を進められる ● 特定のソリューションを簡単に置き換えれる cons ● 特定部署への最適なソリューションが、組織の全体最適にならない可能性がある ● 他システムと統合するには、複雑な構成になる Point solution

Slide 11

Slide 11 text

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 を提唱　　　　　　　　　　共通のデータと複数プロダクトでの統合された体験を競争戦略とする　　　　　　　　　　「アンバンドル(バラバラにする)の時代から、　　　　　　　　　　データを中心としたリバンドル(再構築する)の時代への転換」と説明

Slide 12

Slide 12 text

Slide 13

Slide 13 text

13 © 2024 LayerX Inc. Point Solution 型の SaaS が選ばれた背景には、導入障壁の低さやWebサービスとしての改善イテレーションなど現場から見た使いやすさがあった。ツールやアプリケーション毎に業務システムの提供者が異なり、データや体験が異なることを解消し、共通のデータを元に統合されたユーザー体験を提供する。 SaaS 普及からの転換期バクラクはコンパウンドスタートアップを志向する

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

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プロダクト

Slide 17

Slide 17 text

Slide 18

Slide 18 text

18 © 2024 LayerX Inc. 共有が必要なデータについては、内部通信用の API をプロダクトから提供していた連携するプロダクトが以下のようなユースケースを持ち、システム上での依存が発生する 1. 他プロダクトデータの参照 2. 他プロダクトデータと結合しての検索、データ出力 3. 他プロダクトからの非同期通信によるデータの作成・更新 Polyrepo スタイルでの開発複数プロダクト間で起きる Back-end システムの依存関係プロダクト DB Internal API API Worker DB Internal API API プロダクト Worker 作成・更新結合参照プロダクト

Slide 19

Slide 19 text

19 © 2024 LayerX Inc. 循環参照の問題点 1. 両サービス間でのデプロイ順序を定める事ができなくなる 2. 全サービスの間で一貫性のある依存の流れ、方向性がなくなる 3. 本来、依存のないサービス間にまでサービスダウンなどの影響が波及するドメイン境界が (システムアーキテクチャ上で）正しくない具体的な信号でもある Polyrepo スタイルでの開発大きなドメインを持つサービス同士では、依存グラフ上での循環もうまれやすい DB Internal API API Worker DB Internal API API プロダクト Worker プロダクト参照作成・更新結合参照

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

22 © 2024 LayerX Inc. Microservices や多くの構成要素を持つシステムをビルド、デプロイしていく為のコード管理方法 1. コード共有、再利用を行える 2. コードベースの標準化に取り組める 3. アプリケーション起動に必要な依存関係を集約できる 4. システム連携部分の変更が容易になる 5. ビルド、テストからシステム全体の合意とみなせる 6. CI/CD の共通化が行える 7. システム全体としての変更差分が git 上で追いやすい 8. チーム同士の連携を行いやすい Monorepo コードベースを１つのレポジトリに集約する Infrastructure Front-end Back-end Complicated Subsystem

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Slide 25

Slide 25 text

25 © 2024 LayerX Inc. 1つのレポジトリで1プロダクトを構成するのではなく、より小さなビジネスドメインにフォーカスしたリソースカットでレポジトリを構成する Polyrepo から Monorepo へ 2022年 Back-end 複数のビジネスドメインを区別された形で含める Front-end スモールスタートで含める Infrastructure デプロイ設定、Terraform などの IaC も含める Subsystem ML 系は含めない

Slide 26

Slide 26 text

26 © 2024 LayerX Inc. Directory Layouts ルートディレクトリ配下は、言語ごとに分ける ● モジュール管理など言語が持つエコシステムや CI/CD の記述を容易にするアーキテクチャ上の各コンポーネントはディレクトリで表現され、その内部に実装を閉じる ● Microservices ではサービスの一覧性を高めるグルーピング用のディレクトリ階層を設ける ● サービスのディレクトリはフラットに並び、階層によるサービス依存関係の表現などは行わない Monorepo go web(TypeScript) pkg services packages apps ServiceA ServiceB GraphQL WebappA terraform

Slide 27

Slide 27 text

Slide 28

Slide 28 text

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）を提供するよう振る舞う

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

30 © 2024 LayerX Inc. ● 相互のチームが同じコードベースから始められる ● Enabling team: コンテキストスイッチが小さい ● Enabling team: 仕組みを伝搬するためコストが小さい ● Platform team: 「サービス」提供するためのコストが小さい Monorepo での開発体制チーム間の相互作用における Monorepo の相性の良さ Infrastructure Front-end Back-end Complicated Subsystem

Slide 31

Slide 31 text

Slide 32

Slide 32 text

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個のプロダクトを構成可能に

Slide 33

Slide 33 text

33 © 2024 LayerX Inc. Front-end 表示に関わるリソース解決 (Resolver) を一手に引き受ける ● リソースの集約表現 ● リレーションの解決責任分界点：ビジネスロジックを持たせない ● Operation (ユーザー入力から出力を生成する) には干渉しない ● 必要な API 呼び出しのみを行う Monorepo で実現するアーキテクチャ GraphQL Gateway レイヤ

Slide 34

Slide 34 text

34 © 2024 LayerX Inc. Monorepo で実現するアーキテクチャ Microservices レイヤ Microservices とその API を設計することは、ドメインモデリングすることと同義ビジネス上で核心となる Entity と副作用がある Operation (ユーザー入力を受けて出力を生成する) に必要な API を定義することがこのレイヤーでの最大の関心事 ※ 副作用の例) データベース上のデータを変更する、他サービスの取得ではない API を利用するリソースカットで切られた Microservices である以上、そのサービス境界がトランザクションの境界となる ※ 全てのサービスのローカルトランザクションを合意させる方法 (2Phase Commit, Saga) には、常に困難や制約があるドメインモデリングを通して、顧客と対話するための重要な構成要素を明らかにしていく必要がある依存関係もその過程で明らかになっていく

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

37 © 2024 LayerX Inc. Monorepo で実現したい開発 Stream-aligned team がよりビジネスドメインに集中できる環境をつくるプロダクトの機能拡張、新しいビジネスドメインを実装する際の障壁を取り除く 1. Code Generation 新しいサービスに必要となる足回りのコードを生成する 2. System Foundation すぐに利用可能なシステム的な基盤を提供する 3. Developer Experience 開発者環境でのアプリケーション起動を容易にする

Slide 38

Slide 38 text

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 の呼び出しが容易に

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

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” }

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

45 © 2024 LayerX Inc. main のコードは、CI 上のビルド/テストをパスしているおり、統合システムとして合意が取れている状態最新状態で常にローカルビルドが可能専用プロセスマネージャーからの起動も可能で、ターミナルウィンドウ1つで管理出来る Blog: エンジニアオンボーディングを改善するツールの紹介 | suguru 3. Developer Experience 開発者PCから、アプリケーションが起動出来る

Slide 46

Slide 46 text

Slide 47

Slide 47 text

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 に対しての理解や専門的な運用、ツールも求められるなによりも運用を行うチームの存在は必須

Slide 48

Slide 48 text

48 © 2024 LayerX Inc. Build time and Tools コードベースは常に成長を続ける Monorepo は多くのメリットがある一方で、大きな懸念としてコードベース全体をどう構成し、より短時間でビルドするかがある monorepo.tools では各々のワークスペースに適したビルドツールの比較情報を提供 ※ 現在はビルドを行うマシン性能での解決のみで、特定のツール導入には至っていない

Slide 49

Slide 49 text

Slide 50

Slide 50 text

50 © 2024 LayerX Inc. Atomic Commits への誤解 Atomic Commits とは？ Monorepo ではシステム間の連携箇所に変更を加えることが容易になる 1コミットにその変更全てを含めて、main ブランチに取り込むことが可能しかし、コミットヒストリー上で Atomic Commits を実現していても、分散システムとしてデプロイされる場合には生存している古いアプリケーションとの互換性が必要 main ブランチ上ではビルドが壊れることはなく、デプロイ時に Microservices の契約における構造的破壊を意図せず行ってしまう場合がある

Slide 51

Slide 51 text

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 上でチェックを行っている

Slide 52

Slide 52 text

Slide 53

Slide 53 text

53 © 2024 LayerX Inc. Achievements プロジェクト立ち上げスピード monorepo 環境が整った状態では、ほぼコストゼロコードジェネレーターにより、デプロイまでセットアップに必要なファイルが生成されるコードベース共有 monorepo 下にあるパッケージはすぐに利用できるビジネスドメイン境界 Protobuf の定義から、明確に区切られるデータベースの共通結合パターンは許しておらず、データへのアクセスには必ず API が利用される（Database-per-service）ローカル開発 monorepo をクローンするのみ必要なコードベース、ツールすべてが手に入るビジネスロジックの開発に集中

Slide 54

Slide 54 text

54 © 2024 LayerX Inc. Collaboration 同じ場所、monorepo 内でコラボレートするレポジトリをまたぐようなコンテキストスイッチがない X-as-a-Service 社内「サービス」の提供側としては、monorepo 内ではディレイなしで提供可能 Facilitation チームを助ける仕組みの伝搬や他のレポジトリへの適用漏れが起きない Achievements ビジネスロジックの開発を加速させる