システムをあるべき姿から 設計し直してみた

2025/10/8 「AI開発の実戦メソッドとアーキテクチャ事例 ― toCサービスの高速デリバリを支える技術
」の発表資料です。
https://kauche.connpass.com/event/368490//

Transcript

1. システムをあるべき姿から 設計し直してみた 2025/10/8 toCのスピーディーなデリバリを支える技術的な取り組み 株式会社ユーザベース エンジニア / 崔 井源
2. 崔 井源（ちぇ じょんうぉん） 自己紹介 • 韓国ソウル特別市出身 • 2020年にNAISTで修士課程を修了（ここで理転） • 2020年に株式会社NewsPicksにエンジニアとして新卒入社 • 2024年くらいまで主にNewsPicksの検索システムの開発やメ ンテナンスを担当（検索データの整形、インフラの開発・メ ンテ、検索機能のUI・UX改善など） • 2025年からプラットフォームエンジニアリングチームで UX・EX・DX改善につながる開発を進めている 2 @jonlpstudy
3. システムが複雑になりすぎて 開発効率が悪くて なんとかしたい！ | 01 | 3
4. まず、NewsPicksは ソーシャル経済メディア。 扱っているコンテンツは、 • 記事（オリジナル、 キューレーション) • 動画 • 書籍 • コメント • 決算資料 • … 4 NewsPicksのアプリ画面
5. まず、NewsPicksは タブ 異なる複数のセクションを表示する。「ホーム」 「トップ」「動画」などがそれに該当する。 セクション コンテンツをリストやカルーセルなどでまとめて 表示する。タブの中にある「今日のニュース」 「話題をまとめ読み」などがそれに該当する。 5 NewsPicksのアプリの構成
6. 抱えていた課題 コンテンツ種別も色々あり、セクション も色々あり、複雑な構造のように見える が、実は下記の並びをどうしているのか に過ぎない（すごい単純化すると）。 • セクション名 • サムネ画像 • タイトル • Pick数（コンテンツの人気を表す数 値） 6 NewsPicksの各タブの構成を単純化した図 似たようなことをするのに全部独自の実装がされている
7. 抱えていた課題 さらには、類似するデータを取得してデザイン別に 見せ方を調整し並べるだけなのに、全てそれ専用の 処理が作られている。 各専用処理の中では、セクション定義や独自のデー タ取得ロジックが書かれ、気軽に流用できるものに はなっていない。 7
8. • パターン１ コレクション対応版のメソッドに見せかけて、N+1になっていた fun fetch(targetIds: List<Int>): List<Target> { return targetIds.map { someProcess(it) } } 独自の実装が増えていくと、パフォーマンス管理が難しい 抱えていた課題 8 コレクション対応版に見せかけてN＋1アクセスする処理の例 val newsModels = newsIds.map { newsRepository.findById(it) } 普通にN+1している例
9. • パターン2 同じ種別のデータを一気に取得しないので、何回もDBアクセスが発生する 独自の実装が増えていくと、パフォーマンス管理が難しい 抱えていた課題 9 fun findByIds(ids: List<ContentId>): List<Content> { val newsIds = ids.filterInstance<NewsId>() val newsModels = newsRepository.findByNewsIds(newsIds).associateWith { it.id } val movieIds = ids.filterInstance<MovieId>() val movieModels = movieRepository.findByMovieIds(movieIds).associateWith { it.id } val additionalNewsIds = newsMovieMappingRepository.findByIds(movieIds) val additionalNewsModels = newsRepository.findByNewsIds(additionalNewsIds).associateWith { it.id } return ... }
10. 例えば、ユーザーに見せていいコンテンツとそうではないコンテンツの基準が増えたとすると、一元化さ れていないため、対応コストが高い。 変換やフィルター処理が散らばっていて対応が難しい 抱えていた課題 10
11. あるべき姿から設計し直す | 02 | 11
12. あるべき姿 タブごとにいろんな仕様が盛り込まれているが、単純化してみよう。 コンテンツにもデザインにもいくつかの種類があるが、差はそこだけ。 • タブは単なるセクションを束ねる箱 • セクションは単なるコンテンツを束ねる箱 箱の作り方を汎用化し、コンテンツ取得ロジックを必要に応じて追加する だけにすれば、かなりシンプルになるはず！ 12 NewsPicksのアプリの構成 理想的な構成図
13. あるべき姿 シンプルな問題を定義し、それで検証を行う。 • タブは一つだけ存在し、タブ名は home である • home には３つの異なるデザインのセクションが存在する ◦ セクション1は、速報「記事」を「リスト」で表示する ◦ セクション2は、人気「動画」を「カルーセル」で表示する ◦ セクション3は、人気「記事」を「ランキング」で表示する • セクションに表示すべきコンテンツは「記事」と「動画」の２種類 のみである ◦ 「記事」には「動画」が紐づかないケースがある ◦ 「動画」には必ず「記事」が紐づく ◦ コンテンツをPickするとPick数が表示される • N+1を許容しないので、必ずそのDBには一回だけリクエストする 13 NewsPicksのアプリの構成
14. あるべき姿 14 検証後に固まった構成 ポイント • APIとコントローラーは一つだけを用意 し、流用する • タブやセクションの定義はDBで管理し、 クラスが特定のタブに依存しないように する • コンテンツ種別ごとに一回だけDBにアク セスする • コンテンツ種別ごとにデータを取得する タイミングでフィルター処理を済ませる ようにし、管理しやすくする より具体化する: 開発者が気にするのはカラーの部分だけ
15. より具体化する: 開発者が気にするのはカラーの部分だけ あるべき姿 15 そのセクションにどのコンテンツを表示するかの対象 を決める部分を実装すれば、勝手にそのデータ揃う！ タブやセクションの定義はDBに 格納する（クエリ実行するだ け！） コンテンツ種別ごとにデータ を取得する処理を実装する。 必ずコレクションに対応して いるのでN+1を気にしなくて 済む！フィルタリング処理も 一元化されている。
16. 開発時間を大幅に短縮できた！ | 04 | 16
17. 使ってもらえるように動くまでがお仕事 新機能開発で早速活用 かなり抽象的な実装になったので、初見の人はコードを読むだけで、何を追加実装すればいいのか、そこ だけでいいのかがわからない。だから使えない。 それで、施策チームに「これ使ってみませんか！これなら工数あまり使わなくても作れますよ！サポート します、ペアプロします！」と営業をし、使ってもらうことに。 このAPIを使えば、新機能追加のために追加実装が必要なのは以下のみです！ • データベースにタブとセクションの定義を追加 • （リファレンス実装で作ったもので対応できない画面だったので）箱を作るモジュールを追加 • リポジトリーの追加（コレクション対応版のメソッドは用意されてるので、それを呼び出すようにしてください） 17
18. 使ってもらえるように動くまでがお仕事 新機能開発で早速活用 実際、1〜2時間くらいのペアプロを3回ほど行い、新機能が完成！ ペアプロ以外にも実装が必要だった可能性はあるが、だいたいその時間に収まっていたはず。 New Relicで確認した、レスポンスを返すまでの処理時間も平均300ms程度に収まっていて、開発者が色々 気にしなくてもサクッと作れることが証明できた。 18
19. 最後に | 05 | 19
20. NewsPicksのプラットフォームエンジニアリングチーム についてはこちら⇩ 20 もっと詳しい裏話はこちら⇩
21. 最後までご清聴ありがとうございました。 Thank you 21