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
kazuhiro Tashiro
July 18, 2023
Technology
3
3.9k
増えすぎたマイクロサービスをモジュラーモノリスに移行しているお話
kazuhiro Tashiro
July 18, 2023
Tweet
Share
More Decks by kazuhiro Tashiro
See All by kazuhiro Tashiro
ECS Fargateを本番投入して得た悲喜交交
masaaania
2
3.9k
Other Decks in Technology
See All in Technology
モノレポにおけるエラー管理 ~Runbook自動生成とチームメンションの最適化
biwashi
0
540
RAID6 を楔形文字で組んで現代人を怖がらせましょう(実装編)
mimifuwa
0
290
Claude Code x Androidアプリ 開発
kgmyshin
1
530
Goss: New Production-Ready Go Binding for Faiss #coefl_go_jp
bengo4com
0
1.1k
Rethinking Incident Response: Context-Aware AI in Practice - Incident Buddy Edition -
rrreeeyyy
0
130
ウォンテッドリーのアラート設計と Datadog 移行での知見
donkomura
0
300
あとはAIに任せて人間は自由に生きる
kentaro
3
1.1k
ドキュメントはAIの味方!スタートアップのアジャイルを加速するADR
kawauso
3
190
Amazon Bedrock AgentCore でプロモーション用動画生成エージェントを開発する
nasuvitz
6
390
JOAI発表資料 @ 関東kaggler会
joai_committee
1
200
Backboneとしてのtimm2025
yu4u
3
1.3k
プロジェクトマネジメントは不確実性との対話だ
hisashiwatanabe
0
200
Featured
See All Featured
A better future with KSS
kneath
239
17k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Documentation Writing (for coders)
carmenintech
73
5k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Scaling GitHub
holman
462
140k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Into the Great Unknown - MozCon
thekraken
40
2k
Making Projects Easy
brettharned
117
6.3k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
6k
Designing for humans not robots
tammielis
253
25k
Transcript
増えすぎたマイクロサービスをモジュラーモノリスに移行 しているお話 株式会社サイバーエージェント Kazuhiro Tashiro 2023.7.19 技術的負債、どうやって解消した?リアーキテクチャ・リファクタ事例から学ぶ Lunch LT @Findy
自己紹介 株式会社サイバーエージェント DeveloperProductivity室 サーバーサイドエンジニア OSSのフィーチャーフラグマネジメントシステム Bucketeerの開発・社内SaaSの運用をしています。
本日お話すること - Bucketeerのアーキテクチャとその課題を簡単に。 - モジュラーモノリスの導入について。
Bucketeer - フィーチャーフラグ、A/Bテストの提供・管理 - セルフホストして使ってもらえるように準備中です🏃 bucketeer-io/bucketeer https://bucketeer.io/
既存のアーキテクチャと課題
既存のアーキテクチャ - 約30個のマイクロサービスを運用 - 開発初期から機能のドメインに応じてしっかりサービスを分割してきた。 - サービスの数が増えてくると、問題も増えてくる。 - 運用コスト・学習コスト・インフラコスト
- セルフホストユーザーにとってのハードル
全体図
モジュラーモノリスアーキテクチャ - モノリスとマイクロサービスの中間地点(のどこか)。 - 明確な定義はない。(それぞれの組織・プロダクトがそれぞれのモジュラーモノリスを設 計している) - 「マイクロサービスのコンポーネント性を享受しながらモノリスのシンプルさを享受する」 -
一般的な特徴 - モノリスと同じようにシングルプロセスで動作。 - モノリスと比べて明確な(時に強制的な)コンテキスト境界の設定。
どのようにモジュラーモノリスを導入したか
既存アーキテクチャ - マイクロサービスのPodにはサイドカーとしてEnvoyを置いている。
変更後アーキテクチャ - backendというアプリ(コンテナ)を作成。 - backendの中にポートを変えて複数サーバーを立ち上げることにする。 - アプリ内のサービス間通信もAPIを介して行う。 - コンテキスト間での直接関数呼び出しは選択せず。
- 将来またマイクロサービス化する可能性を考慮してAPIを残す。
複数のサーバーをひとつのアプリ内に 単純にgrpcサーバーを並べていく。 https://github.com/bucketeer-io/bucketeer/blob/08a8685d0d53ff1a07dd28ad02c48143ae49d6c4/pkg/backend/cmd/server/server.go#L442-L468
複数のサーバーをひとつのアプリ内に - 元々のマイクロサービスがシングルランタイム上に並行稼働しているだけなので、 既存コード・ディレクトリ構成の変更はほぼ無かった。 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 変更前 変更後
変更前
変更後
アーキテクチャ変更の結果 - backendアプリの内部に11個のサーバーを並列で稼働。 - 当然、個別にスケールできなくなった。 - ただし、集約したサービスの大部分はリクエスト量が多くない。 (管理画面からのアクセス) -
リクエスト量が多いサービスもRedisを利用して負荷をかなり減らしているので、デメリッ トは小さいと判断。
アーキテクチャ変更の結果 - 起動時間やスケールの所要時間はほとんど変化なし。 - ひとつのアプリ内で複数のサーバーを起動すると影響が出るかもと危惧していたが大 丈夫でした。 - Goのnet/httpを単純に使ってるのでリソース消費量は小さい。
- リソース消費の大きな言語やフレームワークを利用していると悪影響が出やすいかもし れない。
実際のPR, Issue - Issue: マイクロサービスから一部モジュラモノリスへの変更 - https://github.com/bucketeer-io/bucketeer/issues/405 - その他の関連情報やPRなどをこのIssueにまとめています。
まとめ ひとつのアプリ内で複数サーバーを走らせることによって、増えす ぎたマイクロサービスをまとめることができた。
採用強化中です✊ サイバーエージェント Developer Productity室はエンジニア募集中で す! ご興味ある方は是非 DP室公式サイト: https://site.developerproductivity.dev/ を御覧ください!