モジュラーモノリスでスケーラブルなシステムを作る - BASE のリアーキテクチャのいま

@PHPerKaigi 2025（3/23）プログラミングをするパンダ（@Panda_Program）モジュラーモノリスでスケーラブルなシステムを設計・実装する - BASE のリアーキテクチャのいま 1

2 © 2012-2025 BASE, Inc. 自己紹介 • BASE株式会社 • 所属：BASE
/ Product Dev / feature dev1 • 現在の仕事：シニアエンジニア ◦ フロントエンドもバックエンドも書くフルスタックです ◦ スクラム開発やチームの開発プロセスの改善が好きです • 好きなことと活動 ◦ 執筆 ◦ CodeZine様で「バックエンドエンジニアのためのフロントエンド入門」を現在連載中 ◦ Software Design 2022年3月号で TDD 特集の2,3部を執筆しました ◦ 登壇 ◦ Developers Summit 2025、PHP Conference 2022など ◦ twitter: @Panda_Program プログラミングをするパンダ（@Panda_Program）

3 © 2012-2025 BASE, Inc. 宣伝 YouTubeでエンジニア向けのラジオを配信してます（@dialog-radio） https://www.youtube.com/@dialog-radio/videos • ブログや登壇とはまた違った内容です
◦ プロダクトエンジニアって何だろう？ ◦ プロダクトオーナーとエンジニアの違いとは？ ◦ 勉強会のスキルアップ以外の意義とは？ • 毎週月曜日、朝7時配信 ◦ ぜひご視聴 & チャンネル登録お願いします！

5 © 2012-2025 BASE, Inc. はじめに本日お伝えしたいこと • BASEの新規開発はモジュラーモノリス上で行われている •
PHP界隈でのBASEのイメージを少しでも刷新したい • アーキテクチャの話は設計者であるアーキテクト自身が話すことが多い ◦ それを利用する現場のエンジニアが発表すると違った角度になって意義があるのでは？

6 © 2012-2025 BASE, Inc. 目次１２３モジュラーモノリスとは
BASEのリアーキテクチャの目的リアーキテクチャの現在地 4 4年前の狙いと今

10 © 2012-2025 BASE, Inc. モジュラーモノリスとは Monolith First（2015年）新しいプロジェクトを開始する際には、マイクロサービスではなくモノリスから始めるべきで
あり、特にシンプルなアプリケーションの場合はその方が効果的である。モノリスを先に構築することで、サービス間の適切な境界を特定し、マイクロサービスへの移行をスムーズに行うことができる。 → 適切な境界を見つけた後に、少しずつマイクロサービス化することを提案早すぎるマイクロサービス化への警鐘 Monolith First（Martin Fowler） https://martinfowler.com/bliki/MonolithFirst.html

14 © 2012-2025 BASE, Inc. モジュラーモノリスとは What Is a Modular
Monolith?（Milan Jovanović） https://www.milanjovanovic.tech/blog/what-is-a-modular-monolith

15 © 2012-2025 BASE, Inc. モジュラーモノリスとはモジュラーモノリスは、独立したモジュールやコンポーネントにアプリケーションを構造化するアーキテクチャパターン。関連機能をグループ化することでシステムの凝
集性を大幅に改善する。メリット • 簡単なデプロイ（1つデプロイすればいい） • 開発速度の向上（←コードの論理的な分割） • トランザクション管理が容易（MSAと比較） • 運用の複雑さの低減 • マイクロサービスへの移行が容易モジュラーモノリスの定義 What Is a Modular Monolith?（Milan Jovanović） https://www.milanjovanovic.tech/blog/what-is-a-modular-monolith

16 © 2012-2025 BASE, Inc. モジュラーモノリスとは Shopifyの事例（2019年） • モノリスで困っている ◦
異なる機能が同一のコードベースに密結合 ◦ 機能間の独立性が低い • しかし、マイクロサービスは選びたくない ◦ 小さなサービスの集合体 ◦ サービス間の通信による遅延 ◦ トランザクション制御が難しい • このため、モジュラーモノリスを選択 ◦ 単一のアプリケーション内でモジュール性を高める ◦ モノリスとマイクロサービスの利点があるモノリスからモジュラーモノリスへ移行事例 [翻訳] Shopifyにおけるモジュラモノリスへの移行（@tkyowa） https://qiita.com/tkyowa/items/ae9fa550237cb6f48318

