ソフトウェアを“整理整頓”し直す：BASEの商品機能リアーキテクチャ

@BASEとセーフィーが語るバックエンド開発の技術的負債解消への道のりという勉強会にて発表した資料になります

BASEではリアーキテクチャが行われていますが、その中で商品編集機能のリアーキテクチャを行っておりその内容について共有しています

Transcript

1. © 2012-2025 BASE, Inc. 1 ソフトウェアを“整理整頓”し直す： BASEの商品機能リアーキテクチャ @BASEとセーフィーが語るバックエンド開発の 技術的負債解消への道のり 久保田 祐介（ykbt）
2. © 2012-2025 BASE, Inc. 2 久保田 祐介（ykbt） • BASE株式会社 所属 ◦ Tech / Service / TechGrowth Hub/ Platform エンジニア • 現在の仕事 ◦ 新基盤へのリアーキテクチャ作業を主に行っています ◦ バックエンドエンジニアです • 好きなこと ◦ サウナとキャンプ • X: @ykbt13 自己紹介
3. © 2012-2025 BASE, Inc. 3 • BASEで行われているリアーキテクチャについて共有 ◦ なぜやっているかという点は簡潔に、過去の発表なども共有 • 今回は、最近行っている商品のリアーキテクチャに絞って共有 ◦ 進め方や、しんどさの部分が共有できたらなと思っています • この辺の話はあまりしません ◦ BASEが採用しているアーキテクチャの詳細（モジュラーモノリス、DDDなど） ◦ AIを活用したリアーキテクチャ はじめに
4. © 2012-2025 BASE, Inc. 4 BASEのリアーキテクチャについて BASEの巨大ドメイン「商品」 どう進めていったのか 目次 3 4 1 2 9 まとめ
5. © 2012-2025 BASE, Inc. 5 © 2012-2025 BASE, Inc. 5 BASEのリアーキテクチャについて
6. © 2012-2025 BASE, Inc. 6 • 色々な課題があり、中長期的にそれらの課題を解決できるアーキテクチャ がほしかった ◦ レガシーなOSSからの脱却 ◦ 大量トラフィックをさばき切れるアプリケーション ◦ 巨大化したコードベースであっても容易に変化を可能にする • 従来の環境では巨大なモノリスとなっており、これらの課題を解決してい くのが困難 → リアーキテクチャを実施している なぜ、リアーキテクチャをするのか
7. © 2012-2025 BASE, Inc. 7 ぜひ過去の発表もご確認ください モジュラーモノリスでスケーラブルなシステムを設計・実装する - BASE のリアーキテクチャのいま (プログラミングをするパンダ) https://speakerdeck.com/panda_program/base-modular-monolith BASE大規模リアーキテクチャリング (Satoshi Kawashima) https://speakerdeck.com/nazonohito51/base-rearchitecturing
8. © 2012-2025 BASE, Inc. 8 リアーキテクチャの大枠設計 共通基盤作り 移行作業、新機能開発は新環境で BASEのリアーキテクチャ状況 3 4 1 2 旧環境を無くす イマココ
9. © 2012-2025 BASE, Inc. 9 • 新たなアーキテクチャを取り入れた新環境の共通基盤は揃いきった形 • ほとんどの新機能開発は新環境で実装されるようになっている • とはいえ巨大で移行しきれていないドメイン（例：商品）などが、旧環境 に残されていて、それが故に一部旧環境への新機能開発が行われる状態 BASEのリアーキテクチャ状況
10. © 2012-2025 BASE, Inc. 10 © 2012-2025 BASE, Inc. 10 BASEの巨大ドメイン「商品」
11. © 2012-2025 BASE, Inc. 11 • 成長のスピードは止めたくないので、ほそぼそと取り組んでいる ◦ 大々的な移行作業はカート機能を移行する際に行っていて、あとは新環境へちょこ ちょこ移行を行っていっている ◦ これらの移行に合わせて、リアーキテクチャを主導しているチームが共通基盤的な 仕組みを整えている • 新たな機能を作る際に、関連する機能を新環境で一緒に実装 ◦ 例：新機能を追加する際に、旧環境にある1つのAPIを新環境に一緒に移行 リアーキテクチャへの取り組み方
12. © 2012-2025 BASE, Inc. 12 この方法の難点として、 新機能の開発と一緒に移行することが難しいような規模の機能は、 常に旧環境に残り続けてしまうという話がある リアーキテクチャへの取り組み方
13. © 2012-2025 BASE, Inc. 13 BASEにおける商品という巨大ドメイン
14. © 2012-2025 BASE, Inc. 14 • 商品というドメインはECにおける入口のドメイン、 BASEにおいても色々な機能と密接に紐づいている • 巨大すぎて開発のついでで移行することの現実味がない ◦ リアーキテクチャのために開発を1年伸ばしさせてもらいますねー！ はできない 比較的リアーキテクチャへのリソースが使いやすい リアーキテクチャ主導チームで、ついでではない移行作業を実施 BASEにおける商品という巨大ドメイン
15. © 2012-2025 BASE, Inc. 15 BASEの新環境では、DDDを採用している • 誤解を恐れずにいうと、書込の複雑性を解消してくれる設計手法といえる • まず取り掛かるとすれば、書込処理 ◦ 一通りの書込処理を行っている機能を移行すれば、ドメインモデルが一通り準備さ れている状態を作れる ◦ 新環境での開発がスムーズに行えるようになるはず 商品にまつわる各機能への書込を行っている 商品作成・編集機能のリアーキテクチャをまずは進めていく形に 商品の作成・編集
16. © 2012-2025 BASE, Inc. 16 商品の作成・編集 これらの更新処理を新環境へ移行していく リアーキテクチャを実施していきました
17. © 2012-2025 BASE, Inc. 17 © 2012-2025 BASE, Inc. 17 どう進めていったのか
18. © 2012-2025 BASE, Inc. 18 関連機能の洗い出し 各機能のコンテキスト分割 旧・新環境の比較を行う仕組み作り どう進めたのか 3 4 1 2 移行作業
19. © 2012-2025 BASE, Inc. 19 関連機能の洗い出し
20. © 2012-2025 BASE, Inc. 20 関連機能の洗い出し • 作成・編集画面の処理を起点に、関連する機能を調査 ◦ 画面で入力した内容がどう更新されるかだけではなく、 何のために更新しているのかを含めて調べる ◦ 例：「予約 App」という機能は、 直ぐに発送はできないがある日付以降に発送が可能になる ◦ 例：「ラベル App」という機能は、 商品ページ上に特定のラベルをつける（セール中など）
21. © 2012-2025 BASE, Inc. 21 関連機能の洗い出し ブレスト的に各機能の調査を実施
22. © 2012-2025 BASE, Inc. 22 各機能のコンテキスト分割
23. © 2012-2025 BASE, Inc. 23 各機能のコンテキスト分割 • 洗い出した機能が実現したいことから、 境界づけられたコンテキストを決定していく ◦ それぞれの機能を俯瞰的に見ていって、 今あるモジュールのどのあたりに属しそうか、みたいなことを考える ◦ 例：「予約 App」は特定の日付以降で発送が可能になる商品として定義する → 販売に関連するモジュールに属させる ◦ 例：「ラベル App」は購入を促すための商品の付帯情報を定義する → 商品の陳列に関連するモジュールに属させる
24. © 2012-2025 BASE, Inc. 24 各機能のコンテキスト分割 ある程度の機能の単位で所属させるコンテキストを決定している
25. © 2012-2025 BASE, Inc. 25 旧・新環境の比較を行う仕組み作り
26. © 2012-2025 BASE, Inc. 26 リアーキテクチャを進めていくうえでの方法論として、 リライト（書き直し）かリファクタかという話がある • リライト：進めたい方向にスピード感を持って挑めるが、 動作を保証することが難しい、ビッグバンリリースになる • リファクタ：修正を繰り返していく必要はあるが、 動作を保証しやすい、リリースも細かく実施できる リライトとリファクタリング レガシーソフトウェア改善ガイド クリス・バーチャル 著, 吉川 邦夫 翻 訳, 翔泳社, 2016発行 https://www.shoeisha.co.jp/book /detail/9784798145143
27. © 2012-2025 BASE, Inc. 27 BASEではコードベースが全く違う環境への置き換えになるので、 基本的にリライトになってしまう 旧環境でリファクタリングを繰り返していき、 理想の形になったら新環境へ移すという方法も取れるが 以下の理由からリライトを選択 • 移行作業におけるスピード感 • 旧環境と同じ処理が行われているか動作保証できる仕組みづくり リライトとリファクタリング
28. © 2012-2025 BASE, Inc. 28 • DryRunという比較を行う仕組みを準備 ◦ 以前ブログにも書かせてもらっている仕組みです ◦ https://devblog.thebase.in/entry/2024/06/14/110000 旧・新環境の比較を行う仕組み作り
29. © 2012-2025 BASE, Inc. 29 • なぜDryRunという名称なのか ◦ terraformや、ansibleなどのdry runオプションのイメージで、処理を実際に行った 結果がどうなりそうかという意味で付けています ◦ 本番環境への影響は出さないが、実際に本番環境と同等の処理を行った場合に何が 起きるのかというのを確認するものと定義しています 旧・新環境の比較を行う仕組み作り
30. © 2012-2025 BASE, Inc. 30 • 以前の仕組みを拡張 ◦ webリクエストに応じて同期的に比較処理を行っていたのを、非同期的に実行する 形に ◦ 本番影響を考えずに気軽に動作させることができ、キューの内容を再度実行するこ とができるべき等性を担保 差分があったリクエストを気軽に再実行して、修正を繰り返すというスムー ズなフィードバックループを回せるように意識しています 旧・新環境の比較を行う仕組み作り
31. © 2012-2025 BASE, Inc. 31 移行作業
32. © 2012-2025 BASE, Inc. 32 • 実装実装実装 • 基本的にリクエストの内容を右から左に流していくものだとして、 細かいドメインモデリングは基本的に省略して進める ◦ 複雑性がありそうな部分のみ、ドメインモデリングを実施 ◦ 実施してみて複雑性がわかればドメインモデリング、 もうちょっと密にやっておいたほうがいい機能もあったなという反省も • 洗い出した各機能をもう少し深堀り、調査してコーディングをしていく 移行作業
33. © 2012-2025 BASE, Inc. 33 • 一通りの実装を終えたら、今度はDryRunによる差分解消 ◦ 実装し終えてないがゆえの差分なのか、そもそも仕様の把握漏れだったのかという 点がわかりづらかったので、一通り実装し終えてから解消作業をしていきました ◦ これに関しては進め方間違えていかもなあとも思っています ◦ どれだけ差分があるのか読み切れず、終わりの見えない作業になりつつあった • 修正修正修正 移行作業
34. © 2012-2025 BASE, Inc. 34 © 2012-2025 BASE, Inc. 34 まとめ
35. © 2012-2025 BASE, Inc. 35 • 物量がやっぱり圧倒的に多かった ◦ シンプルに時間が多くかかってしまった ◦ メンバー、会社に対しては感謝しかない • そうはいっても、ビッグバンリリース ◦ どうしてもリリースに対する恐怖感が拭えない ◦ やはり本番にリリースしない限りフィードバックループを受けづらい ◦ 今後はリファクタリングによるリアーキテクチャも視野に入れたい • 他の開発作業とのバッティング ◦ いかに矛盾なく各作業を進めていけるのかを調整する困難さ ◦ 未来への投資とはいえスピードの重要さも実感 やってみてどうだったのか
36. © 2012-2025 BASE, Inc. 36 ソフトウェアアーキテクチャはどんな方法を取り入れるにしても、 コードの整理整頓方法を定義していくものにすぎないと感じている BASEではモジュラーモノリス・クリーンアーキテクチャ・DDDを取り込んで いる、この整理整頓力がシステムを強くする ◦ クリーンアーキテクチャやDDDについては変更容易性 ◦ モジュラーモノリスであればコンテキスト分割による責任分界点の明確化 ソフトウェアアーキテクチャ＝整理整頓
37. © 2012-2025 BASE, Inc. 37 リアーキテクチャは変化はするが、成長はしない • 今回の場合は、全く同じ動作を新環境で再現しているにすぎない • BASE利用者に新たな価値提供ができているわけではない しかしながら、”成長痛”を和らげることはできるはず • 当時解決できた課題が成長とともに簡単に解決できなくなっていく ◦ これを勝手に成長痛と呼んでいます • “整理整頓” により、もう少し簡単に解決できる状態にもっていければ、 この成長痛を和らげることができるはず 成長はしないが “成長痛” を和らげる
38. © 2012-2025 BASE, Inc. 38 ご清聴ありがとうございました