Yahoo! Japanのデータ分析基盤の進化 〜クラウド移行から全社的なデータ活用まで〜 #CUS-15 #AWSSummit

本記事は、AWS Summit Japan 2021のセッション動画、「CUS-15: ヤフーのマーケティング事業を支える分析環境の構築と発展」のレポート記事です。

オンプレ環境のデータの移行から、非エンジニア向けのデータ活用術、大規模な組織を横断するためのデータマネジメントなど、ヤフーさんのデータ活用の歴史がモリモリな素晴らしいセッションでした。こんなためになる情報を公開していただき、本当にありがとうございます。

この記事でも内容をまとめていますが、ぜひ本編のセッション動画もご覧ください。データ分析に関わる人は特に必見です。

ヤフーのマーケティング事業を支える分析環境の構築と発展 (CUS-15) - Summits JP Production

概要

"PB(ペタバイト)クラスのデータを取り扱うデータレイクをAWSに構築、数百人が利用する分析基盤に至るまで" ヤフーマーケティング事業における分析環境の構築、及びこれからの分析環境についてお話しします。30人以上の分析官が利用するオンプレミス分析環境における既存の課題とAWSへの移行、AWSに合わせた業務の再構築、データマネジメント、オンプレミス環境との共存などの課題をいかに解決してきたか、これからの事業拡大を分析基盤という側面でどう支えていくか、などをお話いたします。

スピーカー

• 荒川 元秀 氏
  • ヤフー株式会社 マーケティングソリューションズ統括本部 テクノロジーサービス本部 データインテリジェンス部 リーダー
    • 広告主向けの分析サービスを提供する部署
  • 分析環境の構築や分析業務の効率化を担当

内容

• ヤフーの分析サービスと分析環境の変遷
• なぜAWSを選んだのか
• 分析環境の各フェーズの詳細
  • Phase0: 環境準備
  • Phase1: 業務移行
  • Phase2: 本格稼働
  • Phase3: 基盤強化
• まとめ

ヤフーの分析サービスと分析環境の変遷

• 今回題材とするサービス
  • Yahoo! JAPANの圧倒的な量と質のデータを活用した、消費者理解支援・広告効果分析
  • 広告商品と合わせて利用することで、自社データだけでは捉えられない市場ポテンシャルや消費者インサイトを把握することができる

※出典: 消費者理解支援・広告効果分析 - Yahoo!マーケティングソリューション

• 分析事例
  • Yahoo! JAPAN第一想起分析
    • 質問ベースのアンケートとは異なり、検索行動からブランドの第一想起をモニタリングする
    • ブランド想起から検討行動、最終コンバージョンの関係性を一連の流れで説明できる
  • Yahoo! JAPAN 購買効果分析
    • CCC社とのアライアンスによる3,000万規模の実購買パネルや、PayPayを通じたキャンペーンと組み合わせる
    • 商品関与度の低い飲料食品系のメーカーなどの、市場調査、ターゲット策定、訴求方法の検討を支援

※出典: 最新マーケティング情報 - Yahoo!マーケティングソリューション

→ 本セッションでは、上記の数PBクラスのビッグデータを扱う分析環境の変遷について解説していく

• 分析環境の変化
  • Phase0: 環境準備
    • 目標: オンプレミス環境で利用していたデータを、全てAWSに載せ替え
    • 分析者数: なし
  • Phase1: 業務移行
    • 目標: オンプレミス環境で行っていた業務を、AWSで実施すべく業務を移行
    • 分析者数: アナリスト 若干名
  • Phase2: 本格稼働
    • 目標: 本格的に業務を移行し、各種AWSサービスを活用して分析活動の高度化を目指す
    • 分析者数: アナリスト 数十名、コンサルタント 数十名、セールス 200名程度
  • Phase3: 基盤強化
    • 目標: 安定稼働と業務スケールを両立させていくために、オンプレミスと共存するデータ基盤の再構築
    • 分析者数: アナリスト 数十名、コンサルタント 数十名、セールス 数百名、社外ユーザー 1000名以上

なぜAWSを選んだのか

• 当初（オンプレミス）の分析環境の構築目的
  • 課題: クライアントに対して多種多様な提案が求められている一方で、社内のデータに対する裁量（特にインフラ面）が低く、利用範囲が限定的だった
  • → 課題解決に必要なデータ分析やテストマーケティングを短期間で実現するために、データ活用ラボを構築した
• 変化する業務環境
  • データ活用の成功体験が積まれ、データ活用ニーズが高まる
    • （余談ですが、データ活用の成功体験が積まれていること自体、さすがヤフーさんという印象）
  • 組織戦略: 少数に高品質な分析を → スケール重視
  • クライアント: 少数の大企業中心 → 大小多数の企業に
  • 社内組織: 少数精鋭 → 組織化して対応
  • 業務内容: 研究開発中心 → 型化・効率化重視
  • 利用者: エンジニア中心 → アナリスト中心
  • 扱うデータ: 都度必要なデータを収集 → 常時データが揃っている
• オンプレミス環境の課題
  • オンプレで他のプロダクトと同居
  • データ処理はリソースを食いがち
  • ユーザーはエンジニアからアナリストに
  • → 事故が起き、問題が顕在化（Noisy Neighbor問題）

まとめると…↓

• As is
  • 戦略変更に伴う体制面の変化
  • 事故による周囲の目
  • 分析官中心の組織エンジニア不足
• To be
  • オンプレミスのプロダクトとは分離した環境
  • スピード感を持って移行ができる
  • エンジニアの人数は最低限で分析官に必要な業務が実施できる
• → フルマネージドなクラウドへの期待