17 © 2012-2025 BASE, Inc. モジュラーモノリスとは Modular Monoliths • Simon
Brown • GOTO 2018 https://www.youtube.com/watch?v=5OjqD-ow8GE

23 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的 [背景] 10年近いサービス + コロナでECが脚光
→ エンジニア採用強化で組織拡大へ [課題] 1. モノリス上のコードベースの巨大化 2. 古いテクノロジー（古いフレームワーク） 3. トラフィックの急増 4. 組織拡大によるアウトプット量の低下 → 中長期的なアーキテクチャ戦略が必要当時直面していた課題

24 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的 BASEの中⻑期的なアーキテクチャ戦略とは、チームを最小単位とした組織的学習を持続させ、ビジネス・テクノロジー・組織の変化に対応しながら、高い生産性を維持して事業競争力を得るための
システムの構造を作り、維持することである（パンダの要約）

25 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的 LeanとDevOpsの科学（通称Accelerate本）「事業競争力とデリバリパフォーマンスに正の相関がある。ユーザーのフィードバックを素早く得られるから」
デリバリを高速化し、PDCAを素早く回して目的不確実性と方法不確実性（=「何を」「どのように」作れば良いのかわからない）に対処するこの組織的学習をチーム単位で実施する。チームこそが学習の最小単位である組織的学習に力を入れる

26 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的ビジネス・組織・テクノロジーの変化に対応 • ビジネス ◦
ビジネス環境 ◦ プロジェクト組成・解散 ◦ etc. • テクノロジー ◦ 適切なモジュール境界 ◦ トレンドやバージョンアップ ◦ etc. • 組織 ◦ 人の入れ替わり ◦ etc. 変化に対応する

27 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的高い生産性と事業競争力「事業競争力とデリバリパフォーマンスに正の相関がある」生産性が高い組織は、以下のケイパビリティ
を持つ（= 以下のことが出来ている） • チームによる実験の奨励‧実現 • チームへのツール選択権限の付与 • 疎結合のアーキテクチャ • 負担の軽い変更承認プロセス • etc. これらを実現するシステム構成にしたい

28 © 2012-2025 BASE, Inc. BASEのリアーキテクチャの目的「アーキテクチャ」は組織の生産性を支え続けるためのシステム構造。チームを元にしたPDCAサイクルを組織全体で回すことで、目的不確実性と方法不確実性
に対処するアーキテクチャを目指す。そのためにモジュラーモノリスを採用した • 例えば ◦ 1つのチームが1つのモジュールを担当して、モジュール単位で学習・最適化する ◦ 境界線もマイクロサービスより楽に引き直せるシステムの構造 BASE大規模リアーキテクチャリング（Satoshi Kawashima） https://speakerdeck.com/nazonohito51/base-rearchitecturing

32 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 A B C 準備
設計実装（i. 共通基盤, ii. モジュール） D 運用・リアーキテクチャ

34 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 Big Picture Event Storming
を実施 • 参加者 ◦ エンジニア（Platform チーム） ◦ エンジニア（その領域に明るい人たち） ◦ プロダクトマネージャー • 目的 ◦ 領域ごとの境界を把握したい ◦ 1領域 = 1モジュールとする 1領域1.5時間とか3時間とかかかったらしい現在15モジュールある（決済、認証など）イベントストーミング（2022年6月）

35 © 2012-2025 BASE, Inc. リアーキテクチャの現在地サービス領域ごとに展開 GitHub Actions で
ECS にデプロイインフラが分かれているため、繁忙期で負荷が高まった時に決済部分だけスケールアウトするなどが可能インフラの整備

37 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 3層構造クリーンアーキテクチャで構成 • Gateways 層（1層目）
◦ Controller や Command など ◦ Repository や Logger などの実装 Gateways は実装の詳細である RoutingにCakePHP5を使っているが、 FW依存があるのはこのレイヤーだけクリーンアーキテクチャベースのモジュラーモノリス（外側） BASE大規模リアーキテクチャリング（Satoshi Kawashima） https://speakerdeck.com/nazonohito51/base-rearchitecturing

