RedashについてLTしてきました。もともとは単に仕事として会社にRedashを導入する担当になっただけなのですが、運用するうちにRedashの使い勝手と哲学が好きになりました。このブログで記事を書いたり、Redashにプルリクを出したりするようにもなったので、これまでを振り返る意味合いも込めて登壇しました。

スライドはこちらです。

Redashとは？

DBにクエリを投げたり、その結果をグラフにしたりできるダッシュボードツールです。ただし高度な統計・解析機能はそれほど多いわけではありません。むしろ、エンジニアでない人たちでもデータを簡単に見られること を主眼に作られているツールです。

Redashを導入した背景

上記で書いたRedashの特徴とは反対に、エンジニア以外がデータを見る習慣がなかったためです。うちの会社ではBtoBのSaaSを提供しており、個々のクライアントに対するカスタマーサポートは手厚く行えていたのですが、全体の利用状況を定期的に把握することがあまりできておらず、ソフトウェア全体の方針決定にも支障が出ていました。このため、OSSなので無料で手軽に導入できること、そしてエンジニアでない人でも使いやすいことなどが決め手になり、会社でRedashを導入することになりました。今はAWS EC2インスタンスで、公式AMIを使って動かしています。

Redashの機能

Redashはただ単にクエリを投げるだけでなく、プレースホルダーやフィルタ機能を使えば、クエリを書き直さなくても分析範囲を変えることができます。また、クエリの定期実行や、アラート機能による監視も実現できます。うちの会社では簡易的なサービス監視をRedashで行なっているほどです。
他にもスライド内で紹介しきれなかった機能がいろいろあります。詳しい内容は、@kakakakakkuさんのRedashハンズオンをやってみるのがおすすめです。

github.com

Redashを導入して何が変わったか？

導入して約半年が経ったのですが、データを扱う主体が、開発チーム以外にも開かれました。特にCSチームが積極的にRedashを使っており、サービスの簡易的なモニタリングや、新規登録されたID一覧のような、日常業務に使うデータの取得といった用途が多いです。今は自社サービスが始まって以来、間違いなくデータが最も多く見られています。
ただ、運用上の課題もあります。Redashを速く使い始められるようにすることを優先して、工数を最小限に抑えて導入したのですが、業務に定着していくにつれて、バックアップやテスト環境などの運用体制をしっかり整える必要性が高まってきています。とはいえ人員が少なく、他の開発タスクも抱えている中、Redashに割ける工数が多いわけではありません。どうやって安定運用をしていくか悩んでいるところです。

個人的には、大規模なものよりもシンプルで機能がわかりやすいサービスが好きなので、Redashは自分のカラーに合ったツールだと思っています。Docker Imageをダウンロードすればローカル環境で動かすこともできるので、ダッシュボードツールを検討している方は一度試してみてください。