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.4k
マイクロサービスではなくモジュラモノリスを採用した理由
モジュラモノリス徹底解剖〜実践者から学ぶ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
FAST導入1年間のふりかえり〜現実を直視し、さらなる進化を求めて〜 / Review of the first year of FAST implementation
wooootack
1
250
FASTと向き合うことで見えた、大規模アジャイルの難しさと楽しさ / FAST Taught Me Large-Scale Agile Hardships and Fun
wooootack
2
1.1k
(新URLに移行しました)FASTと向き合うことで見えた、大規模アジャイルの難しさと楽しさ
wooootack
0
1.1k
チーム全員で品質課題の改善のために取り組んだことを振り返る / Quality improvement team reflection
wooootack
4
2.5k
無理せずに みんなで作ろう 発信文化
wooootack
3
3.1k
雰囲気でSWRを使ったらハマった話
wooootack
0
53
RustでREST_APIを開発した話.pdf
wooootack
0
250
Other Decks in Programming
See All in Programming
Jakarta EE Meets AI
ivargrimstad
0
520
Go製CLIツールをnpmで配布するには
syumai
2
1k
DataformでPythonする / dataform-de-python
snhryt
0
130
商品比較サービス「マイベスト」における パーソナライズレコメンドの第一歩
ucchiii43
0
240
11年かかって やっとVibe Codingに 時代が追いつきましたね
yimajo
0
230
変化を楽しむエンジニアリング ~ いままでとこれから ~
murajun1978
0
630
[Codecon - 2025] Como não odiar seus testes
camilacampos
0
100
AIに安心して任せるためにTypeScriptで一意な型を作ろう
arfes0e2b3c
0
310
Claude Code派?Gemini CLI派? みんなで比較LT会!_20250716
junholee
1
770
「次に何を学べばいいか分からない」あなたへ──若手エンジニアのための学習地図
panda_program
3
690
ご注文の差分はこちらですか? 〜 AWS CDK のいろいろな差分検出と安全なデプロイ
konokenj
4
720
LLMは麻雀を知らなすぎるから俺が教育してやる
po3rin
3
1.6k
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1370
200k
Balancing Empowerment & Direction
lara
1
520
Building an army of robots
kneath
306
45k
How to Think Like a Performance Engineer
csswizardry
25
1.8k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
47
9.6k
Mobile First: as difficult as doing things right
swwweet
223
9.8k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.6k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Faster Mobile Websites
deanohume
308
31k
Art, The Web, and Tiny UX
lynnandtonic
301
21k
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