2019/05/23 に開催された DMM x ZOZOを支える基盤技術 のイベントレポートです。

●イベント概要
「DMM x ZOZOを支える基盤技術」と題して、DMM.comとZOZOテクノロジーズで勉強会を開催します！

2社ともに巨大なプラットフォーマーとして、どのような基盤やプロセスによって支えているのかを事例を交えながら開発現場のリアルを語ります。
セッション後の交流会は、ビール片手にゲストのみなさまと登壇者が自由に議論できる場に。
会場にはアルコール、ソフトドリンク、軽食を無料でご用意しておりますので、お気軽にご参加ください！

■DMMを支えるプラットフォーム基盤の裏側

石垣 雅人さん

●開発体制
・提供サービス
　　SoE(B to C)
　　　　動画、レンタルなど
　　SoR(B to B)
　　　　アカウント、購入・決済など
・プラットフォーム基盤がないと
　　サービスごとに、アカウント、購入・決済を持つ
　　アカウントが分かれてユーザビリティが低い
　　新規サービス増加時に、既存を生かせない
・実情は？
　　課金UUのうち 約40% が他サービスを使っている
　　動画使っている人が電子書籍を使っているかなど
・Cons
　　単一障害点になりやすい
・Pros
　　新規サービスでの開発コストが下がる
　　新規機能は複数サービスで使える

●ユーザーストーリーから見るプラットフォーム基盤の役割
・購入するまでに考えないといけないこと
　　検索などからDMMトップへ
　　サービスが多すぎてどこに何がどこにあるかわからない
　　　　送客
　　　　　　いかに迷わせずにサービスへ送り届けるか
　　　　回遊
　　　　　　レコメンドなどで他のサービスへ
　　会員登録・認証
　　　　認証が手間なのでSNSログイン
　　　　不正のブロックなど
　　購入・決済
　　　　ここでの離脱は避けたい
　　　　最適化したUI & 豊富な決済手段
　　リテンション
　　　　DMMでしか使えないポイントで、また来てもらう

●ポイント
・送客した、回遊したなどはビッグデータ基盤に流し込んでいる
・買収などで広がっているから独自のIDは生まれてしまう
　　IDを連携することで行動履歴をつなげている

利益の最大化にはサービスの連携が必要

■ZOZOSUITによる計測システムの裏側

指原 卓也さん

●ZOZOSUIT と PB の経緯
・初代ZOZOSUIT
　　着るだけで細かい体型をBluetoothで
　　ZOZOTOWNアプリに送る
・新型ZOZOSUIT
　　ドットマーカーをスマホカメラで360度撮影
・ZOZOプライベートブランド
　　計測した体型データで
　　一人ひとりの体型にあった「あなたのサイズ」
-> 試着しなくてもぴったりから新しい市場を
・MSP事業
　　マルチサイズプラットフォーム事業
　　ZOZOTOWNのブランドさんと協業で商品を作る
　　リーバイスと協業予定

●ニュースを追う
・2017.11 発表
・2017.12 延期
・2018.01 発送開始
・2018.02 アイデアを3億円で買い取り
・2018.04 新型ZOZOSUIT発表 & 発送開始
-> ほぼ毎月ニュースになった

・2018.02->04で
　　物理的に大量生産
　　クライアントアプリ開発
　　サーバサイト開発
　　インフラ開発

●初代ZOZOSUIT計測システム
・バージニアリージョン
　　東京にこだわる必要がなかった
　　最新サービスを摂りたい
・サーバレスアーキテクチャ
　　API Gateway, Lambda, Redis, DynamoDB

●問題1 Lambdaで起きたコールドスタート問題
・安定したリクエストが届いていれば発生しない
・貴重な初期ユーザの体験が損なわれてしまう
　　-> ElasticBeanStalkに変更

●問題2 GDPR問題
・EU内のお客さんの情報を、EU外に出さない
　　データの扱い方、削除ルールなどをお客様に周知
・体型データはセンシティブ
　　-> アイルランドリージョンで

●問題3 商品サイズ管理でのRDBとNoSQL
・部品の組み合わせが膨大
　　NoSQLなら商品仕様の変更にも柔軟
・サイズマスタ、計測データなどサービス成長とともに成長
　　計測データは基本的にRead
　　-> DynamoDB

