モノレポ化、そしてその先へ 〜ヘンリーのRe-architecting戦略〜

モノレポへの移行 LT -生産性の高いアーキテクチャに向けた第一歩- の発表資料です。
https://findy.connpass.com/event/296339/

Transcript

1. Copyrights(c) Henry, Inc. All rights reserved. モノレポ化、そしてその先へ 〜ヘンリーのRe-architecting戦略〜 モノレポへの移行 LT @kohii 2023-10-06
2. Copyrights(c) Henry, Inc. All rights reserved. Kohei Ishikawa / @kohii • 2021.08〜 Henry Inc. ◦ CTO室 Lead Architect ◦ 電子カルテチーム Developer • Indie Hacker • X: @kohii00 About Me
3. Copyrights(c) Henry, Inc. All rights reserved. Henryが作っているもの • レセコン一体型電子カルテ ◦ 電子カルテ: 医療情報を記録・管理するソフトウェア ◦ レセコン: 診療報酬制度に基づいた会計情報を管理する ソフトウェア • ドメインがとんでもなく巨大かつ複雑かつ難解 ◦ うまく扱わないとカオス
4. Copyrights(c) Henry, Inc. All rights reserved. 今日話すこと 1. ヘンリーのバックエンドをモノレポ化した話 2. モノレポ化後の打ち手 3. Re-architectingで大事にしていることとか
5. Copyrights(c) Henry, Inc. All rights reserved. 今日話すこと 1. ヘンリーのバックエンドをモノレポ化した話 2. モノレポ化後の打ち手 3. Re-architectingで大事にしていることとか
6. Copyrights(c) Henry, Inc. All rights reserved. 今年4月にヘンリーのバックエンドをモノレポ化🚀 https://dev.henry.jp/entry/backend-monorepo-part-1
7. Copyrights(c) Henry, Inc. All rights reserved. モノレポ化前のバックエンド（想定） general-api (Accomplishment Team) • 電子カルテ「Henry」のバックエンド本体 • SLOC: 13.9万 receipt-api (Receipt Committee) • general-api から呼び出され、診療報酬 制度に関する処理を行い結果を返す計 算エンジン • Accomplishment Team からの依頼を起 点に receipt-api をインクリメントする • SLOC: 14.6万
8. Copyrights(c) Henry, Inc. All rights reserved. モノレポ化前のバックエンド（実際） • Receipt Committee はユーザー体験を 含めた医事会計業務全般の開発や問い 合わせ先を期待される ◦ general-api やときにはフロントエ ンドの開発も必要 • 逆に、Accomplishment Team も制度の ことを知らずに開発できない
9. Copyrights(c) Henry, Inc. All rights reserved. 1. サービスの切り方自体の問題 • 機能を作るのに仕事の引き継ぎや調整を必要とする構造 • チームの境界付近に非常に難しい問題が落ちている 2. サービス間の関係性の問題 • receipt-api は general-api の内部で定義されたモデルをそのまま受け取る（スタンプ結合。順 応者） • 一方で呼び出しの方向はgeneral-api → receipt-apiで、この方向の依存も当然ある • 双方向の依存 3. 1と2 から、1つの機能を作る上で両サービスを同時に修正する必要 • 分かれて無くていいものが分かれている • 実質はマイクロサービスではなく分散モノリス 課題
10. Copyrights(c) Henry, Inc. All rights reserved. 解決の方針: ドメインによる分割 • ヘンリーのドメインを分割して統治 ◦ ビジネス機能のまとまりに基づいてチーム・システムを グループ化 • 極力チームをまたがずに自律して意思決定・行動し、 単独で価値をデリバリーできるようにする • システムの構造とチームの構造は基本的に一致するよ うにしたい
11. Copyrights(c) Henry, Inc. All rights reserved. 理想への移行の初手としてモノレポ化を選択 󰢏選択肢1. 既存サービスを一旦1つに統合した後にドメインによる整理を進める道 󰢃選択肢2. 理想的な切り方のサービスを作って既存のものを徐々に移行する道 💡選択肢2を選ばなかった理由: • 移行が完了しきるまでのカオス増大 • いつまで経ったも終わらないリスク • “理想的な切り方” が間違っているリスク 💡一方で選択肢1は: • サービスの境界面を含む変更がやりやすくなる（着実に目的に一歩近づける） • 元々密結合なので、アトミックに変更できるようになる利点は大きい（モノレポ化単体でも意味がある） • 容易に後戻りできるし、未来の選択肢が多い。低リスク。
12. Copyrights(c) Henry, Inc. All rights reserved. • 2つの Git リポジトリを1つにまとめる ◦ Git の履歴も統合 • サービスのデプロイメント単位はそのまま • ビルド等の設定を共通化 モノレポ化の内容
13. Copyrights(c) Henry, Inc. All rights reserved. モノレポ化までの道 1. 移行を実現するためのワーキンググループを発足 a. 計画の立案 b. モノレポの具体像の立案 c. モノレポ化のためのバックログの作成・管理 d. 週次でプラン＆状況確認 2. ADRの記述 3. 作業日の決定とアナウンス 4. 準備と手順書の作成 5. やっていき → 入念な準備や便利スクリプトのおかげでスムーズに完了
14. Copyrights(c) Henry, Inc. All rights reserved. それはもううまくいった👏 今回は詳細は割愛します。詳しくはこちらを読んでみてください。 https://dev.henry.jp/entry/backend-monorepo-part-1 医療スタートアップのバックエンドをモノレポ 化した話 〜戦略・プロセス編〜 https://dev.henry.jp/entry/backend-monorepo-part-2 医療系スタートアップのバックエンドをモノ レポ化した話 〜技術編〜
15. Copyrights(c) Henry, Inc. All rights reserved. 今日話すこと 1. ヘンリーのバックエンドをモノレポ化した話 2. モノレポ化後の打ち手 3. Re-architectingで大事にしていることとか
16. Copyrights(c) Henry, Inc. All rights reserved. • ドメインによる分割に向けて匍匐前進中 ◦ ゴールを再定義しすり合わせるのに多くの時間を使った... • 徐々に道が見えてきた モノレポ化後〜今日まで
17. Copyrights(c) Henry, Inc. All rights reserved. やったこと1. モノリス化→整理 ではなく 整理→モノリス化 を 選択 一旦モノリスにしてからドメインの整理をする、という方向で議論を進めていた
18. Copyrights(c) Henry, Inc. All rights reserved. やったこと1. モノリス化→整理 ではなく 整理→モノリス化 を 選択 モノリス化を後回しにして、先に各サービス内でドメインの整理を進める方がいいと判断 （※まだ構想）
19. Copyrights(c) Henry, Inc. All rights reserved. 💡判断の意図: • ドメインの整理という本丸にすぐに着手できる • 巨大な泥団子の回避 ◦ 未整理のものを統合することで認知負荷増大 → 整理の邪魔になる • モノリス化によるデメリット （消費メモリやビルド速度の問題） に対処しやすい ◦ 今のうちにデメリットの回避のための準備ができる ◦ モノリスの期間を短くできる やったこと1. モノリス化→整理 ではなく 整理→モノリス化 を 選択
20. Copyrights(c) Henry, Inc. All rights reserved. やったこと2. 境界が明確なモジュールから括り出す 💡判断の意図: • 整理することで、整理しやすくなる ◦ 残ったコードも複雑度が減り整理しやすくなる ◦ 高凝集・疎結合なパーツを切り出せれば、他の部分との関係も再定義しやすい • ビルド速度向上も見込める ◦ 分けると並列ビルドしやすい、モジュール単位でビルドキャッシュが効く • shared … 特定のドメインによらない、ユーティリティ • master-data … 医療の各制度に基づくマスターデータにアクセスするためのモジュール ◦ データは外部からCSV等で配布される ＝ ヘンリーがモデリングしていないドメイン
21. Copyrights(c) Henry, Inc. All rights reserved. DDDの “境界づけられたコンテキスト” は我々が目指している “ドメインによる分割” のヒントに なりそう • 輪読会 ◦ エリック・エヴァンスのドメイン駆動設計 ◦ 実践ドメイン駆動設計 ◦ マイクロサービスアーキテクチャ • 議論して理解を深める ◦ 抽象的でわかりにくいところもあるので、議論を経て理解を補う ◦ 洞察を社内ブログで共有するメンバーも やったこと3. ドメイン駆動設計（DDD）に学ぶ
22. Copyrights(c) Henry, Inc. All rights reserved. やったこと4. コンテキストマップを描く計画 “境界づけられたコンテキスト” を定義し、俯瞰する見取り図（＝コンテキストマップ）をゲットす る • 「始めるためのスタートライン」としての境界を描く ◦ より確からしい境界はイテレーティブな取り組みの中で見出されていく ◦ その境界はどこまで行っても仮説 ◦ スタート地点として最初の仮説を描きたい • オフラインで集まってガッと描く作戦 ◦ 近々やる予定 ◦ 只今ワークショップのデザイン中（イベントストーミングをベースにした方法を検討）
23. Copyrights(c) Henry, Inc. All rights reserved. 今日話すこと 1. ヘンリーのバックエンドをモノレポ化した話 2. モノレポ化後の打ち手 3. Re-architectingで大事にしていることとか
24. Copyrights(c) Henry, Inc. All rights reserved. 1. 段階的な移行を好む 2. 進化を前提にする 3. 必要十分なアーキテクチャ モノレポ化を含むRe-architectingで大事にしてる考え方
25. Copyrights(c) Henry, Inc. All rights reserved. • 大きな旅路をステップに分けて進む • トランジションのすべての段階でなるべくカオスを増やさない • 一時的なカオスを許容する作戦 → そのカオス期間はだいたい想定よりも 長引く 考え方1. 段階的な移行を好む
26. Copyrights(c) Henry, Inc. All rights reserved. • アーキテクチャはいろいろなもの に影響を受ける • これらはすべて時間と共に変化 する 考え方2. 進化を前提にする
27. Copyrights(c) Henry, Inc. All rights reserved. • 状況も変わるし、自分たちも進化する • 正解は先に進む中で見出されるもの • 拘束力のある長期的な決定は、最終責任時点まで保留 ◦ e.g. マイクロサービスなど 考え方2. 進化を前提にする
28. Copyrights(c) Henry, Inc. All rights reserved. • 開発チームの営みを規定しすぎない • 主役は開発チームであり、適切な判断はそこで生まれる • 権威的なアーキテクトは邪魔になるリスク 考え方3. 必要十分なアーキテクチャ
29. Copyrights(c) Henry, Inc. All rights reserved. • ヘンリーのモノレポ化の取り組みは、“ドメインによる分割” を目指すための 初手 • 只今絶賛匍匐前進中 ◦ もう少し歩みを速めたい... • すべてはドメインの課題にフォーカスするために まとめ
30. Copyrights(c) Henry, Inc. All rights reserved. Thank you We are hiring! https://jobs.henry-app.jp/ 𝕏: @kohii00