マイクロサービスではなく モジュラモノリスを選んだ理由 ～選ばれたのは、モジュラモノリスでした～

名前 粟田 恭介（@wooootack） 経歴 2019年に異業種からエンジニアに転職し、 2021年にプラハに入社。 仕事内容 フルサイクルエンジニアとしてプロダクト開発全般に従事。 約1年前からチームリーダーとして、マネジメントにも挑戦中。 趣味 車（写真は愛車）、アイドルヲタク（歴長め）、ぷよテト（テトリス勢） 自己紹介

(2022年6⽉にジョイン) アガルートアカデミー 新規サービス等 開発⽀援 ・・・ オンライン資格予備校 運営会社 グループ会社 教育事業の⼀つ アガルートアカデミーについて

技術負債が溜まり続けた既存システム ● リリースから約8年、技術負債が溜まり続けていた ● テストやドキュメントがなく、全てを知るのは当時の開発者だけ ● そしてシステムを直せない結果生まれた、大量の「運用回避」 新機能を別システムとして作り 既存システムから新システムに少しずつ移行

マイクロサービスでやろうよ！

マイクロサービスを侮っていた そう簡単に作れるものではない ● サービス間で整合性担保するの、こんな難しいの？ ● インフラエンジニアいないけど、サービスごとに環境用意できるか？ ● 経験者いないけど、気合で乗り切れるのか？ 社外の経験者に話を伺ってみたが、厳しい意見がほとんど ● デプロイ待ちが発生しているくらい肥大化してないなら、メリットが少ない ● 共通処理専門チームやインフラ専門チームが存在していないと手が足りない ● おそらく今の状態だと、マイクロサービスが負債になる

やっぱりモノリス、、、？

モノリスで内部品質を高く保つことは難しい ● 雑に書くとすぐに大きな泥団子になってしまう ● 内部品質を高く保つには、ある程度の設計スキルが必要 ● 将来的にマイクロサービスに移行しづらい 将来性が少し心配

第3の選択肢：モジュラモノリス

泥団子化を防ぎやすい シナリオ層 データベース モジュールB モジュールC モジュールＡ

マイクロサービスへの布石になる サービス境界を探ることができる ● モジュール境界はサービス境界に比べて戻しやすい 先にDBを分割することも可能 ● モジュールごとにDBを用意しても良い ● モジュール間の整合性担保がサービス間の整合性担保に化けるかも？

今日のまとめ

私たちがマイクロサービスを選ばなかった理由 負債になってしまう可能性が高いと判断した ● インフラや共通処理の専門チームを用意できる組織の規模ではなかった チームの規模やサービス特性的にも過剰と判断した ● チームの規模が大きすぎてデプロイ待ちが起きるよう状況ではなかった ● そこまで柔軟なスケールアップが必要ではなかった

私たちがモジュラモノリスを選んだ理由 大きな泥団子状態になるのを防ぎたかった ● モジュールという強い概念を持ち込むことで、仮に泥団子になってしまっても、モ ジュール内にその影響をとどめられる マイクロサービスに移行する可能性はゼロではない ● サービス境界の見極めや、先にDBを分割するなど、布石にできる

唯一絶対の答えはない 置かれた状況から自分たちにとって最適な選択を導き出す ● 組織の規模や文化 ● サービスの特性 ● エンジニアの技術力 ● リリースまでの期間 ● など

We are Hiring 株式会社プラハの応募はこちらから ぜひ⼀緒に、ものづくりを楽しみましょう！ 頭の中にしかないアイデアを形にしていく「ものづくり」はすごく楽しいことです。 しかし学ぶべきことも数多くあり、難しい局⾯に⽴ち向かうことも多々あることでしょう。 そんな時、⼀緒に切磋琢磨できる仲間が集まっていれば、どんな挑戦にも楽しく挑めるのではないでしょうか。 そのような素晴らしい環境で「ものづくり」をしたいと感じてくれた⽅がいましたら、ぜひお声がけください！ 株式会社アガルートテクノロジーズの応募はこちらから https://tech.agaroot.co.jp/#recruit https://www.praha-inc.com/recruit