分散システム？モジュラーモノリス？モノレポ？全部やってみた結果は？

分散システム？モジュラーモノリス？モノレポ？全部やってみた結果は？レバテック株式会社 CTO室/テックリード/河村勇樹

|　© Leverages inc. 2 • 所属： ◦ レバテック CTO室テックリード
• 経歴： ◦ レバレジーズ株式会社 ▪ 2021年1月〜現在 • 業務： ◦ システム戦略 / アーキテクト / 採用 / 技術広報 ◦ TOPIC：最近はTiDBの移行を進めています • 趣味： ◦ お酒・ゴルフ（ベスト91）自己紹介 Introduction かわうそ @_syoryu89

今日、一番伝えたいこと

アーキテクチャを変更していく過程で気づいたこと

”アーキテクチャを変更するときは組織・チームの状態も意識せよ”

1. レバテックについて（アーキテクチャの変遷を説明する上で必要な情報のみ）

|　© 2024 Levtech Co., Ltd. 7 |　© 2024 Levtech Co.,
Ltd. 7 事業ポートフォリオ Product エージェントプログラミングスクールコンテンツメディアプラットフォームダイレクトリクルーティング ITエンジニア・クリエイターのフリーランス・転職・就職・教育のすべてを備える採用プラットフォームエージェントを中心に、求人媒体、プログラミング教育まで IT専門職のキャリアを厚くサポート。

Ltd. 8 事業ポートフォリオ Product エージェントプログラミングスクールコンテンツメディアプラットフォームダイレクトリクルーティング ITエンジニア・クリエイターのフリーランス・転職・就職・教育のすべてを備える採用プラットフォームエージェントを中心に、求人媒体、プログラミング教育まで IT専門職のキャリアを厚くサポート。今日の話のメインはこの部分

Ltd. 9 2. アーキテクチャの変遷と勘所アーキテクチャの変遷をたどりながら各Pointについてご紹介（すっ飛ばしている歴史もあるのでご了承ください）

Ltd. 10 アーキテクチャの変遷 - 年表 -

Ltd. 11 1つのモノリスなら余裕だわ時代いつの時代だろうかｗ

Ltd. 13

Ltd. 14 • 1チームで１モノリスを開発 ◦ チームに対してシステムが大きすぎることもなかった（はず） • 機能開発を最優先 ◦ 必要な機能のデリバリーを最優先 ◦ 内部品質を向上させたいなぁぐらいのお気持ちはあった（はず） ▪ テーブルをもう少し正規化しておいてほしかったなぁ ▪ テストを書いておいてほしかったなぁ 1つのモノリスなら余裕だわ時代 2. アーキテクチャ変遷とその結果

Ltd. 15 1チームじゃ絶対無理だ時代キャパオーバー

Ltd. 17

Ltd. 18 ソースコードとDBを Duplicate（複製）して開発

Ltd. 19 Point ① チームのキャパシティを超えてしまうアーキテクチャは選択しないほうが良い

Ltd. 20 • 1チームで4システム（モノリス）を開発 ◦ ソースコードとDBをDuplicate（複製）して開発 ▪ システムが増えてメンテナンスするのも大変になってきた ▪ 言語やフレームワークのバージョンを上げるのもしんどくなってきた • 拡張性を優先して様々な特性を犠牲にした ◦ ある意味、サービス同士を疎結合にしておきたかったんだろう（と仮説） ▪ その代わり重複してしまった重要な機能とデータが誕生してしまう ▪ サービスごとに分散させたくない機能がばらばらに... 1チームじゃ絶対無理だ時代 2. アーキテクチャ変遷とその結果

Ltd. 21 TypeScriptの時代がやって来た人も増えてきた（自分も入社）

Ltd. 23

Ltd. 24 TypeScriptをベースとしたシステムにリプレース

Ltd. 25 • なぜ、TypeScriptにリプレースしたのか？ ◦ 偶有的な複雑性を少なくするため ◦ 言語やフレームワークが古くなってしまったため ◦ チームを分散して開発・運用コストを軽減させるため • リプレースしただけでは品質は部分的にしか向上しない ◦ 本質的な複雑性にまだ立ち向かえていない ▪ 立ち向かうための準備はできた状態 TypeScriptの時代がやって来た 2. システム変遷とその理由