38 © 2012-2025 BASE, Inc. リアーキテクチャの現在地この2層がモジュール（BaseIncModule） • Application（2層目） ◦
UseCase（サービス層） • Domain（3層目） ◦ ドメインオブジェクト ▪ Entity ▪ Value Object ◦ インターフェース現在15モジュール存在しているクリーンアーキテクチャベースのモジュラーモノリス（内側） BASE大規模リアーキテクチャリング（Satoshi Kawashima） https://speakerdeck.com/nazonohito51/base-rearchitecturing

39 © 2012-2025 BASE, Inc. リアーキテクチャの現在地ディレクトリ構成（簡略化） services ├── modules（内側）
│ └── Someモジュール │ ├── Application │ │ └── CreateFooUseCase │ └── Domain │ ├── Foo │ └── FooRepositoryInterface └── src（外側。Gateways 層） ├── Controller │ └── FooController └── ModuleImplements └── Someモジュール └── Persistent └── FooRepository クリーンアーキテクチャベースのモジュラーモノリス（ディレクトリ構成）

41 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 UnitOfWorkを内包したトランザクションマネージャーでDBトランザクションの制御を自動化→begin~commitの記述は基本的に不要アプリケーション内で発生する個々の更新
（INSERT、UPDATE、DELETE）を都度実行するのではなく、一旦UnitOfWorkに登録し、最後にまとめて実行する。モジュール間通信でDBを操作しても、同一トランザクションとして扱える（トランザクション整合性の破壊防止）トランザクション管理 - UnitOfWork モジュラモノリスにおけるトランザクション設計の考え方（Satoshi Kawashima） https://speakerdeck.com/nazonohito51/transaction-design-on-modular-monolith

42 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 DomainEventを起点としたイベント駆動な処理を書けるようになっている • DomainEventはEntityのライフサイクル変
化で発生する • イベントは永続化時に自動でpublishされる • リスナーは同期・非同期実行を選択できる開発者がドメインルールの実装に集中することが狙い ex. メンバーシップを開設する（開設Event） → 開設完了メールを送信する（開設Mail送信EventListener）ドメインイベントとイベントリスナー（同期・非同期）

43 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 • 同期的な連携 - ModuleProxy
◦ 他のモジュールから呼べる Public な API ◦ メソッドコールで実現する • 非同期的な連携 - 非同期イベントリスナー非同期で問題ない場合は、非同期が望ましい ex. 仮に顧客管理、通知が別モジュールであり同期連携である場合、メンバーシップの開設ボタンを押す → メールサーバーのエラーでメール送信に失敗する → 開設に失敗する → 開設ができない + 顧客の不満につながるモジュール間連携 What Is a Modular Monolith?（Milan Jovanović） https://www.milanjovanovic.tech/blog/what-is-a-modular-monolith

44 © 2012-2025 BASE, Inc. リアーキテクチャの現在地社内ドキュメントに書いてます • DI 機構
- Ray.DI • Open API によるスキーマ定義 • SQS Worker • 認証 • バッチ - ECS Scheduled Taskで実現 • ロギング • テスト用モジュール • 他サービスとのDBスキーマの共有 kawashimaさんいつか話してねその他いっぱい

46 © 2012-2025 BASE, Inc. リアーキテクチャの現在地各プロジェクトではドメイン駆動設計によって開発作業を行っている • ドメインモデリング、ドメインルールを探す
• ドメインイベントを特定するためにイベントストーミングを実施するなど • （いれば）ドメインエキスパートとの会話必要に応じてイネーブリングチームがドメイン駆動設計の手ほどきをすることで、各チームが最終的に自律して開発可能になるように手伝いをしている Domain層の開発あるチームのイベントストーミングの様子

47 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 Domain層のオブジェクトとInterfaceを利用するサービス層 • UseCase
◦ HttpResponsable 型を返す • Factory • メール通知サービス etc. 将来はAIが書くようになるかも？by kawashima Application層の開発

