Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
Monorepo on AWS
y_matsuwitter
October 28, 2022
Programming
0
41
Monorepo on AWS
SaaS on AWS 2022懇親会にて登壇
y_matsuwitter
October 28, 2022
Tweet
Share
More Decks by y_matsuwitter
See All by y_matsuwitter
Information management for a culture of speed: The story of Notion and LayerX
ymatsuwitter
4
6.2k
Tech behind LayerX SaaS products
ymatsuwitter
0
1.7k
2022-10-14-geeksai
ymatsuwitter
5
2.3k
DXD2021 Insights From CTOA reports.
ymatsuwitter
1
510
What is a Tech Company
ymatsuwitter
24
11k
The future from software technology
ymatsuwitter
2
3.2k
Cloud Native and Monorepo
ymatsuwitter
2
1.5k
2019-12-12 DMM meetup
ymatsuwitter
0
2.1k
A year of DMM reformation
ymatsuwitter
31
51k
Other Decks in Programming
See All in Programming
Hatena Engineer Seminar #23「新卒研修で気軽に『ありがとう』を伝え合える Slack アプリを開発した話」
slashnephy
0
400
Remix + Cloudflare Pages + D1 で ポケモン SV のレンタルチームを検索できるアプリを作ってみた
kuroppe1819
4
1.4k
TokyoR#103_DataProcessing
kilometer
0
550
OSC大阪 パスワード認証は人類には早すぎる ~ IDaaSを使ったソーシャルログインのすすめ ~
authyasan
7
1.5k
新卒でサービス立ち上げから Hasuraを使って3年経った振り返り
yutorin
0
240
23年のJavaトレンドは?Quarkusで理解するコンテナネイティブJava
tatsuya1bm
1
140
ipa-medit: Memory search and patch tool for IPA without Jailbreaking/ipa-medit-bh2022-europe
tkmru
0
130
存在しないアセットへの参照と 未公開アセットでのネタバレに どう立ち向かうか / How to prevent missing assets and spoilers by assets
orgachem
0
190
CPU/GPU高速化セミナー 浮動小数点から文字列への高速変換の論文を読んでみた / cpugpu acceleration seminar 20230201
fixstars
0
110
domain層のモジュール化 / MoT TechTalk #15
mot_techtalk
0
150
NGK2023S - OCaml最高! スマホ開発にも使えちゃう?!
haochenxie
0
120
Next.js 13 Layout / Streaming SSR 仕組み解説
sumiren
0
170
Featured
See All Featured
Become a Pro
speakerdeck
PRO
6
3.2k
How New CSS Is Changing Everything About Graphic Design on the Web
jensimmons
214
12k
Done Done
chrislema
178
15k
Scaling GitHub
holman
453
140k
Testing 201, or: Great Expectations
jmmastey
25
5.7k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
38
3.6k
JazzCon 2018 Closing Keynote - Leadership for the Reluctant Leader
reverentgeek
175
9.1k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
120
29k
The World Runs on Bad Software
bkeepers
PRO
59
5.7k
Six Lessons from altMBA
skipperchong
15
2.3k
Keith and Marios Guide to Fast Websites
keithpitt
407
21k
Building a Scalable Design System with Sketch
lauravandoore
451
31k
Transcript
© 2022 LayerX Inc. Monorepo on AWS LayerX @y_matsuwitter 2022.10.26
自己紹介
© 2022 LayerX Inc. 3 自己紹介 松本 勇気 (@y_matsuwitter) 株式会社LayerX
代表取締役CTO 株式会社三井物産デジタル・アセットマネジメント 取締 役 日本CTO協会 理事 Fintech/PrivacyTechを主に管掌 趣味は筋トレと料理
課題背景
© 2022 LayerX Inc. 5 リアーキテクチャへの柔軟性 プロダクトが日々進化・複雑化するため、状況に合わせた適切なアーキテクチャへの変化が必須。 柔軟なリアーキテクチャや相互依存の可視化・検証を可能とする仕組みへの投資が求められる。 App API
Product A App API Product A App API Product B App API Product A App API Product B App API Product C API API 共有するロジックの 切り出し サービス間の参照 拡大 拡大
Monorepoとは
© 2022 LayerX Inc. 7 Monorepoの定義 関連するソースコードを一つの repositoryに閉じ込める コードで表現されたサービス間依 存(grpc等)をCI/CDで検証でき
る。 プロダクトに関わる全てのソースコードを一つのrepositoryに含める開発手法をここではMonorepoと呼称する。 構成するシステム間の依存も含めて全てコードに表現されるため、構成変更の検証が簡単。 Monorepo Polyrepo ServiceA repo ServiceB repo Shared Library repo Product repo ServiceA ServiceB Shared Library 一般的手法に取られる管理手法。 サービスや言語・PFごとに repositoryを構築する。
© 2022 LayerX Inc. 8 Monorepo利用時の要求 開発者に認知的・技術的負担を強いることなく、システム間の依存の検証と運用を可能とする開発者体験を求めたい。 そのためにサービス間依存のCIでの検証やテストの差分実行、deployの効率化などが必須。 サービス間依存の検証 •
grpcやgraphqlなどで Server-Client間のIFを定義 • 定義変更時に、依存する Clientサービスを全てユニッ トテスト等で検証することで、 変更影響を理解しやすくした い。 テストの差分実行 • 一つのrepositoryにたくさん のサービスや言語が含まれる。 • repositoryが拡大し続けるた め、毎度単純なテストを回すと 破綻する。 • 変更が影響する箇所のみを検 証したい。 Deployの効率化 • 一つのrepositoryが全ての サービスのDeployソースとな る。 • 変更にて影響あるものだけを 効率的にDeployしたい。
とあるプロジェクトの Monorepo
© 2022 LayerX Inc. 10 Makefileベースの単純なmonorepo 初期のMonorepo導入プロジェクトではbazelとMakefileの2つの選択肢の中でMakefileベースの手法を選択した。 仕組みとしては単純で、各言語に合わせてCIなどの対応処理をMakefileで実装、開発を効率化。 ./typescript ./go
./terraform └package.json └Makefile └Makefile 言語やPFごとに要件は異なる。 それぞれの言語ごとに合わせた Makefileやpackage.jsonを 用意。 Setup, Build, Run, Test, Lintなどの機能をそれぞれで愚 直に実装する方法を取る。 . ├── Makefile ├── README.md ├── containers │ ├── api │ └── migration ├── docker-compose.yml ├── go │ ├── Makefile │ ├── README.md │ ├── cmds │ ├── ent │ ├── go.mod │ ├── go.sum │ ├── gqlgen.yml │ ├── graph │ ├── pkg │ ├── sam │ ├── seed │ ├── services │ └── tools.go ├── package.json ├── terraform │ ├── Makefile │ ├── README.md │ ├── aws │ ├── buildspec.yml │ └── policy ├── typescript │ ├── README.md │ ├── buildspec.yml │ ├── codegen.yml │ ├── package-lock.json │ ├── package.json │ ├── public │ ├── src │ ├── tsconfig.json │ └── yarn.lock └── yarn.lock 図:とあるプロダクトの構成
© 2022 LayerX Inc. 11 Bazel等のツールを使うケースとの比較 Bazelには依存関係の細かな検知を元にしたmonorepo開発における大きなメリットがある。 一方、小規模な組織にとってBazel利用は対応コストが重く、爆速なサービスリリースを目指しMakefileでの対応を選択。 • OSSのmonorepoに向
いたビルドツール • プロジェクト内の全ての ファイルの依存関係を明示 的に指定。 • 依存関係に応じたビルドや テストの実行をサポートす る。 • ビルドやテストの効率化をツールレベルでサポートし てくれる。 • 様々な言語にプラグインで効率的に対応可能。Goで あればgazelleとの組み合わせ。 メリット 課題 • ツール自体の学習コスト・運用コストの高さ。bazel独 自の記法による依存関係定義が必要。 • typescript等、言語によってはそれぞれに合わせた ツールを用いたほうが管理しやすいケースも。
とあるプロジェクトにおける AWSでの取り組みと課題
© 2022 LayerX Inc. 13 deployの効率化 変更されたコードとCodepipelineの対応関係を考慮したDeployフロー構築が必要。 DBスキーマ変更があればマイグレーションとAPI及びLambdaのdeployを行うといったもの。 webapp api_A
terraform api_B db_migration lambda_A lambda_B • サービスごとに一つのCodePipelineを運用 • 効率化のため、サービス間の依存に応じて、依存先のサービスも同期・非同期を選択し つつ順次deployしたい。 • Githubフックな実行だと、全てのCodePipelineが実行されてしまい非効率… 例:各AppのDeploy依存関係
© 2022 LayerX Inc. 14 API Gateway + LambdaでCodePipelineを起動 CodePipelineをベースとしているため、Pipeline実行のフック方法を変更することで対応。
柔軟なルール設定のために、API GatewayとLambdaでGithubのWebhookを作成、Pipelineを実行する形に。 Github Hook API Gateway API Gateway Lambda CodePipeline CodePipeline CodePipeline CodePipeline 変更されたソース情報 を受領 変更内容に対応する CodePipelineを選 択的に実行
© 2022 LayerX Inc. 15 deployスピード vs 丁寧な依存関係の対応 現時点では、deployスピードとdeployの冪等性にまかせてシンプルなdeployを実装。 一方で今後の課題として、より正確なdeployに向けては依存を考慮した順序制御なども検討したい。
• ConditionalにStageやStepを実行・ス キップできる機能がほしい… • 一つのCodePipelineに複数のPipeline を並べたい… 理想の世界 • 実現しているのは、API Gatewayを 通じて、実行対象のCodePipelineを 絞るという仕組みのみ。 現状 • サービス間の依存がある場合、実行タイ ミングによってはdeploy失敗、再デプ ロイが要求される。 ◦ 例: terraformでのインフラ変 更に巻き込まれる…等 課題 • Lambdaにて、実行順序も加味して deployを実行する。 ◦ 単体のLabmdaの実行時間上限アリ • CodePipelineにて承認ステップを挟み、 手動で順序を担保する。 解決手法
まとめ
© 2022 LayerX Inc. 17 Monorepoの旅は続く… リアーキテクチャしやすさを求めてMonorepoを採用。 AWSらしいMonorepoの実装に向けては、特にDeploy面などまだ改善の余地がある。今後も模索していきたい。 リアーキテクチャのために •
サービスの分割容易性を担保 するには、サービス間依存を検 証しやすい仕組みが必要。 • MonorepoはCI段階でそうし た手当が可能であり有力な選 択肢となりうる。 MakefileによるMonorepo • Bazelの学習・運用コストを勘 案し、Makefile等各言語ごと の実行定義を愚直に作成。 • 結果、サービスリリースまでを 小さなチームで迅速に進めら れた。 • 今後、より効率的なビルドなど を踏まえると課題は残る。 Deployの効率化課題 • 変更内容に対応する依存サー ビスのみをDeployしたい。 • 現状はGithub Hook + API Gateway + Lambdaの組 み合わせで実行制御。 • 将来的には、CodePipeline 内で解決できると理想…
ご静聴ありがとうございました