木を見て森も見る－モジュールが織りなすプロダクトの森

宮田聖也 (38tter) / 株式会社ナレッジワーク
※2025/05/13「Rails, Go, TypeScriptで挑む──バックエンド開発の選択と実践」での発表資料です
https://knowledgework.connpass.com/event/351615/

＝＝＝セッション概要＝＝＝
ナレッジワークは「みんなが売れる営業になる」をスローガンに、営業支援のプロダクトを複数展開しています。 また、昨今は生成AIのプロダクト統合を積極的に進めています。バックエンド開発では Go 言語を採用しています。 本発表では、Go を基盤としたマルチプロダクト展開のアーキテクチャを俯瞰し、内製コンテンツ処理システムや、生成AIのプロダクト統合への取り組みに焦点を当てつつ、チーム開発の実状をお話しします。

Transcript

1. ⽊を⾒て森も⾒る モジュールが織りなすプロダクトの森 株式会社ナレッジワーク 宮⽥聖也 (@38xxer)
2. © Knowledge Work Inc. 2 • 宮⽥聖也 (38tter) • ソフトウェアエンジニア＠ナレッジワーク • Golang, Ruby が好き • 趣味：🍺🍺🍺, ⚽ (󰧹, 󰎼), 🎸, 📷 ⾃⼰紹介
3. © Knowledge Work Inc. ナレッジワーク 製品紹介 3 みんなが売れる営業になる セールスイネーブルメントクラウド 現場担当者の営業支援をするプロダクト、 「ナレッジワーク」を提供しています
4. © Knowledge Work Inc. 事業の特徴 4 4 ①マルチプロダクト展開 ②エンタープライズ顧客 ③マルチテナント SaaS
5. © Knowledge Work Inc. 事業の特徴 5 5 複数のプロダクト展開により シナジーを産み競合優位を築く 従業員数1000 ⼈以上の ⼤企業に限定して提供 顧客企業ごとテナントを作成
6. © Knowledge Work Inc. go を使ったモジュラーモノリス開発 6 6 モジュール化✖モノリス
7. © Knowledge Work Inc. アーキテクチャの概観 7 7
8. © Knowledge Work Inc. アーキテクチャの概観 8 8 CRUD処理 ファイル操作 並⾏処理 共通⾔語で書ける
9. © Knowledge Work Inc. アーキテクチャの概観 9 9 複数のプロダクトに共通する ドメインを共通機能として 切り出す
10. © Knowledge Work Inc. アーキテクチャの概観 10 10 依存関係の順序は プロダクト→共通機能 デプロイ順序も固定
11. © Knowledge Work Inc. アーキテクチャの概観 11 11 Cloud Run アプリケーション 間は Connect で通信
12. © Knowledge Work Inc. アーキテクチャの概観 12 12 依存関係を逆転させるとき e.g. ファイル処理完了の通知
13. © Knowledge Work Inc. おさらい：事業の特徴 13 13 ①マルチプロダクト展開 ②エンタープライズ顧客 ③マルチテナント SaaS
14. © Knowledge Work Inc. ミニサービス 14 14 ミニサービス • Go のバイナリ on Cloud Run • 独⽴なモジュールの集まり
15. © Knowledge Work Inc. ミニサービス 15 15 ミニサービス • Go のバイナリ on Cloud Run • モジュールの集まり モジュール • ドメイン単位の境界 • 同⼀トランザクション内で扱う集約 • 再利⽤可能 ◦ サービス内では import ◦ サービス外からは RPC 呼び出し コンテンツサービス ナレッジモジュール 画像モジュール ナレッジ推薦モジュール ナレッジ検索モジュール …
16. © Knowledge Work Inc. ミニサービス 16 16 ミニサービス • チームの責任範囲の境界 • 「ミニサービスAはチームX、ミニサービス BはチームYの持ち物」のような認識 • 他のチームのミニサービスを触ることもし ばしばある ◦ e.g. 共通基盤へのモジュール追加 コンテンツ ナレッジモジュール 画像モジュール ナレッジ推薦モジュール ナレッジ検索モジュール …
17. © Knowledge Work Inc. モジュール 17 17 モジュール • レイヤーごと責務を分けている ハンドラ • connect PRC のハンドラ • protoc-plugin でコード⽣成を活⽤ ◦ API の権限管理 モジュールサービス • ビジネスロジックの記述 • 更新系‧参照系の I/F を分けている ◦ CQRS アダプタ • データアクセス • ORM は Gorm ナレッジモジュール ハンドラ モジュールサービス アダプタ
18. © Knowledge Work Inc. ミニサービスのディレクトリスタイル 18 18 product/example ├── CODEOWNER ├── README.md ├── backend │ ├── backend_config.cue │ ├── deploy │ ├── script │ │ └── run-local.sh │ └── src │ ├── cmd │ ├── go.mod │ ├── go.sum │ └── server ├── deploy ├── local │ ├── README.md │ └── envfiles │ └── definitions ├── product_config.cue ├── proto │ ├── gen │ │ ├── go.mod │ │ ├── go.sum │ │ └── product │ ├── proto │ │ └── product │ ├── protoevent │ │ └── product │ └── protosdk │ └── product └── tf ├── build └── core ディレクトリスタイルが決まっている • バックエンド開発のボイラープレート 全部⼊り • フロントエンド‧バックエンド実装 • IaC 定義 ◦ terraform • APIスキーマ定義 ◦ buf • デプロイスクリプト ◦ knative ◦ skaffold ◦ gcloud • …etc. 新規プロダクト開発時のスターターキット
19. © Knowledge Work Inc. デプロイフロー 19 19 ミニサービス単位でデプロイ可能 • 開発者が⾃発的にできる ⽅法はいくつかあり環境により異なる • 検証環境では GitHub Actions で ◦ 特定ブランチへのマージトリガー ◦ IssueOps • 本番環境では Cloud Deploy の ◦ DeliveryPipeline 共通機能とプロダクトの依存関係の注意は必要
20. © Knowledge Work Inc. DB マイグレーション 20 20 product/example ├── CODEOWNER ├── README.md ├── backend │ ├── backend_config.cue │ ├── deploy │ ├── script │ │ └── run-local.sh │ └── src │ ├── cmd │ ├── go.mod │ ├── go.sum │ └── server ├── deploy ├── local │ ├── README.md │ └── envfiles │ └── definitions ├── product_config.cue ├── proto │ ├── gen │ │ ├── go.mod │ │ ├── go.sum │ │ └── product │ ├── proto │ │ └── product │ ├── protoevent │ │ └── product │ └── protosdk │ └── product └── tf ├── build └── core sql-migrate • go 製マイグレーションツール • sql ファイルでスキーマ管理 • DB migration は Application deploy と 分離 マルチテナントのデータ分離が必須 • PostgreSQL の⾏レベルのデータ分離 ◦ Raw Level Security • GitHub Actions で lint 実⾏し以下を保証 ◦ RLS 有効 ◦ Row Security Policies の作成
21. © Knowledge Work Inc. アーキテクチャの恩恵を受けた点 21 21 ①新規開発の初速・品質の担保 ②高い再利用性によるスケーラビリティ
22. © Knowledge Work Inc. 新規プロダクト⽴ち上げが⾼速‧省⼒化 22 22 ディレクトリスタイル＝スターターキット モジュール＝ビルディングブロック
23. © Knowledge Work Inc. 新規開発の初速‧品質の担保 23 23
24. © Knowledge Work Inc. ミニサービス 24 24 コンテンツ ナレッジモジュール 画像モジュール ナレッジ推薦モジュール ナレッジ検索モジュール …
25. © Knowledge Work Inc. モジュール化に救われた例：ナレッジの要約処理 25 25 通常のファイル処理
26. © Knowledge Work Inc. モジュール化に救われた例：ナレッジの要約処理 26 26 通常のファイル処理 LLM によるファイルコンテンツの要約処理を追加する
27. © Knowledge Work Inc. モジュール化に救われた例：ナレッジの要約処理 27 27 LLM によりファイルコンテンツの要約処理を追加する 顧客の業種によっては NG →テナント単位で要約機能の ON/OFF が必要
28. © Knowledge Work Inc. モジュール化に救われた例：ナレッジの要約処理 28 28 LLM によりファイルコンテンツの要約処理を追加する 顧客の業種によっては NG →テナント単位で要約機能の ON/OFF が必要 コンテント処理系はセキュリティ都合で隔離されているべき
29. © Knowledge Work Inc. モジュール化に救われた例：ナレッジの要約処理 29 29 LLM によりファイルコンテンツの要約処理を追加する 顧客の業種によっては NG →テナント単位で要約機能の ON/OFF が必要 コンテント処理系はセキュリティ都合で隔離されているべき→共通基盤に問い合わせは NG ❌
30. © Knowledge Work Inc. モジュール化に救われた例：ナレッジの要約処理 30 30 共通基盤バックエンドでコンテンツ処理終了を検知 要約機能が有効なテナントであれば要約タスク実⾏
31. © Knowledge Work Inc. モジュール化に救われた例：ナレッジの要約処理 31 31 新規テナントでファイル⼀括登録 →同じテナントからの⼤量のリクエストにより LLM API の quota が逼迫する →他のテナントからのリクエストを受け付けられない時間が発⽣
32. © Knowledge Work Inc. モジュール化に救われた例：ナレッジの要約処理 32 32 🤔🤔🤔…
33. © Knowledge Work Inc. モジュール化に救われた例：ナレッジの要約処理 33 33 コンテンツ処理に同様の課題を解決する仕組みがあった →リクエストをテナントごとに公平に差配するタスクキュー
34. © Knowledge Work Inc. モジュール化に救われた例：ナレッジの要約処理 34 34 コンテンツ処理系に同様の課題を解決する仕組みがあった →リクエストをテナントごとに公平に差配するタスクキュー →コンテンツ処理系に閉じず、モジュール化されており再利⽤可能