はじめに

こんにちは。ML・データ部/推薦基盤ブロックの佐藤（@rayuron）です。私たちは、ZOZOTOWNのパーソナライズを実現する機械学習を用いた推薦システムを開発・運用しています。また、推薦システムの実績を定常的に確認するためのシステムも開発しています。本記事では、Lookerを用いて推薦システムの実績をモニタリングするシステムの改善に取り組んだ件についてご紹介します。

• はじめに
• 改善の背景と課題
  • 背景
  • 課題
• 課題解決のために
  • 要件1. 指標異常時の自動アラート
  • 要件2. サマリの定期配信
  • 要件3. 上記2つをSlack通知できること
  • ダッシュボードの候補の比較
• 要件を満たすための設計
  • 要件の実現方法
  • 開発環境と本番環境
• 実装
  • ディレクトリ構成
  • ダッシュボードダッシュボード構築の流れ
  • 配信実績に関して
  • 推薦結果に関して
  • GitHub Actions
  • 1. 指標異常時の自動アラート
  • 2. サマリの定期配信
• 工夫した点と苦労した点
  • 工夫した点
  • サマリの定期配信のフォーマット
  • 苦労した点
  • アラートの閾値の決め方
• 改善の効果
• 今後の展望
• おわりに

改善の背景と課題

背景

運用しているシステムの1つにメール配信を利用してシューズアイテムを訴求するシステムがあり、私たちのチームではユーザーが興味を惹くアイテムを推薦するための機械学習システムを開発・運用しています。この推薦システムの実績を定常的にモニタリングするために、Looker Studio（旧 Data Portal）を用いてダッシュボードを構築していました。さらに、このダッシュボードに連携するためのデータを集計するシステム「モニタリングシステム」を運用しており、以下の図で構成されます。

Vertex AI PipelinesはCloud SchedulerとCloud Functionsによって1日1回定期実行されます。Vertex AI PipelinesではBigQueryのジョブを実行し、Looker Studioのダッシュボードに表示しやすい形式でデータを整形してその結果を連携用のテーブルとして保存します。Looker Studioではこの中間テーブルからデータを取得してダッシュボードを表示しています。また、週に1度、指標の変化率を以下の様にSlackで通知していました。

メール配信数: N 件（前週比：N %）
週間売上: N 円（前週比：N %）
1配信あたり流入数: N 件/配信（前週差：N pt）
1配信あたり注文数: N 件/配信（前週差：N pt）
1配信あたり売上: N 円/配信（前週差：N pt）

Vertex AI Pipelinesは一般的に機械学習システムのワークフロー管理ツールとして使用されますが、私たちのチームでは推薦システムの実績をモニタリングする用途でも使用しています。Vertex AI Pipelinesの導入事例については過去のテックブログでも紹介していますのでご参照ください。

課題

モニタリングシステムを運用してみて課題となったのは、指標の異常に気付くのが遅れたり、そもそも気付かないことでした。これまでは人が能動的にダッシュボードを見に行かなければ指標の異常に気づけないという状況でした。

課題解決のために

結論を申し上げると、上記課題を解決するためにVertex AI PipelinesとLooker Studioで構築していたモニタリングシステムをLookerを使用したシステムに置換しました。ここからは代替となるシステムを検討する際の3つの要件をご紹介します。

要件1. 指標異常時の自動アラート

課題の通り、指標の異常に気づくためには人がダッシュボードを見る工程が必要でした。この工程を自動化するため、指標異常時にはアラートを自動的に通知する仕組みを実現する必要があります。異常値の定義の方法には統計学や機械学習を用いる方法がありますが、今回は簡単な閾値の判定で異常値の検知をします。

要件2. サマリの定期配信

要件1を満たすことで明らかな異常値に気づくことはできるものの、こうした閾値判定だけでは中長期的な変化を捉えることができないため、少なからず人の目での定期的なチェックが必要です。また、プロダクトを管理するという観点で指標のトレンドを把握する必要があります。

要件3. 上記2つをSlack通知できること

また、私たちのチームでは通知をSlackで受け取るため上記2つをSlackに通知することが要件となります。

ダッシュボードの候補の比較

部署内では、ダッシュボードとしてLooker、Looker Studio、スプレッドシートを使用しています。そこで、活用事例があるこれらのサービスを使用して要件を満たすシステムが実現できないかを考えました。

スプレッドシートは標準機能で要件を満たさず、Looker Studioは要件2のサマリをメールで送ることができましたが、Slackには通知できませんでした。そのため、全ての要件を満たしたLookerを採用することに決めました。

要件を満たすための設計

上記の要件を実現するためにシステム設計をしました。Lookerのダッシュボードやアラートの細かな設定をすべてGitHubでバージョン管理できるようにすることと設定追加の拡張性を重視しています。

要件の実現方法

Lookerの標準機能を用いて指標異常時の自動アラートとサマリの定期配信のSlack通知を実現します。以下の図のシステム構成を考えました。

アラートと定期配信に関するyamlの設定ファイルを作成し、GitHub Actions上でLooker APIを使ってそれらの情報を設定します。アラートとサマリの定期配信の設定はLookerのUIからできますが、設定数の増大を想定してLooker APIを用います。

開発環境と本番環境

動作確認のために開発環境と本番環境に分け実装します。Lookerのインスタンスを2つ使用し、以下の図のような構成にしました。

Looker IDEからアラートと定期配信の対象となるダッシュボードのために必要なファイルを実装します。アラートと定期配信に関するyamlの設定ファイルに関しては、Looker IDE上でyamlが編集できないため、ローカルPCからPull Requestを作成します。GitHubとLookerのWebhookの設定とブランチの設定をすることで、それぞれのLookerインスタンスがGitHubの変更を反映するようにします。環境毎のブランチとGitHub Actionsの設定についてまとめると以下の様になります。

続きはこちら