Tweet
Tweet

Slide 1

Slide 1 text

2025/3/12　須貝俊 反省 モジュラモノリス タイミーの試行錯誤と現在地

Slide 2

Slide 2 text

自己紹介 須貝 俊 ● 株式会社タイミー（2022年1月入社）のバックエンドエンジニア ● プラットフォームエンジニアリング部所属。バックエンドアプリケーションの内部品質 改善にフォーカスしたチームのPO兼エンジニア ● 2022〜2023年頃タイミーのメインのバックエンドAPIのモジュラモノリス化を推進し ていた

Slide 3

Slide 3 text

目次 ● タイミーについて ● タイミーのシステムアーキテクチャ ● モジュラモノリスを取り巻く状況（ 2025 年3月版） ● タイミーのモジュラモノリス化を振り返 る ● まとめ

Slide 4

Slide 4 text

1 タイミーについて

Slide 5

Slide 5 text

タイミーとは 5 ｢働きたい時間｣と｢働いてほしい時間｣を マッチングするスキマバイトサービス 従来の「求人サイト」でも「派遣」でもない

Slide 6

Slide 6 text

タイミーの特徴 6

Slide 7

Slide 7 text

タイミーについて ● 「タイミー」というひとつのプロダクトがメイン ● 2024年10月期の決算で売上268.8億円 ● 今回の発表もあくまで単一プロダクトで事業をスケールさせている事例 ということ を念頭に置いて聞いてほしい ○ 流行りのコンパウンドスタートアップとかマルチプロダクトの企業ではない （2025年3月時点では）

Slide 8

Slide 8 text

2 タイミーの システムアーキテクチャ

Slide 9

Slide 9 text

タイミーのシステムアーキテクチャ ● 単一のRailsアプリケーションから複数のRailsアプリケーションへ ○ 一部機能（銀行振込）をサブシステムとして切り出した 高セキュリティ・高耐障害性・サブシステム化。そして2億円 ● モノリスの本体APIは現在も成長中 ○ 2025年3月現在でテーブル数は400弱、Model数は1000強 ■ 1年半前（2023年10月）時点ではテーブル数200弱、Model数は500弱 だった

Slide 10

Slide 10 text

タイミーのシステムアーキテクチャ すごく簡略化した図

Slide 11

Slide 11 text

これで268億円までいける アーキテクチャに貴賤なし

Slide 12

Slide 12 text

The Majestic Monolith（余談） https://signalvnoise.com/svn3/the-majestic-monolith/

Slide 13

Slide 13 text

3 モジュラモノリスを取り巻く状 況（2025年3月版）

Slide 14

Slide 14 text

モノリス、モジュラモノリス、マイクロサービス ● モノリス、モジュラモノリス、マイクロサービスのおさらい ● 端的に言うとシステムをどう分割統治するか という手法 ● どれかひとつを選択するというわけではなく、状況に応じて組み合わせるのが現実 的

Slide 15

Slide 15 text

モノリス 単一プロセスのモノリス “全てのコードが単一のプロセスとしてデプ ロイされているシステム” 出典：「モノリスからマイクロサービスへ」 1.2.1 単一プ ロセスのモノリス

Slide 16

Slide 16 text

モジュラモノリス 単一プロセスのモノリスのサブセット “単一プロセスが別々のモジュールで構成 され、それぞれ独立して作業できるもの の、デプロイのために結合する必要がある システムだ。” 出典：「モノリスからマイクロサービスへ」 1.2.1 単一プ ロセスのモノリス

Slide 17

Slide 17 text

マイクロサービス “マイクロサービスとは、ビジネスドメインに 基づいてモデル化された、独立してデプロ イ可能なサービスだ。” 出典：「モノリスからマイクロサービスへ」 1.1 マイクロ サービスとは

Slide 18

Slide 18 text

モジュラモノリスを取り巻く状況（ 2023年10月） ● 2022〜23年頃、マイクロサービス疲れ からの揺り戻しとしてモジュラモノリスへ注 目が集まる ○ Ruby on Rails界隈だとShopify製のpackwerkというツールの登場 ○ この流れを見てタイミーでもモジュラモノリス化を進めた

Slide 19

Slide 19 text

モジュラモノリスを取り巻く状況（ 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 を利用して無事故でリファクタリングした話

Slide 20

Slide 20 text

モジュラモノリスを取り巻く状況（ 2025年3月） ● 各社での運用を経てPros/Consが出揃ってきた状況。マイクロサービスとモジュラ モノリス、モノリスそれぞれをフラットに比較できるようになってきたのではないかと いうのが個人的な感想 ○ モジュラモノリスはハイプサイクルでいうと幻滅期から啓発期の間くらいの感覚（自分の主観）

Slide 21

Slide 21 text

4 タイミーのモジュラモノリ ス化を振り返る

Slide 22

Slide 22 text

導入時に解決したかった課題 ● 複雑な依存関係 ○ 変更の影響範囲を把握することが困難 ○ 上記に伴う開発速度の低下を当時は懸念 ● 認知負荷の増加 ○ タイミーは1プロダクトではあるが複数の業務ドメインを持っている。 1チームが複数のドメインを把 握することに限界がある ● 不明瞭な責任範囲 ○ チームの責任範囲があいまいなため Sentryのアラートの放置、スロークエリの放置などが起きてい る ○ あるいは過剰に広範囲なオーナーシップが求められる

