楽ありゃ苦もあるモノレポ化 / Goodness and Difficulties of Monorepo

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta 自己紹介フリーソフトウェア開発出身。OSSプログラマやBtoB研究開発を経て、現在は医療機関向けにウェブサービスを提供する株式会社ヘンリーでSREやセキュリティなどを担当。元SpotBugsの中のひとで静的解析が好きだが、最近はRDBを Kotlinで実装したりGitHub Actionsを育てたりしている。結局は技術的なめんどくささや遅さをぱっぱと解決して、顧客の課題に注力したい人。 2

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta Henryのモノレポ化のあらすじ Henryは電子カルテ・レセコン・オーダリングシステム一体型の医療機関様向けSaaS。バックエンドを計算エンジンとそれ以外、という雑な分け方をしていた。チーム構造とシステム構造の不一致などの問題が発生、分散した密結合状態に。ドメインの分割について改めて話し合い、プロジェクトを統合してモノレポ化することに。 4 https://dev.henry.jp/entry/backend-monorepo-part-1

Slide 5

Slide 5 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta 1. 複数サービスをまたがる変更をアトミックにできるようになった！ 2. 設定や共通クラス、スクリプトなどを一箇所で管理できるようになった！ 3. コンテキスト境界をコードベースに反映するなどの営みがしやすい！ 5 モノレポ化で開発効率がめちゃくちゃ改善した！🙌 https://dev.henry.jp/entry/backend-monorepo-part-1

Slide 6

Slide 6 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta モノレポにはこういうことも期待していた - 機能追加や不具合修正に変更が1プロジェクトにまとまる - チームは一部のサブプロジェクトだけ責任を持つ - 変更した部分だけビルド・テストして細かく検証サイクルを回せる - 手元で簡単に起動して動作確認できる - 他チームとのインタフェース・契約についてコードで議論し合意できる 6

Slide 7

Slide 7 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta Henryモノレポの現在地 - 機能追加や不具合修正のために他プロジェクトも変更しないといけない - 手元ではなかなか起動できない - チームはすべてのサブプロジェクトを配慮しないといけない - 一部変更すると全部ビルド・テストしないといけない - 他チームとのインタフェース・契約はドキュメントで議論 7

Slide 8

Slide 8 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta - 機能追加や不具合修正のために他プロジェクトも変更しないといけない →モノレポにはなったがコードが未整理 - 手元ではなかなか起動できない →インフラの管理が別プロジェクトのまま - チームはすべてのサブプロジェクトを配慮しないといけない →サブプロジェクトを戦略的に分割できていない - 一部変更すると全部ビルド・テストしないといけない →サブプロジェクトを戦略的に分割できていない - 他チームとのインタフェース・契約はドキュメントで議論 →テストが書きにくい、書いて嬉しくなりにくい Henryモノレポの課題整理 8

Slide 9

Slide 9 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta Henryモノレポの課題を解決する 1. コード以外のモノレポ化を進める a. APIスキーマもモノレポの管理下に置く b. 関連サービスを一発で起動できるdocker-composeファイルの作成 2. モノレポとしての行儀を良くする a. プロジェクト構造リファクタリング b. テストの活用 9

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta なぜAPIスキーマを別リポジトリで管理していたか 11 スキーマをAPI公開プロジェクトで管理すると、APIを使う側は複数のリポジトリからスキーマを取得してこないといけない。中央管理すれば、スキーマ情報の取得は1回で済む。リポジトリ間で責務をきれいに分けることを志向していたため、この利点が大きかった。 https://speakerdeck.com/agatan/server-side-architecture-at-henry-inc?slide=20

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta スキーマ駆動のふりかえり 13 観点モノレポ以前モノレポ以降 gRPCとGraphQLの不整合を防ぐ便利便利並行開発の実現チーム構造とシステム構造の不一致により、思ったようなメリットを享受できなかったリポジトリを分けていたがためのコストは削減できた中央集権管理スキーマをかき集める必要がなく便利別管理していることのデメリットが目立ってきた

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta プロジェクト構成リファクタリング 1. CODEOWNERを使う a. チームが見るべきプロジェクトを限定する b. 課題が発生したときに見るべきチームも明確になる（SentryによるCODEOWNER連携） 2. Gradle Build Cacheを活用する a. いらないビルドを減らすのにとても便利、特にテストを省略できるのがいい b. 上流プロジェクトが変更されるとそれに依存する下流プロジェクトも再ビルドになる＝上流がたくさんあって下流が少ないほうが良い 3. こういうの↑ができるようにコードの持ち主を明らかにして依存を整理する a. 一番大変 16

Slide 17

