【イベント】データ分析基盤Developers Night 〜3社3様分析基盤の変遷〜

2019年4月25日(木曜日)、株式会社マクロミルが主催の、

データ分析基盤Developers Night〜3社3様分析基盤の変遷〜

が開催されました。

マクロミルからは新しいデータ価値とビジネスを創出するビッグデータ分析基盤(前編)
データ分析基盤をつくるための開発事例 
を岡澤 哲也さんよりお話頂きました。

当日はマクロミルの他にも、

  • データドリブンを支えるビッグデータ基盤の変遷
    (合同会社DMM.com 出相 早織 さん/川島 崇秀 さん)
  • ナビタイムジャパンに集まる移動ビッグデータの分析基盤
    (株式会社ナビタイムジャパン 新立 和広 さん)

にもご登壇頂き、定員80名を大きく上回る273名の応募となり、大盛況となりました。

Alt text

今回は中でも株式会社マクロミル 岡澤 哲也 さん にご登壇頂いた、
新しいデータ価値とビジネスを創出するビッグデータ分析基盤(前編)
データ分析基盤をつくるための開発事例
をご紹介致します。

Alt text

マクロミルのストラテジックITソリューション部の位置づけ

岡澤 さん が所属するストラテジックITソリューション部は、
既存のシステム開発・保守の部署とは独立しており、
ビジネス成長のための新規事業開発・技術研究に特化している部署になります。

データ分析基盤構築の背景

なぜデータ分析基盤構築を行うことになったのか?

上記リサーチサービスは当初からあったものではなく、
2000年創業以来徐々に増えてきたものです。
それぞれサービス毎に蓄積してきた様々なデータがありましたが、
そのデータの有効活用はまだまだ発展途上でした。
しかし、ビジネス拡大のためにはそれらのデータの有効活用が必要な状況でした。

データ分析基盤構築の2つのゴール

そこで、
『データからインサイトを得るための環境』の整備が急務
となり以下の2点をゴールとしてデータ分析基盤構築に至りました。

  • 社内すべてのサービス・システムのデータを保有している
  • 各システムのデータ参照が可能なだけではなく、それらを掛け合わせた集計/抽出が可能

アーキテクチャ/ソリューションの選定

選定時のシステムの状況は?

アーキテクチャ/ソリューションの選定にあたって、

  • 各サービス/システムは縦割り構成で、システム間は連携されてない
  • オンプレ環境、クラウド環境が混在
  • 近年の新しいサービスは保有データ量が多い

というシステム的側面がありました。

選定時のその他のシステム以外の状況は?

データレイクにデータを集めるにあたって、
他システム開発部門に依頼するタイミングには、
既に予定タスクによって人も時間も余っていないといった状況となっており、
各システム開発部門にデータ投入の対応を協力してもらうには時間/期間がかかりすぎる
という事情がありました。

そこで、
「貰うのが難しければ、自ら取りに行ってしまえばいいという逆転の発想で進めることにしました」 Alt text

中核サービスとしてのAWS DMS

上記の背景も踏まえ、 AWS Data Migration Service(以下DMS)を中核サービスに据えることと致しました。
ご存知の方もいるかと思いますが、DMSは、

  • 同種データベース間の移行
  • 異種データベース間の移行
  • 継続的なデータレプリケーション

といったことができるサービスです。

ビッグデータの処理フローと処理を実現するAWSサービス

構成の説明をする前に、改めてビッグデータの処理フローを整理すると、 下記のようになります。

Alt text
  1. 分析対象となるデータの収集と保存を行う
  2. 定期的 or 溜まったタイミングでデータを取り出す、
    フォーマット変換、クレンジングや一次集計などデータ変換/加工を行う
    →ETL(抽出/変換・加工/ロード)
  3. ETL済みのデータから目的のデータを取り出す

処理するプロセスの中では、
大事なETL(抽出、変換・加工、ロード)も含まれます。

また、これらの処理フローを実現するAWSサービスは次の図のようになっています。

Alt text

収集ではセキュアにつなぐためのDirect ConnectやKinesisも利用し、
データレイクはS3になっています。
S3を採用しているのはデータ容量が無制限という点からです。

その他では、テーブルの作り方によってはAthenaでも充分にデータウェアハウスとして機能するので、
アドホック分析などでもAthenaも使用しているのと、
社内で利用が進んでいるTableauなどもつなぎにくる想定で構築しております。

最終的なアーキテクチャの概要図

Alt text Alt text

最終的なアーキテクチャの構成としては上記の図のようになりました。
DMSでデータをかき集め、 一度Auroraに格納、そこからファイル化しS3に配置、
ファイル化したものをGlueでカタログ化し、Athenaから引けるようにするという構成になっております。

いくつか工夫した点として、
DMSでは、パッチ処理によって動的にDMSタスクを生成&実行するようにしています。
これは、オリジナルDBを参照するにあたって、リードレプリカがないものもあり、
そういった場合、日中のリソース負荷避け、深夜帯に負荷を集約することが目的です。
また、動的なDMSタスク生成&バッチ実行によって、テーブル増減への自動追従も可能となります。

もう一点、
Auroraでは、「データ量が少ない」「クエリ負荷が低い」「Athenaのオーバーヘッドが許容できない」という社内アプリケーションが
他システムのデータを利用したい場合の参照先としてReaderを開放しています。
データ量が少ない場合などはAthenaのほうがRDS利用より処理時間がかかることがあるからです。

もう少し詳しく

Alt text

先程の概要図に沿って、
もう少し細かく記載すると、上記の図のようになります。

DMSタスクの動的制御部分について

CloudWatchのイベントスケジュールでStepFunctionを起動し、
Lambdaを動かすことで動的にDMSタスクを制御しています。

DMS下のJenkinsについて

エラー時のリカバリ用バッチ処理が入っています。

採用アーキテクチャの結果

メリット

基盤構築で生まれた最大のメリットは「レイクをハブにして縦割り だったシステム間のデータ連携が進み始めている」ことです。

デメリット

一方で、
データの閲覧範囲の制限、マスキングなどのクレンジングの手間がかかることが 大きなデメリットとなってしまっております。
また、ETLのステップを踏まず、オリジナルデータから欲しいデータを無理やり作ろうとするSQL実行が頻発しており、
SQLに関する質疑応答などが増加している状況です。
そのため、そもそもETL済みのデータをいかに提供できるかがポイントとなっておりますが、
開発側にデータサイエンティスト、データベースエンジニアが不足している点は課題であります。

後編(5月28日(火)開催予定!)の内容

今日お話したのは弊社のデータ分析基盤のシステム面ですが、
5月28日(火)開催予定の後編ではビジネス面にフォーカスした内容でお話します。

現在の弊社ではデータ分析基盤により既存データの
新しい価値が生まれ、新たなビジネスへ繋がっています。

しかし、新しいことへのチャレンジは課題を生みます。
直面した課題と対するアプローチなど、包み隠さずお話いたします。
ご興味がある方はぜひお越しください!

イベントの予約は こちら