【一休 × JapanTaxi】サービスを支えるデータ分析基盤に行ってきた #ikyu_japantaxi

8/17（木）に開催された「【一休 × JapanTaxi】サービスを支えるデータ分析基盤」というイベントに行ってきました。

ikyu.connpass.com

資料は上記ページに公開されていますが、一応メモ。

一休.comを支えるデータ分析基盤

実践的な内容でよかったです。
AWS + GCP + Azureというマルチクラウドな分析基盤でした。

  • データ分析基盤環境を再構築した話
    • Before) データ分析を行う環境と本番環境が分断されていた（1日1回しかETLできないなど）。ディスク枯渇のおそれ。
    • After) ログ基盤 + データ分析基盤をクラウドで再構築
  • RedShift上に構築したところ、移行コストが高かった…（元々はSQLServerベース、RedShiftはPostgreSQLベース）
  • Azure SQL Data Warehouseを使うことに。
  • ログ基盤（ログ=ユーザのセッションログ・行動ログ）
    • JavaScript(Ajax) / fastly / API / Kinesis / Lambda / DynamoDB / 基幹DB
    • API部分はGoで実装（t2.small * 4で安定稼働中）
      • API Gateway & Lambdaも検討したが、性能面、安定面でGoがよかった
    • ログ集約部分はKinesis -> Lambda -> Cloud Storage
      • 相性は抜群
  • データ分析基盤
    • AWS(Kinesis / Lambda), GCP(Cloud Storage / BigQuery), Azure(Storage Blob / SQL Data Warehouse)というマルチクラウド構成
    • Lambda -> Azureを直でつなぐのは、Azureの制約でできなかった
  • 活用事例
    • KPI集計, CRM施策
    • 1 to 1マーケティング
      • Nヵ月ぶりにログインしたユーザにクーポンとか
      • プライスダウン通知
  • 今後
    • DynamoDBでリアルタイムに何かしたい（BigQueryだと8Hのタイムラグがある）

質疑応答

Q. 機微な会員情報のマスクは？
A. 会員データはMS SQL Server上にだけ存在する。ユーザにはvisitor IDが割り振られていて、紐付け情報だけDWHで持っている構成。

Q. コスト面やデータ伝送料について
A. BigQueryは安い。データ伝送料についてもそこまで高くはついていない。 ただ、RedShiftは1年のリザーブインスタンスで契約したものの、結局使わなくなったので、その分のコストは無駄になってしまった。。

Q. ログのトランザクション量
A. 10,000弱/分。これでAPI(Go)のCPU負荷は7%くらい。

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

Kinesisや動態管理など、自分の仕事と共通するところも多かったので、興味深く聞かせていただきました。

  • 従来：タクシー⇔配車サーバ⇒動態DB
    • 動態DB: 緯度、経度、ステータス（空車など）を管理するDB
    • 個社ごとに動態DBがあり、BigQuery、Embulkで動態DBをつないでいた（活用されていない動態DBがあったりする）
  • リアルタイムに、過去のデータも、簡単に、便利に、安全にアクセスできるデータ収集基盤が必要になった
  • Kinesis / Lambda / S3 / Athena で構成 ⇒ 失敗。。
    • Kinesisへの書き込みでレート超過が発生
  • ELB / Collector Server / Kinesis / Lambda / S3 / Athena
  • 話変わってAWS IoTの話
    • デバイスの監視には細かいロギングが必要。消費電力を抑えるにはスリープを増やす必要がある ⇒ 対立する要求
    • AWS IoTを使うことでデバイスのロジックをクラウドに移すことができる

LT1 3分で作るストリーム処理基盤 ～Kafka + Flink on Docker編～

FlinkはオフィシャルのDockerイメージが、Kafkaも非公式だがDockerイメージがあるので、docker-compose upで簡単に基盤を作ることができる、という内容でした（デモ付）

LT2 クラシルを支える分析基盤　を支える話

社内で行っているSREエンジニア育成プログラム（アポロ）の話。
SRE本、最近購入したのですがまだ読めてないので、ちょっとずつ消化していかなきゃなぁと…。

  • 本番の障害対応は未経験者には難しく、経験者にだけ経験が集まり、未経験者（新しいSREエンジニア）が育たない悪循環。
  • ミッション1 本番環境と同党のログ収集基盤を構築（Fluentd, BigQuery, re:dash）
  • ミッション2 障害対応
    • ポイント1 過去に実際に起きたインシデントを元に再現
    • ポイント2 障害対応中のタイムラインを記録

LT3 SpinAppを支えるデータ収集基盤

EC2とRedShit中心とデータ収集基盤をGCPで作り直した話でした。結果的にコストは1/8になり、BigQueryも早くて安くてよかったとのこと。

ただ、エラーを返すのが多かったり、体感での障害が（AWSに比べて）多かったとのことでした。実際どうなんでしょうね…。

LT4 b→dashのデータ処理基盤

データ処理基盤のアーキテクチャ刷新のお話でした。
システム拡大に伴ってマイクロサービス化をしたり、データ容量の増大に伴ってスケーラビリティが容易な構成にしたり。
一方で、個社カスタマイズも必要になるとのことで、共通の部分と個別の部分を切り分けで設計されていたとのことでした。

というわけで、いろんな会社のデータ分析基盤について、実践的なアーキテクチャの話を聞くことができた勉強会でした。あと、会場の一休さんも自社から近いため、行きやすくてよかったです。
RedShiftはいいぞ、みたいな話がほぼなく、むしろBigQueryを使ってAWSとGCP組み合わせたケースが多いんですね。

聞いた内容については、うまくプロジェクトにも還元していきたいです。

主催者、発表者、参加者の皆さま、おつかれさまでした。