【一休 × JapanTaxi】サービスを支えるデータ分析基盤


一休.com におけるデータ分析基盤とCRM運用(仮)

株式会社一休 宿泊事業本部システム開発部長 エンジニアリングマネージャー 笹島祐介

  • もともと一部の人がやっていたものを全社向けに再構築したんです。
  • 移行の背景
    • 本番環境と社内の分析環境は分断されていたんですよね。
    • なので、一旦一日1回しかETLできていないし、ディスク容量が足りなくなってきたんです。
    • そうすると日々のマーケティング施策がとまってしまうのでなんとかしようと。なりました。
  • 再構築前のデータ分析基盤
    • 様々なデータソース(基幹DBとGoogleAnalyticsPremium)
    • GAPremiumだと、自動的にGoogleBigQueryに入るんです。
    • DHWはSQLServer
      • DWHに対してTableauやredashを使っています。
  • どうしたかというと
    • DHWをAWS redshiftに移行した。
    • そうしたら、環境が違うせいで、社内のデータサイエンティストからもんくが沢山出た。ツールを移動するの嫌だとか。
    • なので、postgresベースでのredshiftではなくAzure SQL Data warehouseにした。
    • そうするとデータサイエンティストさんのスクリプトを書き直す必要が無いよね。
    • 一休はAWSへの移行を進めていたから安易にredshiftという選択をしてしまったが、それは間違いだった。ということ。
  • どうやって移行したか
    • Kinesisが一休のデータ統合の中心となっている。
    • ログ基盤
      • javascriptでanalytics.ikyu.comからリクエストがコールされる
      • fastly->API Endpoint -> Kinesis -> Lambda -> DynamoDB or GoogleCloudStorage -> SQS -> EC2
      • APIはGOで実装を進めている。
        • PythonAPI Gateway+Lambda等とパフォーマンスを検証したところGOがよかったので。
        • 現在も安定して運用している。GOでよかったと思っている。
      • KenesisとLambdaは相性が結構いいんだよね。非常に楽ちん。エラーが起きてもRETRYが簡単。
    • データ分析基盤
      • Kinesis->Lambda->GoogleCloudStorage->BigQuery->Azure StorageBlob->SQL DatawareHouse
      • なぜこんなんになっているのか?
        • 最初はLambdaからStorageBlobに流したかった。でもできなかった。
        • それはAzureのSQL Datawarehouseでできないことがありました。
          • JSONパースができない。
          • 正規表現を利用した処理ができない。つまり生ログのままではできないんです。ということがわかった。
          • だからGoogleを間に入れた。
          • SQl Datawarehouseの大量ファイルのデータロード性能がダメだった。
          • なので、BiqQUeryで一旦集約するようにするしかなかった。ということ。
  • それらを使ってなにをやっているの?
    • KPI集計
      • 訪問数、CVR
      • 新規会員のリピート数、、とか
    • CRM施策
      • メールを利用した1to1マーケティング(ごぶさたクーポン)
      • 久しぶりに来てもらった人には、クーポンを出すとか。
      • PRICEDOWN通知とかで、以前チェックしたホテルがやすくなったよ。というメール。
  • 今後、こんなことができたらいいな。
    • なぜかDynamoDBがいるんだよね。性能は優れている。リアルタイムに分析して施策を売ってみたい。
    • 例えば、ユーザが旅館を検索して、予約動線までいて今回はやめようとしたユーザに対して、その場で即時再提案する。とか。
    • ユーザの行動ログを可能な限り早く収集する。とか。
    • GA+Biqqueryの構成では解決できない問題があった。
      • データ蓄積のタイムラグ(最短でも8時間)
      • なので、自分たちでコントロールできる基盤が必要ということ。なので、DynamonDBを作った。
  • まとめ
    • うーん。とくになにもない。
    • ちゃんと現行業務やデータ量等、データ分析基盤に関わる要素をきちんと分析してから進めるべきだと再認識しました。
    • まぁ普通そうだよね。
  • 質疑応答
    • マルチクラウドになっているんだけどさ。
      • マルチクラウドに転送するときには個人情報ってマスクするとかはしているの?
        • 会員の情報はすべて基幹DB(SQLServer)に登録されており、各種データ基盤には個人情報はないよん。
        • 紐付け情報だけはかんりするようにしていまーす!
    • マルチクラウドでのコストはどうなん?
      • まぁ高いよね。
    • ログのトランザクション量はどれくらい?
      • 2000record/minぐらい。

タクシー会社を支えるデータ収集技術 〜AWS Kinesis Stream/IoT の導入事例〜

