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

楽天スーパーSaleの舞台裏 - お買い物カゴシステムの負荷対策 / Rakuten Supe...

楽天スーパーSaleの舞台裏 - お買い物カゴシステムの負荷対策 / Rakuten Super Sale

Tech Play登壇資料
https://techplay.jp/event/730636

今年で8年目に突入した「楽天スーパーSale」ですが、開催当初より様々なビジネス上・システム上の課題に直面してきました。 その中でも最重要システムの1つであるお買い物カゴにフォーカスして、それぞれの課題をどのように乗り換えてきたのかを具体的な事例を交えながらご紹介します。

Makito Hashiyama

May 31, 2019
Tweet

More Decks by Makito Hashiyama

Other Decks in Technology

Transcript

  1. 2 自己紹介 ▪経歴 • 2009-2011年:エンジニアとしてWebサービスの開発・運用 • 2012-2014年:お買い物カゴのバックエンドシステムのリード • 2014-2018年:楽天市場のWeb API、フロントエンド開発のマネージャー

    ▪現在の仕事 • 楽天市場開発における技術や開発プロセス、アーキテクチャの標準化 • エンジニアの採用・育成 ▪プライベート • ゲーム(DQ10など) • プログラミングスクール講師、執筆活動
  2. 8 監視内容 – The Four Golden Signals OSS・商用ツール・内製ツールを併用 Latency Traffic

    Errors Saturation クライアントサイド サーバーサイド 網羅性 リアルタイム Dynatrace Uptrends RAT: Rakuten Analytics Tracker MRTG 内製ツール Prometheus + Grafana JENNIFER ELK Stack
  3. 12 トリアージ・対応の具体例 いかに早期(秒単位)に検知、回復させるか。 CDN SLB Web Server Frontend API DB

    KVS External System External API Queue Frontend Web Server API TTLを伸ばす 同時受付セッション 数を絞る 静的コンテンツ表示 QPSを絞る API接続を切る Queueに溜める Blue/Greenを 切り替える インスタンスを増やす APIサーバの 再起動 お買い物の継続が最優先。外部要因であれば、機能を切り捨てる。
  4. 13 トリアージの失敗例 会員サービ スダウン 会員サービス なしで、お買 い物カゴ継続 非会員で購入 ポイント付与 依頼の殺到

    非会員と会員 データを突合 完全復旧 に約6カ月 事後影響を考えると、会員サービスダウン時はお買い物かごを停止させるべきであった。 緊急時に何を優先するか、ビジネスや補償の観点を含めて事前に決めておくことが重要。
  5. 20 試行錯誤その1 – 負荷テストの設計 (1) 全ユーザーシナリオを再現するのは非現実的 (2) 何を目標とするか? X: URLごとのユーザーのアクセス数

    Y: URL が ア ク セ ス 数 に 占 め る 割 合 ( 累 計 ) テスト対象 90%のユーザーアクセスがカバーできるシナリオを設計し、 呼び出すAPI・システムを選別。 共通の目標数値:分間受注件数 Latency Traffic Errors Saturation 覚えやすい、理解しやすい共通目標を設定 することで、課題や達成度を明確にできる。
  6. 21 試行錯誤その2 – データの追加、フィルタリング、破棄 お買い物カゴ 注文確認メール(ダミーアドレス)は、実送信前に破棄 外部API cache • 20万のダミー会員

    • 6,500のダミー店舗 • 100万のダミー商品 を準備 real real 原因2: キャッシュ 原因1: データサイズ dummy dummy dummy dummy real (1)トラフィック量・レイテンシが想定よりも少ない (2) テストデータのフィルタリング、掃除 real ダミー受注データはキャンセル処理 dummy ダミーデータの処理はさせたい vs. サービス影響は出せない
  7. 23 対策 CDN SLB Web Server Frontend API DB KVS

    External System External API Queue Frontend Web Server API ネットワークレイヤー • ネットワーク帯域増強 • 高負荷VIPの隔離 • 専用ネットワークの構築 • CDNの導入 • Timeout / Retry値の最適化 • コネクションプールの利用 アプリケーションレイヤー • 同期処理の非同期化 • APIコール数の削減 • ロック処理の解消 • Deep Copyメソッドの最適化 • JVMオプションの変更(Full GCの抑制) • Appサーバのスレッド数の見直し データレイヤー • メモリ増設 • インスタンス追加 • コネクション数の見直し • キューの保持時間の変更 • SQLチューニング • カーネルパラメータ変更
  8. 27 セール商品の分類 商品タイプ 概要 アクセス 在庫数 商品例 タイムセール商品 通常のセール商品。普段 から売られていることが

    多い。 中 多い カニ、肉、水 目玉商品 スーパーSaleのみで販売。 希少性や割引額が特に高 い商品。 大 少ない 車、宝石、時計 人気商品 特定の層に人気。値段は それほど高くない。テレ ビで紹介された、など。 大 多い 特定のファッションアイ テム、おもちゃ、消耗品
  9. 29 対策1: 専用システムを構築し、検知の仕組を導入 お買い物カゴ 在庫マスタ 在庫管理API 商品ページ 在庫キャッシュ お買い物カゴ 在庫管理API

    商品ページ 人気商品専用のシステムクラスタ 通常商品 人気商品 店舗用システム 監視 人気商品を別のシステムに隔離することで、負荷でシステムが スローダウンしても通常のお買い物は継続させる。
  10. 30 対策2: 在庫キャッシュの更新を非同期にする 商品ページ 在庫1 お買い物カゴ 購入完了 在庫1 在庫0 在庫マスタ

    在庫確認 在庫更新 Aさん Bさん Cさん ・Cさんが、在庫1の商品を購入。 ・A/Bの両方は、アクションを起こしたときに初めて在庫切れに気づく。 ・商品ページ上の在庫が同期であっても、ページがロードされない限り気づかない 少しの仕様変更で、システム的に大きな効果が出ることがある。
  11. 32 課題 # 課題 アクション 1 スーパーSALE同様の負荷を受けきれる試験用の環境が 用意できていない。 クラウドプラットフォームに簡単にデプロイできるため のコンテナ化、マイクロサービス化。

    2 スーパーSALE同様の負荷を柔軟かつ安全にかける手段 が十分に用意できていない。 システムメトリクスと紐づいた、クラウドベースの自動 テスト実行プラットフォームの開発。 3 複数のサービスを跨ったトラブルシューティングが十分 なスピード・精度・統一された手段でできていない。 統一プラットフォーム上のサービスメッシュの導入 (1) 分散トレーシングによるトラフィックの追跡。 (2) Circuit BreakerによるSystem Resiliency の強化
  12. 33 今後目指していくシステムアーキテクチャ CDN BFF API gateway API DB Stream External

    System Queue Traceability: 分散トレーシングによる追跡 Proxy Proxy Proxy Resiliency: Circuit Breaker の実現 cache KVS Flexibility: Microservice化 Scalability:コンテナ化&k8s基盤のクラウドプラットフォーム移行 本番 BFF API gateway API DB Stream Queue Proxy Proxy Proxy cache KVS 試験環境 クラウド 負荷試験環境 メトリクス