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
9.6k
ニーリーにおけるプロダクトエンジニア
nealle
0
810
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
nealle
0
130
事業KPIを基に価値の解像度を上げる
nealle
0
360
一人目PdMとして、まず"自分"をPMFさせることから考える
nealle
0
400
エンジニアが挑む、限界までの越境
nealle
1
850
ニーリーQAのこれまでとこれから
nealle
2
1.4k
データ分析で事業貢献するために
nealle
0
1.9k
SREチームのタスク優先度と向き合う Road to SRE NEXT@札幌
nealle
0
180
Other Decks in Programming
See All in Programming
Is Xcode slowly dying out in 2025?
uetyo
1
260
20250704_教育事業におけるアジャイルなデータ基盤構築
hanon52_
5
770
10 Costly Database Performance Mistakes (And How To Fix Them)
andyatkinson
0
300
#QiitaBash MCPのセキュリティ
ryosukedtomita
1
1.3k
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
760
Railsアプリケーションと パフォーマンスチューニング ー 秒間5万リクエストの モバイルオーダーシステムを支える事例 ー Rubyセミナー 大阪
falcon8823
5
1.1k
AIと”コードの評価関数”を共有する / Share the "code evaluation function" with AI
euglena1215
1
160
スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略
sutochin26
1
5.2k
What Spring Developers Should Know About Jakarta EE
ivargrimstad
0
450
Discover Metal 4
rei315
2
130
MDN Web Docs に日本語翻訳でコントリビュートしたくなる
ohmori_yusuke
1
120
Deep Dive into ~/.claude/projects
hiragram
14
2.5k
Featured
See All Featured
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Adopting Sorbet at Scale
ufuk
77
9.5k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
Scaling GitHub
holman
459
140k
Building Adaptive Systems
keathley
43
2.7k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
820
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Code Reviewing Like a Champion
maltzj
524
40k
RailsConf 2023
tenderlove
30
1.1k
How to Think Like a Performance Engineer
csswizardry
25
1.7k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
740
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
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