48 © 2012-2025 BASE, Inc. リアーキテクチャの現在地クリーンアーキテクチャの一番外側インターフェースで定義したクラスを実装する • 永続化層（CQRSを意識）
◦ Repository ◦ QueryService • Web ◦ Controller • Shell ◦ Command etc. CakePHP5に対する依存があるのはここだけ Gateway層の開発

49 © 2012-2025 BASE, Inc. リアーキテクチャの現在地テストのしやすさ、デプロイの単純化、チーム間のコミュニケーションはうまくいっているそれでも課題はある • 学習コストの高さ
◦ モジュラーモノリス自体の考え方を習得しないといけない ◦ モジュールの中を書くときMVCしか慣れてない人には育成・勉強の必要がある • 機能実装やリアーキテクチャが未完了 ◦ モジュールをまたぐ開発、まだモノリス側にしか機能がない etc. ▪ どのチームがどのタイミングで実装する？ • 全体のイベントストーミングは過去に一度開かれただけ ◦ なぜこの構成か、各モジュールの役割は何かを理解する機会が少ない ◦ 「イベントストーミングは定期的にやったほうがいい」は一般論らしい ▪ 人の入れ替わり、理解の深まり、状況の変化 etc.

50 © 2012-2025 BASE, Inc. リアーキテクチャの現在地学べることがたくさんある（現場のエンジニアの感想） • きっとどこでも通用するエンジニアになれる ◦
モジュラーモノリスという中大規模の企業の技術トレンドに乗った開発経験が積める ◦ しっかりしたオブジェクト指向の設計力が身につく ▪ EntityとValue Objectでドメイン層を構築していく ▪ 外部 SDK のバージョンアップも、依存クラスの差し替えで完了した（DIの力） ▪ コア機能に改修を加える開発でもコンフリクト懸念が全然ない • 開発するドメインのことに集中できる ◦ 技術的なことを乗り越えたら、やりたいこと・やるべきことに集中できる ◦ PdM、デザイナーを巻き込んでイベントストーミングをしているチームもある

51 © 2012-2025 BASE, Inc. リアーキテクチャの現在地超おすすめ書籍 • OOPの設計力が確実にレベルアップする •
Domain層とApplication層の設計に役立つ • 社内でも評判が良い（勉強会2回開催済み） ◦ 「EntityとValue Objectを理解できた」 ◦ 「ドメインイベントの意義が分かった」 ◦ 「もっと早く読みたかった」「軽量DDDはもういらない！スタイルガイド本で OOPの実装パターンを学ぼう」(1.4万view)で紹介 https://speakerdeck.com/panda_program/no-more-lightweight-ddd オブジェクト設計スタイルガイド

52 © 2012-2025 BASE, Inc. 宣伝読書会をします - 04/11（金） 19:00
~ • ROSCAさん主催で『オブジェクト設計スタイルガイド』の読書会をします #ROSCAFE • 会場はBASE（六本木一丁目）です https://rosca.connpass.com/event/348360/

54 © 2012-2025 BASE, Inc. リアーキテクチャの現在地モジュラーモノリスの運用 • デプロイ ◦
GitHub Actions からデプロイ ◦ 社内サーベイで CD/CI が高評価 ▪ 高速デプロイの実現 • Slack にエラー通知 • NewRelicのダッシュボードで監視 ◦ （まだないモジュールもある）運用

55 © 2012-2025 BASE, Inc. リアーキテクチャの現在地 • DryRun ◦ 移行前の旧機能と新機能を同時実行し、永続化の
結果を比較するツール ◦ 「リアーキテクチャをお手伝いするDryRunというツールを作りました」 ▪ https://devblog.thebase.in/entry/2024/06/14/110000 • イベントによるサービス間連携 ◦ 旧環境のモノリスでイベントを発行し、モジュラーモノリスでイベントリスナーを動かせる ▪ 移行作業がまだでも新システムで処理を書ける • DBのアクセス制限 ◦ モジュールごとにアクセス可能なテーブルを制限。CIで違反をチェックリアーキテクチャ支援 - プラットフォームチームによる Team Topologies の輪読会用の備忘録 https://zenn.dev/tabio/articles/team-topologies

