RailsでModular Monolithを選択された御社に質問したいN個の疑問

タイミーのRailsアプリではModular Monolithを採用しています。具体的にはShopify製のpackwerkを使用しています。 最近では他社での採用事例も見かけるようになってきましたが、それでもまだ手に入る情報は少なく手探りでの開発が続いているのが現状です。 そこで自分たちが実際にpackwerkを導入して「ここはどうするのが正解なんだ？」「他社はどうしているのか知りたい」と思った疑問をいくつかピックアップし、具体的にどういう選択をしたか（もしくは今も悩んでいること）をお話しします。これからpackwerkを導入したいチームにも参考になればと思います。

Transcript

1. 2023/10/04　須貝俊 RailsでModular Monolithを選択された御 社に質問したいN個の疑問 @sugaishun （旧Twitter）
2. 自己紹介 2022年1月ジョイン 所属：IronBank Squad（請求・給与振込などお金周りを頑張るチーム） 　　　モジュラモノリスチーム
3. 目次 • モジュラモノリスを取り巻く状況 • Ruby（Rails）とモジュラモノリス • タイミーとモジュラモノリス化 • packwerkを導入して悩んだ点 • まとめ
4. 1 モジュラモノリスを取り巻く 状況
5. モノリス、モジュラモノリス、マイクロサービス モノリス、モジュラモノリス、マイクロサービスについては「モノリスからマイクロサービス へ」という名著があるのでぜひ読んでください。
6. モノリス 単一プロセスのモノリス “全てのコードが単一のプロセスとしてデプ ロイされているシステム” 出典：「モノリスからマイクロサービスへ」 1.2.1 単一プ ロセスのモノリス
7. モジュラモノリス 単一プロセスのモノリスのサブセット “単一プロセスが別々のモジュールで構成 され、それぞれ独立して作業できるもの の、デプロイのために結合する必要がある システムだ。” 出典：「モノリスからマイクロサービスへ」 1.2.1 単一プ ロセスのモノリス
8. マイクロサービス “マイクロサービスとは、ビジネスドメインに 基づいてモデル化された、独立してデプロ イ可能なサービスだ。” 出典：「モノリスからマイクロサービスへ」 1.1 マイクロ サービスとは
9. モジュラモノリスへの揺り戻し 特に定量的なデータはないが最近モジュラモノリスの勉強会をよく見かける気がする。 マイクロサービスは2010年代前半あたりから盛り上がっていた。クラウドインフラの普 及、コンテナ技術の台頭なども背景にあると思う。 マイクロサービスアーキテクチャは2014年にマーチン・ファウラーとジェームス・ルイスが 提唱したソフトウェア開発手法の1つ。 “コンセプトが先というよりは起きていた事象に名前をつけたもの” 出典：「マイクロサービスに至る歴史とこれから」 https://www.slideshare.net/yusuke/xp2021
10. モジュラモノリスへの揺り戻し 国内でも数多くのプロダクトがマイクロサービスを採用した。それから数年が経ち、総括 する段階に入ったように見える。 t_wadaさんの「技術選定の審美眼（2023年版）」でもこの点について触れられていた。 “一方バックエンドはマイクロサービス疲れとモジュラモノリスへの回帰” 出典：「技術選定の審美眼（ 2023年版）」 https://speakerdeck.com/twada/understanding-the-spiral-of-technologies-2023-edition?slide=19
11. 2 Ruby（Rails）と モジュラモノリス
12. Ruby（Rails）とモジュラモノリス Railsでモジュラモノリスを実現するための代表的パターン - Rails Engineの使用 - モジュールのgem化 - packwerk
13. Rails Engineの使用 Rails Engineを活用して任意のモジュールをEngineとして切り出す。 Engineとは “エンジン (engine) は、ホストとなるRailsアプリケーションに機能を提供するミニチュア版 Railsアプリケーションとみなせます。” 出典：「Railsガイド」 https://railsguides.jp/engines.html
14. gem化 gemを活用して任意のモジュールをgem（ライブラリ）として切り出す。
15. packwerk packwerk（発音：パックヴェルク、パックワーク） Shopify製のOSS。2020年登場。 Enforcing Modularity in Rails Apps with Packwerk https://shopify.engineering/enforcing-modularity-rails-apps-packwerk クラスの依存関係のLint - 実行時に影響はない。 - 開発中に実行したり、CIに組み込んだりしてチェックしている。 Ruby on Railsにおけるモジュラモノリスへの回帰がただの揺り戻しではないのは packwerkの登場によるところが大きいのではないか。
16. packwerkは依存関係のlint チェックをパスした場合
17. packwerkは依存関係のlint 違反があった場合
18. パッケージ内がひとつのRailsアプリのようになる packs/xxxx配下にapp, specなどを置く。パッケージ内がひとつのアプリケーションのよ うになるイメージ
19. その他 依存関係に違反があったとしてもpackage_todo.ymlに違反内容だけ記録して警告を無 視できる（rubocopのrubocop_todo.ymlのようなもの） よって段階的な移行が容易。 また、周辺のツールも豊富。
20. それぞれを比較 評価観点 • モジュール分割の試行錯誤の容易性（可逆性） • 依存関係の検査容易性 • 保守性 • 開発者の学習コスト • 再利用性
21. 試行錯誤容易性（可逆性） Rails Engine 同一リポジトリで完結するため比較的容易。 gem化 リポジトリを分けるので分割の試行錯誤のコストは高い。 packwerk 同一リポジトリで完結するため比較的容易。ファイル移動のみ。
22. 依存関係の検査容易性 Rails Engine エンジンの数が増えたときに大変そう。自分はやり方を知らない。 gem化 Bundlerを使用すれば依存関係を出せそうな気がする。 packwerk packwerkは依存関係の違反検査ツールなので得意。
23. 保守性 Rails Engine 一度仕組みを作ればそこまで労力はかからないように見える。 gem化 デプロイの手間は増えそう。依存gemの更新作業も増える。 packwerk 一度仕組みを作ればそこまで労力はかからない。
24. 学習コスト Rails Engine Railsが用意している仕組みなので情報はある。学習コストは少しある。 gem化 gemを作ったことがあればほぼ無い。 packwerk 学習コストはやや高い。
25. 再利用性 Rails Engine 依存関係を慎重に管理すれば再利用性は高い。 gem化 再利用性は高い。 packwerk 再利用性は低い。
26. 3 タイミーと モジュラモノリス化
27. 課題 コード上で何が何に依存しているのか把握しきれない状態。 上記によって変更による影響範囲がわからない。 また、エンジニアの増加に伴いチームも増えていくため、チームの責任範囲を明確にし ていく必要がある。
28. 前提 Railsアプリケーションとしては中規模程度のモノリス。 テーブル数は200強 Model数は500弱 もともとマイクロサービス化を試していたが、モノリスに戻している。 参考：マイクロサービスからモノリシックへ。チャットサーバ移行の道のり https://tech.timee.co.jp/entry/2022/03/01/112239
29. packwerkの導入 試行錯誤の容易さ、依存関係の検査容易性を重視しpackwerkを選択した。 昨年の10月から本番環境に導入している。
30. 誰が進めているか 当初は20%ルールを活用して自分がサイドプロジェクト的に進めていた。 その後、投資対象としての優先順位が上がり今年の7月からモジュラモノリスチーム（た だし兼務）が誕生し、進行している。 CTO室所属のシニアエンジニアと自分の2名体制。 疑問：モジュラモノリス化、誰が進めていますか？
31. どう分けるか ドメイン（問題領域）単位での分割 物によっては機能単位での分割となっている箇所もある。 疑問：パッケージの粒度はどうしていますか？ - 現在は小さめの粒度で切っておいて後からまとめようと考えている。 - 理想は1チーム1パッケージではあるとは思うが（問題領域とチームが一致している 状態）弊社では組織のほうが流動性が高い。1チーム1パッケージにこだわりすぎる と組織の変更に追従しづらくなる。 - パッケージを細かく分割した上でグルーピング（階層化）などを行えば良いが今は そこまではやっていない。
32. どこから分けるか 特に複雑になってきているスポットワークシステム領域から分割を進めている。
33. 境界の探索 チームでイベント、機能などを洗い出し
34. 境界の探索 グルーピング
35. 内向きの依存が少ない箇所から進める まず請求周りから分割していった。 - ドメインが比較的明確でイメージしやすかった。 - 最初は依存関係はある程度無視して進める想定ではあったが、内向きの依存関係 が少ない箇所から進めるのは良さそうに見える。 - たまたまではあるが「モノリスからマイクロサービスへ」でも（この場合はマイクロ サービスへの移行の話ではあるが）請求書機能を抽出する例が挙げられている。 自分が所属しているチームは請求周りを担当しており、ほとんど該当のパッケージだけ で開発が完結する状況になっている。
36. 現状 packs配下に14のパッケージが生まれた （2023/10/02現在） ファイル数で1600強あるうちの500弱が移 動済み。だいたい3割。 GitHubのコードオーナー機能を活用し、 オーナーを明示している。コードオーナー によるapproveはまだ必須にしていない。
37. 今後 もっと早くapp配下のすべてのコードのパッケージ分割をしてほしい、という要求。 アプローチ - モジュラモノリスチームがトップダウンでパッケージ分割をする。 - パッケージ分割にフォーカスして（精度が落ちても良いので）ボトムアップ的にチー ムが主体となって分割する。
38. トップダウンで分割 兼務を解消して仮に100%リソース投下しても良いと言われたとしても、チームメンバー のポジションの特性上100%フォーカスできる状況になるとは考えにくい（他にも色々な 仕事を抱えている）。 パッケージ分割は可逆性が高いとはいえ、ある程度正解を探したくなるので時間をかけ てドメインを理解した上で分割したくなってしまう。
39. ボトムアップで分割 おそらくコンウェイの法則が加速する。 コンウェイの法則 “システムを設計する組織は、その組織のコミュニケーション構造を模倣した構造を 持つ設計を生み出すことになる。” – Melvin E. Conway トップダウンで分割するよりは早く進みそうではある（後述する仕組みとセットで対応する ことで）。
40. 実験がはじまる（予定） 結果、ボトムアップのアプローチに。app配下のコードの修正を実質不可能にする荒療 治を進める予定。 - app配下からpacks配下へ移動をせざるを得なくなる。 - 導入直後は開発生産性が落ちることが想定されるがこの懸念についてはCTOと合 意済み。 - この実験がどうなるのかは自分も気になるところなので機会があればまた登壇する なり技術ブログで報告するなりしたい。
41. 4 packwerkを導入して 悩んだ点
42. packwerkを導入して悩んだ点 ここからは主にpackwerkを導入して悩んだ点を紹介する。
43. Sorbetを入れるべき？ SorbetはRubyの型チェックツール https://sorbet.org/ packwerkは仕組みとしてはソースコードをパースして定数（Class、Module名など）を抽 出し、依存関係の違反のチェックを行う。 なのでメソッドの引数や戻り値などの型は検査の対象外となる。 出典: packwerkのREADMEのlimitations https://github.com/Shopify/packwerk#limitations
44. Sorbetを入れるべき？ Sorbetを導入すればコード上に型（Class=定数）を書くのでpackwerkの検査の対象と できる。 タイミーではすでにRBS, Steepを導入しているため、さらにSorbetを導入するのは避け たい。 Sorbetを使ったRubyのコードに抵抗感がある（個人の見解）。 ただ、厳密に依存関係をチェックするなら恩恵を受けたい気持ちもある。
45. Railsのアソシエーションに困る packwerkでは定数が検査の対象と先述したが、例外のひとつにRailsのアソシエーショ ンがある。 has_many, belongs_toなどを見て依存関係を検査してくれる。 詳細はAssociationInspectorの実装を読んでください。 https://github.com/Shopify/packwerk/blob/main/lib/packwerk/association_inspector.rb
46. Railsのアソシエーションに困る ActiveRecordのassociationを経由すれば、他のパッケージのコードを呼び出せてしま うのでこの検査自体は非常にありがたい。 定義箇所は上記の検査でわかるがアソシエーションを経由して他のパッケージのデータ にアクセスしている箇所を網羅的に把握するのは骨が折れる。 hacomonoさんの「モノリスなRailsにモジュラーモノリスを導入した話」の「永続化層の分 割の実現」が参考になった。 参考：「モノリスなRailsにモジュラーモノリスを導入した話」 https://techblog.hacomono.jp/entry/2023/08/22/110000
47. publicディレクトリどうする？ 前提：packwerkではpacks/{some_package}/app/public に置いたものは公開イン ターフェイス扱いになり可視性チェックの対象外となる。 何をパッケージのpublicなインターフェイスとして公開するか。 先述したassociationが自由すぎる問題を解消しようとするとRepositoryパターンを導入 して、結果をPOROに変換して返すなどが考えられる。 一方でActiveRecordのメリットが失われることになる。
48. publicディレクトリどうする？ freeeさんの下記の資料にまさに同様の話がある。 参考：「深いドメインと統合型経営プラットフォームを支えるモジュラモノリスの事例」 https://speakerdeck.com/ogugu9/modular-monolith-that-support-deep-domains-and-integrated-manageme nt-platform?slide=20 タイミーの場合、パッケージ分割を先に進めており、ドメイン境界がある程度固まったも のに対してpublicディレクトリの課題に向き合う想定。一部のパッケージでは検証が進 んでいるものの次のフェーズ、という状況。
49. 5 まとめ
50. まとめ タイミーはpackwerkを導入しています。 気になった点については懇親会の時間などにお話できればと思います。 Xでも質問受けますのでぜひ。https://x.com/sugaishun packwerkの導入でお悩みの方ぜひご相談ください。 結局N個の疑問はいくつあったのか。
51. ご清聴ありがとうございました