DMMのデータ活用を支えるビッグデータ基盤・ML基盤のクラウド移行 (CUS-40) #AWSSummit

AWS Summit Online Japan 2021

#AWS Migration

#データレイク

春田拓海 | Takumi

2021.05.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

本記事は、AWS Summit Japan 2021のセッション動画「CUS-40: AWS移行事例紹介 ~DMM のデータ活用を支えるビッグデータ基盤・ML基盤のクラウド移行 ~」のレポート記事です。

概要

"50以上の事業を展開するDMM。年々増えるデータ、バッチ、業務。そんな状況をAWS上での基盤構築を通じて打開した事例紹介" 50以上のビジネスを展開するDMM.comでのデータ活用基盤（データレイク基盤と機械学習基盤）をAWS上に構築した事例を紹介します。データレイク基盤はオンプレ上で動いていた3000以上のJobの完全移行を実施し、よりスケーラブルな分析、データ処理、Single Source of Truth (SSoT)を実現しています。機械学習基盤はArgoなどエコシステムが豊富なAmazon EKS Kubernetesを採用し、機械学習モデルの継続的なデプロイを行うことが可能なプラットフォームを実現しています。

スピーカー

座間味卓臣氏
- 合同会社DMM.com データ本部本部長

内容

DMMについて
データ本部について
移行後のシステム概要について
データ基盤の移行について
- データ基盤移行前
- データ基盤移行後
機械学習(ML)基盤の移行について
- ML基盤移行前
- ML基盤移行後
まとめ

DMMについて

会社概要
- 社名: 合同会社 DMM.com
- 所在地: 本社（東京都港区）、加賀事業所（石川県加賀市）、金沢事業所（石川県金沢市）
- 設立: 1999年11月17日（設立23年目）
- 資本金: 1,000万円
具体的な数字
- 連結売上; 2,340億円
- DMM.comサービスの会員数: 3,409万人
- 事業数: 50以上
- グループ会社; 20社以上
- 従業員数; 4,101名
事業コンセプト
- 規模の大小、ジャンル関係なく、未来を感じるビジネスに投資し、領域問わず、なんでもやる
- 動画からゲーム、株、英会話など

データ本部について

DMM TECH VISION
- DMMのテックチームの「在り方」を明文化
4つのTECH VALUE
- Agility（敏捷的）
  - 誰もが素早く挑戦し、失敗が許容できる技術的基盤がある
  - 見つけた最適解を全体に広める仕組みがある
- Scientific（科学的） ←今回の焦点
  - 数値を共通言語とし、エンジニア、ビジネスサイドに関係なく意見が評価・実施される
  - 改善に再現性があり、全社で活かされていく
- Attractive（魅力的）
  - 日本で最もエンジニアを惹きつける組織
  - 多事業展開や新技術、R&Dから成る多くの技術的チャレンジがある
- Motivative（意欲的）
  - 誰もが能力を発揮できる場にいる
  - 透明性の高い組織で、誰もが自分の仕事の意義を理解している

DMMのデータ本部
- データ活用を推進するScientificに関わる本部
- 計測から課題発見、施策立案、UXの提供を行っている
データの収集から活用までを担当
- ①データ取り込み
  - Data Engineer
- ②データの整形
  - Data Engineer
- ③分析環境の提供
  - Data Analyst
- ④データ解析（MLはおもに解析・データ生成で活用）
  - Data Scientist
  - Data Engineer
- ⑤データを活用したアプリケーションの提供（商品レコメンド・検索など）
  - SRE
  - Application Engineer

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

背景
- 年々増える事業・データに対応可能な基盤が求められる
→ シンプルでスケーラブルな環境をAWSで構築した

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

データ基盤移行前

データ規模
- 日時データ連携量: 1TB以上
- テーブル数: 数百TBのテーブルが1,000以上
- 分析利用者: 1,000人以上、様々な職種
- 実行Query数: 20,000/週以上
- 実行ジョブ数: 2,000/日以上
移行前の状況や課題
- データの個別最適化が進み、事業ごとに環境が乱立
  - 172個のVMが稼働していた
