Metabaseって何ができるの？ 〜導入提案時にチームメンバへ伝えたいこと〜

この記事は BABY JOB Advent Calendar 2024 の 11 日目の記事です。

はじめに

BABY JOB のY-Kanohです。
入社してまだ半年程度ですが、「アドベントカレンダーがある」と言われたら参加しないわけにはいかないでしょう！！

何を書こうか迷ったのですが、最近導入を検討している Metabase の紹介をします！
（最近はチーム内の課題解消や仕様設計がメインで、たまに実装をやる感じの業務なのですが、せっかくのアドベントカレンダーですし、エンジニアとして1記事ぐらいは技術系にしないとね笑）

Metabase自体はすでにメジャーなBIツールかと思いますので、この記事では以下のようなシチュエーションの人を想定して紹介します。

この記事の対象

• プロダクトで Metabase の導入をしたい人
• 導入にあたって周りを納得させたい人
• Metabase の概要をざっくり共有したい人

Metabaseとは

https://www.metabase.com/

Metabase社がOSSとして開発している、さまざまなデータソースに対応したデータ可視化ツール（Business Intelligence tool：BIツール）です。
サービスで利用しているDBの接続文字列等を Metabase に登録することで、Metabase 経由でDBクエリの実行や、データのグラフ化、ダッシュボード化などが行うことができます。

私は Metabase を PHPカンファレンス香川2024で聴いたこの発表で教えていただきました。

https://speakerdeck.com/yamato_sorariku/number-phpconkagawa-regasikodonimoobuzababiriteiwo-shao-sizutushi-merusabisujian-shi

発表自体は、サービスに対して的確な監視を行うことでオブザーバビリティを獲得する内容で、末尾にMetabase の紹介がありました。
この発表を覚えていたため、現プロダクトに参画した時、チームの課題解決方法として Metabase の導入を提案することができました。（登壇者の @yamato_sorariku さん と、機会をつくってくださったPHPカンファレンス香川2024に感謝!!）

なぜ導入しようと思ったのか？

導入しようと思ったとき、最初に導入の目的を説明する必要があります。
私の場合は、大きく2つの理由から導入を提案しました。
けっしてダッシュボードがカッコよかったからじゃない

理由1：プロダクトの状況を誰もが把握できる状態にしたかった

一つ目の理由は、ビジネスサイドのメンバも、開発のメンバも、等しく自プロダクトの状況がわかる状態にするためです。

弊プロダクトでは、ビジネス上の戦略立案を行うビジネスサイドのチームと、機能開発を行う開発チームが分かれています。
ビジネスサイドのチームでは、戦略立案のため現在のサービス利用状況などを把握する必要がありますが、メンバは非エンジニアなので、SQLの発行は得意ではありません。
一方開発チームは、SQLの知識があるためDBからデータを参照することができますが、プロダクトの戦略にはあまり関わっていなかったため、現在の利用状況などを気にする機会が少なくなっていました。

本来であれば、サービスの状況はプロダクトに関わる全チームが把握できるようにすべきです。
ビジネスサイドのチームからも簡易にデータへアクセスができ、開発チームもプロダクトの状況を理解しつつ開発にあたるべきです。

そのためには、誰でも簡単にサービスの利用状況を確認できるプラットフォームを構築する必要があると感じました。

理由2：リリースした機能の効果測定を容易にしたかった

二つ目の理由は、開発した機能の効果測定を行うためです。

弊社では（ありがたいことに）CI/CD環境が整えられており、開発開始から短期間でのリリースが可能な状態が構築されています。
しかし、開発した機能がどれぐらいウケたのか、どれぐらい利用されているのかを確認する術が多くありませんでした。

