J A P A N M A Y , , Amazon Web Services, Inc. or its affiliates. All rights reserved. 画面に映る資料の撮影などによる本セッション資料の転用を禁止しております

(1)

(2)

AWS 移行事例紹介

~ DMM のデータ活用を支えるビッグデータ基盤・ML基盤のクラウド移行 ~

座間味卓臣

合同会社 DMM.com データ本部本部長 C U S - 4 0

(3)

アジェンダ

• 自己紹介

• DMMについて

• データ本部について

• 移行後のシステム概要について

• データ基盤の移行について

• 機械学習(ML)基盤の移行について

• まとめ

(4)

アジェンダ

• 自己紹介

• DMMについて

• データ本部について

• 移行後のシステム概要について

• データ基盤の移行について

• 機械学習(ML)基盤の移行について

• まとめ

(5)

自己紹介

• 合同会社 DMM.com

データ本部

本部長

座間味卓臣 ( Takumi Zamami )

• 経歴

• 2018年1月入社社長室配属

• 2018年5月 AI部部長

• 2020年3月データサイエンス部部長

• 2021年1月データ本部本部長

(6)

アジェンダ

• 自己紹介

• DMMについて

• データ本部について

• 移行後のシステム概要について

• データ基盤の移行について

• 機械学習(ML)基盤の移行について

• まとめ

(7)

(8)

(9)

(10)

(11)

(12)

(13)

(14)

アジェンダ

• 自己紹介

• DMMについて

• データ本部について

• 移行後のシステム概要について

• データ基盤の移行について

• 機械学習(ML)基盤の移行について

• まとめ

(15)

(16)

(17)

データの収集から活用までを担当

Client Users Application server DWH, Datamart Data Analyst ①データ取り込み ②整形 ③ 分析環境の提供 ④ データ解析（MLはおもに解析・データ生成で活用） ⑤ データを活用したアプリケーションの提供（商品推薦・商品検索） Data Engineer Data Scientist, Data Engineer SRE Application Engineer

(18)

アジェンダ

• 自己紹介

• DMMについて

• データ本部について

• 移行後のシステム概要について

• データ基盤の移行について

• 機械学習(ML)基盤の移行について

• まとめ

(19)

(20)

そんな要求に答える、現在のシステム（移行後）

AWS Cloud Data center Office Server Client User Client API Cluster Batch Cluster DWH Data Mart Amazon EMR

Amazon S3 Amazon S3 Amazon S3

AWS Glue Data Catalog

Amazon EMR Amazon Athena

Amazon SageMaker Service Task Service Amazon DynamoDB _Elastic Load Balancing Amazon Route 53 Users AWS Glue Crawler

(21)

アジェンダ

• 自己紹介

• DMMについて

• データ本部について

• 移行後のシステム概要について

• データ基盤の移行について

• 機械学習(ML)基盤の移行について

• まとめ

(22)

AWS Glue Crawler Data center Server Client Users

まずは、データ基盤のクラウド移行について

AWS Cloud Office

User Client API Cluster Batch Cluster DWH Data Mart Amazon EMR

Amazon SageMaker Service Task Service Amazon DynamoDB Elastic Load Balancing Amazon Route 53

(23)

データ基盤規模

Client Users Application server DWH, Datamart 分析利用者 1TB/1日以上追加 Data Engineer Data Scientist, Data Engineer SRE Application Engineer 数百TBのデータ 1,000 Table 以上 _{1,000人以上} • 事業担当者 • エンジニア • マーケティング担当者 …. 実行ジョブ実行Query 20,000 / 週以上

(24)

データ基盤移行前

(25)

ハイブリット構成データが散在

Client Application server DWH 分析利用者 DWH DWH ①基盤チーム管理外の独自コピー, 独自処理 AWS Cloud Data center 悲しい過去の事例 • 基盤チーム管理外の独自コピー、独自処理Batchが存在(①) • 元データ不具合発生時の再取り込み時(②)に誰も整合性を担保できないデータ発生(③) • データの不一致をユーザーが検知(④) • データの差分調査が発生 • 利用者から信頼を失う ④一致すべきデータの不整合を検知 ②不具合発生時は再取り込み ③独自管理のため再実行されない DWH

(26)

プロダクトごとに利用データが異なる

Client Application server DWH DWH DWH AWS Cloud Data center DWH プロダクトA プロダクトB プロダクトC 分析利用者

(27)

事業ごとに独立した、高い柔軟度

Client Application server DWH DWH DWH AWS Cloud Data center DWH プロダクトA プロダクトB プロダクトC 分析利用者

(28)

結果的に数多くのシステムが乱立

Virtual machine 数

172

