Scalebase Analytics powered by Looker

「ScalebaseにおけるLooker 組込みアナリティクスを活用した顧客向け分析サービスの展開」
Year End Looker Meetup 2020 発表資料
https://discover.looker.com/2020yearendmeetup_ja.html

Transcript

1. Scalebaseにおける Looker組み込みアナリティクスを活用した 分析サービスの展開 2020/12/07 Year End Looker Meetup 2020 Naoki Ainoya / Alp, Inc.
2. 自己紹介 • Naoki Ainoya • SRE @ Alp, Inc. • Scalebaseの開発・運用
3. 本日お話すること Scalebaseに分析機能を実装するにあたり… • Lookerの選定理由 • 組み込みAnalyticsの実装方式と構成 • 実運用・開発フロー
4. サブスクリプションビジネス効率化・収益 最大化プラットフォーム
5. Scalebaseが対象とするビジネスモデル
6. 契約・請求・分析のオペレーションを一気通貫で管理 SFAや会計システムと連携し、シームレスなオペレーションを実現
7. 契約・請求・分析のオペレーションを一気通貫で管理 SFAや会計システムと連携し、シームレスなオペレーションを実現
8. Scalebaseの分析機能 • Scalebase内のデータを リアルタイムに可視化する 分析ダッシュボードを提供 • Looker組み込みアナリティクス (Embed SSO)で Scalebaseサービス内に埋め込み 顧客に展開
9. Lookerを採用した理由 Scalebaseへの分析機能実装にあたっての条件 • 人的・時間的リソースが限られている状況で、素早く立ち上げること • 急激なサービスの成長にも耐えられる作りになっていること
10. Lookerを採用した理由 サービスに組み込み可能なBIソリューションをいくつか検証し、Lookerを採用 • リソースが限られている状況で、素早く立ち上げること →LookMLの高い表現力・開発のしやすさ →Embed SSOによる組み込みとダッシュボード開発の容易さ • 急激なサービスの成長にも耐えられる作りになっていること →Looker自体がパフォーマンスのボトルネックになりづらいアーキテクチャ →負荷に応じてデータウェアハウスのアーキテクチャを将来変更して捌ける （小さく始められ、かつ処理が重くなってもこちらで対応でき、手詰まりとならない）
11. 結果として：リリースまでのタイムライン おかげさまで機能検討開始からリリースまで半年程度で完了 • PRD・要件定義: 1~2ヶ月 • BIソリューション選定: 1~2ヶ月 • Looker社リードのもとPoC: 1ヶ月 • 実装: 2~3ヶ月 (Lookerのプロフェショナルサービス利用） PoC、実装はLookerチームの支援でスピード感持って進められた。感謝！
12. メンバー構成 全員兼務あり、限られたメンバー構成で無理なく進行 • PM: 1名 • デザイン: 1名 • フロント: 1名 • バックエンド: 1名 • SRE: 1名 ※業務委託含む
13. 全体構成 • データ基盤無い状態から最小構成で始めて データ規模に応じアーキテクチャを変更して いく方針 • バックエンド: Aurora MySQL ※Persistent Derived Table(PDT)の作成時 の負荷には注意 ※AuroraリードレプリカにはPDT対応してい ないので処理を逃したい場合は自前でレプ リケーションを組む必要がある • 一部の重い計算をS3 + AthenaでETL処理
14. MySQLバックエンド周りのLookML構成 • 最初1model/1connectionで複数環境に対応することを考えた • PDT Overridesに変数が埋め込めない仕様上、MySQLの物理ホストを環境別に 分ける構成と相性が良くない
15. MySQLバックエンド周りのLookML構成 • 変数埋め込みでの切り替えはあきらめ、複数connection設定にした。 が、modelのconnection設定を動的に切り替えられない • ベースとなるmodelファイルを用意し、環境ごとに書き換えて複製して対応
16. MySQLバックエンド周りのLookML構成 • modelファイルはGitHub Actionsで自動生成 • 開発環境用のmodelファイルを変更後masterにマージすると、他環境用の定 義が自動生成されたPRが作成されるようにしている
17. LookML開発フロー • Looker本番・開発インスタンス用に2リポジトリ構成
18. LookML開発フロー • GitHub Actionsを活用して運用自動化、安全にリリース • gitリポジトリでダッシュボード定義を管理できる利点が活躍
19. LookML開発フロー • Looker 7.20でmaster以外をデプロイ元ブランチに設定可能に 2リポジトリ構成は必要なくなりそう。やったぜ。 ※未検証
20. ダッシュボード開発フロー • LookMLで定義したダッシュボードは直接WebUIで編集できないため 自分の作業用ディレクトリにコピーして編集、gitに乗せる運用
21. ダッシュボード開発フロー • gzrでの設定同期はダッシュボードidをインスタンス間で合わせるのが困難と判断し 利用していない • 組み込み用のダッシュボードURLを番号でなく名前で定義したかった
22. ダッシュボード開発フロー • （とは言え手作業が多いのでAPIで自動化できないか検討中
23. ダッシュボード開発フロー • (ダッシュボード定義のdiffが大きくなりがちなのも対策検討中 elements以下の配列順序が不定のようで、 作成の都度順序が変わり、 大きなdiffが出て見づらい
24. これからの取組み • データ量増加に備えたデータ基盤の整備 S3をデータレイクにした構成への移行 • 独自Lookの開発 • リグレッションテスト ◦ データ ◦ ダッシュボードの見た目 • LookML管理外のLooker設定のコード化 (terraform等での管理を検討中)
25. まとめ • Looker採用によってScalebaseの分析機能を素早く立ち上げることができた • スタートアップにおいて人・時間の制約がある状況でも無理なく実現 • LookMLのおかげでダッシュボード定義もブラックボックス化しにくく運用面の不安 が少ない • Lookerが機能で対応していない設定部分もCIでの定義自動生成などである程度カ バーしてしまえるのもConfiguration as Codeの良さ • Lookerは社内BIだけでなく、プロダクトで顧客向けの分析機能を提供したい場合に もおすすめです
26. We’re hiring! • データの力で サブスクリプションビジネスの 世界を変えましょう • https://thealp.co.jp • https://herp.careers/v1/alpinc