方針の軌道修正をするためのデータ分析がおろそかになっては、変更からのリードタイムが短い利点を活かしきれていません。今後プロダクトを長期に渡り成長させるためには、まずリリースした機能の効果測定を妨げる要素はできるだけ無くしたいと考えました。
また、できれば能動的にデータを取得するのではなく、受動的にデータを目にするようにすべきとも考えました。そのためには、Slackやメールで定期的な通知を行える Metabase が適していると感じたのです。

Metabase でできることの紹介

次に、Metabase でどのようなことができるようになるかメンバに説明する必要があるでしょう。
Metabase では以下のようなことができます。

• SQL などのDBクエリの保存/実行
• SQL 実行結果のグラフ化
• ダッシュボードの作成/公開
• Slack、メールによる定期的な通知
• 権限制御

公式サイトによると Metabase は20を超えるデータリソースに対応しています。
いずれかを利用しているサービスであれば、Metabase を簡単に導入することができます。
詳しくは Metabase公式サイトのData sources をご覧ください。

クエリとクエリビルダー

Metabase では、SQL のようなネイティブクエリの作成/保存と、クエリビルダーによるクエリの作成/保存ができます。

クエリの編集画面

クエリビルダーについての詳細は省きますが、SQL を知らないメンバでもDBの中身を確認できるようになります。

クエリビルダーによるクエリの作成

実行したクエリの結果は、グラフなどで可視化することができ、これらを集めてダッシュボード化することもできます。

作成できるダッシュボード例

コレクション

保存したクエリとその実行結果は「コレクション」という単位で整理できます。
コレクションの中には複数の SQL 実行結果やダッシュボードを保存できます。
また、後述しますが、コレクションごとにユーザグループのアクセス権を制御することも可能です。

Slack/メールでの通知

作成したクエリの実行結果は、結果をSlackやメールで定期通知させることができます。
通知タイミングは毎時、日次、週次のタイミングから選ぶことができます。

通知タイミング設定

導入時に説明が必要なこと

さて、Metabase でできることがわかっても、いざ導入しようとするといくつかメンバに説明が必要なはずです。
ここでは、私が実際にチームメンバへ導入時に説明した内容を解説します。

開発メンバ以外が無条件でDBにアクセスできてしまうの？

一番気になることは以下のような社内セキュリティ的観点でしょう。

• 開発メンバ以外が SQL を実行できるのはよくない
• ユーザの個人情報などが閲覧できると問題である
• 非エンジニアによって不用意に負荷のかかる SQL を実行されると困る

これら課題の解決方法として、Metabase にはユーザグループやDBごとに権限管理を行う機能があります。

Metabaseで制御できる権限単位

前提

• 権限は"ユーザ"ではなく"ユーザグループ単位"に設定できる
• 権限がバッティングした時は、最も許可されたアクセス権が優先される

制御単位

• データベース/テーブル ごとのアクセス権を設定できる
• SQLを保存する"コレクション"ごとにアクセス権を設定できる

以下に解説しますが、詳しくは Metabaseの公式ドキュメント を参照してください。

ユーザとユーザグループ

Metabase は管理者がユーザを発行し、ユーザはメールアドレスとパスワードでサインインして利用することができます。

ユーザは複数のユーザグループに属すことができ、ユーザグループごとにデータへのアクセス権を設定できます。
アクセス権は、「データベース/テーブルへのアクセス権」と「コレクションへのアクセス権」を設定できます。

ユーザグループとユーザの設定

データベース/テーブルごとのアクセス権

Metabase では、データベースごとにユーザグループのアクセス権限を設定できます。

ユーザグループごとの権限設定

設定できる権限は以下の通りです。
クエリビルダーを使って自由にデータを閲覧してほしい場合は、「詳細設定」により機密性の高いテーブルのみに権限制御をかけることもできます。

• クエリビルダーとネイティブ：クエリビルダーでも SQL でもクエリを作成できます
• クエリビルダーのみ：SQL 等でのクエリ作成はできません
• 不可：閲覧もクエリの作成もできません
• 詳細設定：各テーブルごとに権限設定をできます（下図参照）