■レコメンド/検索の大規模展開に関する課題と解決策

藤井 亮太さん

●利用状況
・レコメンド
　　10サービス
　　167種、400箇所以上
・検索
　　14サービス
　　検索 + リストとして利用

●レコメンド / ABテストの効率化
・レコメンドは着実に進んでいる
・それぞれのKPIは伸び悩んでいる
・ABテストで効率的に探索したい
　　オフライン評価
　　alias機能
　　効率的に

●単純化したレコメンドのしくみ
　　item_id        -> API
　　tracking_id <- API

●オフライン検証
・過去の傾向から効果を予測
・リリース前に品質を担保

●alias機能
・しくみ
　　商品詳細、購入完了画面で、同一のitem_idを渡す
　　それぞれに、個別のtracking_idを返す
・異なるコンテキストで実施できる

●ABテスト
・しくみ
　　複数の商品詳細画面で、同一のitem_idを渡す
　　異なるロジックで、個別のtraking_idを返す
・異なるロジックで実施できる

●aliasとABテストを組み合わせている
・コンテキストとロジックをかけ合わせたパターンを一括実施
　　ABテスト数 x alias の検証が必要
　　-> 関連するレコメンドを一括で見るダッシュボード
・1本/month から 5本/2week

●検索システム
・solr 4.10
　　古い...
・複数箇所から参照されている
　　変更しにくい
　　-> 参照元を集約したい

●solrにアクセスする検索ライブラリが巨大
・ログベーステスト
　　メソッド/引数/変数のロギング
　　hadoopに蓄積
　　ログデータをテストケースに変換
　　挙動をログで担保
・メリット
　　自動生成した大量のケースで網羅性高い
　　ユーザ利用が多いコードが沢山テストされる
　　仕様がわからないコードがテストできる
　　-> 2名 x 4ヶ月 でリファクタ完了

■ZOZOTOWN HTTPS化におけるSREチームのアプローチ

横田 工さん

2019.03 にZOZOTOWNをHTTPS化

●なぜhttps化するの？
・ブラウザ表示でのイメージダウン
・http2対応
・SEO影響
・いろいろあるが、SREちーむとしては
　　ユーザーに安心してサイトをご利用していただくこと

●SSL通信のおさらい
・RSA鍵交換
　　鍵が一定
　　秘密鍵がリークすると共通鍵を見られてしまう
・ECDHE(Forward Secrecy)
　　クライアントとサーバーで使い捨ての鍵を持つ
　　機器の負荷は上がる

●昔のZOZOTOWN
・Chrome DeveloperTool / Securityパネル
　　時代遅れ
・SSL Labsでの判定
　　B判定
　　Forward Secrecyしましょう
-> サイトHTTPS化と並走して解消しよう
　　鍵交換の優先順位をRSA->ECDHE方式
　　不要なCiphersを精査

●構成
・Before
　　FW & LB: 復号化
　　FW & LB -> WAF
　　WAF -> FW & LB
　　FW & LB -> web
　　※負荷がかかると FW & LB がボトルネックに

・復号ポイントを変更、スケールアウトへ
　　FW & LB -> WAF(複数)
　　WAF: 復号化
　　WAF -> 後段LB
　　後段LB -> web
　　※WAFでスケールアウト

●なるべく本番に近い構成で負荷試験
・安心して本番を迎えられた
・スケールにどこまで耐えられるかの目処がたった

■DMMの不正対策システムと運用サイクル

寺西 一平さん

●狙われやすいもの
・ログイン
　　アカウント乗っ取り
　　　　アカウントリストアタック
　　　　ブルートフォース
・クレカ登録
　　有効性確認
　　　　ダークウェブ上のクレカ情報で
　　　　試しに入力してみる
　　　　通ったら使われてしまう
・購入
　　アカウント乗っ取り 70%
　　不正手段で得たクレカの利用 30%

●不正対策システムと運用
・成果
　　70% の 50%以上を防止
・何をしたか？
　　不正を検出できる条件を見つける
　　その状態を維持する

