エムスリー エンジニアリングG AI・機械学習チームの笹川です。 10/31から 出張 でM3 USAのNYオフィスに来ています。 NYオフィスはNYのタイムズスクエアのすぐそばにあり、アーティストのライブなどが行われる会場としても有名なマディソンスクエアガーデンも徒歩5分ほどの距離です。 この時期はNBA観戦が捗りますね！（最高の職場です！）
このところは、休日にルームメイトの冨岡とNew Yorkらしいところに行ってニューヨーカー感を高めたり、平日にはオフィスの部屋を追われて、タイムズスクエアでコーディングをするなどしています (フィクションかもしれません)。
今回は、M3 USAのプロダクト向けにデータ分析環境の整備を兼ねて、KPIモニタリングのためのダッシュボードツールを導入したので、そこで利用したデータ連携ジョブの実装、ダッシュボードツールなどの技術スタックや運用部分での工夫について説明します。
KPIモニタリングツール導入の意義
一般にKPIを繰り返し確認し、意識して行動することは非常に重要です。一方で人間は怠惰な生き物なので、面倒なことに対しては億劫になってしまい離れていってしまいます。
例えば、「日々のKPIを確認するために、社内の共有サーバー（スペック低め）の深いディレクトリにある秘伝のエクセルファイルを開き (他の人が開いていて、ロックされていることもある)、手動で日付などを修正したスクリプトを流す。15分待つとやっと一つ目の値が出るが、集計対象のデータの一部に欠損があると計算が落ちる。」みたいな状態であったらどうでしょうか。この状態で「日々KPIを意識して動け」「日次でKPI進捗を報告しろ」なんて言われて従うのは、よっぽどドMな少数の方に限られるでしょう。
KPIへのアクセスコストは0に近いほどよく、実際にそうなっているよう環境を整備しておくべきです。そして、日々繰り返し行うことの物理的コストを下げることは、とてもコストパフォーマンスのよい投資であるだけでなく、怠惰を美徳とするエンジニア（をはじめとした関係者全員）の心理的不満の解消にも繋がるでしょう。
今回導入したKPIモニタリングツールの構成
今回は、日本でも導入し利用が進んでいるBigQuery + Redashの構成でいくことにしました。 構成は以下の図のようになっています。
以下では個々の技術的要素について説明します。
アプリケーションのDB → BigQueryのデータ連携
BigQueryはパフォーマンス面でもコスト面でも非常に優れたDWH環境です。 日本のM3では、ダッシュボード用途のみならず、機械学習プロダクトのデータソースや、データ加工用の環境としての利用盛んです。 ゆくゆくは、日本とUSの間で相互にデータの利用や、プロダクトの展開を進めていくために、日本と同様の環境を構築することにしました。
本番アプリケーションで発生しDB (M3 USAではOracleが多い) に格納されたデータをBigQueryに連携する部分は、もはやデータ連携に関しては定番となりつつあるDigdag + Embulkで構成しました。
Digdag
Digdagはジョブの依存関係の記述の他、定期実行のスケジューリング、リトライの設定、ジョブの異常/正常終了の通知担当するワークフロー管理ツールです。Digdagの最大の特徴は、YamlベースのDSLで上記に挙げたようなジョブの各種設定を簡単に記述できることで、基本的な内容は エンジニアであれば15分ほどドキュメントを読めば実装できるようになるでしょう (詳細に関しては公式ドキュメントや，他の記事に譲ることとします)。
Digdagは、ジョブサーバを用意し、サーバーモードで起動した上でジョブ設定を書いたファイル (digファイル) と、ジョブ実行に必要なスクリプトなどをpushして利用します。その際に、Digdagでは、digファイルのあるディレクトリ以下のディレクトリしかジョブ資材として認識できないようので、今回は以下のようなディレクトリ構成を採用しました。
ポイントは、db1_load 、 db2_load などのデータ連携ジョブに必要な資材のディレクトリを、digファイルをまとめた workflow ディレクトリの下にシンボリックリンクを貼ったことです．このようにすることで、Digdagの都合で無駄にディレクトリ階層が深くなるのを避けることができ、見通しの良いディレクトリ構成とすることができました。
Embulk
Embulkは、ローカルファイル、Oracle、PostgreSQL、S3、BigQueryなど様々な入力データから、バルクでデータを転送することに特化したデータ転送ツールです。データの入力、出力に合わせた様々なプラグインが用意されており、それらを導入した上で、こちらもYamlをベースにした設定ファイルを記述することでデータ転送ジョブの設定を書くことができます。
上記のサンプルのように，in のセクション、 out のセクションそれぞれに、入力テーブル、出力テーブルの設定を記載します。
BigQueryへの連携においては、BigQuery outputプラグインを利用しますが、連携時に既存テーブルに対するデータの追加、オーバーライトの別の設定や、新規連携などでテーブルがない場合の処理など、オプションを利用して挙動を細かくコントロールできてとても便利です。
Redashの構築
Redashは様々なデータソースに対応した、データ可視化ツールです。 BigQueryにももちろん対応しており、データの取得、可視化、ダッシュボード作成を行うことができます。 加えて、作成したグラフや、それをまとめたダッシュボードについては、個々に権限設定を行うこともできます (個人的には権限設定機能に少しクセがあると感じており、どのように運用するべきか試行錯誤中です。いい方法を思いついた際には別途記事にします)。
今回はAWS上にインフラを用意することにしました。 公式が専用のAMIを用意してくれていることもあり、Redash特有の設定などは特に必要なく、インフラ準備のためのTerraformの実装コストも低く便利でした。今回は公式のAMIを使うのみのシンプルな構成とし、日次でインスタンスのスナップショットと、後述するツールによるクエリのバックアップを実施することとしました。
ダッシュボード、クエリの開発と運用
ダッシュボードやクエリは、作るだけで終わりでなく、実際にダッシュボードが使われて初めてその価値を発揮します。 運用面での機能や、工夫について説明します。
クエリに利用するデータソースについて
今回、ほとんどのデータはBigQueryから引く形としましたが、一部BigQuery以外から取得するものもありました。そのような場合、既存のデータとの結合が一般には難しくなります。 今回の事例では、サイト上でのユーザ情報のトラッキングにGoogle Analytics (GA) を利用している部分があり、無料プランを利用しているためBigQueryに連携することができません。そこで、RedashのQuery Result Data Sourceの機能を利用し、あらかじめGAのデータを取得するクエリをRedashで書いた上で、そのクエリ結果をあたかもDB上のテーブルのように扱って、Redash内部で結合して分析、可視化することができます。
ダッシュボードの更新とその通知
BigQueryに定期的に連携されるデータをダッシュボードに反映する必要があります。 Redashは手動で更新する方法の他に、あらかじめ登録しておいたスケジュールにしたがって自動的に実行する機能が備わっています。
また、ダッシュボードの更新はSlackを用いて通知してやることでアクセスコストをさらに下げています。 「通知」なんて言ってみたものの、イケてるSlack Botを実装したわけではなく、Slackのリマインダ機能をRedashの更新時間に合わせて発行する原始的なものです。それでも現状は十分に機能するので一旦このくらいの省エネ実装にしています。 今回のように、SlackへRedashのボードURLを共有する際に、SlackにRedash Appを連携していると、以下の図のようにRedashのURLを展開してくれます。 こうすると、URLを共有するだけでRedashをわざわざ見に行かなくてもざっくり内容を把握できるので便利です。
コスト管理
Redashの利用が進んでくると、多数のクエリが実行されるなどしてBigQueryの利用量が増加し、コスト面が問題になることがあります。 Redashには登録されたBigQueryのクレデンシャルごとに、1クエリあたりのデータ利用量にキャップを付加する仕組みがあるため、うっかりイケてないクエリを大量に流してしまい、まずい額を使ってしまったなどという問題を防ぐことができます。 なお，月次での利用料の制限には、BigQuery側で制限をかける必要もあるので注意してください．
クエリのバージョン管理
Redashのクエリは、基本的にはRedash管理画面のGUI上で編集する形となっているのですが、Redash側にはクエリをバージョン管理する仕組みがないので、無邪気に編集を重ねると、ダッシュボードの内容が壊れてしまったが、復元できない！ということになる恐れがあります。 それを防ぐため、今回はクエリのダンプツールであるredashmanを利用することにしました。 このツールを定期的に回してクエリをGit管理することで、クエリが壊れてしまった場合に前のバージョンに戻せるようにしています。 個人的にはRedash側でこの機能を提供してほしいなー、と思っています。
まとめ
今回は、USプロダクト向けにデータ分析環境の整備と、KPIモニタリングのためのダッシュボードツールを導入した件について説明しました。 今回の取り組みでKPIへのアクセスコストを大きく下げることができたことに加え、日本の構成との共通化を進めることもできたので、今後はグローバルに施策の横展開を実施していきたいと思っています。
We are hiring
エムスリーでは、KPIのモニタリングのみならず、データを活用したビジネス推進のために、上記で紹介したようなデータ基盤の整備、活用推進ができるエンジニアを求めています。日本、US双方で採用を行なっていますので、興味を持たれた方はぜひ以下のリンクからご応募ください。