Ltd. 26

Ltd. 27 Backendの周辺で障害が多い？互いに DBを直接参照していて変更を行いづらい？

Ltd. 28 Point ② チーム（システム）が分離した状態では共通機能の統制は難しい

Ltd. 29 • 複製による設計のダメージがここでもろに来た ◦ 登録周りの仕組みを一部変更 ▪ → 変更できていない仕組みの部分で障害... ◦ マスタ・リファレンスデータ（職種やスキルなど）を変更 ▪ → 他のサービスでは変更されておらず障害に... • チーム（システム）が分散した状態ではなかなか統制が取りづらい ◦ ”共通であるべき”ものを共通化すべき ▪ 共通ライブラリ？マイクロサービス？モジュラーモノリス？モノレポ？ TypeScriptの時代がやって来た - リプレース後 - 2. システム変遷とその理由

Ltd. 30 モジュラーモノリスでやってみた時代まあそうも上手くいかない...笑

Ltd. 32

Ltd. 33 チーム間で調整業務が必要になった... 想定していない機能が本番にリリースされてしまい障害も度々発生...

Ltd. 34 Point ③ アーキテクチャを変更するときはチームの独立デプロイ可能性も考慮しよう

Ltd. 35 • Backendがモジュラーモノリスになった ◦ 理由 ▪ マイクロサービスやるキャパシティはさすがにない ▪ 共通ライブラリを作成すると管理するチームが必要になってしまう ◦ 方針 ▪ 共通機能はシステム内の共通モジュールを参照する • チームの独立デプロイ可能性の考慮が足りてなかった ◦ リリースのたびにチーム内で調整が必要になってしまった ▪ 時には予期せず機能が本番にリリースされてしまうことも... モジュラーモノリスでやってみた時代 2. システム変遷とその理由

Ltd. 36 理想状態がやっと見えてきた時代明るい夜明けの予感...笑

Ltd. 38

Ltd. 39 モノレポ化プロセスも分離

Ltd. 40 • モノレポ化によりかゆいところが解消できた ◦ サービスごとにパッケージ化及びプロセスも分離 ▪ 独立デプロイ可能性も向上 ◦ 共通モジュールは共通パッケージ化 ▪ 必要な共通ロジックも同じリポジトリ内で管理 • モノレポ化したけど残ってしまった課題 ◦ 共通パッケージをどこが管理するべきなのか ▪ 暫定で横断チームが管理する形にしました ◦ mainブランチへのマージが各チームで同期してしまう ▪ 他のチームによる変更が起因で障害発生する可能性はある理想状態がやっと見えてきた時代 2. システム変遷とその理由

Ltd. 41 各サービスのプロセス（gRPC）を管理内部にはユースケースやインフラの実装各サービスの共通機能を共通パッケージを管理キャッシュの仕組みを共通化共通のドメインオブジェクトなども管理

Ltd. 42 まとめ

Ltd. 43 • Point ① ◦ チームのキャパシティを超えてしまうアーキテクチャは選択しないほうが良い • Point ② ◦ チーム（システム）が分離した状態では共通機能の統制は難しい • Point ③ ◦ アーキテクチャを変更するときはチームの独立デプロイ可能性も考慮しようまとめ LAST

”アーキテクチャを変更するときは組織・チームの状態も意識せよ”

宣伝

|　© Leverages inc. 46 • 🔥レバテック開発部テックブログ🔥 ◦ https://zenn.dev/p/levtech ◦
2月からZennで開始 ▪ 平均15本/月の記事を公開 • 外部登壇資料 ◦ https://speakerdeck.com/leveragestech • 会社紹介資料_エンジニア職向け ◦ https://speakerdeck.com/leverages/levte ch-hui-she-shao-jie-zi-liao-enziniazhi-xia ng-ke 情報発信中です！！！宣伝

Ltd. 47 ご清聴ありがとうございました！！！

分散システム？モジュラーモノリス？モノレポ？全部やってみた結果は？

分散システム？モジュラーモノリス？モノレポ？全部やってみた結果は？

More Decks by Tech Leverages

Other Decks in Technology

Featured

Transcript