- データが散在
  - 基盤チーム管理外の独自Batchが存在し、類似データが散在
  - オンプレとAWSのハイブリッド構成（AWSはデータのバックアップ用途として利用）
- データの品質が低くなり、利用者からの信頼を失う
- データ基盤チームは6人体制で、業務負荷が高くパンクしかけていた
課題解消に向けて
- スケール可能なシステム・業務の実現
  - どうしても必要な業務・システムのも残す
  - 可能な限りManagedなサービスを利用
  - 管理対象のシステム・業務を極限まで減らす
- Single Source of Truth (SSoT) の実現
  - すべてのデータを一箇所に集める
- データ品質の可視化の実現
  - データ品質の監視を導入
  - 利用者にデータ品質を可視化

データ基盤移行後

オンプレ環境
- 最低限のシステムのみを残す → VM数は本番環境で8まで削減できた
  - Docker
  - Digdag
  - Jenkins
AWS環境
- 全てのデータを同一AWSアカウントのAmazon S3に集約し、3層に分割
  - Data Lake、Data Warehouse、Data Mart
  - → SSoTを実現
  - → 監査用のログ取得も容易になり、監査対応業務を廃止
- テーブル定義の更新に、AWS Glue Crawlerを使用して自動化
  - 作成したCatalogは、Hive(Spark)やAmazon Athenaから参照可能
  - → テーブル更新業務を廃止
- バッチジョブにAmazon EMRを使用し、乱立していた言語をSparkで再実装
  - 再実装の際に不要なJobや、集約可能なJobを整理
  - → 結果、オンプレ時代の1/8程度のスペックで運用を実現
  - → クラスタ管理業務の廃止、監視対象のJob数削減による業務負担軽減
- データ品質に関わる情報をGlue Data Catalogに集約
  - → データに関する問い合わせ対応を大幅に削減
- 利用者向けSQL実行環境をAthenaに集約
結果
- 利用者 → 安心してデータを利用できる環境を獲得
  - データの不整合の解消
  - データ品質が可視化
- 基盤担当 → データ活用促進へ注力可能な状態を獲得
  - 運用業務の大幅削減
  - （副次的に）利用実態を把握可能な状態を獲得
- → 年々増加するデータへ対応可能な、安心してデータ活用推進が可能な環境を獲得

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

ML基盤移行前

移行前の状況や課題
- ハイブリッド構成のため、巨大な処理をオンプレのDWHで行う際には調節が必要
  - 気軽に実験しづらい環境だった
- 各プロダクトごとで効果計測の指標がバラバラ
  - プロダクト横断的な評価が困難
- 環境やリリース方法が異なるため、知見の共有がしづらかった
課題解消に向けて
- スケール可能なシステムの提供
  - 可能な限りManagedなサービスを利用
  - 管理対象のシステム・業務を極限まで減らす
- リリース影響評価を統一
  - ABテストの評価方法を統一
- Agility高い環境の獲得
  - 非データ活用領域を集約
  - 業界のプラクティスを導入可能な状態の実現

ML基盤移行後

AWS基盤
- S3のDWH層データをEKSのBatch Clusterが処理
- 処理結果をDynamoDBに書き込み
- DynamoDBをEKSのAPI Clusterが読み込む
Batch Cluster
- Data Scientist / Data Engineer向け
- スケーリングはEKSに任せ、良いモデル・Batchを作ることに注力
- WorkflowエンジンにAlgoを採用
- Schedulingやworkflow の定義はyamlを書くだけ
- Spark on k8sやAmazon SageMakerを自由に使える
DynamoDB
- Batch ClusterとAPI Clusterの間に設置し責務を分離
- API ClusterのStateもDynamoDBで管理し、アプリケーションをステートレスに
API Cluster
- SRE / Application Engineer向け
- サービスの安定性維持、継続的改善に注力
- Flaggerを採用し、リリースやABテストの切り替えを自動検証（カナリアリリース）
- Istio導入によりAPI間の通信（影響範囲）可視化を実現
→ Managedでスケーラブルな環境を獲得
→ 楽にデータ活用促進に注力できる状態の獲得