Implementation of a large-scale real-time risk control system based on Flink in Alibaba

現在、Flink はグループ内のほぼすべての BU で利用されています。独身の日のピーク時には、計算能力は毎秒 40 億件に達し、計算タスク数は 3 万以上、合計 100 万以上のコアを使用しています。データミドルオフィス、AI ミドルオフィス、リスク管理ミドルオフィス、リアルタイム運用保守、検索とレコメンデーションなど、グループ内のほぼすべての主要ビジネスをカバーしています。

1. Flink ベースのリスク管理システムの構築

リスク管理は、ルールエンジン、NoSQL DB、CEP などを含む大きなテーマです。本章では、リスク管理の基本概念について主に紹介します。ビッグデータ側では、リスク管理を 3 × 2 に分類しています。

- 2 は、リスク管理がルールベースか、アルゴリズム・モデルベースかの方式を表します。
- 3 は、事前リスク管理、事中リスク管理、事後リスク管理の 3 つのタイプを表します。

1.1 3 つのリスク管理業務

事中リスク管理と事後リスク管理では、エンド側の検知は非同期です。一方、事前リスク管理では、エンド側の検知は同期です。

事前リスク管理について補足します。事前リスク管理は、学習済みモデルまたは計算済みデータを ApsaraDB for Redis や ApsaraDB for MongoDB などのデータベースに保存します。

- 一つの方法は、エンド側の Sidden、Groovy、Drools などのルールエンジンが直接 ApsaraDB for Redis や ApsaraDB for MongoDB からデータをフェッチして結果を返す方式です。

- もう一つの方法は、Kubeflow KFserving をベースに、エンド側のリクエストに応じて学習済みアルゴリズムとモデルに基づいて結果を返す方式です。

全体として、どちらの方法のレイテンシも約 200 ミリ秒であり、同期 RPC または HTTP リクエストとして使用できます。

Flink 関連のビッグデータシナリオでは、非同期のリスク管理リクエストとなります。非同期の適時性は非常に低く、通常 1 秒から 2 秒です。超低遅延を求める場合は、事中の一種のリスク管理として扱い、リスク管理の意思決定プロセスをマシン側で処理することも可能です。

一般的には、Flink SQL で指標しきい値の統計を取り、Flink CEP で行動シーケンスルールを分析し、TensorFlow on Flink で TensorFlow のアルゴリズムを記述してから、Flink で TensorFlow のルールを計算する方式が用いられます。

1.2 Flink がルールベースのリスク管理に最適な理由

現在、Flink はアリババグループ内のリスク管理に最適な選択肢であり、理由は 3 つあります。

- イベント駆動

- ミリ秒レイテンシ

- ストリーミングバッチ統合

1.3 ルールベースのリスク管理の 3 要素

ルールベースのリスク管理には 3 つの要素があり、以降のすべての内容はこれら 3 つの要素を中心に展開されます。

- 事実：リスク管理イベントを指し、ビジネス側またはログの埋め込みポイントから取得され、リスク管理システム全体への入力となります。

- ルール：ビジネス側が定義するもので、このルールが満たすべきビジネス目標を定めます。

- しきい値：ルールに対応する記述の重大度を表します。

1.4 Flink ルール式の強化

Flink では、ステートレスルールとステートフルルールに分けることができます。ステートフルルールが Flink のリスク管理の核心です。

- ステートレスルール：主にデータ ETL に使用されます。一つのシナリオは、イベントの特定の値セグメントが X を超えた場合に、現在のリスク管理動作がトリガーされる場合です。もう一つのシナリオは、Flink タスクの下流がモデルまたはアルゴリズムベースのリスク管理である場合です。Flink 側でルール判定を行う必要はなく、データの量子化と正規化（マルチストリーム相関、case when 判定など）を行い、データを 0/1 ベクターに変換してから、下流の TensorFlow にプッシュして予測を行います。

- ステートフルルール：

- 統計ルール：統計分析に基づく計算ルールです。たとえば、5 分以内のアクセス数が 100 を超えた場合、リスク管理がトリガーされるとみなされます。

