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
Ça bouge du côté des animations CSS !
goetter
2
160
Unity Android XR入門
sakutama_11
0
180
PRレビューのお供にDanger
stoticdev
1
240
お前もAI鬼にならないか?👹Bolt & Cursor & Supabase & Vercelで人間をやめるぞ、ジョジョー!👺
taishiyade
7
4.2k
機能が複雑化しても 頼りになる FactoryBotの話
tamikof
1
220
CSS Linter による Baseline サポートの仕組み
ryo_manba
1
160
PHPのバージョンアップ時にも役立ったAST
matsuo_atsushi
0
230
技術を改善し続ける
gumioji
0
150
ABEMA iOS 大規模プロジェクトにおける段階的な技術刷新 / ABEMA iOS Technology Upgrade
akkyie
1
220
Introduction to kotlinx.rpc
arawn
0
770
color-scheme: light dark; を完全に理解する
uhyo
7
500
クリーンアーキテクチャから見る依存の向きの大切さ
shimabox
5
1.1k
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
51k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Java REST API Framework Comparison - PWX 2021
mraible
29
8.4k
Six Lessons from altMBA
skipperchong
27
3.6k
Designing for humans not robots
tammielis
250
25k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
13
1k
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