(本番のみ）などなど。。。。これらの組み合わせにより構成された、 * 2 * 2

(29)

問い合わせ

業務負荷が高く、6人の基盤チームはパンク

Client Application server DWH DWH DWH AWS Cloud Data center DWH プロダクトA プロダクトB プロダクトC 分析利用者担当者担当者問い合わせ問い合わせ問い合わせ基盤担当

(30)

問い合わせ

データ基盤を取り巻く課題まとめ

Client Application server DWH DWH DWH AWS Cloud Data center DWH プロダクトA プロダクトB プロダクトC 分析利用者担当者担当者問い合わせ問い合わせ問い合わせ基盤担当 ① ② ② ② ② ③ ③ ③ ③ ④ ①システムが乱立 ②データが散在 ③データの状態がわからず、安心して使えない結果的に ④基盤チームに問い合わせ殺到し業務負荷が高い状態

(31)

問い合わせ

増加データへの対応、データ活用推進が困難な状況

Client Application server DWH DWH DWH AWS Cloud Data center DWH プロダクトA プロダクトB プロダクトC 分析利用者担当者担当者問い合わせ問い合わせ問い合わせ基盤担当 ①システムが乱立 ②データが散在 ③データの状態がわからず、安心して使えない結果的に ④基盤チームに問い合わせ殺到し業務負荷が高い状態

(32)

問い合わせ

クラウド移行を通じ、課題解消を目指す

Client Application server DWH DWH DWH AWS Cloud Data center DWH プロダクトA プロダクトB プロダクトC 分析利用者担当者担当者問い合わせ問い合わせ問い合わせ基盤担当 ①システムが乱立 ②データが散在 ③データの状態がわからず、安心して使えない結果的に ④基盤チームに問い合わせ殺到し業務負荷が高い状態スケール可能なシステム・業務の実現 • どうしても必要な業務・システムのみ残す • 可能な限りManagedなサービスを利用 • 管理対象のシステム・業務を極限まで減らす

Single Source of Truth ( SSoT ) の実現

• すべてのデータを一箇所に集める

データ品質の可視化の実現

• データ品質の監視を導入

(33)

(34)

オンプレシステムについて

AWS Cloud Office

Amazon SageMaker Service Task Service Amazon DynamoDB _Elastic Load Balancing Amazon Route 53

(35)

最低限のシステムのみに

オンプレデータ取り込みのための * 2 * 2 Virtual machine 数

8

(本番のみ）

(36)

Data center Server Client Users

アマゾンウェブサービス（AWS）のシステムについて

Office User DWH Data Mart

Amazon EMR Amazon S3 Amazon S3

Amazon EMR Amazon Athena AWS Cloud

Amazon S3

AWS Glue Crawler

(37)

Amazon S3を活用したSSoTの実現

Amazon EMR Amazon Athena AWS Cloud Amazon S3 すべてのデータを同一AWSアカウントのAmazon S3に集め、SSoTを実現 Audit用のログ取得も容易  監査対応業務の廃止注意した点） • スローダウンへの対策

(38)

Data center

Server Client Users

AWS Glue Crawler 活用でTable定義を自動化

Office

User

DWH Data Mart

Amazon S3

AWS Glue Crawlerを活用し、Amazon S3に保存されたデータからTable定義を自動作成 Hive (Spark), Amazon Athena でも読み書き可能な形式に対応

 テーブル定義更新業務を廃止

AWS Glue Crawler

(39)

EMRを活用した効率改善

Amazon EMR Amazon Athena AWS Cloud Amazon S3 ジョブごとにクラスタを分割し、リソースを割当様々な言語で実装されていたBatchの実装をSparkで再実装（再実装の際に不要なJobや、集約可能なJobを整理）  結果的にオンプレ時代の 1/8 程度のスペックで運用を実現  クラスタ管理業務の廃止、監視対象のJob数削減による業務負担軽減注意した点 )

• Amazon S3にVPC endpoint を設定 ( 利便性観点で EMR を public subnet に配置 )

AWS Glue Crawler

(40)

Data center

Server Client Users

AWS Glue Data Catalogを活用したデータ品質可視化

Office

User

DWH Data Mart

Amazon S3

データ品質に関わる情報*をGlue Data Catalogに集約し、利用者がデータの品質を確認可能な状態を実現

( *: ex.データ更新時間、データValidation成否等 )  データに関する問い合わせ対応を大幅に削減

AWS Glue Crawler

(41)

Athenaを活用したQuery環境の提供

Amazon EMR Amazon Athena AWS Cloud Amazon S3 SQLの実行環境をAthenaに集約し、Query実行環境の管理業務を廃止実行環境を一元化したことにより、Audit 対応業務も大幅削減 AWS Glue Crawler

(42)

結果的に利用者、基盤担当が幸せに

Office DWH Data Mart

Amazon EMR Amazon Athena AWS Cloud Amazon S3 基盤担当 User 安心してデータを利用できる環境を獲得 • データの不整合の解消 • データ品質が可視化データ活用促進へ注力可能な状態を獲得 • 運用業務の大幅削減 • （副次的に）利用実態を把握可能な状態を獲得 Managedなスケール可能な環境を獲得

(43)

アジェンダ

• 自己紹介

• DMMについて

• データ本部について

• 移行後のシステム概要について

• データ基盤の移行について

• 機械学習(ML)基盤の移行について

• まとめ

(44)

次に、ML基盤のクラウド移行について

AWS Cloud Office

Amazon SageMaker Service Task Service Amazon DynamoDB _Elastic Load Balancing Amazon Route 53

(45)

ML基盤移行前

(46)

データ活用促進に向けた課題

データ活用促進に向けた課題 • スケール性オンプレのリソースが共有となっており、重たい処理実行時には調整が必要 (①) • 効果計測方法がバラバラ ABテスト等リリース効果評価の仕組みを各プロダクトで実装。横断評価が困難(②) • 業界のプラクティス導入工数が大きいプロダクトごとに別々の環境を利用しており、実装管理方法・Release方法が異なっていた。知見の共有がしづらく、プラクティス導入時も個別対応が必要となっていた(③) DWH DWH AWS Cloud Data center DWH プロダクトA プロダクトB プロダクトC 担当者担当者 ① ② ③

(47)

クラウド移行を通じた課題解消方針

データ活用促進に向けた課題 • スケール性オンプレのリソースが共有となっており、重たい処理実行時には調整が必要 (①) • 効果計測方法がバラバラ ABテスト等リリース効果評価の仕組みを各プロダクトで実装。横断評価が困難(②) • 業界のプラクティス導入工数が大きいプロダクトごとに別々の環境を利用しており、実装管理方法・Release方法が異なっていた。知見の共有がしづらく、プラクティス導入時も個別対応が必要となっていた(③) DWH DWH AWS Cloud Data center DWH プロダクトA プロダクトB プロダクトC 担当者担当者 ① ② ③ スケール可能なシステムの提供 • 可能な限りManagedなサービスを利用 • 管理対象のシステム・業務を極限まで減らすリリース影響評価を統一 • ABテストの評価方法を統一 Agility高い環境の獲得 • 非データ活用領域を集約 • 業界のプラクティスを導入可能な状態の実現

(48)

(49)

移行後のML基盤

AWS Cloud API Cluster Batch Cluster DWH Amazon S3 AWS Glue Data Catalog Amazon SageMaker Service Task Service Amazon DynamoDB _Elastic Load Balancing Amazon Route 53

(50)

各専門家が得意な領域に注力

AWS Cloud API Cluster Batch Cluster DWH SRE / Amazon S3 AWS Glue Data Catalog Amazon SageMaker Service Task Service Amazon DynamoDB _Elastic Load Balancing Amazon Route 53 Data Scientist /

(51)

ML 基盤 Batch cluster

AWS Cloud API Cluster DWH Amazon S3 AWS Glue Data Catalog Service Elastic Load Balancing Amazon Route 53 Batch Cluster Amazon SageMaker Task Service Amazon DynamoDB

(52)

Service

Spark on Amazon EKS, Amazon SageMaker の活用

AWS Cloud API Cluster DWH Amazon S3 AWS Glue Data Catalog Service Elastic Load Balancing Amazon Route 53 Batch Cluster Amazon DynamoDB Amazon SageMaker Task • 良いモデル・Batch を作ることに注力

• Scheduling や workflow の定義は yaml を書くだけ • Spark on k8s, Amazon SageMaker はお好みで

• Amazon SageMaker operator を利用することで、 Batch化もYamlを記述するだけで実現可能

(53)

Service

DynamoDB の活用

AWS Cloud API Cluster DWH Amazon S3 AWS Glue Data Catalog Service Elastic Load Balancing Amazon Route 53 Batch Cluster Amazon SageMaker Task

• Batch ClusterとAPI Clusterの間に設置し責務を分離

• Data Scientist, Data Engineer は良いデータを届けることに注力 • Key にABテストIDを入れ、モデルを分離

• StateをAPI Cluster外に分離することで、

StatelessなApplicationに限定し、API Clusterの運用工数を削減

Amazon DynamoDB

(54)

ML 基盤 API cluster

AWS Cloud Batch Cluster DWH SRE / Amazon S3 AWS Glue Data Catalog Amazon SageMaker Task Service Elastic Load Balancing Amazon Route 53 API Cluster 推薦API Amazon DynamoDB • サービスの安定性維持、継続的改善に注力 • Scalingは Amazon EKS におまかせ

• Flagger を採用し、リリースやABテストの切り替えをトラフィック1%単位で自動検証

ABテスト判定購入済商品除外

(55)

Microservices on Amazon EKS + Istio + Flagger による

アジリティ獲得

認証用API 推薦API

購入済み商品除外API

ABテスト判定API _{Campaign api}

・・・ ① ② ⑤ ⑥ ③ ④ ⑨ ⑩ ⑧ ⑦ API Cluster Amazon DynamoDB • APIを疎結合にし、再利用性を向上車輪の再開発を抑止 • Istio導入により API間の通信(影響範囲) 可視化を実現

(56)

Microservices on Amazon EKS + Istio + Flagger による

アジリティ獲得

⑥リリース完了 ② v2(新しいversion) へトラフィックを徐々に流す（エラー検知で自動差戻し） ④v2の検証を完了 v1をv2へ置換 ⑤置き換えたv2へトラフィックを徐々に戻すリリースまでの流れリリースまでのトラフィック推移

(57)

各専門家が得意領域に注力できる環境の獲得

AWS Cloud API Cluster Batch Cluster DWH Amazon S3 AWS Glue Data Catalog Amazon SageMaker Service Task Service Amazon DynamoDB _Elastic Load Balancing Amazon Route 53 Managedなスケール可能な環境を獲得システムの安定性向上・Agility向上に注力可能に業界のプラクティスを楽に導入可能にリソースを気にせず気軽に実験可能に良いアルゴリズム・Batchの実装に注力 SRE / Application Engineer Data Scientist / Data Engineer

(58)

アジェンダ

• 自己紹介

• DMMについて

• データ本部について

• 移行後のシステム概要について

• データ基盤の移行について

• 機械学習(ML)基盤の移行について

• まとめ

(59)

(60)

そんな課題をAWS移行を通じて解決しました

Amazon SageMaker Service Task Service Amazon DynamoDB _Elastic Load Balancing Amazon Route 53 Users AWS Glue Crawler Users

(61)

今後は、さらなるデータ活用促進に注力

Amazon Service Task Amazon DynamoDB _Elastic Load Balancing Amazon Route 53 Users AWS Glue Crawler Users ①より新鮮なデータを利用者に届ける ②複雑な分析が可能な環境の提供 ④ニアリアルタイムに結果を変える仕組みの構築

(62)

We’re hiring !

(63)

Thank you!

座間味卓臣

AWS 移行事例紹介

J A P A N M A Y , , Amazon Web Services, Inc. or its affiliates. All rights reserved. 画面に映る資料の撮影などによる本セッション資料の転用を禁止しております

AWS 移行事例紹介

~ DMM のデータ活用を支えるビッグデータ基盤・ML基盤のクラウド移行 ~

座間味 卓臣

アジェンダ

• 自己紹介

• DMMについて

• データ本部について

• 移行後のシステム概要について

• データ基盤の移行について

• 機械学習(ML)基盤の移行について

• まとめ

アジェンダ

•

自己紹介

• DMMについて

• データ本部について

• 移行後のシステム概要について

• データ基盤の移行について

• 機械学習(ML)基盤の移行について

• まとめ

自己紹介

• 合同会社 DMM.com

データ本部

本部長

座間味 卓臣 ( Takumi Zamami )

• 経歴

• 2018年1月 入社 社長室配属

• 2018年5月 AI部 部長

• 2020年3月 データサイエンス部 部長

• 2021年1月 データ本部 本部長

アジェンダ

• 自己紹介

•

DMMについて

• データ本部について

• 移行後のシステム概要について

• データ基盤の移行について

• 機械学習(ML)基盤の移行について

• まとめ

アジェンダ

• 自己紹介

• DMMについて

•

データ本部について

• 移行後のシステム概要について

• データ基盤の移行について

• 機械学習(ML)基盤の移行について

• まとめ

データの収集から活用までを担当

アジェンダ

• 自己紹介

• DMMについて

• データ本部について

•

移行後のシステム概要について

• データ基盤の移行について

• 機械学習(ML)基盤の移行について

• まとめ

そんな要求に答える、現在のシステム（移行後）

アジェンダ

• 自己紹介

• DMMについて

• データ本部について

• 移行後のシステム概要について

•

データ基盤の移行について

• 機械学習(ML)基盤の移行について

• まとめ

まずは、データ基盤のクラウド移行について

データ基盤 規模

データ基盤移行前

ハイブリット構成 データが散在

プロダクトごとに利用データが異なる

事業ごとに独立した、高い柔軟度

結果的に数多くのシステムが乱立

172

業務負荷が高く、6人の基盤チームはパンク

データ基盤を取り巻く課題まとめ

増加データへの対応、データ活用推進が困難な状況

座間味卓臣

座間味卓臣 ( Takumi Zamami )

• 2018年1月入社社長室配属

• 2018年5月 AI部部長

• 2020年3月データサイエンス部部長

• 2021年1月データ本部本部長

データ基盤規模

ハイブリット構成データが散在

アマゾンウェブサービス（AWS）のシステムについて

座間味卓臣