概要

非モジュラーモノリスからモジュラーモノリスへのステップ

株式会社ナレッジワーク 川中さん

なぜモジュラーモノリスにするのか？

• チーム事情

マイクロサービスと比較したメリット

•  バージョン整理整合容易性

• インフラ引用容易性

どのように変更したか？

• トップレベルには意味ごとにモジュールが並び、その中が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分割する？

• 両方のパターンがある

• トランザクションは極力分割する

変更容易性は？

マイクロサービスに比べ、モジュールの立ち上げや統廃合はかなり容易

可用性への対応は？

• 実行時にはモノリスなので単一障害点になりうる

結局どうなのか？

多くの組織で必要十分な選択肢になり得る

オライリーのモノリスからマイクロサービスへ

まとめ

アーキテクチャは事業や組織論と密接に紐づいているため、技術面以外の戦略もセットで現実解を探すことが重要

• 選択はゼロイチではない

  • モノリスとマイクロサービスの間くらいの選択肢としてモジュラモノリス

  • モノリスで十分な場合もある