楽天スーパーSaleの舞台裏 - お買い物カゴシステムの負荷対策 - May 31, 2019 楽天株式会社 ECマーケットプレイス開発部 Marketplace Core Architect Section シニアマネージャー 橋山 牧人

2 自己紹介 ■経歴 • 2009-2011年：エンジニアとしてWebサービスの開発・運用 • 2012-2014年：お買い物カゴのバックエンドシステムのリード • 2014-2018年：楽天市場のWeb API、フロントエンド開発のマネージャー ■現在の仕事 • 楽天市場開発における技術や開発プロセス、アーキテクチャの標準化 • エンジニアの採用・育成 ■プライベート • ゲーム（DQ10など） • プログラミングスクール講師、執筆活動

3 楽天について ※2018/12月時点

4 楽天スーパーSALE ※2019/03/04時点 2012年3月より開始した大型セールイベント。

5 本日のアジェンダ：楽天スーパーSALEの舞台裏 セール当日の様子 システム上の課題解決：負荷試験 ビジネス上の課題解決：人気商品への対応 今後の取り組み

6 本日のアジェンダ：楽天スーパーSALEの舞台裏 セール当日の様子 システム上の課題解決：負荷試験 ビジネス上の課題解決：人気商品への対応 今後の取り組み

7 システム監視の様子 100名以上が楽天クリムゾンハウスに集結し、同じフロアで監視。 社長をはじめとした役員達もセールの状況に集中。 ※2015年12月時点

8 監視内容 – The Four Golden Signals OSS・商用ツール・内製ツールを併用 Latency Traffic Errors Saturation クライアントサイド サーバーサイド 網羅性 リアルタイム Dynatrace Uptrends RAT: Rakuten Analytics Tracker MRTG 内製ツール Prometheus + Grafana JENNIFER ELK Stack

9 独自の監視項目 システムの負荷予測や可用性を、ビジネスの観点から確認。 売上高 受注件数 メール配信 エントリー数

10 楽天ゴールデンイーグルス優勝セール 優勝セールの瞬間、日本の全トラフィックの約10%が楽天に集中。 優勝候補日は社内で観戦。優勝したら即監視。

11 トラブルシューティング 検知 トリアージ 対応 調査 いかに早期に検知、回復させるか。

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サーバの 再起動 お買い物の継続が最優先。外部要因であれば、機能を切り捨てる。

13 トリアージの失敗例 会員サービ スダウン 会員サービス なしで、お買 い物カゴ継続 非会員で購入 ポイント付与 依頼の殺到 非会員と会員 データを突合 完全復旧 に約6カ月 事後影響を考えると、会員サービスダウン時はお買い物かごを停止させるべきであった。 緊急時に何を優先するか、ビジネスや補償の観点を含めて事前に決めておくことが重要。

14 本日のアジェンダ：楽天スーパーSALEの舞台裏 セール当日の様子 システム上の課題解決：負荷試験 ビジネス上の課題解決：人気商品への対応 今後の取り組み

15 きっかけ 2012年開始当初より負荷起因のシステムトラブルが続いており、原因の特定、根本的な対策が急務であった。 特定 対策 確認

16 原因の特定 特定 対策 確認

17 どうやって負荷状況を再現するか？ お買い物カゴ 開始直後のピーク時には、通常ピーク時の約20倍のアクセス。 ステージングでは再現できない 日本有数の規模とトラフィック 準備期間がない（3か月未満） いろいろな条件 Publicクラウドは使わない

深夜の本番負荷試験

19 本番環境での負荷試験 お買い物カゴ 当時のエンジニアがノウハウを持っていた JMeterを負荷ツールとして採用。 負荷生成サーバ 負荷生成サーバ 負荷生成サーバ DB 監視 外部API 本番

20 試行錯誤その1 – 負荷テストの設計 (1) 全ユーザーシナリオを再現するのは非現実的 (2) 何を目標とするか？ X: URLごとのユーザーのアクセス数 Y: URL が ア ク セ ス 数 に 占 め る 割 合 （ 累 計 ） テスト対象 90%のユーザーアクセスがカバーできるシナリオを設計し、 呼び出すAPI・システムを選別。 共通の目標数値：分間受注件数 Latency Traffic Errors Saturation 覚えやすい、理解しやすい共通目標を設定 することで、課題や達成度を明確にできる。