- シーケンスルール：イベントシーケンスにおいて、あるイベントが前後のイベントに影響を与えるものです。たとえば、クリック、ショッピングカートへの追加、削除の 3 つのイベントがあります。この連続したアクションシーケンスは特別な行動であり、商人の商品評価スコアを悪意を持って低下させている可能性がありますが、これらの 3 つのイベントは単独ではリスク管理イベントではありません。Alibaba Cloud リアルタイムコンピューティング Flink は、シーケンスベースのルール機能を強化し、クラウド上およびグループ内の e コマース取引シナリオに技術的なサポートを提供しています。

- 混合ルール：統計ルールとシーケンスルールの組み合わせです。

2. アリババのリスク管理実践

本章では、アリババが前述の 3 つのリスク管理要素をエンジニアリングでどのように満たしているかを主に紹介します。

技術全体では、現在 3 つのモジュールに分かれています。知覚、処分、洞察です。

- 知覚：すべての例外を検知し、事前に問題を発見することが目的です。たとえば、通常のデータ分布と異なるデータタイプをキャプチャし、そのような例外のリストを出力します。また別の例として、ある年に自転車政策の調整によりヘルメットの販売量が増加し、関連商品のクリック率とコンバージョン率の上昇につながった場合、これは正常な動作であり不正行為ではないため、このような状況をタイムリーに検知・捕捉する必要があります。

- 処分：ルールの実装方法を定めます。現在、時間単位、リアルタイム、オフラインの 3 つの防御ラインがあります。単一ポリシーのマッチングと比較して、関連付けと統合の精度がより高くなります。たとえば、あるユーザーの最近の期間における連続行動について包括的に調査が行われます。

- 洞察：現在検知できていない、ルールで直接記述できないリスク管理行動を発見することが目的です。たとえば、リスク管理はサンプルを高度に抽象化して表現する必要があります。まず適切な部分空間に射影してから、時間次元と組み合わせて高次元で特徴量を発見し、新しい異常を識別します。

2.1 Phase I：SQL リアルタイム相関＆リアルタイム統計

このフェーズでは、SQL 評価ベースのリスク管理システムがあり、シンプルな SQL を使用してリアルタイム相関と統計を行います。たとえば、SQL で SUM(amount)>50 を集計する場合、SUM(amount) がルールで、50 がルールに対応するしきい値です。10、20、50、100 の 4 種類のしきい値が同時にオンラインで実行されているとします。単一の Flink SQL ジョブでは 1 つのルールしか実行できないため、これら 4 つのしきい値に対して 4 つの Flink ジョブを申請する必要があります。利点は、開発ロジックがシンプルでジョブの隔離性が高いことですが、欠点は計算リソースの大幅な無駄です。

2.2 Phase II：ブロードキャストストリーム

Phase I のリスク管理ルールの主な問題は、ルールとしきい値が不変であることでした。現在、Flink コミュニティでは BroadcastStream ベースの実装などのソリューションがあります。下図では、Transaction Source がイベントの受信を担当し、Rule Source は BroadcastStream です。新しいしきい値がある場合、BroadcastStream を通じて各オペレータにブロードキャストできます。

たとえば、1 分間に 10 回以上アクセスしたリスク管理対象を判定する場合、618 や独身の日には 20 回や 30 回に変更する必要があるかもしれません。変更後、リスク管理システムの下流のオンラインシステムで検知できるようになります。

最初のフェーズでは、選択肢は 2 つしかありませんでした。1 つはすべてのジョブをオンラインで実行すること。もう 1 つはある時点で Flink ジョブを停止し、新しい指標に基づく新しいジョブを開始することです。

BroadcastStream ベースであれば、ルール指標しきい値を配信でき、ジョブを再起動することなくオンラインの指標しきい値を直接修正できます。

2.3 Phase III：動的 CEP

Phase II の主な問題は、指標しきい値のみが更新可能だったことです。ビジネスシステムを大幅に効率化しましたが、実際のところ上位のビジネス要件を満たすのは困難です。主な要望は 2 つあります。CEP と組み合わせて行動シーケンスの検知を実現すること。CEP と組み合わせた後でも、しきい値やルール自体を動的に変更できることです。

Phase III では、Alibaba Cloud Flink は CEP 関連の高度な抽象化を行い、CEP ルールと CEP 実行ノードをデカップリングしました。これにより、ルールを ApsaraDB RDS や Hologres などの外部サードパーティストレージに保存できます。CEP ジョブのデプロイ後、データベース内の CEP ルールをロードして動的な置換を実現できるため、ジョブの表現力が強化されます。

