視聴メモ: モジュラモノリス徹底解剖〜実践者から学ぶLunch LT〜
概要
非モジュラーモノリスからモジュラーモノリスへのステップ
株式会社ナレッジワーク 川中さん
なぜモジュラーモノリスにするのか？
チーム事情
マイクロサービスと比較したメリット
バージョン整理整合容易性
インフラ引用容易性
どのように変更したか？
トップレベルには意味ごとにモジュールが並び、その中がclean architectureのようになっている
モジュールが公開するAPI以外はinternal packageへ
まずはディレクトリ分け
まずmodule単位で切って全部公開(ディレクトリだけ移動する)
他のmoduleから内部データが無造作に使われていたりするため、隠蔽は諦める
言語によってはpackage公開ルール周りで不自然な構成になるので、諦める
一部モジュールAPIの公開(隠蔽していく)
容易なモジュールから着手
最終構成
LTの発表内容になかった追加事項
モジュール間のRDBデータ分離は
やっていない
モジュール間のトランザクション
基本的には無いように作る
どうしてもうまくいかないやつは使用を見つめ直す
モジュールの粒度
最初はまずはなるべく小さく(後から解くのは難しい)
小さく分けた複数のモジュールを関連するモジュールでまとめ、大きな意味でのまとまりを後で作る
RDRAとDDDでGoのモジュラーモノリスアプリを設計してみた話
株式会社ラクス 今本さん
別の登壇資料発見
RDRAに関する概念
システム価値
システムが「誰にとっての価値を実現するか」を明らかにする
システム外部環境
システムが「どのように使われるのか」を明らかにする
システム境界
システムと「どう関わるか」を明らかにする
システム
システムそのものを表現する
[アイコン・ダイアグラム]
アイコン
ダイアグラム
作図はdraw.ioで作図した
実践してみた感想
「要件定義」にとどまらず「基本設計」まで踏み込んだドキュメントが完成される
「業務」や「ビジネスユースケース」の分割は難しい
ビジネスとシステムのバランス感覚が必要
基本/詳細設計フェーズ
戦略的DDDを実践
コンテキストマップの作成
ユビキタス言語となる用語集の作成
レイヤードアーキテクチャを採用した
DDDを実践した感想
実装フェーズ
Goでモジュラーモノリス
GoのWorkspace modeを活用
実装の基本方針
未来の話
Goでモジュラーモノリスを実践してみた感想
TypeScript・モジュラーモノリスによる型安全なWebサービス開発
SALESCORE株式会社 成澤さん
最近バズった記事
発表資料
設計紹介
垂直分割: ドメインごとに分割
水平分割: レイヤーごとに分割
どちらも利用している
Turborepoを使ったモノレポ構成
モジュールごとにpackage.jsonを定義し、mainにindex.tsを指定
index.tsにexportしたい関数を書く
実装イメージ
アプリからは「モジュールを呼び出して組み合わせる」イメージで実装できる
良かったところ
複雑なサービスが複数のモジュールから構成されている感覚を強く持てる→頭の中が整理できる
依存関係を強制し、レイヤーを明確にできる
悪かったところ
buildとlintのパフォーマンスが悪い
初期構築の難易度が高い
マイクロサービスではなくモジュラモノリスを採用した理由
株式会社プラハ 粟田さん
技術負債が溜まり続けた既存システム
リリースから8年
テストやドキュメントがない
安易に直せない→大量の「運用回避」
新機能を別システムとして作るという選択を取った
まずはマイクロサービス化を検討した
そう簡単に作れない
コストがかかる
サービスごとにインフラ
社外の経験者に伺っても厳しい意見がほとんど
デプロイまちが発生するくらい肥大化していないならメリットが少ない
逆にマイクロサービスが負債になる
ではモノリス？
雑にかくとすぐに大きな泥団子になる
内部品質を高く保つにはある程度の設計スキルが必要
将来的にマイクロサービスに移行しづらい
モジュラモノリスを検討
モジュールで分けられて疎結合になるため、泥団子化を防ぎやすい
マイクロサービスへの布石になる
モジュール境界はサービス境界に比べて戻しやすい
先にDBを分割することも可能
モジュールごとにDBを用意しても良い
まとめ
マイクロサービスを選ばなかった理由
多くの問題を解決できるが、負債になる可能性が高いと判断
組織の規模に見合わない
モジュラモノリスにした理由
大きな泥団子化を防ぎたかった
マイクロサービスに移行する可能性はゼロではない
モノリスとマイクロサービスを経てモジュラモノリスを導入した実践事例
アソビュー株式会社 兼平さん
アソビューの歴史
モノリス ~2012
マイクロサービス ~2015
モノリス 2020~
目指したもの
事業、組織が拡大してもひとりひとりのパフォーマンスを最大限発揮し、技術だけでなく事業貢献ができるように
実現方法
別記事にて
分割単位、境界の決め方
今後の事業や組織成長、変化も踏まえやすい単位を意識
現状の組織には合わせすぎない、組織変更に適用できるように
DB分割する？
両方のパターンがある
トランザクションは極力分割する
変更容易性は？
マイクロサービスに比べ、モジュールの立ち上げや統廃合はかなり容易
可用性への対応は？
実行時にはモノリスなので単一障害点になりうる
結局どうなのか？
多くの組織で必要十分な選択肢になり得る
オライリーのモノリスからマイクロサービスへ
まとめ
アーキテクチャは事業や組織論と密接に紐づいているため、技術面以外の戦略もセットで現実解を探すことが重要
選択はゼロイチではない
モノリスとマイクロサービスの間くらいの選択肢としてモジュラモノリス
モノリスで十分な場合もある