2019-05-23 DMM x ZOZOを支える基盤技術 #dmm_zozo勉強会
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を利用する発想の経緯
短いの発表時間の中でたくさんの「なるほど！」と「共感」をいただけました。登壇者の皆さん、運営の皆さん ありがとうございました！
いいなと思ったら応援しよう！
