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.
   

   View Slide

2. 自己紹介
   ● Naoki Ainoya
   ● SRE @ Alp, Inc.
   ● Scalebaseの開発・運用
   

   View Slide

3. 本日お話すること
   Scalebaseに分析機能を実装するにあたり…
   ● Lookerの選定理由
   ● 組み込みAnalyticsの実装方式と構成
   ● 実運用・開発フロー
   

   View Slide

4. サブスクリプションビジネス効率化・収益
   最大化プラットフォーム
   

   View Slide

5. Scalebaseが対象とするビジネスモデル
   

   View Slide

6. 契約・請求・分析のオペレーションを一気通貫で管理
   SFAや会計システムと連携し、シームレスなオペレーションを実現
   

   View Slide

7. 契約・請求・分析のオペレーションを一気通貫で管理
   SFAや会計システムと連携し、シームレスなオペレーションを実現
   

   View Slide

8. Scalebaseの分析機能
   ● Scalebase内のデータを
   リアルタイムに可視化する
   分析ダッシュボードを提供
   ● Looker組み込みアナリティクス
   (Embed SSO)で
   Scalebaseサービス内に埋め込み
   顧客に展開
   

   View Slide

9. Lookerを採用した理由
   Scalebaseへの分析機能実装にあたっての条件
   ● 人的・時間的リソースが限られている状況で、素早く立ち上げること
   ● 急激なサービスの成長にも耐えられる作りになっていること
   

   View Slide

10. Lookerを採用した理由
    サービスに組み込み可能なBIソリューションをいくつか検証し、Lookerを採用
    ● リソースが限られている状況で、素早く立ち上げること
    →LookMLの高い表現力・開発のしやすさ
    →Embed SSOによる組み込みとダッシュボード開発の容易さ
    ● 急激なサービスの成長にも耐えられる作りになっていること
    →Looker自体がパフォーマンスのボトルネックになりづらいアーキテクチャ
    →負荷に応じてデータウェアハウスのアーキテクチャを将来変更して捌ける
    （小さく始められ、かつ処理が重くなってもこちらで対応でき、手詰まりとならない）
    

    View Slide

11. 結果として：リリースまでのタイムライン
    おかげさまで機能検討開始からリリースまで半年程度で完了
    ● PRD・要件定義: 1~2ヶ月
    ● BIソリューション選定: 1~2ヶ月
    ● Looker社リードのもとPoC: 1ヶ月
    ● 実装: 2~3ヶ月 (Lookerのプロフェショナルサービス利用）
    PoC、実装はLookerチームの支援でスピード感持って進められた。感謝！
    

    View Slide

12. メンバー構成
    全員兼務あり、限られたメンバー構成で無理なく進行
    ● PM: 1名
    ● デザイン: 1名
    ● フロント: 1名
    ● バックエンド: 1名
    ● SRE: 1名
    ※業務委託含む
    

    View Slide

13. 全体構成
    ● データ基盤無い状態から最小構成で始めて
    データ規模に応じアーキテクチャを変更して
    いく方針
    ● バックエンド: Aurora MySQL
    ※Persistent Derived Table(PDT)の作成時
    の負荷には注意
    ※AuroraリードレプリカにはPDT対応してい
    ないので処理を逃したい場合は自前でレプ
    リケーションを組む必要がある
    ● 一部の重い計算をS3 + AthenaでETL処理
    

    View Slide

14. MySQLバックエンド周りのLookML構成
    ● 最初1model/1connectionで複数環境に対応することを考えた
    ● PDT Overridesに変数が埋め込めない仕様上、MySQLの物理ホストを環境別に
    分ける構成と相性が良くない
    

    View Slide

15. MySQLバックエンド周りのLookML構成
    ● 変数埋め込みでの切り替えはあきらめ、複数connection設定にした。
    が、modelのconnection設定を動的に切り替えられない
    ● ベースとなるmodelファイルを用意し、環境ごとに書き換えて複製して対応
    

    View Slide

16. MySQLバックエンド周りのLookML構成
    ● modelファイルはGitHub Actionsで自動生成
    ● 開発環境用のmodelファイルを変更後masterにマージすると、他環境用の定
    義が自動生成されたPRが作成されるようにしている
    

    View Slide

17. LookML開発フロー
    ● Looker本番・開発インスタンス用に2リポジトリ構成
    

    View Slide

18. LookML開発フロー
    ● GitHub Actionsを活用して運用自動化、安全にリリース
    ● gitリポジトリでダッシュボード定義を管理できる利点が活躍
    

    View Slide

19. LookML開発フロー
    ● Looker 7.20でmaster以外をデプロイ元ブランチに設定可能に
    2リポジトリ構成は必要なくなりそう。やったぜ。
    ※未検証
    

    View Slide

20. ダッシュボード開発フロー
    ● LookMLで定義したダッシュボードは直接WebUIで編集できないため
    自分の作業用ディレクトリにコピーして編集、gitに乗せる運用
    

    View Slide

21. ダッシュボード開発フロー
    ● gzrでの設定同期はダッシュボードidをインスタンス間で合わせるのが困難と判断し
    利用していない
    ● 組み込み用のダッシュボードURLを番号でなく名前で定義したかった
    

    View Slide

22. ダッシュボード開発フロー
    ● （とは言え手作業が多いのでAPIで自動化できないか検討中
    

    View Slide

23. ダッシュボード開発フロー
    ● (ダッシュボード定義のdiffが大きくなりがちなのも対策検討中
    elements以下の配列順序が不定のようで、
    作成の都度順序が変わり、
    大きなdiffが出て見づらい
    

    View Slide

24. これからの取組み
    ● データ量増加に備えたデータ基盤の整備
    S3をデータレイクにした構成への移行
    ● 独自Lookの開発
    ● リグレッションテスト
    ○ データ
    ○ ダッシュボードの見た目
    ● LookML管理外のLooker設定のコード化
    (terraform等での管理を検討中)
    

    View Slide

25. まとめ
    ● Looker採用によってScalebaseの分析機能を素早く立ち上げることができた
    ● スタートアップにおいて人・時間の制約がある状況でも無理なく実現
    ● LookMLのおかげでダッシュボード定義もブラックボックス化しにくく運用面の不安
    が少ない
    ● Lookerが機能で対応していない設定部分もCIでの定義自動生成などである程度カ
    バーしてしまえるのもConfiguration as Codeの良さ
    ● Lookerは社内BIだけでなく、プロダクトで顧客向けの分析機能を提供したい場合に
    もおすすめです
    

    View Slide

26. We’re hiring!
    ● データの力で
    サブスクリプションビジネスの
    世界を変えましょう
    ● https://thealp.co.jp
    ● https://herp.careers/v1/alpinc
    

    View Slide