●不正を検出できる条件を見つける
・失敗例
　　過去の購入時との変化
　　　　IPアドレス、ブラウザ
　　-> 2%くらいしか見つけられなかった
　　理由
　　　　ネカフェ、wifiスポット、引っ越し
　　　　VPN、プライベートブラウズ
　　-> 不正ユーザしか見ていなかった
・成功例(改善中)
　　2段階チェック
　　　　確実に本人操作と言える購買の検出
　　　　不正ユーザの特徴を含む購買の検出
　　　　　　日本語のページに台湾からロシア語で
　　　　　　など
　　-> 13%くらい見つけられた

●不正対策
　　= 不正ユーザへの嫌がらせ
　　いたちごっこになる

●不正ユーザの検出サイクル
　　ルール案 -> 試験 -> 評価 -> 有効化
　　返金業務と連携
　　継続することが重要！

●伝えたいこと
・現状把握
　　不正被害をモニタリング
　　ラベリングして対応を考えよう
・横連携
　　守りが弱いところが狙われる
　　　　SCMを変えるだけでも100->10などもよくある
　　一社では限界がある
　　　　企業を越えてノウハウ共有しましょう

■ZOZOTOWN Azure SQL Database 節約術

鶴見 純一さん、杉山 弘二さん

●コーデ相談 by WEAR
・今日リリース！
・Alexaにコーデを相談

●SQL Database節約の経緯
・セールのときだけスケールアップさせたい
　　オンプレだと事前にリソースを用意
　　ハードからの準備だと、数ヶ月かかることも
・read / writeで分かれている
　　read系をクラウド(Azure)へ
・スケールできるようになったけど高い
　　core, memoryで決まる
　　4core x 28GB で 23.5万 〜

●オートスケールの方針
・CPUやメモリ使用率でスケール
・時間帯でスケール

●時間帯でスケール
・ZOZOTOWNを含めたECサイトの傾向
　　朝〜夕方：普通
　　夕方〜夜：多い
　　深夜　　：少ない
　　-> これだけで40%くらい安くできた
・AzureAutomationでPowerShellを実行
　　Runbookでスケジュール指定
　　メリット
　　　　コスト削減できた
　　　　仕組み化でセール時も同様に
　　デメリット
　　　　ビジネスクリティカルだとスケール変更で30min
　　　　スケール変更時に 10秒くらい切断
　　　　スケールダウンでメモリもダウン
　　　　　　キャッシュが効かないことも
・Read Scale-Out
　　3台に書き込まれている
　　replica 2台
　　メリット
　　　　1台料金で、2台分のread
　　デメリット
　　　　SecondaryReplicaのメトリクスが取得できない

●Azure標準機能でのデメリットに対応する
・監視できないサービスは運用できない
　　カスタムメトリクスをとってDataDogへ
・必要なこと
　　定期的
　　バッチジョブ
　　台数増減に合わせて
　　安定稼働

●k8sのCronJobで実現
・ターゲットに合わせたカスタムメトリクス収集
・メリット
　　コンテナと一緒にゴミが破棄される
　　マニュフェストファイル管理でメンテしやすい
　　空き状況に応じてpodを起動してくれるから安定
・構成
　　jobコンテナ: CronJob
　　　　-> APIコンテナ -> メトリクス収集
　　　　-> DataDogへ送信
　　　　　　-> PagerDutyでOnCall！
　　　　-> 破棄
・Datadog
　　Azure Integration, kubernetes Integrationはある
　　でも Secondary Replicaのメトリクスは取れない

●まとめ
・組み合わせで当初のコストから 70%削減！
・デメリットを技術と創意工夫で解決していくのは面白い取り組み

■感想

・プロダクトをまたがってCXをシームレスにつなぐ
・GDPRへの対応の実際
・コンテキストとロジックをかけ合わせた施策の検証
・ログベーステストでのリファクタ
・WAFでの復号化
・whiteとblackの特徴をかけ合わせた不正検知
・マネージドサービスを利用した生の声
・ツールとしてk8sを利用する発想の経緯

短いの発表時間の中でたくさんの「なるほど！」と「共感」をいただけました。登壇者の皆さん、運営の皆さん ありがとうございました！