生鮮ECのタイムセールを耐え抜いてきた話 / Handling high traffic sale days at Cookpad Mart

by Leonard Chin

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

クックパッドマートECの性質からくる制約   ● お届け日が購入前に確定   ● 販売者のプラットフォームである   ○ 販売者数が多い  ○ 販売者の在庫がそれぞれ管理（日毎）   ○ 営業日（出荷可能日）   ○ 注文の締め切り（締め時間）   ● 自社流通  ○ キャパシティに上限がある   ■ ハブ（倉庫）  ■ カーゴ（トラック）  ■ ステーション（冷蔵庫）   ○ 限りあるトラックのルーティング   ○ 受取場所の営業日、営業時間   「この商品、購入できますか？」の判定が複雑   © 2022 Cookpad Inc. 6 どんな商品が買えるのか？の課題 

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

● Application ○ Ruby on Rails v6.1, Ruby 3.0 ● Datastores ○ Amazon Aurora (MySQL 5.7 compat.) ○ Amazon Elasticache (memcached) ○ Amazon Redshift ○ Amazon S3 ● Infrastructure ○ Amazon Web Services © 2022 Cookpad Inc. 15 クックパッドマートの技術スタック（バックエンド） 

Slide 16

Slide 16 text

Slide 17

Slide 17 text

● モニタリング  ○ Server metrics ○ Application Performance Monitoring ○ Slow query log ○ etc. ● 分析と対策  ○ 事実の記録して、共有  ○ 根本原因の分析  ○ 対策の提案と実施とフォローアップ  ● 権限と調整  ○ ソフトウェアの変更  ○ インフラストラクチャの変更 (DevOps)  ○ 仕様の変更  © 2022 Cookpad Inc. 17 負荷対策に必要なこと 

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

対策を実行するために、権限を獲得する必要がある。DevOpsを実践してる組織として、インフラストラクチャはセルフサービス化してる。また、プロダクト組織としても、職能横断チームを構成しているため、仕様変更の交渉も隔たりなく行ってる     © 2022 Cookpad Inc. 20 権限と調整  DevOps道具 hako-console Infrastructure as Code (IAM, Terraform) Stream-aligned product teams

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

APMの「Time Consumed」順で対策するendpointを極める  © 2022 Cookpad Inc. 25 中期の負荷対策：パフォーマンス・チューニング（１）  症状対策 N+1クエリー preload ARメモリー肥大化 pluckする Slow Query index追加、テーブル変更、 join を減らすアプリ計算量メモ化、キャッシュ活用飛び道具はなく、地道に取り組んでくだけです。高い効果が期待できるendpointを順に計測して、チューニングしていく。そして、また計測する  

Slide 26

Slide 26 text

本当の飛び道具は「仕様の変更」   ● その（遅い）機能は本当に適切なのか？   ● クライアントはレスポンスを全部使っているのか？   ● もっと効果的な機能を差し替えないか？     特に進化の早いサービスの場合、１年前に「必要」だと思われた機能は１年後に意味があるのか怪しい。プロダクトチーム内で無駄を見つけ、議論して、リプレースしていく。     © 2022 Cookpad Inc. 26 後期の負荷対策：仕様変更 

Slide 27

Slide 27 text

Before  ホーム画面に全カテゴリから１０商品ずつを表示   →しかしカテゴリも商品も10x以上増え、巨大なレスポンスになって、レスポンス生成も通信も遅い   After  ホーム画面を見直し、カテゴリ商品の表示を別画面に移す。代わりに特集コンテンツやユーザ別コンテンツを表示   →結果、パフォーマンスも改善し、使い勝手UP   © 2022 Cookpad Inc. 27 後期の負荷対策：仕様変更／事例（１）ホーム画面 

Slide 28

Slide 28 text

疑問　タイムセールの短時間にプッシュ通知を送る必要は本当にあるのか？売上に効果あるのか？   検証　プッシュ通知を開始時刻とずらして、変化はあるのか？   → 早く購入したいユーザば予告を見てプッシュ通知に頼らずに訪問することがわかった。プッシュが遅くても、売上に影響なし  結果　プッシュ通知をスロトリングし、ユーザの起動を分散して負荷を分散してピークを減らした   © 2022 Cookpad Inc. 28 後期の負荷対策：仕様変更／事例（２）プッシュ通知 