運用しながらリアーキテクチャ

2025/3/7
事業成長を加速する技術基盤 5社が語るリプレイス・リアーキテクチャの最前線
https://timeedev.connpass.com/event/344976/

Transcript

1. 運用しながらリアーキテクチャ Railsライクなフレームワークで構築されたサービスを運用しながら オニオンアーキテクチャにリアーキしていく 株式会社ニーリー プラットフォーム本部 アーキテクチャチーム 野呂 有我 2025/03/07 事業成長を加速する技術基盤 5社が語るリプレイス・リアーキテクチャの最前線
2. 2 氏名 所属 経歴 野呂 有我 ／ Yuga NORO 株式会社ニーリー プラットフォーム本部 アーキテクチャチーム ・大学院時代に友人と楽譜販売サービスを立ち上げ ・その後、SIer企業に参画 ・副業としてニーリーでいくつかの開発に携わる ・フリーランスを経て、ニーリーへ 1｜自己紹介
3. 目次 1｜自己紹介 2｜プロダクト紹介 3｜DRFについて 4｜起こった問題 5｜意思決定 3 6｜ 振り返り 7｜ まとめ・これからのこと
4. 4 2｜プロダクト紹介
5. 5 3｜Django DRFについて DRFは、超高速開発を可能にするPythonのWeb Framework Djangoのプラグインで、 View/Serializer/Modelの3つのパーツを組み合わせて、一瞬でAPIを構築できる 認証やユーザー管理、ファイルのアップロードに至るまで基本的には全て組込済み
6. 6 弊社もその高速開発を利用し、機能をどんどん作り 急激なグロースを実現 • ・プロダクト開発人数が当初の 2人から20人以上にまで増加 • ・顧客も増え続け、機能開発のさらなる加速が必要になった 3｜DRFについて
7. 7 ・スタートアップは最初からそのサービスが成功するかどうかを知る術はない！ ・できる限り少ないコストで、できるだけ早くサービスを、機能をリリースし続け、 　結果として生き残ったサービスだけが「その先」を知ることができる！ ・ 結果として「技術的な借入」が沢山ある状態に ・「借入」は「利息」を生み、開発速度が段々遅くなっていく 3｜DRFについて
8. 8 ・開発を止めたくなかった（止められなかった） 　→ 移行中は機能開発が止まってしまう ・移行にかかるリソースも開発に回したかった 　→ 開発アジェンダは増えるばかり ・性能的な面などで問題が起こっているわけではなかった 　→ Python/Django/DRFに問題があるわけではない！ 3｜DRFについて
9. 9 4｜起こった問題 では、その時どんな問題があったか？ 1. 依存関係の複雑化 2. 業務ロジックの分散と技術的関心との密結合 3. キャッチアップ難度の増加
10. 10 5｜意思決定 意思決定 ・ある日、決済会計領域の大規模な改修が決定 ・そこで今ある問題↓をその領域に持ち込まないためにどうすべきかを考えた 1. 依存関係の複雑化 2. 業務ロジックの分散と技術的関心との密結合 3. キャッチアップ難度の増加
11. 11 依存関係の複雑化/業務知識の分散/技術的関心との密結合 4｜起こった問題
12. 12 意思決定 依存関係の複雑化を食い止めるため以下のルールを策定 1. 別Appの関数への直接依存の禁止 2. 別Appのテーブルへの直接の書き込みの禁止 3. View/SerializerからDBへのアクセスを禁止 4. SerializerはViewからのみ依存して良い 5. ViewはUrl.pyからのみ依存して良い 5｜意思決定
13. 13 意思決定 業務ロジックの分散と技術的関心との密結合を食い止めるため 1. View/Serializer/Modelへの業務ロジック記載を禁止 2. Usecase層という、業務フローを組み立てる層を追加 3. Domain層という、業務ロジックを記載する層を追加 4. Domain層からDBへの書き込みを禁止 5. DBの読み書きが許される Infrastructure層を追加 5｜意思決定
14. 14 意思決定 これにより、各レイヤーの分担と依存の方向は以下のように 5｜意思決定
15. 15 意思決定 一般的なオニオンアーキテクチャーを採用 5｜意思決定
16. 16 意思決定 これを実現するために、 APIViewとserializers.Serializer以外の使用を断念😭 5｜意思決定 一般的なオニオンアーキテクチャーを採用
17. 17 意思決定 これを実現するために、 InjectorというDIコンテナ(のようなもの)を利用 https://github.com/python-injector/injector 5｜意思決定 一般的なオニオンアーキテクチャーを採用
18. 18 意思決定 一般的なオニオンアーキテクチャになったため、 新規参画者にも「この領域はオニオンアーキテクチャです」 と言えば大体伝わるようになり、 参画ハードルもグッと下がった！ 5｜意思決定
19. 19 意思決定 一般的なオニオンアーキテクチャになったため、 新規参画者にも「この領域はオニオンアーキテクチャです」 と言えば大体伝わるようになり、 参画ハードルもグッと下がった！ …が 5｜意思決定
20. 20 意思決定 ・今オニオンアーキテクチャ化しているのは 　この青い部分だけ ・その部分については見通しもよくなり、 　参画ハードルも下がっていると信じている ・だが未だそうなっていない箇所の方が多い! apps/ ├── __init__.py ├── __pycache__ ├── business_crosscuing ├── cash_selement_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 ├── selements └── users 5｜意思決定
21. 21 意思決定 5｜意思決定
22. 22 意思決定 ・この問題があると、いくらApp1つ単位で依存関係を整理しても、 　結局外からDBの値を書き換えられてしまう 5｜意思決定
23. 23 意思決定 ・この問題があると、いくらApp1つ単位で依存関係を整理しても、 　結局外からDBの値を書き換えられてしまう ・そこで、「Internal API層」を追加 　・これはマイクロサービスであればRPC(Httpなど)に置き換わっているはずの部分 5｜意思決定
24. 24 意思決定 5｜意思決定
25. 25 意思決定 5｜意思決定
26. 26 意思決定 5｜意思決定
27. 27 6｜振り返りと現状の整理 結果、どうだったか？
28. 28 6｜振り返りと現状の整理 導入中 ・DRFの持っている便利機能を大部分捨てる判断のため、 　最初はメンバーの反応が気になった ・最初のAppへの導入中は、書く量の増加が目につき不安だった ・最初はもっと厳格にオニオンアーキテクチャを 　導入する予定だったが、 　必要性の薄そうな部分を少しずつ削って柔軟にした 　　・この判断も実は少し不安だった
29. 29 6｜振り返りと現状の整理 導入中 ・「必要性の薄そうな部分」は、層ではなくルールの厳密さの部分 ・よく言われる完全性・純粋性・性能のどれを犠牲にするか？ 　に加えて、最初のリリースタイミングが早まる選択 　はどれか？をよく話し合った（トレードオフ） ・この時「借入メモ」を思いついていたらもう少し判断しやすかっ　 たかも… 　※借入メモについては「開発　借入メモ」でググってください 🙏
30. 30 6｜振り返りと現状の整理 導入後 ・最初の導入プロジェクトに参加してくれたメンバーの反応は上々　 だった（と思う） ・逆に考えることが減る ・レイヤーが増えることで変更がしやすくなる ・凝集度が高くなるため影響範囲の特定がとにかく簡単 ・というより、層ごとに単体テストがあるので、 　影響範囲は勝手に特定される
31. 31 6｜振り返りと現状の整理 現時点での所感 ・この形がベストかはわからないが、既存の資産を捨てず、開発速　 度も落とさずに（部分的にではるが）問題を解決できた ・もし、同じような課題を抱えている方や、 　今後抱える方の問題解決の参考にしていただけたら幸い ・特にInternal API の考え方は、マイクロサービスとモノリスの 　いいとこ取りができる可能性があり、おすすめ
32. 32 まとめ ・FrameWorkを捨てる・捨てないの他に、 　一部捨てるも判断としてアリ ・ルールは厳密に適用しなくても良いが、 　トレードオフは考慮する。そしてコメントする。 ・モジュール単位でリアーキテクチャする場合、他のモジュールの　 影響を受けないように層を設けるとヨシ 7｜まとめ・これからのこと
33. 33 これからのこと ・新しいApp領域を作成する場合にどんな規範に沿うか、 　どんなアーキテクチャを採用するかは概ね決まった ・しかし、実際にはまだ最初に挙げた状態のままのAppが 　沢山あり、そしてそれらの領域は大抵コア業務ドメイン ・次は、既存の部分をいかに漸進的によくしていくか、 　というお話ができるといいなと思ってます 7｜まとめ・これからのこと
34. ニーリーではプロダクトエンジニア、 その他のポジションも積極採用中です！ https://jobs.nealle.com/ We are hiring!!!
35. Thank you 35