次に、ジョブの柔軟性が強化されます。たとえば、あるアプリの動作を確認し、その動作の指標しきい値を更新したい場合、Flink 自体ではなくサードパーティストレージを通じて CEP ルールを更新できます。

このアプローチのもう一つの利点は、ルールを上位のビジネス側に公開できることで、ビジネス側が実際にリスク管理ルールを記述できるようになります。真のルールセンターとして機能するようになり、これが動的 CEP 機能のメリットです。Alibaba Cloud のサービスでは、動的 CEP 機能が最新バージョンに統合されています。Alibaba Cloud のフルマネージド Flink サービスは、リスク管理シナリオの開発サイクルを大幅に簡素化します。

2.4 Phase IV：共有コンピューティング

Phase III を基盤として、Alibaba Cloud は「共有コンピューティング」ソリューションを開発しました。この共有コンピューティングソリューションでは、CEP ルールをモデリングプラットフォームで完全に記述でき、上位の顧客やビジネス側に対して使いやすいルール記述プラットフォームを公開します。ドラッグ＆ドロップなどの方法でルールを組み立て、スケジューリングエンジンでイベントアクセスソースを選択してルールを実行できます。たとえば、タオバオ APP 用の複数のモデルを、同じファクトの Flink CEP ジョブに完全に適用でき、ビジネス側、実行層、エンジン層を完全にデカップリングできます。現在、Alibaba Cloud の共有コンピューティングソリューションは非常に成熟しており、豊富な顧客実践があります。

2.5 Phase V：ビジネス開発とプラットフォーム構築の分離

エンジン側、プラットフォーム側、ビジネス側の間で、Phase IV ではエンジン側とプラットフォーム側のデカップリングを実現しましたが、ビジネス側とは依然として強く結びついています。両者の作業モードは依然として甲乙の協力関係です。つまり、ビジネス側がビジネスルールを把握し、プラットフォーム側がビジネスチームのリスク管理ニーズを受けてリスク管理ルールを開発します。しかし、プラットフォームチームは通常人員の優先度が低く、ビジネスチームはビジネスの発展とともに成長していきます。

この時点で、ビジネス側自体が基本的な概念を抽象化し、共通のビジネス仕様を蓄積し、使いやすい DSL を組み立て、Alibaba Cloud の完全にデカップリングされた Open API を通じてジョブを投入できます。

グループ内で約 100 の BU を同時にサポートする必要があるため、各 BU にカスタマイズされたサポートを提供することは不可能です。代わりに、エンジンの機能を最大限に開放し、ビジネス側が DSL カプセル化を通じてプラットフォームに投入することで、顧客に対しては 1 つのミドルオフィスのみを公開します。

3. 大規模リスク管理の技術的課題

本章では、大規模リスク管理における技術的課題と、Alibaba Cloud がフルマネージド Flink 商用製品でこれらの技術的課題をどのように克服しているかを主に紹介します。

3.1 細粒度リソース調整

ストリームコンピューティングシステムでは、データソースはブロッキングノードではないことが多く、上流のデータ読み取りノードには計算ロジックがないためパフォーマンス問題はありません。下流のデータ処理ノードがタスク全体のパフォーマンスボトルネックとなります。

Flink ジョブはスロット単位でリソースが分割されるため、デフォルトではソースノードとワーカーノードが同じ同時実行数を持ちます。この場合、ソースノードと CEP ワーカーノードの同時実行数を個別に調整したいと考えます。たとえば、下図では、あるジョブの CEP ワーカーノードの同時実行数が 2000 に達する一方、ソースノードは並列度 2 だけで済むことがわかります。これにより CEP ノードのパフォーマンスを大幅に向上できます。

さらに、CEP ワーカーノードが配置される TM のメモリと CPU リソースを分割します。オープンソース Flink では、TM は全体として同型、つまりソースノードとワーカーノードは同じ仕様です。リソース節約の観点から、実際の本番環境では、ソースノードは CEP ノードと同じ量のメモリと CPU リソースを必要としません。ソースノードは、データキャプチャに必要なより小規模な CPU とメモリだけで十分です。

Alibaba Cloud のフルマネージド Flink では、ソースノードと CEP ノードを異型の TM 上で実行できます。つまり、CEP ワーカーノードの TM リソースはソースノードの TM リソースより大幅に大きく、CEP ワーカーの実行効率がより高くなります。細粒度リソース調整による最適化を考慮すると、クラウド上のフルマネージドサービスは自建 IDC Flink と比較して 20% のコストを節約できます。

