Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

今日、一番伝えたいこと

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

| © 2024 Levtech Co., Ltd. 10 | © 2024 Levtech Co., Ltd. 10 アーキテクチャの変遷 - 年表 -

Slide 11

Slide 11 text

| © 2024 Levtech Co., Ltd. 11 | © 2024 Levtech Co., Ltd. 11 1つのモノリスなら余裕だわ時代 いつの時代だろうかw

Slide 12

Slide 12 text

| © 2024 Levtech Co., Ltd. 12 | © 2024 Levtech Co., Ltd. 12 アーキテクチャの変遷 - 年表 -

Slide 13

Slide 13 text

| © 2024 Levtech Co., Ltd. 13 | © 2024 Levtech Co., Ltd. 13

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

| © 2024 Levtech Co., Ltd. 15 | © 2024 Levtech Co., Ltd. 15 1チームじゃ絶対無理だ時代 キャパオーバー

Slide 16

Slide 16 text

| © 2024 Levtech Co., Ltd. 16 | © 2024 Levtech Co., Ltd. 16 アーキテクチャの変遷 - 年表 -

Slide 17

Slide 17 text

| © 2024 Levtech Co., Ltd. 17 | © 2024 Levtech Co., Ltd. 17

Slide 18

Slide 18 text

| © 2024 Levtech Co., Ltd. 18 | © 2024 Levtech Co., Ltd. 18 ソースコードとDBを Duplicate(複製)して開発

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

| © 2024 Levtech Co., Ltd. 21 | © 2024 Levtech Co., Ltd. 21 TypeScriptの時代がやって来た 人も増えてきた(自分も入社)

Slide 22

Slide 22 text

| © 2024 Levtech Co., Ltd. 22 | © 2024 Levtech Co., Ltd. 22 アーキテクチャの変遷 - 年表 -

Slide 23

Slide 23 text

| © 2024 Levtech Co., Ltd. 23 | © 2024 Levtech Co., Ltd. 23

Slide 24

Slide 24 text

| © 2024 Levtech Co., Ltd. 24 | © 2024 Levtech Co., Ltd. 24 TypeScriptをベース としたシステムにリプレース

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

| © 2024 Levtech Co., Ltd. 26 | © 2024 Levtech Co., Ltd. 26

Slide 27

Slide 27 text

| © 2024 Levtech Co., Ltd. 27 | © 2024 Levtech Co., Ltd. 27 Backendの周辺で 障害が多い? 互いに DBを直接参照していて 変更を行いづらい?

Slide 28

Slide 28 text

| © 2024 Levtech Co., Ltd. 28 | © 2024 Levtech Co., Ltd. 28 Point ② チーム(システム)が分離した状態では 共通機能の統制は難しい

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

| © 2024 Levtech Co., Ltd. 31 | © 2024 Levtech Co., Ltd. 31 アーキテクチャの変遷 - 年表 -

Slide 32

Slide 32 text

| © 2024 Levtech Co., Ltd. 32 | © 2024 Levtech Co., Ltd. 32

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

| © 2024 Levtech Co., Ltd. 37 | © 2024 Levtech Co., Ltd. 37 アーキテクチャの変遷 - 年表 -

Slide 38

Slide 38 text

| © 2024 Levtech Co., Ltd. 38 | © 2024 Levtech Co., Ltd. 38

Slide 39

Slide 39 text

| © 2024 Levtech Co., Ltd. 39 | © 2024 Levtech Co., Ltd. 39 モノレポ化 プロセスも 分離

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

| © 2024 Levtech Co., Ltd. 42 | © 2024 Levtech Co., Ltd. 42 まとめ

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

宣伝

Slide 46

Slide 46 text

| © 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 情報発信中です!!! 宣伝

Slide 47

Slide 47 text

| © 2024 Levtech Co., Ltd. 47 | © 2024 Levtech Co., Ltd. 47 ご清聴ありがとうございました!!!