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
730
運用しながらリアーキテクチャ
2025/3/7
事業成長を加速する技術基盤 5社が語るリプレイス・リアーキテクチャの最前線
https://timeedev.connpass.com/event/344976/
Nealle
March 07, 2025
Tweet
Share
More Decks by Nealle
See All by Nealle
“いい感じ“な定量評価を求めて - Four Keysとアウトカムの間の探求 -
nealle
1
10k
ニーリーにおけるプロダクトエンジニア
nealle
0
840
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
nealle
0
130
事業KPIを基に価値の解像度を上げる
nealle
0
370
一人目PdMとして、まず"自分"をPMFさせることから考える
nealle
0
400
エンジニアが挑む、限界までの越境
nealle
1
860
ニーリーQAのこれまでとこれから
nealle
2
1.4k
データ分析で事業貢献するために
nealle
0
1.9k
SREチームのタスク優先度と向き合う Road to SRE NEXT@札幌
nealle
0
190
Other Decks in Programming
See All in Programming
「テストは愚直&&網羅的に書くほどよい」という誤解 / Test Smarter, Not Harder
munetoshi
0
170
#QiitaBash MCPのセキュリティ
ryosukedtomita
1
1.3k
なぜ適用するか、移行して理解するClean Architecture 〜構造を超えて設計を継承する〜 / Why Apply, Migrate and Understand Clean Architecture - Inherit Design Beyond Structure
seike460
PRO
3
770
Deep Dive into ~/.claude/projects
hiragram
14
2.6k
初学者でも今すぐできる、Claude Codeの生産性を10倍上げるTips
s4yuba
16
11k
ペアプロ × 生成AI 現場での実践と課題について / generative-ai-in-pair-programming
codmoninc
2
18k
High-Level Programming Languages in AI Era -Human Thought and Mind-
hayat01sh1da
PRO
0
780
Goで作る、開発・CI環境
sin392
0
230
ISUCON研修おかわり会 講義スライド
arfes0e2b3c
1
450
ふつうの技術スタックでアート作品を作ってみる
akira888
1
860
PipeCDのプラグイン化で目指すところ
warashi
1
280
GitHub Copilot and GitHub Codespaces Hands-on
ymd65536
2
150
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Code Reviewing Like a Champion
maltzj
524
40k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
GitHub's CSS Performance
jonrohan
1031
460k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
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