増えすぎたマイクロサービスをモジュラーモノリスに移行しているお話

Slide 1

Slide 1 text

増えすぎたマイクロサービスをモジュラーモノリスに移行しているお話  株式会社サイバーエージェント Kazuhiro Tashiro 2023.7.19 技術的負債、どうやって解消した？リアーキテクチャ・リファクタ事例から学ぶ Lunch LT @Findy

Slide 2

Slide 2 text

自己紹介    株式会社サイバーエージェント DeveloperProductivity室  サーバーサイドエンジニア  OSSのフィーチャーフラグマネジメントシステム  Bucketeerの開発・社内SaaSの運用をしています。 

Slide 3

Slide 3 text

本日お話すること      - Bucketeerのアーキテクチャとその課題を簡単に。  - モジュラーモノリスの導入について。 

Slide 4

Slide 4 text

Bucketeer  - フィーチャーフラグ、A/Bテストの提供・管理  - セルフホストして使ってもらえるように準備中です🏃  bucketeer-io/bucketeer https://bucketeer.io/

Slide 5

Slide 5 text

既存のアーキテクチャと課題 

Slide 6

Slide 6 text

既存のアーキテクチャ  - 約30個のマイクロサービスを運用  - 開発初期から機能のドメインに応じてしっかりサービスを分割してきた。   - サービスの数が増えてくると、問題も増えてくる。  - 運用コスト・学習コスト・インフラコスト   - セルフホストユーザーにとってのハードル  

Slide 7

Slide 7 text

全体図 

Slide 8

Slide 8 text

モジュラーモノリスアーキテクチャ  - モノリスとマイクロサービスの中間地点（のどこか）。  - 明確な定義はない。（それぞれの組織・プロダクトがそれぞれのモジュラーモノリスを設計している）  - 「マイクロサービスのコンポーネント性を享受しながらモノリスのシンプルさを享受する」   - 一般的な特徴  - モノリスと同じようにシングルプロセスで動作。   - モノリスと比べて明確な（時に強制的な）コンテキスト境界の設定。  

Slide 9

Slide 9 text

どのようにモジュラーモノリスを導入したか 

Slide 10

Slide 10 text

既存アーキテクチャ  - マイクロサービスのPodにはサイドカーとしてEnvoyを置いている。 

Slide 11

Slide 11 text

変更後アーキテクチャ  - backendというアプリ（コンテナ）を作成。  - backendの中にポートを変えて複数サーバーを立ち上げることにする。  - アプリ内のサービス間通信もAPIを介して行う。  - コンテキスト間での直接関数呼び出しは選択せず。   - 将来またマイクロサービス化する可能性を考慮してAPIを残す。  

Slide 12

Slide 12 text

複数のサーバーをひとつのアプリ内に  単純にgrpcサーバーを並べていく。  https://github.com/bucketeer-io/bucketeer/blob/08a8685d0d53ff1a07dd28ad02c48143ae49d6c4/pkg/backend/cmd/server/server.go#L442-L468  

Slide 13

Slide 13 text

複数のサーバーをひとつのアプリ内に  - 元々のマイクロサービスがシングルランタイム上に並行稼働しているだけなので、既存コード・ディレクトリ構成の変更はほぼ無かった。  account cmd/server.go api/api.go apiサーバーの立ち上げアプリのエントリポイント auth cmd/server.go api/api.go apiサーバーの立ち上げアプリのエントリポイント apiサーバーの立ち上げ api.goの変更は一切無しアプリのエントリポイント account api/api.go backend cmd/server.go auth api/api.go 変更前  変更後 

Slide 14

Slide 14 text

変更前 

Slide 15

Slide 15 text

変更後 

Slide 16

Slide 16 text

アーキテクチャ変更の結果  - backendアプリの内部に11個のサーバーを並列で稼働。  - 当然、個別にスケールできなくなった。  - ただし、集約したサービスの大部分はリクエスト量が多くない。   （管理画面からのアクセス）  - リクエスト量が多いサービスもRedisを利用して負荷をかなり減らしているので、デメリットは小さいと判断。 

Slide 17

Slide 17 text

アーキテクチャ変更の結果    - 起動時間やスケールの所要時間はほとんど変化なし。  - ひとつのアプリ内で複数のサーバーを起動すると影響が出るかもと危惧していたが大丈夫でした。  - Goのnet/httpを単純に使ってるのでリソース消費量は小さい。   - リソース消費の大きな言語やフレームワークを利用していると悪影響が出やすいかもしれない。 

Slide 18

Slide 18 text

実際のPR, Issue    - Issue: マイクロサービスから一部モジュラモノリスへの変更  - https://github.com/bucketeer-io/bucketeer/issues/405  - その他の関連情報やPRなどをこのIssueにまとめています。 

Slide 19

Slide 19 text

まとめ  ひとつのアプリ内で複数サーバーを走らせることによって、増えすぎたマイクロサービスをまとめることができた。   

Slide 20

Slide 20 text

採用強化中です✊  サイバーエージェント Developer Productity室はエンジニア募集中です！  ご興味ある方は是非   DP室公式サイト: https://site.developerproductivity.dev/  を御覧ください！ 