59 © 2012-2025 BASE, Inc. 4年前の狙いと今今は、1チーム1モジュールではない。オーナーがいるのは全15モジュール中10個。残りは Feature
Dev チームが担当する。事業競争力の源泉となるモジュールは常に開発要望がある。しかし、他はそうでもない専門分化戦略とビジネスニーズの両者の力学をバランスさせた結果こうなった（逆コンウェイ戦略ではない） by kawashima さんモジュール構造と一致させた組織構造 BASE株式会社 BASE Dept Product Dev Division 紹介資料 https://speakerdeck.com/base/base-productdevdivision

60 © 2012-2025 BASE, Inc. モジュールごとに中長期的な開発と運用の責任を担うオーナーとなる専門チームを配置 • Platform チーム ◦
全チームが自走するための支援をする責任を持つ ◦ 結果的に認証などの汎用サブドメインのオーナーとして動く傾向がある • モジュールオーナーのチーム（Cart Team etc.） ◦ 事業競争力の源泉となるコアドメインや周辺を専門的に見て、PDCAを回す ▪ 事業競争力の源泉 =コアモジュール = ビジネス上の頻繁な変更要求 = 頻繁な改修 ◦ 対象モジュールの中長期的な開発・運用の質に責任を持つ • Feature Dev チーム ◦ モジュールオーナーではなく複数のモジュールを横断して新機能開発を行う ◦ その時のビジネスニーズを素早く満たすことに責任を持つ ◦ 傾向として支援サブドメインに近い場所での活動が多い ◦ PdM、デザイナーと協業して機能開発をする 4年前の狙いと今

61 © 2012-2025 BASE, Inc. 4年前の狙いと今 Platform Team Feature Dev
Team Cart Team etc. 汎用サブドメインが多めモジュールオーナー支援サブドメインが多めコアドメインモジュールオーナーモジュールごとに中長期的な開発と運用の責任を担うオーナーとなる専門チームを配置

65 © 2012-2025 BASE, Inc. ◦ モジュラーモノリス ▪ モノリス上のコードベースの巨大化、古いテクノロジーから移行・脱却できた ▪
トラフィックの急増 • → モジュールオーナーが責任を持つ体制に ▪ 組織拡大によるアウトプット量の低下 • → さらにチームが増えてもアウトプットを出せる体制 ◦ 組織的学習 ▪ 技術（How）のPDCAが回っているチーム = モジュールオーナーであるチーム ▪ プロダクトの（What）PDCAを回すチーム = モジュールオーナーではないチーム • ビジネス上の「いま・最も・重要な」領域の開発要望に素早く答える • 機能が市場に刺さらないと開発が継続しないため、技術の学習サイクルは回せないこともある 4年前の狙いと今まとめ

66 © 2012-2025 BASE, Inc. 4年前の狙いと今 • Q. どのようにモジュールの境界線を引きましたか？ ◦
イベントストーミングの後にpivotイベント（不可逆的な変化を引き起こすイベント）を特定し、コアの部分とそうでない部分を分けた。ただし、線引きはどうしても恣意的になるため、他社のECの区分を参考にするなど独自なものにならないように調査した • Q. 開発後、モジュールの引き直しは行われましたか？ ◦ 機能追加時どのモジュールに書くべきかわかりづらい場合は、Platformチームに相談しているため大きく誤ることはない。ただイベントストーミングや境界の再考をすると気づくことはあるかもしれない（が、コア以外はケアしすぎなくてもいいという温度感） • Q. デプロイについてもう少し詳しく教えてください ◦ モジュラーモノリスのコードを1つのDockerイメージとしてビルドし、管理画面や決済など、各領域ごとのECSにデプロイしている。管理画面では決済モジュールのコードは全く呼ばれないということもある発表後に質問頂いたことの Q&A

モジュラーモノリスでスケーラブルなシステムを作る - BASE のリアーキテクチャのいま

モジュラーモノリスでスケーラブルなシステムを作る - BASE のリアーキテクチャのいま

More Decks by panda_program

Other Decks in Technology

Featured

Transcript