3.2 ストリーミングバッチ統合＆アダプティブバッチスケジューラ

ストリームエンジンとバッチエンジンが同じ実行モードを採用しない場合、データの口径が不一致になることがあります。この問題の原因は、バッチルールの下でストリームルールを完全に記述することが難しいためです。たとえば、Flink に特殊な UDF があるが、Spark エンジンには対応する UDF がありません。データ口径が不一致の場合、どちらのデータ口径を選ぶかが非常に重要な問題となります。

Flink のストリーミングバッチングの基盤の上で、ストリームモードで記述された CEP ルールを同じ口径でバッチモードでも実行し、同じ結果を得ることができます。そのため、バッチモード関連の CEP ジョブを別途開発する必要はありません。

これを基に、Alibaba はアダプティブバッチスケジューラを実装しました。実際、CEP ルールのデイリー効果出力は必ずしも均等ではありません。たとえば、今日の行動シーケンスに異常行動がなく、下流に投入されるデータが少数しかない場合もあります。このとき、バッチ分析用にエラスティッククラスターが予約されます。CEP 結果が少ない場合、下流のバッチ分析は少量のリソースしか必要としません。各バッチ分析ワーカーノードの並列度は、最初から指定する必要さえありません。ワーカーノードは、上流データの出力とタスクのワークロードに基づいて、バッチモードで並列度を自動調整でき、真に弾力的なバッチ分析を実現します。これが Alibaba Cloud Flink バッチスケジューラの独自の利点です。

3.3 結合読み取りによる共通レイヤーの負荷削減

これは実際の運用で遭遇する問題です。現在の開発モードは、基本的にデータミドルプラットフォームベース、つまりリアルタイムデータウェアハウスです。リアルタイムデータウェアハウスシナリオでは、データソースは多くないかもしれませんが、中間層の DWD が多くなります。中間層は多くの DWS レイヤーに発展し、さらには各部门が使用する多くのデータマートになる可能性があります。この場合、単一テーブルの読み取り負荷が大きくなります。

通常、複数のソーステーブルを相互に関連付けて（ワイド化して）DWD レイヤーを形成します。単一のソーステーブルから見ると、複数の DWD テーブルに依存しています。DWD レイヤーは、異なるビジネスドメインのオペレーションによっても消費され、DWS を形成します。この状況に基づいて、Alibaba はソースベースの統合を実装しました。DWD を 1 回読み取るだけで、Flink 側でビジネスドメインの複数の DWS テーブルを処理できます。これにより、パブリックレイヤーの実行負荷を大幅に削減できます。

3.4 KV 分離設計のステートバックエンド

CEP ノードの実行には、特に行動シーケンス計算モードで、非常に大規模なローカルデータ読み取りが伴います。過去のデータまたは一定期間内の行動シーケンスをすべてキャッシュする必要があるためです。

この場合、大きな問題は、バックエンドのステートストレージ（RocksDB など）に非常に大きなパフォーマンスオーバーヘッドが生じ、CEP ノードのパフォーマンスに影響を与えることです。現在、Alibaba は KV 分離設計のステートバックエンドを実装しました。Alibaba Cloud Flink では、デフォルトで Gemini をステートバックエンドとして使用しています。CEP シナリオでの実測パフォーマンスは少なくとも 100% 向上しています。

3.5 ディメンションデータのパーティションローディング

多くの場合、リスク管理は履歴行動に基づいて分析する必要があります。履歴行動データは一般に Hive や ODPS テーブルに保存され、このテーブルの規模は TB 级别に達する可能性があります。オープンソース Flink では、デフォルトで各ディメンションテーブルノードにこの超大規模なディメンションテーブルをロードする必要がありますが、これは実際には非現実的です。Alibaba Cloud は Shuffle ベースのメモリデータ分割を実装しました。ディメンションテーブルノードは、現在の Shuffle パーティションに属するデータのみをロードします。

4. Alibaba Cloud Flink FY23 リスク管理進化計画

Alibaba Cloud 全体として、FY23 の進化計画には以下が含まれます。

- 表現力の強化
- 可観測性の向上
- 実行能力の強化
- パフォーマンスの向上