Cookpad TechConf 2022 - About PJ Takanawa (Hiromu Miyazaki)

Cookpad TechConf 2022 の資料です。

Transcript

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