JapanTaxi株式会社 システムデザイン事業部 部長 長谷川 直

  • 動態データの従来までの使われ方
    • 動態データとは(もともとは分析用途ではなかった)
      • 車の経度緯度ステータス
    • でもね、この動態データが需要予測とかに利用できそうだ。ということで。
    • Bigquery<-embulk<-動態データ
    • いままでは、やりたいひとだけがやっていた。
    • 社内のリクエストを収集
      • リアルタイムに動態データを取得したい。
      • 過去の動態データを取得したい。
      • 動態データ取得方法が共通化され、簡単にアクセスできる
    • で、二、三日で構築してみた。
      • Knestis Stream -> Consumer(Lambda)-> S3 -> Athena -> プロダクトB
    • 結果失敗してしまった。
      • シャードの見積もりがあまったためにストレームに対する
    • なので、ELB -> Collector Svr -> Kinessi Streamにしてみたら、なんとかなった。
    • この基盤を利用して、需要予測や奇跡の表示ができている。
      • タクシーを利用してどの道をとうったか、とかがわかるようになっている。
  • AWS Iotの活用事例について
    • リモコンでタクシーを呼ぶデバイスを開発してみた。
      • バイスをちゃんと監視したい。
      • ふぐアリを作り込みにくいものにしたい。
      • 消費電力を抑えたい。
        • それを抑えるには、スリープ時間を増やすしかない。でもそうなると細かい監視ができなくなる。
        • 相反する関係性となってしまう。
      • バイス側のロジックをクラウドにもっていければいいよね。となった。
        • クラウド上からログを送信するようにすればよい。
        • ロジックもクラウド上にあるのでいいよね。となる。
        • ほとんどの動作をクラウドでできるようになれば、スリープ状態になるようね
        • ということで、AWS Iotを利用することにしました。
      • AWS Iotを利用することによって
        • MessageReceiver/Senderを実装する。
        • そうすると、状態管理や、LED制御や、スリープ制御をクラウド上で実装するようにしたよん。
      • バイス側でロジックを持たないので、ファームアップデートとかなくてもよい。
      • AWS Greengrassは使っていないよ。

LT:田中康一さま 「3分で作るストリーム処理基盤 ~Kafka + Flink on Docker編~」

ウェブニウム株式会社CTO

  • 今回作るもの
    • リアルタイムなストリーム処理基板を作る
  • INPUT/OUTPUTを受け取っているもの
    • apache kafka(message queue)
      • 複数のトピックをもっている。
      • トピックをわけて情報を流すことができる。
      • ProducerとConsumerの関係になっている。
      • Kafkaの場合は、GroupIDが違えば、再度同じ情報を取得することができる。
    • apache flink(データ処理を行うもの)
      • ストリーム処理をするもの(バッチ処理ではない)。ずっと処理を行い続けるもの。
      • High Performance
      • Stafeful
      • Low Tenancy
      • apache sparkと比較してもHight Throuputであると公式資料に売ったっている。
    • dockerhubにflinkがある。
    • kafkaはkafka-docker(公式ではないが)あり。docker-composeがあるのでやってみてね。
      • HA構成を構成するためにzookeeperを使っている

LT:motobrewさま 「クラシルを支える分析基盤 を支える話」

  • kurashiruというアプリを作っている。
  • margaret hamilton/NASAのソフトウエアエンジニア(SREサイトリライアビリティエンジニアリング)
  • SRE??
    • プログラミングを教えてくれるところはあるけど、SREのスキルをアップさせるにはどうすればいいの?
    • 経験者にはより経験があつまるけど、未経験者にはないよね。
    • なのでSRE育成プログラムを作った。
    • ミッション1
      • 本番環境と同等のログ収集基盤を構築してみる。
    • ミッション2
      • 障害対応訓練
      • Googleがやっている障害対応の訓練をやっている。
      • NetflikはChaosMonkey。
      • ポイント
        • 過去のインシデントをベースでやる。
        • 障害対応中のタイムラインを記録するようにする。
        • 先輩のエンジニアが実際のやり方を見せる。
      • やってよかったこと
        • スキルアップ
        • 障害チケットではなく、postmortemにしてみた。
            * タイムライン
            * ナレッジの共有
            * どこでどんなコマンドを売って、どうやったのかを記録する。
          
    • 課題
      • ミッションの作成
      • 網羅異性
      • 実務で通用するか?

LT:Shogo_Suzukiさま 「SpinAppを支えるデータ収集基盤」

  • DATAを収集する部分
    • Adjust
    • AppsFlyer
    • Firebase
  • もともとEC2とRedshfit中心だったか、しんどくなった。
    • ELB->EC2->SQS->Instance->DyamonDB->redshiftだった。
    • redshfitがいっぱいデータがたまってきて集計が間に合わなくなってきた。
    • スパイクに耐えられない。
  • なので、GCPで全部作り直した。
    • GAT+GOで高速オートスケール
    • 安くてハイパフォーマンスなBigQuery
    • 全部GCPの方が都合が良い。
      • PUB/SUBも使いたかったな。
  • GAE->TaskQueue->GAE->GCS->DataFlow->BigQuery
  • 嬉しいこと。
    • まえのAWSからコストが1/8となった。比較があるよ。
    • BigQueryが早くて安くてうれしい
  • たいへんなこと
    • フルマネージドサービスが結構エラーを返す。
    • AWSに比べて障害が多い気がする。

LT:idobataさま 「b→dashのデータ処理基盤」

株式会社フロムスクラッチ CTO 次世代マーケティングプラットフォームb->dash

  • システム刷新の理由
    • システムが拡大
      • アプリケーションが像が
      • データ容量が増加
    • ユーザ数(社数)が増加
      • 個社ごとの要望に対応する
  • 構成
    • DHWにRedshiftを作っている。
      • 課題X
        • データクレンジングができない
        • ・・
    • 全体構成
      • redshiftでパワー対応していたものをマイクロサービス化してみた。
      • dataflowはdataspiderを使っている。
  • 今後やりたいこと
  • まとめ
    • データを活用したマーケティングは当たり前の時代になっていくr.
    • b->dashはは共通部分と個別部分を切り分けている。
      • 共通部分nお保守性が向上した
      • 顧客ごとに個別に拡張させることが可能なので、コスト効率を向上させている。