Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
マイクロサービスではなくモジュラモノリスを採用した理由
Search
Kyosuke Awata
July 22, 2023
Programming
4
2.3k
マイクロサービスではなくモジュラモノリスを採用した理由
モジュラモノリス徹底解剖〜実践者から学ぶLunch LT〜 の登壇資料
https://findy.connpass.com/event/289311/
Kyosuke Awata
July 22, 2023
Tweet
Share
More Decks by Kyosuke Awata
See All by Kyosuke Awata
無理せずに みんなで作ろう 発信文化
wooootack
3
1.7k
雰囲気でSWRを使ったらハマった話
wooootack
0
37
RustでREST_APIを開発した話.pdf
wooootack
0
230
Other Decks in Programming
See All in Programming
The Clean ArchitectureがWebフロントエンドでしっくりこないのは何故か / Why The Clean Architecture does not fit with Web Frontend
twada
PRO
56
17k
仕様変更に耐えるための"今の"DRY原則を考える
mkmk884
9
3.3k
もう僕は OpenAPI を書きたくない
sgash708
6
1.9k
React 19アップデートのために必要なこと
uhyo
8
1.6k
LINE messaging APIを使ってGoogleカレンダーと連携した予約ツールを作ってみた
takumakoike
0
130
CDKを使ったPagerDuty連携インフラのテンプレート化
shibuya_shogo
0
120
Better Code Design in PHP
afilina
0
180
Honoとフロントエンドの 型安全性について
yodaka
7
1.5k
⚪⚪の⚪⚪をSwiftUIで再現す る
u503
0
120
kintone開発を効率化するためにチームで試した施策とその結果を大放出!
oguemon
0
340
Jakarta EE meets AI
ivargrimstad
0
680
[JAWS DAYS 2025] 最近の DB の競合解決の仕組みが分かった気になってみた
maroon1st
0
170
Featured
See All Featured
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.2k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7.1k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
175
52k
Why Our Code Smells
bkeepers
PRO
336
57k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
134
33k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.3k
Faster Mobile Websites
deanohume
306
31k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.3k
A Modern Web Designer's Workflow
chriscoyier
693
190k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Transcript
マイクロサービスではなく モジュラモノリスを選んだ理由 ~選ばれたのは、モジュラモノリスでした~
名前 粟田 恭介(@wooootack) 経歴 2019年に異業種からエンジニアに転職し、 2021年にプラハに入社。 仕事内容 フルサイクルエンジニアとしてプロダクト開発全般に従事。 約1年前からチームリーダーとして、マネジメントにも挑戦中。 趣味
車(写真は愛車)、アイドルヲタク(歴長め)、ぷよテト(テトリス勢) 自己紹介
(2022年6⽉にジョイン) アガルートアカデミー 新規サービス等 開発⽀援 ・・・ オンライン資格予備校 運営会社 グループ会社 教育事業の⼀つ アガルートアカデミーについて
技術負債が溜まり続けた既存システム • リリースから約8年、技術負債が溜まり続けていた • テストやドキュメントがなく、全てを知るのは当時の開発者だけ • そしてシステムを直せない結果生まれた、大量の「運用回避」 新機能を別システムとして作り 既存システムから新システムに少しずつ移行
マイクロサービスでやろうよ!
マイクロサービスを侮っていた そう簡単に作れるものではない • サービス間で整合性担保するの、こんな難しいの? • インフラエンジニアいないけど、サービスごとに環境用意できるか? • 経験者いないけど、気合で乗り切れるのか? 社外の経験者に話を伺ってみたが、厳しい意見がほとんど •
デプロイ待ちが発生しているくらい肥大化してないなら、メリットが少ない • 共通処理専門チームやインフラ専門チームが存在していないと手が足りない • おそらく今の状態だと、マイクロサービスが負債になる
やっぱりモノリス、、、?
モノリスで内部品質を高く保つことは難しい • 雑に書くとすぐに大きな泥団子になってしまう • 内部品質を高く保つには、ある程度の設計スキルが必要 • 将来的にマイクロサービスに移行しづらい 将来性が少し心配
第3の選択肢:モジュラモノリス
泥団子化を防ぎやすい シナリオ層 データベース モジュールB モジュールC モジュールA
マイクロサービスへの布石になる サービス境界を探ることができる • モジュール境界はサービス境界に比べて戻しやすい 先にDBを分割することも可能 • モジュールごとにDBを用意しても良い • モジュール間の整合性担保がサービス間の整合性担保に化けるかも?
今日のまとめ
私たちがマイクロサービスを選ばなかった理由 負債になってしまう可能性が高いと判断した • インフラや共通処理の専門チームを用意できる組織の規模ではなかった チームの規模やサービス特性的にも過剰と判断した • チームの規模が大きすぎてデプロイ待ちが起きるよう状況ではなかった • そこまで柔軟なスケールアップが必要ではなかった
私たちがモジュラモノリスを選んだ理由 大きな泥団子状態になるのを防ぎたかった • モジュールという強い概念を持ち込むことで、仮に泥団子になってしまっても、モ ジュール内にその影響をとどめられる マイクロサービスに移行する可能性はゼロではない • サービス境界の見極めや、先にDBを分割するなど、布石にできる
唯一絶対の答えはない 置かれた状況から自分たちにとって最適な選択を導き出す • 組織の規模や文化 • サービスの特性 • エンジニアの技術力 • リリースまでの期間
• など
We are Hiring 株式会社プラハの応募はこちらから ぜひ⼀緒に、ものづくりを楽しみましょう! 頭の中にしかないアイデアを形にしていく「ものづくり」はすごく楽しいことです。 しかし学ぶべきことも数多くあり、難しい局⾯に⽴ち向かうことも多々あることでしょう。 そんな時、⼀緒に切磋琢磨できる仲間が集まっていれば、どんな挑戦にも楽しく挑めるのではないでしょうか。 そのような素晴らしい環境で「ものづくり」をしたいと感じてくれた⽅がいましたら、ぜひお声がけください! 株式会社アガルートテクノロジーズの応募はこちらから
https://tech.agaroot.co.jp/#recruit https://www.praha-inc.com/recruit