Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Cookpad Tech Kitchen #26「数千万レコードをリアルタイムに捌く生鮮EC事業開発」の資料
https://cookpad.connpass.com/event/239885/

70762059db0218c6f0ff48042ca0756a?s=128

Leonard Chin

April 08, 2022
Tweet

More Decks by Leonard Chin

Other Decks in Programming

Transcript

  1. © 2022 Cookpad Inc. Cookpad Tech Kitchen #26 2022/3/24 生鮮ECのタイムセールを


    耐え抜いてきた話
 クックパッド株式会社
 Leonard Chin / レオ
  2. © 2022 Cookpad Inc. 2 Leonard Chin (レオ)
 オーストラリア .au

    出身
 2012年クックパッド株式会社入社
 • 広告事業、海外事業、TV事業、レシピ事業
 2020年買い物事業に参画
 • バックエンドエンジニア、テックリード
 • 買物プロダクト開発部ECアプリケーション開発グループ長
 
 Twitter: @lchin GitHub: l15n

  3. 生鮮ECクックパッドマートの特徴
 © 2022 Cookpad Inc. 3

  4. クックパッドマートでの買物の流れ
 © 2022 Cookpad Inc. 4 アプリで注文
 (ユーザ)
 注文日
 納品・出荷


    (販売者)
 出荷日
 ステーションへ配達
 (流通)
 受取日
 受け取る
 (ユーザ)
 受取日

  5. © 2022 Cookpad Inc. 5 クックパッドマートアプリでの買物
 ステーション(受け取り場所) 
 受け取り日
 カート追加


    注文
 ステーション(受け取り場所)& 
 受け取り可能時間

  6. クックパッドマートECの性質からくる制約 
 • お届け日が購入前に確定 
 • 販売者のプラットフォームである 
 ◦ 販売者数が多い


    ◦ 販売者の在庫がそれぞれ管理(日毎) 
 ◦ 営業日(出荷可能日) 
 ◦ 注文の締め切り(締め時間) 
 • 自社流通
 ◦ キャパシティに上限がある 
 ▪ ハブ(倉庫)
 ▪ カーゴ(トラック)
 ▪ ステーション(冷蔵庫) 
 ◦ 限りあるトラックのルーティング 
 ◦ 受取場所の営業日、営業時間 
 「この商品、購入できますか?」の判定が複雑 
 © 2022 Cookpad Inc. 6 どんな商品が買えるのか?の課題

  7. DPは商品の「購入可否状態」を管理するキャッシュ
 
 DP数 = 商品数 x お届け日 x 拠点
 


    • 商品数: 1万以上
 • お届け日: 1週間分が参照可能
 • 拠点数: 数百
 → 数千万件の「生きている」レコード
 © 2022 Cookpad Inc. 7 DeliveryProduct (DP)

  8. タイムセール:施策と試練
 © 2022 Cookpad Inc. 8

  9. • 毎週開催
 • 時間限定のセール
 • 特別価格でマ美味しい商品を紹介する 
 • 在庫に限りがある
 •

    一斉プッシュ通知でユーザに知らせる 
 ユーザにも、事業にもメリットが大きい施策 
 しかし、、、
 © 2022 Cookpad Inc. 9 施策:タイムセール

  10. © 2022 Cookpad Inc. 10 タイムセールで何が起きるか(初期/2020年頃)
 プッシュ通知を
 一斉送信
 買物客が一気に
 押し寄せる


    大変

  11. ユーザが殺到し、サーバーがパンク状態になってしまうとせっかくの販売 機会を失ってしまう上、ユーザの信頼まで失ってしまう。 
 
 どうすれば、タイムセール中でも快適な買物体験を提供できるか? 
 
 
 © 2022

    Cookpad Inc. 11 タイムセールの機会損失

  12. Push通知は全ユーザに数分間に届くため、 
 • 平常時の50-100xのアクセス 
 • 短時間(〜5分間)のにアクセス集中 
 • アクセスパターンが変わる

    
 ◦ 起動画面へのアクセス 
 ◦ 買物行動(カート追加、決済) 
 © 2022 Cookpad Inc. 12 タイムセールの技術的課題

  13. とてもやり甲斐がある 
 意訳:難しい
 © 2022 Cookpad Inc. 13 クックパッドマートにおける負荷対策のチャレンジ
 📈


    受取日 x 拠点の組み合わせで
 キャッシュが効きにくい
 負荷が短時間に集中するため、
 サーバ増設すると無駄が多い
 成長フェーズですので、データ量も アクセス数が増え続けてる

  14. タイムセールの負荷対策:準備編
 © 2022 Cookpad Inc. 14

  15. • 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 クックパッドマートの技術スタック(バックエンド)

  16. © 2022 Cookpad Inc. 16 クックパッドマート:ECサービス全体概要
 今回の話の中心


  17. • モニタリング
 ◦ Server metrics ◦ Application Performance Monitoring ◦

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

  18. © 2022 Cookpad Inc. 18 モニタリング Scout APM Server Metrics

    (Grafana) SLI/SLO (Grafana) Slow Query (Kibana) クックパッドマートでは、それぞれのレイヤーでモニタリングを実現してる。 

  19. 組織として取り組むために、「決まった場所」「決まった方法」で記録を残して、協力できるようにしてる。対策も記録し、結果をフォローアップして豆に記録して、知見 (グラフの読み方、対策の効果)を貯めている。 
 © 2022 Cookpad Inc. 19 分析と対策
 専用Slackチャンネル

    #kaimono-isucon Issueとして記録 レポートテンプレートの 半自動化
  20. 対策を実行するために、権限を獲得する必要がある。DevOpsを実践してる組織として、インフラストラクチャはセルフサービス化してる。また、プロダクト組織として も、職能横断チームを構成しているため、仕様変更の交渉も隔たりなく行ってる 
 
 © 2022 Cookpad Inc. 20 権限と調整


    DevOps道具 hako-console Infrastructure as Code (IAM, Terraform) Stream-aligned product teams
  21. タイムセールの負荷対策:実施編
 © 2022 Cookpad Inc. 21

  22. © 2022 Cookpad Inc. 22 初期の負荷対策:スケールアップ・スケールアウト(1)
 初期症状:unicornワーカー完売 
 • 全ワーカーが完売


    • リクエストキューが1500件以上 
 
 対策:AWS scheduled taskで事前にアプリケーションスケールアウト 
 
 しかし・・・

  23. 症状
 • 初動はreader CPU 100% 
 • その後はwriter CPU 100%

    
 対策
 • readerはスケールアウト 
 ◦ 台数増やす
 ◦ 都度でも常設でも
 • writerはスケールアップ 
 ◦ より大きいインスタンス 
 ◦ 常設
 © 2022 Cookpad Inc. 23 初期の負荷対策:スケールアップ・スケールアウト(2)

  24. タイムセールのたびに、スケールアウト を実施する体制
 
 Tradeoff:
 • サーバーコスト
 vs
 • エンジニアへの運用負担 


    
 正直、なかなか大変でしたが、本質な 対策のための時間稼ぎとして有効 
 © 2022 Cookpad Inc. 24 初期の負荷対策:スケールアップ・スケールアウト(3)
 Cost管理
 On-Call担当の
 タイムセール対応 手順化

  25. APMの「Time Consumed」順で対策するendpointを極 める
 © 2022 Cookpad Inc. 25 中期の負荷対策:パフォーマンス・チューニング(1)
 症状

    対策 N+1クエリー preload ARメモリー肥大化 pluckする Slow Query index追加、テーブル変更、 join を減らす アプリ計算量 メモ化、キャッシュ活用 飛び道具はなく、地道に取り組んでくだけです。高い効果が期待できるendpointを順に計測して、チューニングしていく。そして、また計測する 

  26. 本当の飛び道具は「仕様の変更」 
 • その(遅い)機能は本当に適切なのか? 
 • クライアントはレスポンスを全部使っているのか? 
 • もっと効果的な機能を差し替えないか?

    
 
 特に進化の早いサービスの場合、1年前に「必要」だと思われた機能は1年後に意味があるのか怪しい。プロダ クトチーム内で無駄を見つけ、議論して、リプレースしていく。 
 
 © 2022 Cookpad Inc. 26 後期の負荷対策:仕様変更

  27. Before
 ホーム画面に全カテゴリから10商品ずつを表示 
 →しかしカテゴリも商品も10x以上増え、巨大なレスポンスになって、レ スポンス生成も通信も遅い 
 After
 ホーム画面を見直し、カテゴリ商品の表示を別画面に移す。代わりに特 集コンテンツやユーザ別コンテンツを表示 


    →結果、パフォーマンスも改善し、使い勝手UP 
 © 2022 Cookpad Inc. 27 後期の負荷対策:仕様変更/事例(1)ホーム画面

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

    2022 Cookpad Inc. 28 後期の負荷対策:仕様変更/事例(2)プッシュ通知

  29. タイムセールの現状
 © 2022 Cookpad Inc. 29

  30. • パフォーマンスSLIはSLOを維持できてい る
 • on-call担当のスケールアウト、監視が不 要に
 
 🎉 常に快適な買物体験を提供 


    🎉 bizに施策実施タイミングの制約なし 
 © 2022 Cookpad Inc. 30 平和なタイムセール
 対策不要の様子

  31. © 2022 Cookpad Inc. 31