はじめに
こんにちは、DR&MLOps チームの hyamamoto です！ こちらの記事は Gunosy Advent Calendar 2021 の 6 日目の記事です。昨日の記事は楠さんの『SaaS Redash 終了に向けた対応と分析の民主化（方針編）』でした。 今回は前回記事の続編になるので、ぜひ前編から読んで頂けると幸いです。
前回の振り返り
前回の振り返りとして、SaaS Redash の終了に向けて、次のような方針を打ち出しました。
- 社内で Redash 環境を整備し、SQL によるアドホックな分析環境の整備
- Amazon QuickSight を用いた、規格化された分析環境の整備
ここで、1 の方法については Redash が公式に提供する Helm Chart を利用することで解決します。 そこでこの記事では 2 を達成するに至った方法とその振り返りを示していきたいと思います。
移行作業の内容
以前ご紹介したのですが、弊社では Baikal というデータ基盤を構築しています。 tech.gunosy.io このため前提として Athena からデータを取得し QuickSight で可視化することを目指していきます。
1. 移行が必要な Dashboard の洗い出し
まず、社内で SaaS 版 Reash を用いて分析に利用している Dashboard とその裏で走っているクエリを洗い出しました。 その後、クエリの実行間隔や Dashboard の利用方法を確認し、優先順位を決めることでサービス終了時に社内業務が止まらないように留意しました。
2. QuickSight向け Athena View の作成
1 で洗い出したクエリの移行に伴い Athena View を Terraform で作成し、QuickSight で読み込むようにしました。QuickSight ではクエリを記述し Athena からデータを取得することが可能ですが、運用上ルールとして QuickSight 内でクエリを記述しないということを取り決めました。
この理由として次のことがメリットが挙げられるためです。
- Terraform による IaC 化により、社内の重要クエリを GitHub 上で管理できる
- View 化することで普段のアドホックな分析でも再利用することができる
また、View のクエリは大きく 2 つに大別して用意しました
使い回されるための汎用的な View
各アプリケーションの RDB より ETL してきたデータは基本的に正規化されており、分析の際には何度も JOIN する必要があります。 そこで、厳密にディメンションモデリングを行ったわけではありませんが、JOIN するテーブルの組み合わせを View とすることで、 規格化されたクエリのもと必要なデータの取得をできるようになりました。
Dashboard で取り込むための View
Dashboard で直接表示するために、必要なディメンジョンとファクトを持った View を整備しました。 これにより QuickSight 上ではカスタムクエリや加工を行うことなく、View を選択するだけでデータの取得ができるようになります。 結果、Dashboard で利用するすべてのクエリは GitHub で管理されるようになりました。
3. BigQuery の Table の作成
1 の洗い出し時に浮き彫りになったこととして、Spreadsheet や GAS から Redash にアクセスし利用しているチームの存在です。セキュリティ性の観点から、社内構築した Redash はプライベートネットワークに配置しているため、これらのサービスからアクセスすることはできません。 そこで BigQuery を用いて Spreadsheet へのこれらのチームへデータを共有しました。
GoogleWorkspace に基づき認証・認可の設定できる点や、Spreadsheet との連携が簡便である点*1が採用理由となりました。 一方で、マルチクラウド環境は運用コスト・インフラコストが上がるという課題があるため、あくまでも BigQuery によるデータ分析は補助的なものに留めています。 共有するデータも生データではなく、先に集約したデータを送るようにし、基本的には QuickSight による分析に移行するようにしています。
4. SaaS 版 Redash のバックアップ作成
最後にこれまで利用してきたクエリを有事に確認できるようクエリのバックアップを取りました。 この際、公式が提供している query_export.py を用いることで、 比較的容易にすべてのクエリの取得が可能でした。 また、弊社ではバックアップしたクエリを GitHub 上に配置しており、そのファイル名をクエリの ID と揃えることで SaaS 版 Redash のリンクを簡単にバックアップ先の URL と読み替えることができるようになっています。これによりリンクさえわかっていれば、サービス終了後もバックアップからクエリを取得し、新しく作成した Redash での分析や可視化を再現できるようになっています。
振り返っての所感
最後に SaaS Redash 終了への対応を追えての良かったことやプロジェクトでの反省点・難しさをまとめようと思います。 今後、分析用の Dashboard を作成する人たちの参考になれば幸いです。
良かったこと
View としてクエリが共通化・IaC 化されたこと
これが最大かつ最高のメリットだと思います。 というのも、既存の Redash では社内の KPI を確認するクエリがバージョン管理されず、レビューもされないという状態が続いていました。 この点において View を作成し GitHub の管理配下に置いたことは非常に大きなメリットだったと思います。 もちろん、これは Redash が終了していなくてもできていたことではあるものの、今回の対応で強制的に腰が上がったという点で良かったです。
QuickSight によるインタラクティブな分析
Redash による可視化では、Dashboard 上においてインタラクティブな分析はほとんどできませんでした。 特に QuickSight による可視化ではドリルダウンやデータのフィルタリングをインタラクティブに行えるため、一つのグラフで表現できる情報量が増えました。 Redash 環境の場合、Dashboard から少し深ぼって分析したい場合は各自が Redash でクエリを書いて確認するという場面が多かったように感じています。 この点 QuickSight では GUI から分析を深掘って行くことができるようになったため、SQL に不慣れなユーザーでも心理的な障壁が低い状態で社内のデータをより柔軟に確認できるようになったと言えるでしょう。
以上のようなことは分析の民主化という観点で、移行前の状態から一歩進むことができたように感じています。
反省点・難しさ
View 作成時のトップダウンとボトムアップのバランス感
前編も少し触れましたが結果的にデータマートを短期間で作成するという作業になりました。 このため主な作業は View の大量生産になります。 これに対して、社内から利用しているクエリを集めつつ、裏で先に汎用的な View を作成することで移行の高速化を目指しました。 しかしながら、それでもかなり直前までバタバタしたものになってしまいました。
作業後半になるにつれて見ててきたことして、実際に社内の人々が見ているデータというのは同じようなファクトを異なったディメンションの組み合わせにすぎないということです。 このため、集められた 1 つ 1 つのクエリをコツコツ移行していくのではなくて、多少の移行漏れも覚悟の上でトップダウン的に仕様を決めて Dashboard を作成していたほうが効率的に進められたように思います*2。 また、良くも悪くもすでに分析をしていたクエリが大量にあったため、View による共通化をしていく中でタスクの粒度感が難しく、プロジェクトの進行把握も難しい状態に陥りました。 様々な人が書いたクエリを 1 つずつ確認して、何を見たいかについて把握するのもとても時間のかかる作業で、実際に手を動かす時間よりも既存クエリの仕様の把握に掛けた時間のほうが多かったようにも思います。 もちろん、オレオレで Dashboard を作った結果、仕様が漏れていて業務に支障が出ても問題なので、双方向のアプローチは必要ではあるものの、もう少しそのバランスをトップダウン側に倒しても良かったのかなと感じています。
マクロ平均の扱い
QuickSight でドリルダウンが可能になった反面、グラフの見方によっては一部のファクトがマクロ平均になってしまい、マイクロ平均と大きく乖離した値が出てしまうことがあります。 例えば、OS 毎に平均したファクトをドリルダウンせずに全体で見ようとした場合には、Android と iOS のマクロ平均の値が表示されます。 結果、全データに対する Android の比率が圧倒的に多かったとしても、iOS のファクトの上振れ下振れが全体のファクトに大きな影響を与えてしまいます。
以上の内容から、マクロ平均の値だけが表示されると誤った意思決定を利用者が行う可能性があるため、マイクロ平均を Dashboard 上で出力するようにしたいと考えました。 この対応としてディメンションが僅かに異なるだけの View を複数作成する必要があり、 View の作成・管理コストが高くなってしまうことや、本質的にはほぼ同じデータなのに異なったデータセットとして QuickSight に取り込む必要があることは課題に感じています。
おわりに
以上が今回の SaaS Redash 終了に向けた対応になります。結果的に社内におけるデータ分析がより民主化したことは良かったように思います。 この記事が同じような課題を抱えている方々の何らかの参考になれば幸いです。
次回は吉岡さんの「2021年に新規の iOS アプリを作った話」 という記事です。 お楽しみに！
