Redash運用に付きまとう課題とその解決方法

by orkShinnosuke

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Copyright © 2018 eureka, Inc. All rights reserved. 8 Redashの導入背景 (2015/10頃) ● Redashに白羽の矢が立った理由 ○ 様々なデータソース (MySQL, BigQuery...etc)につなげる ○ 簡単にクエリ / グラフ / ダッシュボードの作成が可能 ○ SQLの保存でノウハウのストックが可能 ○ SQLの定期実行が可能 ○ APIが備わっている ○ CSVで結果をDLできる ○ 無償(OSS版)

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Copyright © 2018 eureka, Inc. All rights reserved. 10 ● グラフ/ダッシュボード作成 ○ 管理画面で確認していた指標 (売上 / 登録者数...etc) のダッシュボード化 ○ 施策の効果測定時にグラフ作成 Redashの主な使い方 (クエリ増殖期: 15/10~16/12) ● APIを使ってデータをSlackへ ○ Pairsの特に重要な指標 (売上etc) はAPIで取得したデータを Slackに流す ※Redashは希望者全員が使用可　社内の希望者全員がクエリ /グラフ等の作成/編集可能としていたオーソドックスな使い方が主流 ● クエリの保存/フォーク ○ 効果測定等で使ったクエリを保存。似たような分析実施の際はフォーク

Slide 11

Slide 11 text

Copyright © 2018 eureka, Inc. All rights reserved. 11 ● 課題1: 不正確 / 不要なクエリの乱立 ○ 正しくないクエリによる誤った意思決定の誘発 ○ 検索が困難に ● 解決方法1-1: Redashアカウント作成と権限変更フローの確立 ○ スキルに応じた権限に変更 ● 解決方法1-2: クエリに命名ルールを定める ○ 公式 / 非公式クエリに分けるため命名ルールを制定。非公式クエリはアーカイブ ■ [公式]サービス+国名: 粒度+内容(グルーピング) ● BIチームのLGTMがあれば[公式]マーク ● 例: [公式]Pairs日本: Daily売上(男女*デバイス) Redashの課題/解決方法 (クエリ増殖期: 15/10~16/12)

Slide 12

Slide 12 text

Copyright © 2018 eureka, Inc. All rights reserved. 12 ● 解決方法1-2: クエリに命名ルールを定める ○ 命名ルールは暫くは運用に乗った。が途中から廃れた。厳密に運用するならメタデータを使い、自動的に命名をチェックする仕組みと併用した方がよい ○ 公式/非公式クエリに分けるだけなら、最近の versionで対応するならPublish/Unpublishを使い分けるのはあり ■ ※Unpublishクエリはdashboard等から参照できない Redashの課題/解決方法 (クエリ増殖期: 15/10~16/12)

Slide 13

Slide 13 text

Copyright © 2018 eureka, Inc. All rights reserved. 13 Redashの課題/解決方法 (クエリ増殖期: 15/10~16/12) ● 課題2: 使いづらいグラフ / ダッシュボードの乱立 ○ グラフ毎に違う配色によるミスリードが発生 ● 解決方法2-1: 配色ルールを制定 ○ 例：male/female, pc/sp/ios/android ○ 制定した結果グラフ / ダッシュボードの見やすさが改善 ○ こちらのルールは守られている (メリットの大きさ故？ )

Slide 14

Slide 14 text

Copyright © 2018 eureka, Inc. All rights reserved. 14 Redashの課題/解決方法 (クエリ増殖期: 15/10~16/12) ● 課題3: BigQuery課金額の上昇 ○ 多くのエンジニア、ディレクターに開放したことでたまに怪しいクエリが ... ● 解決方法3-1: Scanned Data Limit (MB)を指定 ○ RedashのDataSource設定画面でScanするDataの上限を決められる ● 解決方法3-2: 課金額の可視化と定期的なチェック ○ GCPの費用という枠組みで、これは社内の SREチームが主にやってくれている ● 解決方法3-3: BigQueryデータソースに対するクエリ実行時のルール制定 ○ 例: “SELECT *”の禁止 ● 解決方法3-4: 課金が発生する旨の可視化

Slide 15

Slide 15 text

