クックパッドマートの失敗したデータ設計 Before / After 大放出

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 2022 Cookpad Inc. 2 バックエンドエンジニア  Who?  @mokuzon  Motoi Okuzono  職種経歴 SNS 趣味 2016/08 クックパッド入社  社内情報共有ツール開発  2017/05 クックパッド料理教室  2019/07 クックパッドマート販売者  2019/12 クックパッドマート流通  2022/07 クックパッドマート EC  @mokuzon  オーケストラでホルンを吹く    飲酒  最近はモンハンはやくサンブレイクやりたい 

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© 2022 Cookpad Inc. 5 ラベル  ● ラベルの種類ごとにテーブルがあり   ● 1 枚ごとに 1 レコード     ● その日の出荷する注文が締め切られたタイミングで一斉にレコード書き込み   ● そのレコードを元にラベルプリンターで印刷     ● 印刷のためのデータとログとしてのデータが共通   Before ● 配送データが書き換わると印刷前にラベルデータも作り直し   ● 販売者の欠品処理とデータ作成タイミングが同じでエラーが多発   Problem

Slide 6

Slide 6 text

© 2022 Cookpad Inc. 6 ラベル  ● 印刷データは配送データから動的に生成   ● その印刷データをログとして印刷時にレコード書き込み     ● クックパッドマートにおける宣言的ラベル生成   https://techlife.cookpad.com/entry/2021/08/18/100000   After 詳しい人イベント参加者限定コンテンツイベント参加者限定コンテンツ

Slide 7

Slide 7 text

© 2022 Cookpad Inc. 7 営業日  ● 定休日と臨時休業日をそれぞれ別テーブルに記録   Before ● 定休日に臨時営業したくなったらもう一つテーブルを追加...?   ● 営業有無を算出するロジックが複雑化し扱いづらい   ● 臨時休業と臨時営業を同時に設定できないようにしたりも必要   Problem ● 販売者や受け取り場所にはお休みの日があるところもある   ● お盆やお正月など不規則なスケジュールもある  

Slide 8

Slide 8 text

© 2022 Cookpad Inc. 8 営業日  ● 営業の有無をベタに保存するテーブルを作り、それを参照   ● 上記テーブルのデータを作るための規則を保存するテーブルも用意     ● 営業日などの規則性と例外を扱うための設計   https://blog.osa.in.net/schedule-and-scheduling-policies-pattern/   After 詳しい人イベント参加者限定コンテンツイベント参加者限定コンテンツ

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© 2022 Cookpad Inc. 10 留まることの表現    ● 「この便に乗っているものは何時から何時」というドメイン知識から   「これとこれは被る」というのをすべて網羅して判定   ● 今日出荷された商品は昨日出荷された商品が最初に到達するハブでは時間帯が被らない  ● 今日出荷された商品は昨日出荷された商品が最後に到達するハブでは時間帯が被る  ● etc…  ● というような条件を愚直に十数件判定 Before ● 競合するパターンをすべて洗い出すのは難しい   ○ 実際に考慮漏れをして競合させてしまい損失が出たことも 😭  ○ 肌感では複数サイクル (マートでは日) を跨いだ影響が出るようになると   考慮漏れが発生しだす   Problem ココに入れたい被ってるコンテナある？

Slide 11

Slide 11 text

© 2022 Cookpad Inc. 11 留まることの表現    ● 素朴に留まることを表現するテーブルを用意   ● クックパッドマート最難解ロジック!?「採番」   https://techlife.cookpad.com/entry/cookpad-mart-assignments-2022   After 詳しい人イベント参加者限定コンテンツイベント参加者限定コンテンツイベント参加者限定コンテンツ

Slide 12

Slide 12 text

買えることの表現    クックパッドマートでは購入時に以下 2 つを選択する   受け取り場所  受け取り日  この組み合わせを Delivery と呼んで概念化している   とある商品 ( Product ) がとある Delivery で買えるかは状況によって変わる   ● 販売者の営業日  ● 配送経路の関係 (現在はこれによって差がステーション間に出来ることはほぼない)     買えないにも 2 種類ある   ● 同じ受け取り場所で異なる受取日なら買える   ○ これを明確に表示したい   ● 同じ受け取り場所ならどうやっても買えない     これを表現する手段が必要  

Slide 13

Slide 13 text

© 2022 Cookpad Inc. 13 買えることの表現    ● 買える  ○ DeliveryProduct という中間モデルで表現   ● 同じ受け取り場所で異なる受取日なら買える   ○ DeliveryUnavailableProduct という中間モデルで表現   ● それぞれデータは同名のテーブルに永続化   Before ● 商品一覧を作るのに毎回 DP と DUP をクエリーして足し合わせる必要がある   ● 商品を購入可能 ⇔ 不可能の状態が管理しにくい   ○ 都度レコードの生成・削除が必要   Problem

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© 2022 Cookpad Inc. 16 PDF  1. Excel でテンプレートを作る   2. rubyXL gem を使って Rails のデータを書き込む   3. LibraOffice で PDF に変換する   4. qpdf でテンプレートで用意された余分なページを削除   Before ● PDF の種類が増えるたびに Excel のテンプレートが増え、Docker の image size が肥大化   ● 実行時間が長い  ● テンプレートで想定していない量の注文が入るたびに、テンプレートの行数を増やす   ぬくもりのあるオペレーション 😇  Problem

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

● クックパッドマートは作り直しにとっても寛容   ○ 最初の要件に対しては元の作り方で十分だったが、要件が増えて辛くなることはザラ   ○ 最初から未来の要件をすべて見通すのは不可能   ○ とにかく最初はシュッと作るが、辛くなったらすぐ作り直しを検討していくことで   新規事業にとって重要な初速と長期運用に必要な品質のバランスを取っている     ● クックパッドマートではいろんなことができます   ○ 登場人物の種類が多い   ■ ユーザー、販売者、ドライバー、受け取り場所設置者、マートスタッフ etc.   ○ それぞれに対して物理的に必要なもの、必要なロジックが沢山ある   ○ 何かしら刺さっていたら幸いです   伝えたかったこと  © 2022 Cookpad Inc. 19