Looker BEACON 2021 / How we implemented Scalebase Analytics with Looker

Looker BEACON 2021 / Looker組み込みアナリティクスによるScalebase分析機能の展開

Transcript

1. Looker組み込みアナリティクスによる
   Scalebase分析機能の展開
   BEACON Japan 2021
   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を採用した理由
   サービスに組み込み可能なBIソリューションをいくつか検証し、Lookerを採用
   検討時の要件:
   ● 人・時間のリソースが限られている状況で、素早く立ち上げること
   ● 急激なサービスの成長にも耐えられる作りになっていること
   

   View Slide

10. Lookerを採用した理由
    検討時の要件:
    ● 人・時間のリソースが限られている状況で、MVP(Minimum Viable Product)を素早
    く立ち上げ、改善できること
    ● Developer Experienceが重要
    →LookMLの高い表現力・開発のしやすさ
    　定義のGit管理ができ、変更管理・レビュー・リリース管理がしやすい
    →Embed SSOによる組み込みとダッシュボード開発の容易さ
    

    View Slide

11. Lookerを採用した理由
    検討時の要件:
    ● 急激なサービスの成長にも耐えられる作りになっていること
    →Looker自体がパフォーマンスのボトルネックになりづらいアーキテクチャ
    →負荷に応じてデータウェアハウスのアーキテクチャを将来変更して捌ける
    （小さく始められ、かつ処理が重くなってもこちらで対応でき、手詰まりとならない）
    

    View Slide

12. 他BIツールの検討時に問題になったこと
    ● 自社サービスへの組み込み方法
    ● ユーザーアカウントのプロビジョニング方法
    

    View Slide

13. 組み込みのしやすさ
    ● シンプルな機構で実装が容易だった
    

    View Slide

14. 組み込みのしやすさ
    ①組み込みURL生成リクエスト
    

    View Slide

15. 組み込みのしやすさ
    ①ダッシュボードURL
    生成リクエスト
    ②サーバサイドでダッシュボードURL生成、API
    キーで署名
    (事前にLookerからAPIキーを取得)
    

    View Slide

16. 組み込みのしやすさ
    ②サーバサイドでダッシュボードURL生成、API
    キーで署名
    (事前にLookerからAPIキーを取得)
    ● URL生成時に、Lookerへのアクセス権限やLookerダッ
    シュボードで使用するユーザ属性(ユーザIDなど)をパラ
    メータとして付与して生成
    ● 生成URLをAPIキーで署名するため
    第三者が不正に生成・改ざんすることは困難
    ● APIキーは事前に取得して使用するため、URL生成の
    都度Lookerに問い合わせる必要が無いので楽
    

    View Slide

17. 組み込みのしやすさ
    ①ダッシュボードURL
    生成リクエスト
    ②サーバサイドでダッシュボードURL生成、API
    キーで署名
    (事前にLookerからAPIキーを取得)
    ③生成されたURLでLooker
    ダッシュボードをiframe呼び
    出し
    

    View Slide

18. ユーザアカウントのプロビジョニング方法
    ● アカウントの発行
    ● BIサービス側と自社サービス側のアカウントの同期
    

    View Slide

19. ユーザアカウントのプロビジョニング方法
    ③生成されたURLでLooker
    ダッシュボードをiframe呼び
    出し
    このとき、Looker側にユーザーアカウントが
    自動作成される
    ScalebaseサーバからLookerに対して都度ア
    カウント発行処理等は必要無い
    

    View Slide

20. ユーザアカウントのプロビジョニング方法
    ③生成されたURLでLooker
    ダッシュボードをiframe呼び
    出し
    このとき、Looker側にユーザーアカウントが
    自動作成される
    ScalebaseサーバからLookerに対して都度ア
    カウント発行処理等は必要無い
    事前のアカウント
    払い出し処理が不要
    

    View Slide

21. まとめ:Lookerを組込み分析で使用するメリット
    ● スケーラビリティのあるアーキテクチャ
    ● LookMLによるダッシュボード、データモデルのメンテナンス容易性
    ● 組込み実装のしやすさ
    ● ユーザアカウントのプロビジョニングが楽
    その結果・・・
    

    View Slide

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

    View Slide

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

    View Slide

24. 全体構成・開発フロー
    ● Lookerと接続するデータインフラの構成
    ● LookMLダッシュボード・データモデルの開発フロー
    

    View Slide

25. 全体構成
    ● データ基盤無い状態から最小構成で始める
    ● データ規模に応じアーキテクチャを変更して
    いく方針
    ● LookerからAurora MySQLを直接参照する
    構成
    ○ リアルタイム性を重視
    

    View Slide

26. 重い集計の逃し方
    ● MySQLでは重すぎる処理が出てきたら、S3
    とAthenaで集計する処理で補助
    

    View Slide

27. 重い集計の逃し方
    ● LookerのPersistent Derived Table(PDT)機
    能を使って重い集計処理は一時テーブルに
    キャッシュ可能
    ● 簡単なETLならLookerだけで実現可能
    

    View Slide

28. データ規模に応じたなめらかな拡張
    ● データ規模に応じアーキテクチャを変更
    ● LookerからMySQLへの参照をやめる
    ● AWS Athena + Federated Queryによって
    データ同期の遅延を損なうことなく切り替え
    ● LookMLに大規模な変更をせずに無停止で
    変更を実現
    

    View Slide

29. LookML開発フロー
    ● Lookerのエディタ上で編集し、Lookerインスタンスに反映するフロー
    ● 素早く開発できるようにする
    ● かつ、安全なリリースを行えるようにする必要がある
    →Git連携を生かしてGitHub上でCI/CDを構築して開発・運用
    

    View Slide

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

    View Slide

31. LookML開発フロー
    ● GitHub Actionsを活用して運用自動化、安全にリリース
    ● gitリポジトリでダッシュボード定義を管理できる利点が活躍
    ※Looker 7.20からデプロイ元ブランチを選択可能になったため、現在は1リポジトリで実現可能
    

    View Slide

32. 補足: デザイン面
    ダッシュボードのデザインをLooker上でどう表現するか
    ● LookerのビルトインのVisualizationを利用する場合は、
    見た目のカスタマイズある程度できるが、妥協は必要
    ● ただ、拡張の余地は多いにある
    

    View Slide

33. デザイン面: 独自Visualizationによる拡張
    ● Custom Visualizationを使用してタイル部分を自前で実装可能
    ● 実際にmultiple_valueのコードをフォークしてデザインを
    少し変えて使用している
    

    View Slide

34. デザイン面: API・SDKによる拡張
    ● API/SDKを使用してiframe呼び出しをやめて完全に自前デザインにすることも可能
    ● 実際にフィルタ部分をiframe外で自前実装している
    iframe
    iframe外の実装
    

    View Slide

35. リリース後の反響
    ● 多くのフィードバックをいただいた
    ● 可視化に対するニーズは多様
    ● 様々な可視化の切り口がある(経理担当者・事業企画者・経営者etc..)
    ● まだまだこれからだが、要望に応える分析機能を提供していく
    ○ 入金状況・コホート・レイヤーケーキチャートなど続々と対応している
    ● 一般的なSaaS開発と同様、顧客の声に耳を傾けひたすら改善あるのみ
    

    View Slide

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

    View Slide

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

    View Slide