テーブルごとの権限設定

テーブルごとのアクセス権確認

データベース/テーブルごとにアクセス権を付与していると、各データベース/テーブルを誰が編集/閲覧できるのかを確認したくなるかと思います。
そのため、Metabase ではデータベースやテーブルごとにどのユーザグループにどんな権限が割り当てられているのかを一覧で確認することもできます。

テーブルに対するアクセス権一覧

コレクションごとの権限設定

データベース以外にも、前述した「コレクション」に対するユーザグループごとの権限管理も行うことができます。

コレクションごとの権限

設定できる権限は以下の通り。^[1]

• キュレーション：コレクションとそのコンテンツを編集、移動、削除できます
• 閲覧：内容の確認のみできます
• アクセスがありません：表示することもできません

権限がバッティングしたときの挙動

前述の通り、1ユーザは複数のユーザグループに所属することができます。
また、データベース/テーブルへのアクセス権と、コレクションのアクセス権が別々に設定することができます。
そのため、「所属しているグループA、Bのうち、グループAのみに閲覧が許可されているグラフが存在する状態」や、「ユーザテーブルへのアクセス権がないのに、ユーザ情報が含まれるコレクションへのアクセスは許可されている状態」になる場合があります。

この場合、そのユーザには最も許可されたアクセス権が付与されます。^[2]

よって、たとえテーブルでアクセス権を「閲覧不可」に設定していたとしても、コレクションでアクセス権を付与してしまわないよう注意する必要があります。

また、有償版にした場合、ここで挙げたもの以外にも、各クエリの実行結果ダウンロード権限などを設定することもできるそうです。

頻繁なクエリ実行でDBに負荷がかからない？

次に問題になりそうなことは、「本番 DB に負荷がかからないか」でしょう。
実行結果確認画面が頻繁に表示され、SQL がその度に実行されてしまうと、クエリによっては DB に負荷を与えてしまうことになります。

この解決策として、Metabase には結果をキャッシュする機能があります。^[3]
具体的には、クエリの平均実行時間を使用して、クエリの結果を決めた期間キャッシュします。

例えば、以下キャプチャの場合、クエリの実行に平均10秒かかる場合は、10秒に乗数100をかけて、1,000秒間はキャッシュを保持します。

結果のキャッシュ設定

構築大変じゃない？

Docker がある環境の場合は、以下のコマンドで構築は完了です。^[4]

docker run -d -p 3000:3000 --name metabase metabase/metabase

また、Java11 がある環境であれば、公式サイトから実行ファイルをダウンロードし、以下コマンドで実行できます。^[5]

java -jar metabase.jar

上記方法で、とりあえず Metabase を起動することができるので、ブラウザから以下の URL にアクセスすることで初期設定を行うことができます。

http://{ホスト名}:3000/setup

ただし、上記コマンドで導入した場合、Metabase はデフォルトでクエリ等を保存するため H2 Database を利用します。
しかし公式ドキュメントでは、本番稼働時は H2 Databaseではなく PostgreSQL、MySQL、MariaDB などの利用を推奨しているため、運用の様子を見て移行しましょう。
移行方法は、公式ドキュメント に記載されています。

EOLになっていない？

Metabase は OSS として開発が進められており、現在も定期的にリリースが行われています。
（この記事を書いている時点で、3日前に最新版のリリースがありました。）

https://github.com/metabase/metabase

どれぐらいのスペックがあれば動くの？

こちらにある質問によると、1つ以上のCPUと1GB以上のメモリで動作させることができるそうです。

最後に

Metabase でできることについての記事は多いのですが、導入時に気になる内容をまとめた記事はあまり見かけなかったのでまとめてみました。
チームで検討する際の材料になれば幸いです。

---

脚注

1. Collection permissions

2. Key points regarding permissions

3. Adaptive caching policy

4. Run your own free self-hosted
instance of Metabase

5. Running the Metabase OSS JAR file