反省 モジュラモノリス タイミーの試行錯誤と現在地

アーキテクチャ選定の事例と学び ～モノリス、マイクロサービス、モジュラーモノリスの共生と最適化～
https://findy.connpass.com/event/344567/

上記のイベントで発表した内容です。

Transcript

1. 2025/3/12　須貝俊 反省 モジュラモノリス タイミーの試行錯誤と現在地
2. 自己紹介 須貝 俊 • 株式会社タイミー（2022年1月入社）のバックエンドエンジニア • プラットフォームエンジニアリング部所属。バックエンドアプリケーションの内部品質 改善にフォーカスしたチームのPO兼エンジニア • 2022〜2023年頃タイミーのメインのバックエンドAPIのモジュラモノリス化を推進し ていた
3. 目次 • タイミーについて • タイミーのシステムアーキテクチャ • モジュラモノリスを取り巻く状況（ 2025 年3月版） • タイミーのモジュラモノリス化を振り返 る • まとめ
4. 1 タイミーについて
5. タイミーとは 5 ｢働きたい時間｣と｢働いてほしい時間｣を マッチングするスキマバイトサービス 従来の「求人サイト」でも「派遣」でもない
6. タイミーの特徴 6
7. タイミーについて • 「タイミー」というひとつのプロダクトがメイン • 2024年10月期の決算で売上268.8億円 • 今回の発表もあくまで単一プロダクトで事業をスケールさせている事例 ということ を念頭に置いて聞いてほしい ◦ 流行りのコンパウンドスタートアップとかマルチプロダクトの企業ではない （2025年3月時点では）
8. 2 タイミーの システムアーキテクチャ
9. タイミーのシステムアーキテクチャ • 単一のRailsアプリケーションから複数のRailsアプリケーションへ ◦ 一部機能（銀行振込）をサブシステムとして切り出した 高セキュリティ・高耐障害性・サブシステム化。そして2億円 • モノリスの本体APIは現在も成長中 ◦ 2025年3月現在でテーブル数は400弱、Model数は1000強 ▪ 1年半前（2023年10月）時点ではテーブル数200弱、Model数は500弱 だった
10. タイミーのシステムアーキテクチャ すごく簡略化した図
11. これで268億円までいける アーキテクチャに貴賤なし
12. The Majestic Monolith（余談） https://signalvnoise.com/svn3/the-majestic-monolith/
13. 3 モジュラモノリスを取り巻く状 況（2025年3月版）
14. モノリス、モジュラモノリス、マイクロサービス • モノリス、モジュラモノリス、マイクロサービスのおさらい • 端的に言うとシステムをどう分割統治するか という手法 • どれかひとつを選択するというわけではなく、状況に応じて組み合わせるのが現実 的
15. モノリス 単一プロセスのモノリス “全てのコードが単一のプロセスとしてデプ ロイされているシステム” 出典：「モノリスからマイクロサービスへ」 1.2.1 単一プ ロセスのモノリス
16. モジュラモノリス 単一プロセスのモノリスのサブセット “単一プロセスが別々のモジュールで構成 され、それぞれ独立して作業できるもの の、デプロイのために結合する必要がある システムだ。” 出典：「モノリスからマイクロサービスへ」 1.2.1 単一プ ロセスのモノリス
17. マイクロサービス “マイクロサービスとは、ビジネスドメインに 基づいてモデル化された、独立してデプロ イ可能なサービスだ。” 出典：「モノリスからマイクロサービスへ」 1.1 マイクロ サービスとは
18. モジュラモノリスを取り巻く状況（ 2023年10月） • 2022〜23年頃、マイクロサービス疲れ からの揺り戻しとしてモジュラモノリスへ注 目が集まる ◦ Ruby on Rails界隈だとShopify製のpackwerkというツールの登場 ◦ この流れを見てタイミーでもモジュラモノリス化を進めた
19. モジュラモノリスを取り巻く状況（ 2025年3月） • 2024年に入ってShopifyが総括しはじめる ◦ The Myth of the Modular Monolith - Rails World 2024 Eileen Uchitelle - The Myth of the Modular Monolith - Rails World 2024 ◦ A Packwerk Retrospective A Packwerk Retrospective • うまく活用している事例もある ◦ コインチェックさん サイロ化した金融システムを、 packwerk を利用して無事故でリファクタリングした話
20. モジュラモノリスを取り巻く状況（ 2025年3月） • 各社での運用を経てPros/Consが出揃ってきた状況。マイクロサービスとモジュラ モノリス、モノリスそれぞれをフラットに比較できるようになってきたのではないかと いうのが個人的な感想 ◦ モジュラモノリスはハイプサイクルでいうと幻滅期から啓発期の間くらいの感覚（自分の主観）
21. 4 タイミーのモジュラモノリ ス化を振り返る
22. 導入時に解決したかった課題 • 複雑な依存関係 ◦ 変更の影響範囲を把握することが困難 ◦ 上記に伴う開発速度の低下を当時は懸念 • 認知負荷の増加 ◦ タイミーは1プロダクトではあるが複数の業務ドメインを持っている。 1チームが複数のドメインを把 握することに限界がある • 不明瞭な責任範囲 ◦ チームの責任範囲があいまいなため Sentryのアラートの放置、スロークエリの放置などが起きてい る ◦ あるいは過剰に広範囲なオーナーシップが求められる
23. どう解決しようとしたか • Shopifyのpackwerkを使用したモジュラモノリス化 ◦ packwerkはパッケージ間の依存関係の違反検出ツール • パッケージ分割を先に進めて、その後依存関係の整理という方針
24. packwerk packwerk（発音：パックヴェルク、パックワーク） Shopify製のOSS。2020年登場。 Enforcing Modularity in Rails Apps with Packwerk https://shopify.engineering/enforcing-modularity-rails-apps-packwerk クラス（定数）の依存関係のLint - 実行時に影響はない - 開発中に実行したり、CIに組み込んだりしてチェックしている
25. packwerkは依存関係の lint チェックをパスした場合
26. packwerkは依存関係の lint 違反があった場合
27. パッケージ内がひとつの Railsアプリのようになる packs/xxxx配下にapp, specなどを置く。パッケージ内がひとつのアプリケーションのよ うになるイメージ
28. その他 依存関係に違反があったとしてもpackage_todo.ymlに違反内容だけ記録して警告を無 視できる（rubocopのrubocop_todo.ymlのようなもの） よって段階的な移行が容易。
29. packwerk導入の結果 • 2025年3月現在で48のパッケージが生まれた • 全体の67.5%がパッケージ化されている ◦ app配下の.rbファイルの数: 943 ◦ packs配下の.rbファイルの数: 1989
30. 課題① 依存関係 📝 モジュラモノリスにしても依存関係の複雑さは簡単には解決しない • 󰢏Pros ◦ packwerkによってパッケージ間の依存関係の可視化はされた • 󰢄Cons ◦ 依存関係は複雑なままになっている箇所が大半 ◦ packwerk自体はどうコードを整理していくか教えてくれるわけではないので、これは自分たちで試 行錯誤し続ける必要がある ◦ さらにpackwerkでは検出できない類の依存もあるので、 packwerkのチェックをすべてパスしたから OKというわけでもない ◦ マイクロサービスほどではないが境界の試行錯誤のコストは高い
31. 課題② 認知負荷の増加 📝 チームが見るべき対象はある程度明確になった • 󰢏Pros ◦ パッケージ化によってチームが見るべき箇所は限定されてきた ◦ 新規にジョインした人やインターンからはポジティブなフィードバックが多い • 󰢄Cons ◦ コードを読んでいて「このパッケージ何？」というシーンは増えた
32. 課題③ 不明瞭な責任範囲 📝 パッケージ化だけでは責任範囲を明確にできない • 󰢏Pros ◦ パッケージ化 + GitHubのCODEOWNERSでパッケージのオーナーが明確になった • 󰢄Cons ◦ packwerkでコードのグルーピングは楽になるが、 CODEOWNERS単体でも実現は可能なので packwerkが無くても良い ◦ ユーザー価値をベースにチームを作っているので、チームが責任を持つ価値と静的なコードが一致 しないケースではコードオーナーの設定が難しい
33. 学んだこと① そもそも分割をするべきだったのか？ いま振り返ると自分はやるべきではなかった と考えている。 導入時に解決しようとしていた課題はどれも事業やプロダクトの課題ではなかった。 - 分割したら生産性が上がります、は課題としては弱い（本当にまずいケースもある が） - 事業やプロダクトの課題を解決するための分割のほうが推進しやすい（銀行振込 のサブシステム化はこれに該当）
34. 学んだこと② もう一度やり直すならどうするか？ 課題のある箇所に限定して分割を進める。 - アプリケーション全体をパッケージ化しようとするとモジュラモノリスという手段が目 的化する - 強い課題が無いのであればあえてやらない（意思決定を遅延させる） - 必要最低限のアーキテクチャ
35. 学んだこと③ packwerkを導入すべきか？ 使わずに済むなら使わないほうが良い - Railsのレールを外れる代償はある - 事業のコアなモデルの設計に注力するほうが価値がある - 単一のRailsアプリに複数プロダクトが同居しているなどであればまた別 - privacyチェッカーは慎重に使うべき - 開発者の関心事がパッケージの publicなAPIに行き過ぎる危険性がある - それをやりたくて有効化しているなら問題ないが、ツールに振り回されないように
36. 5 まとめ
37. まとめ - プロダクトの課題を解決するために分割する - 課題に応じた必要最低限のアーキテクチャ - モジュラモノリスにもマイクロサービスでも同様 - packwerkは慎重に使うこと - なんとなく良さそうで導入するとツールに振り回される可能性大
38. ご清聴ありがとうございました