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
Nealle
March 07, 2025
Programming
0
810
運用しながらリアーキテクチャ
2025/3/7
事業成長を加速する技術基盤 5社が語るリプレイス・リアーキテクチャの最前線
https://timeedev.connpass.com/event/344976/
Nealle
March 07, 2025
Tweet
Share
More Decks by Nealle
See All by Nealle
TROCCO×dbtで実現する人にもAIにもやさしいデータ基盤
nealle
0
1.5k
AI OCR API on Lambdaを Datadogで可視化してみた
nealle
0
240
生成AI、実際どう? - ニーリーの場合
nealle
0
740
“いい感じ“な定量評価を求めて - Four Keysとアウトカムの間の探求 -
nealle
4
15k
ニーリーにおけるプロダクトエンジニア
nealle
0
1.2k
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
nealle
0
440
事業KPIを基に価値の解像度を上げる
nealle
0
460
一人目PdMとして、まず"自分"をPMFさせることから考える
nealle
0
440
エンジニアが挑む、限界までの越境
nealle
1
1.2k
Other Decks in Programming
See All in Programming
Kiroの仕様駆動開発から見えてきたAIコーディングとの正しい付き合い方
clshinji
1
210
🔨 小さなビルドシステムを作る
momeemt
3
670
為你自己學 Python - 冷知識篇
eddie
1
350
Vue・React マルチプロダクト開発を支える Vite
andpad
0
110
詳解!defer panic recover のしくみ / Understanding defer, panic, and recover
convto
0
230
AIを活用し、今後に備えるための技術知識 / Basic Knowledge to Utilize AI
kishida
21
5.6k
CJK and Unicode From a PHP Committer
youkidearitai
PRO
0
110
テストコードはもう書かない:JetBrains AI Assistantに委ねる非同期処理のテスト自動設計・生成
makun
0
240
RDoc meets YARD
okuramasafumi
4
170
複雑なドメインに挑む.pdf
yukisakai1225
5
1.1k
[FEConf 2025] 모노레포 절망편, 14개 레포로 부활하기까지 걸린 1년
mmmaxkim
0
1.6k
モバイルアプリからWebへの横展開を加速した話_Claude_Code_実践術.pdf
kazuyasakamoto
0
320
Featured
See All Featured
Code Reviewing Like a Champion
maltzj
525
40k
Visualization
eitanlees
148
16k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
Fireside Chat
paigeccino
39
3.6k
Designing for Performance
lara
610
69k
Done Done
chrislema
185
16k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
580
Being A Developer After 40
akosma
90
590k
Rails Girls Zürich Keynote
gr2m
95
14k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.9k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.1k
Site-Speed That Sticks
csswizardry
10
810
Transcript
運用しながらリアーキテクチャ Railsライクなフレームワークで構築されたサービスを運用しながら オニオンアーキテクチャにリアーキしていく 株式会社ニーリー プラットフォーム本部 アーキテクチャチーム 野呂 有我 2025/03/07 事業成長を加速する技術基盤
5社が語るリプレイス・リアーキテクチャの最前線
2 氏名 所属 経歴 野呂 有我 / Yuga NORO 株式会社ニーリー
プラットフォーム本部 アーキテクチャチーム ・大学院時代に友人と楽譜販売サービスを立ち上げ ・その後、SIer企業に参画 ・副業としてニーリーでいくつかの開発に携わる ・フリーランスを経て、ニーリーへ 1|自己紹介
目次 1|自己紹介 2|プロダクト紹介 3|DRFについて 4|起こった問題 5|意思決定 3 6| 振り返り 7|
まとめ・これからのこと
4 2|プロダクト紹介
5 3|Django DRFについて DRFは、超高速開発を可能にするPythonのWeb Framework Djangoのプラグインで、 View/Serializer/Modelの3つのパーツを組み合わせて、一瞬でAPIを構築できる 認証やユーザー管理、ファイルのアップロードに至るまで基本的には全て組込済み
6 弊社もその高速開発を利用し、機能をどんどん作り 急激なグロースを実現 • ・プロダクト開発人数が当初の 2人から20人以上にまで増加 • ・顧客も増え続け、機能開発のさらなる加速が必要になった 3|DRFについて
7 ・スタートアップは最初からそのサービスが成功するかどうかを知る術はない! ・できる限り少ないコストで、できるだけ早くサービスを、機能をリリースし続け、 結果として生き残ったサービスだけが「その先」を知ることができる! ・ 結果として「技術的な借入」が沢山ある状態に ・「借入」は「利息」を生み、開発速度が段々遅くなっていく 3|DRFについて
8 ・開発を止めたくなかった(止められなかった) → 移行中は機能開発が止まってしまう ・移行にかかるリソースも開発に回したかった → 開発アジェンダは増えるばかり ・性能的な面などで問題が起こっているわけではなかった → Python/Django/DRFに問題があるわけではない!
3|DRFについて
9 4|起こった問題 では、その時どんな問題があったか? 1. 依存関係の複雑化 2. 業務ロジックの分散と技術的関心との密結合 3. キャッチアップ難度の増加
10 5|意思決定 意思決定 ・ある日、決済会計領域の大規模な改修が決定 ・そこで今ある問題↓をその領域に持ち込まないためにどうすべきかを考えた 1. 依存関係の複雑化 2. 業務ロジックの分散と技術的関心との密結合 3.
キャッチアップ難度の増加
11 依存関係の複雑化/業務知識の分散/技術的関心との密結合 4|起こった問題
12 意思決定 依存関係の複雑化を食い止めるため以下のルールを策定 1. 別Appの関数への直接依存の禁止 2. 別Appのテーブルへの直接の書き込みの禁止 3. View/SerializerからDBへのアクセスを禁止 4.
SerializerはViewからのみ依存して良い 5. ViewはUrl.pyからのみ依存して良い 5|意思決定
13 意思決定 業務ロジックの分散と技術的関心との密結合を食い止めるため 1. View/Serializer/Modelへの業務ロジック記載を禁止 2. Usecase層という、業務フローを組み立てる層を追加 3. Domain層という、業務ロジックを記載する層を追加 4.
Domain層からDBへの書き込みを禁止 5. DBの読み書きが許される Infrastructure層を追加 5|意思決定
14 意思決定 これにより、各レイヤーの分担と依存の方向は以下のように 5|意思決定
15 意思決定 一般的なオニオンアーキテクチャーを採用 5|意思決定
16 意思決定 これを実現するために、 APIViewとserializers.Serializer以外の使用を断念😭 5|意思決定 一般的なオニオンアーキテクチャーを採用
17 意思決定 これを実現するために、 InjectorというDIコンテナ(のようなもの)を利用 https://github.com/python-injector/injector 5|意思決定 一般的なオニオンアーキテクチャーを採用
18 意思決定 一般的なオニオンアーキテクチャになったため、 新規参画者にも「この領域はオニオンアーキテクチャです」 と言えば大体伝わるようになり、 参画ハードルもグッと下がった! 5|意思決定
19 意思決定 一般的なオニオンアーキテクチャになったため、 新規参画者にも「この領域はオニオンアーキテクチャです」 と言えば大体伝わるようになり、 参画ハードルもグッと下がった! …が 5|意思決定
20 意思決定 ・今オニオンアーキテクチャ化しているのは この青い部分だけ ・その部分については見通しもよくなり、 参画ハードルも下がっていると信じている ・だが未だそうなっていない箇所の方が多い! apps/ ├── __init__.py
├── __pycache__ ├── business_crosscuing ├── cash_selement_common ├── client_analytics ├── client_manuals ├── core ├── core_system_link ├── coupon_page ├── customers ├── digital_cash_results ├── digital_cash_schedules ├── guarantees ├── libs ├── mypage ├── parkings ├── payments ├── platform ├── reservation_and_approval ├── selements └── users 5|意思決定
21 意思決定 5|意思決定
22 意思決定 ・この問題があると、いくらApp1つ単位で依存関係を整理しても、 結局外からDBの値を書き換えられてしまう 5|意思決定
23 意思決定 ・この問題があると、いくらApp1つ単位で依存関係を整理しても、 結局外からDBの値を書き換えられてしまう ・そこで、「Internal API層」を追加 ・これはマイクロサービスであればRPC(Httpなど)に置き換わっているはずの部分 5|意思決定
24 意思決定 5|意思決定
25 意思決定 5|意思決定
26 意思決定 5|意思決定
27 6|振り返りと現状の整理 結果、どうだったか?
28 6|振り返りと現状の整理 導入中 ・DRFの持っている便利機能を大部分捨てる判断のため、 最初はメンバーの反応が気になった ・最初のAppへの導入中は、書く量の増加が目につき不安だった ・最初はもっと厳格にオニオンアーキテクチャを 導入する予定だったが、 必要性の薄そうな部分を少しずつ削って柔軟にした ・この判断も実は少し不安だった
29 6|振り返りと現状の整理 導入中 ・「必要性の薄そうな部分」は、層ではなくルールの厳密さの部分 ・よく言われる完全性・純粋性・性能のどれを犠牲にするか? に加えて、最初のリリースタイミングが早まる選択 はどれか?をよく話し合った(トレードオフ) ・この時「借入メモ」を思いついていたらもう少し判断しやすかっ たかも… ※借入メモについては「開発 借入メモ」でググってください
🙏
30 6|振り返りと現状の整理 導入後 ・最初の導入プロジェクトに参加してくれたメンバーの反応は上々 だった(と思う) ・逆に考えることが減る ・レイヤーが増えることで変更がしやすくなる ・凝集度が高くなるため影響範囲の特定がとにかく簡単 ・というより、層ごとに単体テストがあるので、 影響範囲は勝手に特定される
31 6|振り返りと現状の整理 現時点での所感 ・この形がベストかはわからないが、既存の資産を捨てず、開発速 度も落とさずに(部分的にではるが)問題を解決できた ・もし、同じような課題を抱えている方や、 今後抱える方の問題解決の参考にしていただけたら幸い ・特にInternal API の考え方は、マイクロサービスとモノリスの
いいとこ取りができる可能性があり、おすすめ
32 まとめ ・FrameWorkを捨てる・捨てないの他に、 一部捨てるも判断としてアリ ・ルールは厳密に適用しなくても良いが、 トレードオフは考慮する。そしてコメントする。 ・モジュール単位でリアーキテクチャする場合、他のモジュールの 影響を受けないように層を設けるとヨシ 7|まとめ・これからのこと
33 これからのこと ・新しいApp領域を作成する場合にどんな規範に沿うか、 どんなアーキテクチャを採用するかは概ね決まった ・しかし、実際にはまだ最初に挙げた状態のままのAppが 沢山あり、そしてそれらの領域は大抵コア業務ドメイン ・次は、既存の部分をいかに漸進的によくしていくか、 というお話ができるといいなと思ってます 7|まとめ・これからのこと
ニーリーではプロダクトエンジニア、 その他のポジションも積極採用中です! https://jobs.nealle.com/ We are hiring!!!
Thank you 35