21 試行錯誤その2 – データの追加、フィルタリング、破棄 お買い物カゴ 注文確認メール（ダミーアドレス）は、実送信前に破棄 外部API cache • 20万のダミー会員 • 6,500のダミー店舗 • 100万のダミー商品 を準備 real real 原因2: キャッシュ 原因1: データサイズ dummy dummy dummy dummy real (1)トラフィック量・レイテンシが想定よりも少ない (2) テストデータのフィルタリング、掃除 real ダミー受注データはキャンセル処理 dummy ダミーデータの処理はさせたい vs. サービス影響は出せない

22 対策 特定 対策 確認

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チューニング • カーネルパラメータ変更

24 本日のアジェンダ：楽天スーパーSALEの舞台裏 セール当日の様子 システム上の課題解決：負荷試験 ビジネス上の課題解決：人気商品への対応 今後の取り組み

25 次の商品の共通点は何でしょう？ gelato pique 福袋 妖怪ウォッチのメダル 花王メリーズ

26 次の商品の共通点は何でしょう？ gelato pique 福袋 妖怪ウォッチのメダル 花王メリーズ 特定の層に対して絶大な人気を誇る商品

27 セール商品の分類 商品タイプ 概要 アクセス 在庫数 商品例 タイムセール商品 通常のセール商品。普段 から売られていることが 多い。 中 多い カニ、肉、水 目玉商品 スーパーSaleのみで販売。 希少性や割引額が特に高 い商品。 大 少ない 車、宝石、時計 人気商品 特定の層に人気。値段は それほど高くない。テレ ビで紹介された、など。 大 多い 特定のファッションアイ テム、おもちゃ、消耗品

28 なぜシステム上の問題が出たのか？ 在庫キャッシュの仕組みに問題があり、同一キャッシュの連続更新時に処理が遅延していた。 お買い物カゴ 在庫マスタ 在庫管理API 商品ページ (1) マスタの情報を更新する 在庫キャッシュ (2) 表示用の在庫キャッシュを更新する

29 対策1: 専用システムを構築し、検知の仕組を導入 お買い物カゴ 在庫マスタ 在庫管理API 商品ページ 在庫キャッシュ お買い物カゴ 在庫管理API 商品ページ 人気商品専用のシステムクラスタ 通常商品 人気商品 店舗用システム 監視 人気商品を別のシステムに隔離することで、負荷でシステムが スローダウンしても通常のお買い物は継続させる。

30 対策2: 在庫キャッシュの更新を非同期にする 商品ページ 在庫1 お買い物カゴ 購入完了 在庫1 在庫0 在庫マスタ 在庫確認 在庫更新 Aさん Bさん Cさん ・Cさんが、在庫1の商品を購入。 ・A/Bの両方は、アクションを起こしたときに初めて在庫切れに気づく。 ・商品ページ上の在庫が同期であっても、ページがロードされない限り気づかない 少しの仕様変更で、システム的に大きな効果が出ることがある。

31 本日のアジェンダ：楽天スーパーSALEの舞台裏 セール当日の様子 システム上の課題解決：負荷試験 ビジネス上の課題解決：人気商品への対応 今後の取り組み

32 課題 # 課題 アクション 1 スーパーSALE同様の負荷を受けきれる試験用の環境が 用意できていない。 クラウドプラットフォームに簡単にデプロイできるため のコンテナ化、マイクロサービス化。 2 スーパーSALE同様の負荷を柔軟かつ安全にかける手段 が十分に用意できていない。 システムメトリクスと紐づいた、クラウドベースの自動 テスト実行プラットフォームの開発。 3 複数のサービスを跨ったトラブルシューティングが十分 なスピード・精度・統一された手段でできていない。 統一プラットフォーム上のサービスメッシュの導入 (1) 分散トレーシングによるトラフィックの追跡。 (2) Circuit BreakerによるSystem Resiliency の強化

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 試験環境 クラウド 負荷試験環境 メトリクス

No content