Copyright © 2018 eureka, Inc. All rights reserved. 15 運用を通しての学び (クエリ増殖期: 15/10~16/12) ● 権限整備は真っ先に対応するのが吉 ● 運用ルールは監視し続ける人(または仕組み)がいないと廃れる ● BigQuery使いすぎ問題を防ぐには制約と可視化が大事 ● 守るメリットが大きいルールほど守られやすい ● 運用の辛みを解消してくれる機能(Publish機能など)が続々リリースされているので、辛みを感じたらversion upすれば解消しないか確認

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Copyright © 2018 eureka, Inc. All rights reserved. 17 ● VisualizeはGoogle Spreadsheetへアウトソーシング ○ RedashでのVisualizeに限界を感じる ■ グラフをコピーしづらい etc ○ 有意差を判定するためにも Spreadsheetの方が都合がよかった Redashの主な使い方 (API多用期: 17/01~18/02) ● 定期実行クエリの多用 ○ 定期実行したクエリの実行結果を APIで取得して対応する分析が増加事業成長に伴い、使い方のバリエーションが増える ● データ欠損検知でアラートを使用 ○ データ件数等をチェックし、異常値であれば Slackにアラートを流す

Slide 18

Slide 18 text

Copyright © 2018 eureka, Inc. All rights reserved. 18 ● 課題1: キューにクエリが詰まる ○ 定期実行クエリが増えた結果、クエリが詰まる事例が増えた ○ 前提としてこの場合の原因は色々考えられる。原因によって解決方法は変わる Redashの課題/解決方法 (API多用期: 17/01~18/02) 引用: 一歩踏み込むRedash https://speakerdeck.com/ariarijp/bu-ta-miip-mu-redash

Slide 19

Slide 19 text

Copyright © 2018 eureka, Inc. All rights reserved. 19 ● 解決方法1-1: 重い定期実行クエリを停止 ○ メタデータを使い実行に時間がかかっているクエリを検知 & 必要に応じて停止原因: クエリが重い ● 解決方法1-2: クエリをチューニング ○ MySQLクエリをBQクエリに置き換えて数十分レベルで軽量化した事例も ● 解決方法1-3: 遅いクエリをタイムアウトさせる ○ REDASH_ADHOC_QUERY_TIME_LIMITを使う。定期実行クエリには効かない ● 解決方法1-4: クエリが詰る前のログを確認し実行者に注意喚起 ○ アナログだが地味に効果あり

Slide 20

Slide 20 text

Copyright © 2018 eureka, Inc. All rights reserved. 20 ● 解決方法1-5: キューの数を増やす ○ supervisord.confの設定で増やせる ● 解決方法1-6: クエリの定期実行時間が重ならないように可視化 ○ 同時実行数を減らすことで、キューがつまらないようにする ● 解決方法1-7: 後回しで良いクエリは”キャンセル” ○ v3.0の話ですがキャンセルボタンがうまく効かない .. 原因: クエリの同時実行数に対しキュー数が少ない

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Copyright © 2018 eureka, Inc. All rights reserved. 22 運用を通しての学び (API多用期: 17/01~18/02) ● クエリがキューに詰まる件に関しては特効薬がない ● キューの数を増やす、サーバーをスケールアップするなどで一時的には負荷が減ることはあるが、クエリが増えればまた同じ問題にぶつかる ● 重い定期実行クエリの停止、クエリが詰る前のログを確認し実行者に注意喚起など、地道な改善作業を続けていくことが大事

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Copyright © 2018 eureka, Inc. All rights reserved. 24 ● Tableau導入の背景 ○ 膨大な量のデータ (数百~千万レコード) をVisualizeしたいという依頼の増加 ○ 主要KPI(売上やPairs内アクションetc)を様々な切り口から深掘りをしたいという依頼の増加 ■ 切り口が多岐に渡るので、 1個1個クエリをRedashで作っているとキリがない ○ →膨大なデータを扱えかつ Pivot機能とVisualize機能が充実したTableauで対応 Redashの主な使い方 (Tableau併用期: 18/03~現在) 多様化する分析ニーズに対応するためRedashとTableauを併用

Slide 25

Slide 25 text

Copyright © 2018 eureka, Inc. All rights reserved. 25 ● RedashとTableauの棲み分け ○ Tableau: 主要KPIを様々な切り口から見て深掘りする分析で使用 ○ Redash: Tableauに用意されている切り口でカバーできないアドホックな分析や、即時性が求められる分析で使用(Tableauにデータを上げる前にはデータの中間集計・整形が必要 ) Redashの主な使い方 (Tableau併用期: 18/03~現在) 多様化する分析ニーズに対応するためRedashとTableauを併用

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Copyright © 2018 eureka, Inc. All rights reserved. 28 参考文献 ● re:dash + BigQueryでクエリのコスト上限が指定できるようになった ○ http://ryotarai.hatenablog.com/entry/2015/12/17/104600 ● Redashの長期運用を見据えてクエリの名前付けについて考える ○ http://ariarijp.hatenablog.com/entry/redash-advent-calendar-day-24 ● 一歩踏み込む Redash ○ https://speakerdeck.com/ariarijp/bu-ta-miip-mu-redash ● Changing the Number of Workers ○ https://redash.io/help/open-source/admin-guide/maintenance