原文：https://blog.cloudera.com/blog/2015/07/designing-fraud-detection-architecture-that-works-like-your-brain-does/
現著者：Gwen Shapira, Ted Malaska
訳注：本稿は2015/7/30に公開されたブログの翻訳です。アーキテクチャー設計が主題となっており、特定のコンポーネントに強く依存するものではありませんが、対応する技術など、ブログ公開当時から更新されている部分もありますので、最新情報はClouderaのドキュメントなどをご確認ください。また、以下で訳注としても補足します。
本記事では、不正検知システムのアーキテクチャー概要について解説します。その際、比較対象として、人間の脳のメカニズムについて説明します。また、技術要素としては、Spark StreamingとApache Kafkaの利用を想定しています。
不正の検出とは、本質的に、人々が「通常しているように」行動しているかどうかを見極めることであるといえます。言い換えれば、一連の行動の中のアノマリー（異常、逸脱、特異点）を捉えることです。この考え方は、クレジット・カード詐欺検知や、医薬品を不正に入手するために病院を渡り歩いている患者の発見、あるいはオンラインゲーム・コミュニティの中でのいじめ・脅迫に類する行為の特定など、様々に応用することが可能です。
さて、不正検出アーキテクチャーの設計の概観を捉えるに当たって、人間の脳がどのようにしてアノマリーを検出し、それへの対応を学んでいるかについて説明することから始めたいと思います。概して言えば、我々の脳は、情報を分析するための、いくつかの階層的なシステムを持っています。（人間の脳の情報処理プロセスに興味のある方へは、Daniel Kahneman著 「Thinking Fast and Slow」を推薦します。）
テニスの試合を例にとると、選手達は、対戦相手の打ったボールの軌道を認識し、対応する必要があります。試合中選手は、ほとんど瞬間的に、この認識＝対応ループを処理し続けなければなりません。それは、ほとんど考える間も無いほどの瞬間で、反応は本能的とでもいえるレベルのものですが、実際には、ごく短い時間に何らかのパターンを認識し対応しているはずです。さらに、試合の１セットを終え次のセットまでの間には、これまでの試合の進行を反省し、対戦相手の戦術や戦略を特定し、調整を行なっています。また、試合が終了し、次の試合までの期間には、試合を振り返ることのできる、ずっと長い時間があります。その間に、試合の特定の局面について、なかなか改善できない欠点を見出したり、反対に上達を感じるかもしれません。その結果、次の試合では、より良いプレーを行うことができるのです。（この反省過程は、意識的な場合もあれば、無意識的な場合もあります。言うなれば、シャワーを浴びている時のような、ことさら何も考えていないときに、懸案の問題の答えにたどり着くようなものとでもいえるでしょうか）
３つのシステムのコンビネーション
同様に、効果的な不正検知アーキテクチャでは、一連のイベントの中のアノマリーを検出するために、３つのサブシステムが連携して働きます。これは丁度、人間の脳が、認識＝対応ループに要することのできる期間に応じて、３種類の異なった働きをしているのと似ています。
（ニア）リアルタイム・システム: このシステムの仕事は、イベントを受信し、できるだけ早く返信することです（通常100ミリ秒以内）。このシステムは通常、時間を要する処理は担当せず、パターンマッチングと事前定義済みルールの適用のみを行います。アーキテクチャー的には、ローカルメモリにプロファイルをキャッシュするなどの手法を用いて、高いレベルのロー・レイテンシー（低遅延）、ハイ・スループット（高い処理速度）を達成することに焦点が当てられます。
ストリーム処理システム: このシステムは、入力データの処理に多少長い時間を使うことを許容しますが、それでも受信してから数秒から数分以内に処理を行います。このシステムの目的は、ユーザーのすべての活動について集積されたデータを使用して、不正検出モデルのパラメータをリアルタイムに近い間隔で調整することです（具体的な例としては、現時点で疑わしいターゲット〜地域や仕入先〜にフラグを立てる、といったことが考えられます）。
オフライン処理システム: このシステムは、入力から出力までのタイム・ラグを数時間から、時には数ヶ月間まで取ることによって、モデル自体の改善に焦点を合わせます。このプロセスには、新しいデータを使ったモデルのトレーニングや、データ内の新たな特徴量（フィーチャー）の調査、および新しいモデルの開発まで含まれます。また、BIツールを使用したデータ探索のように、人の手によるデータ分析が伴うことも珍しくありません。
以前のブログで、ニア・リアルタイムシステム（本記事の一番目のタイプ）を実装する際のさまざまなパターンを検討し、Clouderaがストリーム処理システムにSpark Streamingを推奨する理由について説明しました。その内容を要約すると、リアルタイム応答システムに推奨されるアーキテクチャは、応答が必要なイベントを提供するApache Kafkaトピックをコンシューマ（消費者）としてサブスクライブ（購読）することで、入力システムとの間を疎結合にしたサービスでした。このサービスは、キャッシュされた状態とルールを使って、イベントにすばやく対応します。（Apache HBaseのようなデータストアを外部コンテキストとして用いる事もできます）。また、詳しくは後に触れますが、 サービスを分散化するためにKafkaのパーティション（訳注参照）を用いることができます。この場合、分散化された各インスタンスは、データ全体のサブセットを処理します。
この設計の長所は、この分散アプリケーションが自己完結的になること、さらに実装については、多くの手法から選ぶことができることです。例えば、Apache Flume Interceptor（訳注参照）、YARNコンテナ、Mesos、Docker、Kubernetesなどその他多くの分散システム・コンテナ・フレームワークが採用可能です。 Kafkaがデータの永続化とパーティショニングの作業を担当するため、アプリケーション選択の高い自由度を確保できるのです。
訳注：Interceptorは、Flumeのもつ一機能です。https://flume.apache.org/FlumeUserGuide.html#flume-interceptors
また、同様の役割として、Apache NiFiを使うことも選択肢となります。Apach NiFiでは、Flume以上に多くの対象との接続がサポートされています。
以上を踏まえて、リアルタイム検知システムと、ストリーム/オフライン分析処理システムとを統合する方法を見てみましょう。
リアルタイム検知と分析処理の統合
ここでも統合の鍵は、スケーラブルで順序性をもつイベントストレージとしてのKafkaの使用です。 Kafkaにコンシューマ（消費者）が登録されている時、コンシューマグループのメンバーとして、あるいはそれぞれ異なるコンシューマグループとして、トピック（メッセージ・フィード）をサブスクライブ（購読）することができます。 二つ以上のコンシューマが同じグループのメンバーとして、イベントを読み取るためにトピックをサブスクライブ（購読）している場合、それぞれがパーティション（トピックのサブセット）を「所有」し、各自が所有するパーティションからイベントを取得します。グループ内の一つのコンシューマがクラッシュした場合、そのパーティションはグループ内の他のコンシューマに引き継がれます。このアプローチは、負荷分散と高可用性の両方のメカニズムを提供し、将来、負荷が増加した場合には、同じグループにコンシューマを追加することで各データ処理アプリケーションの規模をスケールアウトすることができます。
一方で、複数の目的の異なるアプリケーションが同じデータを読むことが必要な場合もあります。ここでの例としては、リアルタイム・システムとストリーミング・システムはどちらもKafkaから同じデータを読みこみます。この場合、各アプリケーションは異なるコンシューマグループになり、それぞれ独立して自分のペースでKafkaからのメッセージを消費します。
その際、バッチジョブや分析者によるオフライン処理のためには、データをHDFSのようなデータストア層に保存する必要がありますが、 これはFlumeを使って簡単に行うことができます。 この場合、Kafkaをチャンネルとして、HDFSをシンクとして定義するだけです。この時、FlumeはKafkaからイベントを読み取り、それらをHDFS、HBase、またはApache Solrに書き込むことができます（訳注参照）。これらの保存されたデータは、Apache Spark、Impala、Apache Hive、あるいは様々なBIツールからアクセスできます。
訳注：ここでも、Apache NiFiを使うことが可能です。Apach NiFiでは、またグラフィカルなデータフロー定義画面やフロー定義の管理機能が提供されています。これにより、さらに簡単に、また管理された形で、 Kafka から HDFS や HBase、Kudu などのデータストアと連携を実現できます。
ここで特筆すべきは、各システムは異なるコンシューマグループに加入し、それぞれ独自の時間軸でイベントを個別に読み取ることができることです。したがって、ストリーム処理システムでイベントの処理に時間がかかっていても、リアルタイムシステムには一切影響がありません。 Kafkaの長所は、コンシューマーの数や振る舞いに関係なく、一定期間イベントが保存されることです。また、コンシューマーが追加されても追加前と同程度のパフォーマンスを維持します。
最後にこのシステム統合の締めくくりとして、ストリームおよびオフライン処理システムからリアルタイムシステムに対して、ルールとモデルの更新をフィードバックする機能について見ていきます。このプロセスは、いわば人間（の脳）が、練習を通じて、その能力を向上させるようなものです。（例えば、受発注管理システムのようなアプリケーションへの応用として、過去の取引に応じて、特定の仕入先に対して承認トランザクションの閾値を変更するということが考えられます）。
ここで、取りうる一つのアプローチは、ストリーム /オフライン・システムがHBaseに保存されたモデルを更新した上で、適当なタイミングでリアルタイムシステムに対して、モデルの更新を促すことです（リアルタイムシステムは、自分の内部のルールの更新のために非同期的にHBaseをチェックします）。
また別のオプションとしては、モデルの更新を、専用のKafkaトピックに送信することです。リアルタイムシステムはそのトピックを購読し、更新が通知されると、それを自分のルールキャッシュに適用し、更新されたルールに従って自身の振る舞いを変更します。この設計で興味深いのは、モデルの保管がKafkaに完全に任されていることです。それにより、コンパクション（データ圧縮）機能を有効に使いながら、各モデルの最新の状態が、アプリケーションとは独立して保存され、リアルタイム・アプリケーションは、いつでもそれらを取得しキャッシュできるようになります。
最後に
ここまで読んでいただき、ありがとうございました。ここで取り扱った課題について、何らか新しい発見があったと感じていただければ幸いです。具体的な手順など、さらに進んだトピックについてはfraud-detection tutorial at Strata — Hadoop World NYC 2015をご参照ください。
著者について
Gwen Shapiraは、Clouderaのソフトウェア・エンジニアであり、Apache SqoopおよびKafkaのコミッターです。Gwenは、顧客のためにスケーラブルなデータ・アーキテクチャー設計を行ってきた15年の経験を持っています。また、O’Reillyから出版されているHadoop Application Architecturesの共著者でもあります。
Ted Malaskaは、Clouderaのソリューション・アーキテクトであり、Apache Spark、Flume、そして HBaseのコントリビューターです。また、上記書籍の共著者でもあります。