分析環境の各フェーズの詳細

Phase0: 環境準備

• データ移行用のネットワークの構築
  • AWS Direct Connectを使用し、オンプレのHadoopやTeradataのデータをAWSへ移行

• 体制: PM 1名、エンジニア1名
• ユーザー: なし
• 期間: 3ヶ月
• ポイント
  • オンプレ環境のアセットは定型業務やガバナンスに最適化されており、これをクラウド上で実現することへの障壁
    • → いずれはオンプレミスに戻る前提で社内調整
  • クラウドへの知見がなかったため、AWSのソリューションアーキテクトのサポートを受けながら理解を深めていった

Phase1: 業務移行

• オンプレミス環境をAWS上で再現したい
• オンプレミス環境
  • Hadoop上でHiveを使ってシンプルな分析
  • 定期ETL処理をJenkinsで管理
• AWS環境
  • データはS3に配置
  • Hiveでの集計・分析処理は据え置きとし、Amazon EMRを使用
  • 定期ETL処理をJenkinsからAWS Glueに置き換え

• 体制: PM 1名、エンジニア 1.5名
• ユーザー: アナリスト 若干名
• 期間: 6ヵ月
• ポイント
  • 「まずはオンプレミス環境を再現する」というミニマムさを意識したため、移行はスムーズだった
  • Amazon EMRでのHive構築の簡単さ → 分析官側が移行を主導できた
  • 手順書を整えて勉強会を実施することで、誰でも使えるようになった
  • ある程度上位レイヤーまでコンセンサスを取り、半強制的に移行を進める
  • 分析業務をさらに高度化するための技術検証も行い、今後の展開を織り込むことで上位レイヤーの期待値を上げる
  • バッチ処理系の移行はシェル中心からPython中心になったため、難航

Phase2: 本格稼働

• AWSサービスを使い倒す
  • Amazon QuickSight、Amazon SageMakerの導入
  • 非技術者（コンサルタントやビジネスユーザー）の利用促進
    • Amazon Athenaを活用
    • SQLを使い方をレクチャし、直接データを触ってもらえるようにした

• 体制: PM 1名、エンジニア 1.5名
• ユーザー: アナリスト 数十名、コンサルタント 数十名、セールス 200名程度
• 期間: 6ヵ月
• ポイント
  • 思っていたよりもAWSサービスが多角的に揃っていたため、業務の高度化ができた
  • Amazon Athenaを活用し、ビジネスサイドのコンサルタントにSQLを教育
    • 分析官を介さずに、直接データ集計が可能になったのは評判が良かった
    • 最初は分析官がコンサルタントにSQLの使い方を教えていたが、今はコンサルタントが教える側に回っているほど
  • 分析官は単純なSQL抽出業務中心からSageMaker Notebookを活用したより高度な分析にシフト
    • → SageMaker Notebookを使った分析事例が出たことにより、上位レイヤーの期待値も加速
  • QuickSightを用いて、分析官もビジネスサイドも独自にシームレスなダッシュボードを構築
  • コロナ禍でも業務を継続しつつ、新たな挑戦が可能に
  • ビジネスサイドのAthena等の利用状況をQuickSightでトラッキングし、利用促進

Phase3: 基盤強化

• Data Lakeアカウントの作成
  • AWS Lake Formationを導入し、データマネジメントを強化
  • データの仕様や権限周りの確認をスムーズに
• 非分析官向けの独自ツールを開発
  • SQLを使えない人でも、フォームを入力するだけで簡単な分析ができるインターフェース（仮称: SURGE）
  • → さらにビジネスユーザーをスケールさせる

• 体制: PM 数名、エンジニア 十数名、データマネジメント 数名 (+データマネジメントコンサル)
• ユーザー: アナリスト 数十名、コンサルタント 数十名、セールス 数百名、社外ユーザー 1000名以上
• ポイント
  • 誰でもある程度データ分析ができるように独自ツール（仮称: SURGE）を開発し、社外にも公開して分析サービス化
  • データマネジメントが課題だったため、社外コンサルを入れオンプレ側を含め整理
    • AWS Lake Formationを導入し、柔軟な権限管理を実現
  • SURGEを含め主要ツールの利用状況をトラッキング
    • データ分析を全社的に浸透させるために、泥臭くマンパワーで現場へアクション
  • タグ付けなどによるコストトラッキングを開始
    • → 分析が型化された売上と紐づけて可視化
  • S3バケットをS3 Intelligent-Tieringのストレージクラスに切り替えし、コスト最適化

まとめ

• ポイント
  • 環境準備: 元々オンプレミス側から半ば追い出されるような形でスタート
  • 業務移行: AWSが思っていたよりも使いやすく、想定よりもスムーズに完了
  • 本格稼働: 大きな労力をかけずに本格稼働させることができ、業務自体が高度化
  • 本格稼働: 事例を作りつつユーザー自体のスケールを意識しながら組織を巻き込み
  • 基盤強化: ユーザーの増加に耐えうるだけの、基盤強化を実施
• 今後の課題
  • 基盤強化の完遂
    • 非分析官向け分析ツールのサービス化
    • マネジメントされたデータへの完全移行
  • 利用者のスケールに向けた、次の取り組みへ
    • 安定稼働のための各種運用効率化とガバナンス強化
      • 権限管理、データ運用ポリシー整備など
    • オンプレミス側各種ツールとの共存、連携
      • データのカタログ化、既存ダッシュボードとの共存
    • 分析環境と広告関連ツールのシームレスな連携
    • 定期ETL処理の管理・運用効率化
    • DWHとの共存による高速化・効率化
    • これらを実現するための技術教育、採用強化