Slide 23

Slide 23 text

どう解決しようとしたか ● Shopifyのpackwerkを使用したモジュラモノリス化 ○ packwerkはパッケージ間の依存関係の違反検出ツール ● パッケージ分割を先に進めて、その後依存関係の整理という方針

Slide 24

Slide 24 text

packwerk packwerk（発音：パックヴェルク、パックワーク） Shopify製のOSS。2020年登場。 Enforcing Modularity in Rails Apps with Packwerk https://shopify.engineering/enforcing-modularity-rails-apps-packwerk クラス（定数）の依存関係のLint - 実行時に影響はない - 開発中に実行したり、CIに組み込んだりしてチェックしている

Slide 25

Slide 25 text

packwerkは依存関係の lint チェックをパスした場合

Slide 26

Slide 26 text

packwerkは依存関係の lint 違反があった場合

Slide 27

Slide 27 text

パッケージ内がひとつの Railsアプリのようになる packs/xxxx配下にapp, specなどを置く。パッケージ内がひとつのアプリケーションのよ うになるイメージ

Slide 28

Slide 28 text

その他 依存関係に違反があったとしてもpackage_todo.ymlに違反内容だけ記録して警告を無 視できる（rubocopのrubocop_todo.ymlのようなもの） よって段階的な移行が容易。

Slide 29

Slide 29 text

packwerk導入の結果 ● 2025年3月現在で48のパッケージが生まれた ● 全体の67.5%がパッケージ化されている ○ app配下の.rbファイルの数: 943 ○ packs配下の.rbファイルの数: 1989

Slide 30

Slide 30 text

課題① 依存関係 📝 モジュラモノリスにしても依存関係の複雑さは簡単には解決しない ● 󰢏Pros ○ packwerkによってパッケージ間の依存関係の可視化はされた ● 󰢄Cons ○ 依存関係は複雑なままになっている箇所が大半 ○ packwerk自体はどうコードを整理していくか教えてくれるわけではないので、これは自分たちで試 行錯誤し続ける必要がある ○ さらにpackwerkでは検出できない類の依存もあるので、 packwerkのチェックをすべてパスしたから OKというわけでもない ○ マイクロサービスほどではないが境界の試行錯誤のコストは高い

Slide 31

Slide 31 text

課題② 認知負荷の増加 📝 チームが見るべき対象はある程度明確になった ● 󰢏Pros ○ パッケージ化によってチームが見るべき箇所は限定されてきた ○ 新規にジョインした人やインターンからはポジティブなフィードバックが多い ● 󰢄Cons ○ コードを読んでいて「このパッケージ何？」というシーンは増えた

Slide 32

Slide 32 text

課題③ 不明瞭な責任範囲 📝 パッケージ化だけでは責任範囲を明確にできない ● 󰢏Pros ○ パッケージ化 + GitHubのCODEOWNERSでパッケージのオーナーが明確になった ● 󰢄Cons ○ packwerkでコードのグルーピングは楽になるが、 CODEOWNERS単体でも実現は可能なので packwerkが無くても良い ○ ユーザー価値をベースにチームを作っているので、チームが責任を持つ価値と静的なコードが一致 しないケースではコードオーナーの設定が難しい

Slide 33

Slide 33 text

学んだこと① そもそも分割をするべきだったのか？ いま振り返ると自分はやるべきではなかった と考えている。 導入時に解決しようとしていた課題はどれも事業やプロダクトの課題ではなかった。 - 分割したら生産性が上がります、は課題としては弱い（本当にまずいケースもある が） - 事業やプロダクトの課題を解決するための分割のほうが推進しやすい（銀行振込 のサブシステム化はこれに該当）

Slide 34

Slide 34 text

学んだこと② もう一度やり直すならどうするか？ 課題のある箇所に限定して分割を進める。 - アプリケーション全体をパッケージ化しようとするとモジュラモノリスという手段が目 的化する - 強い課題が無いのであればあえてやらない（意思決定を遅延させる） - 必要最低限のアーキテクチャ

Slide 35

Slide 35 text

学んだこと③ packwerkを導入すべきか？ 使わずに済むなら使わないほうが良い - Railsのレールを外れる代償はある - 事業のコアなモデルの設計に注力するほうが価値がある - 単一のRailsアプリに複数プロダクトが同居しているなどであればまた別 - privacyチェッカーは慎重に使うべき - 開発者の関心事がパッケージの publicなAPIに行き過ぎる危険性がある - それをやりたくて有効化しているなら問題ないが、ツールに振り回されないように

Slide 36

Slide 36 text

5 まとめ

Slide 37

Slide 37 text

まとめ - プロダクトの課題を解決するために分割する - 課題に応じた必要最低限のアーキテクチャ - モジュラモノリスにもマイクロサービスでも同様 - packwerkは慎重に使うこと - なんとなく良さそうで導入するとツールに振り回される可能性大

Slide 38

Slide 38 text

ご清聴ありがとうございました