Slide 1
Slide 1 text
No content
Slide 2
Slide 2 text
巨大なレシピサービスの
アーキテクチャを最高にしたい
宮崎広夢（@hilinker）
クックパッド事業本部 レシピサービス開発部
2
Slide 3
Slide 3 text
自己紹介
2021年新卒でクックパッドに入社。
現在は主にレシピサービスの基盤周りを見ている。
TypeScript が好き。
3
宮崎 広夢（HN: どや）
Slide 4
Slide 4 text
4
1. レシピサービスの歴史と課題
2. レシピサービスのアーキテクチャを
最高にしたい
Slide 5
Slide 5 text
5
なレシピサービス
クックパッドの
Slide 6
Slide 6 text
6
なレシピサービス
クックパッドの
Slide 7
Slide 7 text
レシピサービスとは：サービス的概要
● 料理レシピサービス
● 複数プラットフォームで提供
○ Web （PC・スマートフォン）
○ Android・iOS アプリ
● 歴史の長いサービス
○ 技術的負債やレガシーも多い
7
1. レシピサービスの歴史と課題
Slide 8
Slide 8 text
8
Slide 9
Slide 9 text
2017年時点の
cookpad_allレポジトリの LoC
9
Slide 10
Slide 10 text
cookpad_all に全てがあった時代（2017年ごろ）
10
https://logmi.jp/tech/articles/319343
1. レシピサービスの歴史と課題
Slide 11
Slide 11 text
11
Slide 12
Slide 12 text
12
Slide 13
Slide 13 text
13
Slide 14
Slide 14 text
うおおおお！！時代はマイクロサービスだ！！！
14
1. レシピサービスの歴史と課題
Slide 15
Slide 15 text
BFF (Backend For Frontend)
● フロントエンドのため API を集約し、UI/UX 上のデータ整形を行うオーケス
トレーション層の1種
15
● クライアント ↔ サーバ間に BFF を用意
○ クライアントから無数のマイクロサービスに
直接アクセスしたくなかった
● マイクロサービスにおける BFF の活躍
○ リソースの集約・クライアントへの API の提供を行う
○ 集約時に発生するロジックや必要なデータを扱う
1. レシピサービスの歴史と課題
Slide 16
Slide 16 text
レシピサービスのアーキテクチャ
16
1. レシピサービスの歴史と課題
Slide 17
Slide 17 text
レシピサービスはどう変わった？
● 開発・保守がやりやすくなった
○ 何を変更すると何に影響があるか全く見通しが立たない、
クソデカモノリスを触る必要がなくなった
○ 機能開発のスピードを出しやすくなった
○ ライブラリやミドルウェアの更新などがしやすくなった
17
1. レシピサービスの歴史と課題
Slide 18
Slide 18 text
おさらい：レシピサービスの歴史
18
1. レシピサービスの歴史と課題
Slide 19
Slide 19 text
19
Slide 20
Slide 20 text
20
Slide 21
Slide 21 text
なんか開発がつらい
21
/search_result って
どんなレスポンス
返すんでしたっけ？
nullable じゃないはずの
image フィールドに
null が返ってきた…
サービス多すぎて
どこに何書けばいいか分
からん
（よく分からないけど
コピペで動いたので）
レビューお願いします
2.レシピサービスのアーキテクチャを最高にしたい
Slide 22
Slide 22 text
22
Slide 23
Slide 23 text
レシピサービスのアーキテクチャを振り返ってみる
23
2.レシピサービスのアーキテクチャを最高にしたい
Slide 24
Slide 24 text
マイクロサービス（たくさん）
BFF（おおきくてむずかしい）
24
Slide 25
Slide 25 text
25
Slide 26
Slide 26 text
26
“見通し”の悪い開発
2.レシピサービスのアーキテクチャを最高にしたい
Slide 27
Slide 27 text
27
“見通し”の悪い開発
2.レシピサービスのアーキテクチャを最高にしたい
Slide 28
Slide 28 text
28
“見通し”の悪い開発
2.レシピサービスのアーキテクチャを最高にしたい
Slide 29
Slide 29 text
29
“見通し”の悪い開発
2.レシピサービスのアーキテクチャを最高にしたい
Slide 30
Slide 30 text
30
“見通し”の悪い開発
2.レシピサービスのアーキテクチャを最高にしたい
Slide 31
Slide 31 text
31
“見通し”の悪い開発
2.レシピサービスのアーキテクチャを最高にしたい
Slide 32
Slide 32 text
32
“見通し”の悪い開発
2.レシピサービスのアーキテクチャを最高にしたい
Slide 33
Slide 33 text
33
“見通し”の悪い開発
2.レシピサービスのアーキテクチャを最高にしたい
Slide 34
Slide 34 text
34
Slide 35
Slide 35 text
なんか開発がつらい
● アプリケーションごとの責務が不明瞭
● フロントエンドとサーバーサイドのエンジニアが
双方の実装状況を意識する必要がある
● 技術スタックの分散
35
2.レシピサービスのアーキテクチャを最高にしたい
Slide 36
Slide 36 text
36
アプリケーションごとの責務が不明瞭
Slide 37
Slide 37 text
● リソースサーバーから返ってきたリソースの visible フィールドが false だっ
た場合に、クライアントに null を返す
37
クライアントを振り回す BFF ロジック
● ユーザーが有料会員のときだけ
マイフォルダのレシピを検索結果に埋め込む
● マイクロサービス化で分割されてしまったデータの結合処理
2.レシピサービスのアーキテクチャを最高にしたい
Slide 38
Slide 38 text
38
● 現状、クックパッドの BFF はロジックてんこもり
○ 一部のハードコードされたデータも持っている
■ 例）季節キャンペーンデータとか
BFF ってロジック持って良いんだっけ？
● BFF がロジックを持たない方が複雑性は小さい
● 特にルールがないまま運用されている
2.レシピサービスのアーキテクチャを最高にしたい
Slide 39
Slide 39 text
39
フロントエンドとサーバーサイドの
エンジニアが
双方の実装状況を意識する必要がある
Slide 40
Slide 40 text
● アプリ向け BFF
○ どんなレスポンスが返ってくるか実装を読まないと分からない
○ スキーマなどの約束事がない
○ コミュニケーションコストが高い
○ フロントエンドが壊れやすい
40
ある API がどういった API なのか分からない
2.レシピサービスのアーキテクチャを最高にしたい
Slide 41
Slide 41 text
41
技術スタックの分散
Slide 42
Slide 42 text
42
● バックエンドは で、アプリの BFF は で、
Web の BFF は で……
技術スタックの分散
● 元々アプリ向け BFF はアプリエンジニアが書く想定だった
○ 実際はサーバーサイドエンジニアが書くことが多かった
● コンテキストスイッチと学習のコストが高い
2.レシピサービスのアーキテクチャを最高にしたい
Slide 43
Slide 43 text
ここまでのおさらい
● レシピサービスはクソデカモノリスからマイクロサービス化した
● マイクロサービス化によって開発・保守しやすくなった側面もある
● でも最近なんか開発がつらい
○ アプリケーションごとの責務が不明瞭
○ フロントエンドとサーバーサイドのエンジニアが
双方の実装状況を意識する必要がある
○ 技術スタックの分散
43
2.レシピサービスのアーキテクチャを最高にしたい
Slide 44
Slide 44 text
44
Slide 45
Slide 45 text
プロジェクト Takanawa 始動
45
Slide 46
Slide 46 text
プロジェクト Takanawa とは？
● レシピサービスにおける「何かつらくね？」を解消するプロジェクト
46
● レシピサービス全体のアーキテクチャをいい感じにして、
開発しやすい状態にする
● やること
○ レシピサービスへの Gateway 層の導入
○ アプリケーションごとの責務の整理
○ 周辺負債の返済・機能の削減
2.レシピサービスのアーキテクチャを最高にしたい
Photo by: https://dime.jp/genre/869047/
Slide 47
Slide 47 text
プロジェクト Takanawa とは？
● レシピサービスにおける「何かつらくね？」を解消するプロジェクト
47
● レシピサービス全体のアーキテクチャをいい感じにして、
開発しやすい状態にする
● やること
○ レシピサービスへの Gateway 層の導入
○ アプリケーションごとの責務の整理
○ 周辺負債の返済・機能の削減
2.レシピサービスのアーキテクチャを最高にしたい
Photo by: https://dime.jp/genre/869047/
Slide 48
Slide 48 text
レシピサービスへの Gateway 層の導入
● BFF がしんどい
48
● API Gateway 層（api4-gateway）を導入する
● フロントエンドは api4-gateway 経由でリソースを取得する
○ Web、iOS、Android 全てのプラットフォーム
2.レシピサービスのアーキテクチャを最高にしたい
Slide 49
Slide 49 text
おさらい：旧アーキテクチャ
49
2.レシピサービスのアーキテクチャを最高にしたい
Slide 50
Slide 50 text
理想のすがた
50
2.レシピサービスのアーキテクチャを最高にしたい
Slide 51
Slide 51 text
api4-gateway：概要
● API Gateway パターン
● クライアントからのリクエストは必ずここを通る
● 責務
○ GraphQL のスキーマに基づく共通のインターフェースを提供
○ 複数のサーバーからのリソースを集約する
51
2.レシピサービスのアーキテクチャを最高にしたい
Slide 52
Slide 52 text
52
Slide 53
Slide 53 text
api4-gateway のここが違うよ
● プラットフォームごとに共通の GraphQL によるスキーマを提供
53
● ロジック・データを持たせない！
○ オーケストレーション層はロジックを持ちがちでつらくなる
○ api4-gateway はあくまで透過的にバックエンドを扱うだけの
薄い層にする
○ ロジックを書けないような構成にする
○ むずかしいことは全部バックエンドにやらせる
2.レシピサービスのアーキテクチャを最高にしたい
Slide 54
Slide 54 text
むずかしいことは全部バックエンドにやらせる
● 処理を各バックエンドサーバーに返還する
54
● レシピサービスにおけるメインとなるバックエンドを決めた
○ 置き場所がなかったものに明確な置き場所を与えた
（そしてそれは BFF ではない）
● メリット
○ ロジック・データの責任の所在がはっきりする
○ オーケストレーション層がすっきりする
○ 手慣れた Ruby でロジックが書ける
2.レシピサービスのアーキテクチャを最高にしたい
Slide 55
Slide 55 text
おさらい：レシピサービスの課題
● アプリケーションごとの責務が不明瞭
55
● フロントエンドとサーバーサイドのエンジニアが
双方の実装状況を意識する必要がある
● 技術スタックの分散
2.レシピサービスのアーキテクチャを最高にしたい
Slide 56
Slide 56 text
api4-gateway は何を解決する？
● アプリケーションごとの責務が不明瞭
○ api4-gateway にロジック・データは置かないで、
各リソースサーバーに返還する
○ 既存の BFF を改善していくだけだと不十分
● フロントエンドとサーバーサイドのエンジニアが
双方の実装状況を意識する必要がある
○ 共通の GraphQL スキーマでコミュニケーションが取れる
● 技術スタックの分散
○ 難しいロジックを Ruby で書ける
○ アプリ用 BFF を捨てることで利用言語を１つ減らせる
56
2.レシピサービスのアーキテクチャを最高にしたい
Slide 57
Slide 57 text
まとめ
● マイクロサービス化＋BFF はちゃんと導入するのがムズい
57
● 既存のアーキテクチャが抱えているつらさを無くしたい
● プロジェクト Takanawa では api4-gateway 導入して
つらさをなくそうとしている（道半ば）
Slide 58
Slide 58 text
No content