Slide 17 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta プロジェクト構成の理想理想的にはプロジェクト間依存がシンプルで、階層が浅い方が良い。それぞれのプロジェクトは小さく、ぱっとビルド・テストできるようにしたい。ドメインモデルが余計なサードパーティライブラリに依存しない形で書けるとなお良い。 17 https://blog.kengo-toda.jp/entry/2021/01/30/173611

Slide 18

Slide 18 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta よくあるプロジェクト構成実際はプレゼンテーション層からデータアクセス層までを含む大きなプロジェクトとなっている。マスタの存在がプロジェクト階層を深くしている（Shared Libraries Pattern）。ドメインモデルが全文検索などの永続層関係のサードパーティに依存できてしまう。ドメインモデルのテストが大げさになりがち。 18 そもそも適切なドメイン境界がわからん

Slide 19

Slide 19 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta 「適切なドメイン境界」を探して三千里「電子カルテ・レセコン・オーダリングシステム一体型」のSaaSなのだから、その3つに切り分ければいいのでは？ ● あくまでも歴史的な境界であって、ドメインの境界ではないと考えている ○ レセコン（1975年〜） ○ オーダリングシステム（1980年代〜） ○ 電子カルテ（1999年〜） ● 入院情報など、複数システムから参照されるデータも多い ○ 歴史をなぞることよりも、お客様の課題を解決することが大切 19

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta なぜプロジェクト分割が難しいのか 21 $ jdeps \ -include 'com\.example\.packagename\..*' \ -regex 'com\.example\.packagename\..*' \ -dotoutput 'path/to/dot' \ 'path/to/app-all.jar' $ cat 'path/to/dot/app-all.jar.dot' | \ sed 's/ (app-all.jar)//g' | \ dot -Tsvg > 'path/to/output.svg' みんなも自社のjarファイルを解析してみよう！

Slide 22

Slide 22 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta Henryにおけるプロジェクトリファクタリングの現在地 ● モジュラモノリスに持っていく ○ 「ひとつのドメインとして一箇所に凝集されているべきだったもの」をまとめる ○ ビルドの並列性も向上する ● チームの粒度に沿ったプロジェクト構成にするために議論を続ける ○ チームを増やしたり減らしたりという試行錯誤もしている ○ 前例のないシステムを作っているので、フットワーク軽くやっていくのが重要 22

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta テストを活用する 1. テストを書きにくくしている技術的課題の解決 a. マスターデータに依存したコードが多いという前提条件 b. データベースが起動していないとテストが実行できない→Testcontainers c. データベース（Postgres）を起動するのに時間がかかる→Testcontainers d. テストが現在時刻に依存しがち→Clockインタフェースの実装をconstructor injection 2. 自動テストの実行を爆速化 a. マルチスレッド化 b. マルチプロセス化 i. Fan-out ii. Test Distribution c. Predictive Test Selection d. Gradleサブプロジェクトの分割 24

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta SlackやNotionを活用した同期的・非同期的なコミュニケーションを厚くとり、混乱を抑えることを意識しました。またsubmoduleから始めて並行期間を設け、早く失敗する・すぐ直せるように意識していました。詳細は技術ブログで！ 28 Monorepoにするときに混乱しなかった？ https://dev.henry.jp/entry/backend-monorepo-part-2

Slide 29

Slide 29 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta GradleでビルドしているServer-side Kotlinプロジェクトの場合、ビルドのボトルネックはだいたいテスト。2プロジェクトを並列してビルドすれば、CIビルドに必要な実体験時間はほぼ変わりません。なお2リポジトリに共通して存在したクラスを統合し共通ライブラリとして括りだした関係で、トータルの（GitHub Actionsの課金根拠となる）ビルド時間は短縮されています。 29 CIが遅くならない？

Slide 30

Slide 30 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta なります。ただできるだけわかりやすくなるような書き方はあると思っていて、GitHub Actionsのreusable workﬂowを使うとか、できるだけGradle世界で完結させて GitHub Actionsのジョブはシンプルに保つとかの戦い方を選択しています。 30 CI複雑にならないですか？

Slide 31

Slide 31 text

Copyright © Henry, Inc. All rights reserved. #hack_at_delta モノレポ化もそうですが、多くの問題解決はひとりでは実行できません。弊社のこのモノレポ化プロジェクトでもGradleに詳しい人、bash scriptでの自動化に明るい人、detektプラグインを書いた人、サービスの構成に詳しい人など多くのエンジニアが協力しています。ですから自分ではわからないことやできないことに遭遇したときに、自ら学ぶことも大切ですが、他のひとに助けを求めてチームで解決することもできるようになると良いと思います。こうした協力関係のうえに、チームとして・サービスとしての問題解決が成り立つものだと考えます。 31 エンジニアにとって大切なことは何か？