CA Reward

Tech Blog

Tech Blogトップに戻る

BOSATSU meets Cloud Dataflow 〜ストリーミング処理を用いた不正検知機能の開発〜

2017.02.20

  • このエントリーをはてなブックマークに追加
  • Pocket
ヤマツカ
ヤマツカエンジニア

概要

開発部の山塚です。普段は、CAリワードの不正対策研究機関 BOSATSU でリワード広告の不正対策開発をしております。 先日、リアルタイム不正検知機能を開発した際に、Google Cloud Platform(以下、GCP)のCloud Dataflow(以下、Dataflow)を利用。ストリーミング処理によるリアルタイムな不正検知を実現しました。 これまでもCAリワードではGCPを用いた開発を行ってきましたが、Dataflowを利用した開発は本開発が初でした。 本記事では、Dataflowを利用した開発において、良かった点、苦労した点を書いていきます。ほぼ良かった点ですが。

BOSATSUxDataflow

Dataflowとは

Dataflowは、GCPが提供するバッチ処理、ストリーミング処理を実現するフルマネージドサービスです。 現在は、そのプログラミングモデル、SDKが、Apache Beam(incubation)として、 OSSへの移行が進められています(関連記事)。 特徴として、バッチ処理とストリーミングの処理のモデルが統合されており、データレイクに貯められた静的なデータや ログのような流れ続けるリソースに対してもAPIの変数を変えるだけで、ほとんど同様に扱うことができます。 他にも、スライディングタイムウィンドウや、セッションウィンドウなどのウィンドウ処理、データを遅延を扱うトリガーの制御など ストリーミング処理の痒いところに手が届く機能を提供してくれてます。

なぜ、Dataflowか

ストリーミング処理を提供するフレーブワークの選択肢としては 他にも、Spark StreamingやFlink、Stormなどが挙げられます。 今回の開発は、期間が短かく担当開発者も僕一人でした。 チームとしてGCPでの開発の知見・実績ができてきた背景もあり、フルマネージドサービスであるDataflowを採用することにしました。 僕自身、Apache Beam、Dataflowに興味があり、実働システムに導入したかったというのも大きな理由なのですが。

SDK

JavaとPythonのSDKが公式で提供されています。 現在、ストリーミング処理はPythonのSDKは対応しておらず、Javaで開発を進めました。 他の言語の選択肢としては、Spotifyが公開しているscioというScalaのAPIがあるようです。

開発したこと

下記図のように、Pub/Subに送られてきた計測ログをDataflowを用いて集計を行います。 不正判定されたユーザー特性などの結果をPub/SubとBigQueryに出力します。 Pub/Subに出力されたデータはブラックリストなどシステムに反映され、BigQueryに出力されたデータは結果の分析に用います。

Overview

良かった点

APIがシンプルかつ強力

上記はコードのサンプルで、データに対する処理の流れ(パイプライン)を示します。 Pub/Sub に流れてくるログのストリーミングを取得し(1)、 ログのtimestampプロパティをタイムスタンプに設定し、10分までの遅延を許容します(2)。 時間幅を1時間としたウィンドウ処理を5分刻みで起動し(3)、それぞれの計算結果(4)を出力します(5)。 Apache Sparkでは、Dataflowのよいにウィンドウ処理のAPIがなく、擬似的に行うためもっと実装が複雑になります。

DataflowとApache Sparkと何が違うのかに関してはこちらが詳しいです。

Dataflow/Beam と Spark: プログラミング モデルの比較

基本的には DoFn を継承したクラスをつなげていく形となり、データに対する処理の流れが理解しやすかったです。 例えば、上のコード例の場合では、 (1) ParseLog の処理では JsonのString → LogInfo とする。 (2) ~ (3) は LogInfo → LogInfo (4) Calculateの処理で、ある値をKeyとした合計処理をすると LongInfo → KVとなる。 (5) 出力の処理では KV → PDone(終了) となる。 というようにデータが処理されていく。

テストのライブラリがデフォルトで存在する。

ドキュメントにもあるように Junitを使用したテストを行います。 独自に実装した個々の処理(DoFn関数)ごとにテストや複数の処理を連結させた処理(PTransform関数)のテストなどを行うことができ、実装を効率的に行うことができました。

Dataflow Monitoring Interfaceでボトルネックの発見

パイプラインの監視をDataflow Monitoring Interfaceで行うことができます。 パイプラインと処理時間が表示され、処理の中でどこがボトルネックとなっているか追いやすくなっています。

UI

苦労した点

Dataflowでの開発にあたり、まず苦労したところを書いていきます。

  • Dataflow & ストリーミング処理の理解

僕自身、開発に入るまで、Dataflowってなんだ? そもそも、ストリーミング処理ってなんだっけ?状態でした。 最初に、Dataflowのドキュメントを読み始めたのですが、いきなりプログラミングモデルの説明からはじまり、チンプンカンプンでした。 下記の動画を見て、まずはDataflowとストリーミング処理の概念を掴まれた方が良いかと思います。 ストリーミングの理解には下記の説明動画がよかったです。GIFなどを使った動的な図でストリーム処理を説明してくれています。 Dataflow: A Unified Model for Batch and Streaming Data Processing

その後は、ドキュメントのコードサンプルが参考になりました。

余力のある方は、下記の記事を読んでいただければストーリミング処理とは何か、理解する助けになるかと。

The world beyond batch: Streaming 101

The world beyond batch: Streaming 102

まとめと展望

今回は、Dataflowの利用にあたり、良かった点と苦労した点を述べました。 リアルタイム不正検知の開発では主にスライディングウィンドウ処理を用いて機能を実装しましたが、 セッションウィンドウ処理などを使えば、より一層、不正対策に効果的な処理が実現できそうです。 個人的にはApache Beamで、SparkやFlinkをランナーにしていろいろ試してみようと思います。

ヤマツカ
ヤマツカエンジニア