こんにちは。StanbyのDataPlatformグループでデータエンジニアをやっている陳です。 今回は、スタンバイ社が独自に開発しているリアルタイム分析プラットフォームのStanby Analyticsを紹介します。
Stanby Analyticsとは
何故Stanby Analyticsを作る事になったのか
GAの廃止 Stanbyはサービス開始時からGoogle Analytics（ユニバーサル アナリティクス、以下UA）を使っており、UAをベースとした分析結果で事業判断を行なってきました。 しかし、Google社から2023年のUAサポート終了と、Google Analytics4 (以下GA4)の移行が案内されたことをきっかけに、社内でStanby Analyticsプロジェクトが開始されました。
GA4の金額が高い 全ての分析要件をGA4で満たすプランを検討した結果、スタンバイのユーザー数増加に伴って、全てのイベントログをGA4で取得するには高額になる為、内製化でコストダウンを期待できる事がわかりました。
GA4のカスタマイズ性が低い Google Analyticsは完成度の高いプロダクトですが、GA4単体ではStanbyの分析要件を満たせません。何か特殊な処理をしたい時、カスタマイズ性の低さがUA時代から課題になっていました。
データ基盤を統一したい スタンバイではAWSをベースに開発をしており、Data Platformグループが開発している基盤は全てAWS上にあります。GAはデータをGCPのBig Queryに保存するので、データ基盤が分断されている状態でした。GAのデータを他のデータと一緒に分析したい場合、Big Queryからデータを持って来なければならなく、工数がかかっていた事が問題となっていました。
Stanby Analyticsのアーキテクチャー
アプリケーション層
フロントエンドにJSを埋め込み、フロントで発火した全てのイベントをログとしてサーバーサイドに飛ばしています
Data Pipeline層
フロントエンドから来たイベントログは、API Gatewayを通しKinesis Streamに送られます。 Kinesis StreamはメッセージQueueの役割を果たしており、ここからバッチ処理とリアルタイム処理のパイプラインに分かれて行きます。
バッチ処理の場合
生データを簡単な分類をしてKinesis Firehoseを通しS3に書き込んでいきます。
リアルタイム処理の場合
Kinesis Analyticsを通して必要なビジネスロジックを全てonlineで処理をしていきます。例えばセッション周りのKPIを処理する場合、FlinkのSession Window Functionを用いて同一Sessionで発生した全てのイベントをAggregateし計算した後Opensearchにデータを書き込みます。なので指標によってmsレベルのラグと、ビジネスロジックに応じて数分 ~ 数十分ラグのパイプラインが同時に走り処理を行なっています。
下の画像はFlinkのパイプラインの1つですが、Pipeline上で色んな処理や集計を行なった上でデータの書き込みを行なっている図になります。
- Data Storage & Computing層
バッチ処理の場合
S3に書き込まれたデータはAWS Glueで定期的に加工され、datalake(S3)に保存されます。分析者は基本的にAthenaを使いdatalake上のデータを分析する様になっています。
リアルタイム処理の場合
基本的に加工ロジックは全て前処理のパイプライン上で終了しているので、Opensearchの役割は簡単なフィルタリングと、書き込まれたデータの検索となっています。結果として複雑なQueryが実行される事はほぼなく、ニアリアルタイムな分析が可能となっています。
- Visualization層
バッチ処理の場合
RedashやTableauを使用しており、データアナリストの方々に作成して頂いたダッシュボードでアプリケーションの状態を可視化し日々分析を続けています。
リアルタイム処理の場合
OpenSearchに付属したKibanaで可視化しており、今は一番基本的な指標のみを可視化しています。こちらは分析用途以上に、異常検知が目的となっています。
リアルタイム処理の異常検知
Stanby Analyticsにおけるリアルタイム処理の最大の利点が異常検知になります。
過去スタンバイでは、サービスリリース後異常値を検知する仕組みが整っていなく、ユーザー様に大きなご迷惑をおかけしてしまった経験があります。このような事態を防止する為、Stanby Analyticsが活用されています。
アラート閾値の設置が難しい
スタンバイは求人検索エンジンのサービスであり、基本的に24時間365日の稼働をしています。当然ながら、1日の中ではアクセスが集中する時間帯、閑散する時間帯があります。ピーク時のアクセス数はオフピーク時の約10倍程になります。更に求人が活発になる季節性や、CM等による一時的なアクセスの急騰
もあります。下の画像では一日内の指標の変化になりますが、ピーク時とそうでない時間帯でかなりの落差がある事を示しています。
そんな中、アクセス数やクリック数の様な動的な指標の異常値を従来の固定閾値を設定する方法で検知するのはとても難しくなります。リアルタイムの異常検知において、ただ単に0, 1の様な死活監視だけでなく、急激なKPIの変化をいち早く検知し、アクションを起こす事が求められています。
KibanaのAnomaly Detection
上記の課題を解決する為、今回Stanby Analyticsで採用したのはKibanaのAnomaly detection機能です。
https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html
注: AWSのOpenSearchサービスでは、7.10バージョンのKibanaしか提供していない為、Stanbyでは7.10のKibanaを使用しています。
アルゴリズムに関する具体的な説明は割愛させて頂きますが、KibanaではRandom Cut Forestを使用しており、教師なし学習を用いて直近のWindowサイズ内のデータと比較する事により高速に異常値の発見を可能としています。
Anomaly Detectionのパラメータ数は多くなく、簡単な閾値の設定だけで始められるお手軽な機械学習機能となっています。
Anomaly Detectionの運用
結論から申し上げますと、現状プロダクション環境で異常検知が出来てるかはわかりません。
理由はまだリリースして数ヶ月程度なので、プロダクションレベルでの異常が発生していないからです。（いいこと）
なので今回はプロダクション環境で意図的に異常値を発生させた時の結果となっています。
19:00にOpenSearchへ書き込むデータ量を半分にした所、数分でAnomaly Gradeが上がり、20分程度で
異常レベルが70%を超え、アラートが発火されます。今回はリリース作業等で一時的な異常を無視する為、敢えて20分以上異常が続く場合のみ発火させるようにチューニングしています。
その後もデータ量を半分のまま暫く流し続けると、徐々に新しいデータ量に対しての学習が進んで行き、数時間後には正常値とみなしてアラートが止まっている事がわかります。
Stanby Analyticsの展望
以上がStanby Analyticsの現在となっていますが、まだまだ開発途中のプロダクトで、日々チームメンバーと議論しながら改善を行なっています。
Stanby Analyticsの将来像：
Flink SQLの実装
現在のKinesis AnalyticsはScalaのアプリケーションで書かれていますが、作ってみたら意外とFlinkSQLで代替できそうなコードが多かったです。FlinkSQLで作る事により、Batch処理と同じコードでロジックのメンテナンスが可能です。
LakeHouseの導入
現在のBatchシステムはHourlyの集計しか行なっていません。Athenaで他のデータと分析する際には1時間のラグが発生します。HudiやIcebergといった仕組みを用いて、Batch集計のニアリアルタイム化を目指しています。
データ分析の民主化
現在、新指標の追加やダッシュボード作成はエンジニアが主体で動いています。データドリブンな文化を目指すには、誰でもデータを扱える民主的な環境提供が必要不可欠です。データプラットフォームのエンジニアだけでなく、誰もが簡単にデータ分析を始められるプラットフォームを目指しています。
最後に
Stanby Analyticsの開発によって、UAでは解決困難だった分析やコスト面の課題をクリアし、更にリアルタイムなアノマリー検知の仕組みにより、より迅速且つ柔軟な異常検知が可能となりました。 Data PlatformチームではStanby Analyticsの開発、運用だけでなく、社内のデータ基盤の改善やデータパイプラインの構築等沢山の業務に関われます。スタンバイ社のデータ活用支援やそれ関係する技術領域に興味関心がある方は、是非一度お気軽にご相談ください。
スタンバイのプロダクトや組織について詳しく知りたい方は、気軽にご相談ください。 www.wantedly.com
