はじめに
こんにちは、DR&MLOps*1 チームの楠です！ こちらの記事は Gunosy Advent Calendar 2021 の 5 日目の記事です。
昨日の記事は UT さんの『更新できるデータレイクを作る 〜Apache Hudiを用いたユーザデータ基盤の刷新〜』でした。
5 日目と 6 日目では、DR&MLOps チームメンバーで前後編に分けて『SaaS Redash 終了に向けた対応と分析の民主化』をテーマにした記事をお届けします。 本日は、SaaS Redash サービスの終了に合わせて Gunosy ではどのような対応を執ったのか、その意思決定の部分をご紹介します！
前提知識・背景
Redash とは？
Redash は、社内データの取得問い合わせ・データ視覚化・ダッシュボード作成を一貫して行える BI ツールソフトウェアです。
Gunosy では SaaS 版の Redash を採用しており、社内でインフラ面を考慮することなく Web 上で Redash の機能を利用することができました。 アドホックな分析業務から KPI 監視による日々の意思決定まで、幅広く利用されていました。
SaaS 版 Redash の終了(End of Life)
このアドベントカレンダーが公開されている現在 2021-12-05 には、先述の SaaS 版 Redash はすでに利用不可能になっています。 2021-11-30 でサービスを終了するとの発表があったからです。
Gunosy では、この変化にただ対処するだけでなく、一旦ゼロベースで「Gunosy における分析基盤をどうしていくか」という方針そのものを BI チーム・DR&MLOps チームを中心に考え直しました。 その上で、次に述べるような 2 つの軸を持った方針に至りました。
- 分析の方法と結果をシェアする文化を残したい
- SQL を書かなくても分析の入り口に立てる、分析の民主化へ
次からは、それぞれの方針について詳述していきます。
方針1. 分析の方法と結果をシェアする文化を残したい
Gunosy は、エンジニア以外の職種でも SQL を叩けるチームがあるなど、環境と文化の面で SQL を用いた分析へのリテラシーがあります。 それは例えばこのようなブログ記事からも汲むことができると思います。
このような環境・文化を継続させていきたいというのが方針 1. となります。
そのために、SaaS 版 Redash と似たような使い心地で全社的に SQL を用いた分析基盤を提供することを考えました。 そして、その実装方法は「OSS Redash の社内 EKS 基盤へのデプロイ」としました。 これにより、利用者から見たときの使い心地がほぼ変わらない SQL 実行基盤の継続した提供ができると判断しました。
今回のスコープから逸れますので技術的な詳細は省きますが、EKS 基盤が整っていれば Helm チャートから Redash を素早く展開することが可能です。 また、社内でノウハウのある EKS 基盤に乗せることで運用コストもかなり低く抑えることができると考えています。 こちらもまた機会があればお話ししたいと思います。
方針2. SQL を書かなくても分析の入り口に立てる、分析の民主化へ
方針 1. で述べたような文脈から、Gunosy では全社的に SQL を用いた分析への高いリテラシーを有していると認識しています。 その上で、次の段階として「分析タスクの深さによってツールを使い分ける」ことを考えました。 具体的には、SQL を触らなくても分析のできる新たな BI ツールを導入することにしました。
Redash のみの環境では「分析するためには SQL を書くこと（書けること）」が前提となってしまいますが、もっと広い意味での分析の可能な環境を作りたいというのが方針 2. の指すところです。 SQL を書かずとも、練られた分析ダッシュボードを持っていればそこでの操作だけで必要な判断材料を揃えることは可能です。 また、ある程度の集計・分析処理をプリセットとして持っておく（＝データマート化しておく）作業も同時に進めることで、車輪の再発明やオレオレ定義での分析を抑制する狙いもあります。
より広い意味での分析環境の構築を考えたとき、別のシステムを用意することで「SQL を書かない分析」のためのコンテキストを切り分けて別途用意したいという狙いがありました。*2 そういった点を鑑みて、次の状態を目指すことにしました。
- SQL を書けるスタッフは Redash 含め横断的に分析し、
- そうでないスタッフは新 BI ツールから信頼のできるデータマートの情報を利用してグラフィカルな分析を達成する
新たな BI ツールとしては、Amazon QuickSight を採用しました。 主な要素を次に挙げます。
- 権限による利用の切り分けができる
- 編集者（分析者）と閲覧者のロールがある
- 閲覧者ロールが安いのもあり、費用対効果が高いと判断
- 普段エンジニアが利用している AWS と地続き
- そのため認知的負荷が低いと思われる
方針まとめ
以上の観点から、まとめると次のような意思決定となりました。
- 方針1. 分析の方法と結果をシェアする文化を残したい
- Redash を社内にデプロイし、アドホックな分析のための SQL 実行用に継続して使ってもらう
- 方針2. SQL を書かなくても分析の入り口に立てる、分析の民主化へ
- Amazon QuickSight を導入し、信頼できるデータソースを用いたグラフィカルで確度の高い分析情報に全社的にアクセスしてもらう
対応作業を終えて
対応作業後の所感ですが、統一的で信頼できるデータセットに立脚する分析ダッシュボード群が構築できたことは、大きな前進だと感じています。*3
QuickSight は、Free Tier といって利用ユーザーが 1 名であれば無料で利用できます。*4 なので、まずは手軽に PoC を始められる点もよいと思いました。 これからは全社的に BI ツールに関する知見もどんどん溜まっていくと思いますので、それらも共有していければ嬉しいです。
これからもより良いデータ基盤のために、日々改善を続けていこうと思います！
おわりに
次回は、これらの方針がどのように達成されていったのかを、実装技術ベース・体験ベースで語る『SaaS Redash 終了に向けた対応と分析の民主化（実践編）』となる予定です。
アドベントカレンダーはまだまだ続きますので、引き続きよろしくお願いします！
