Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Scalebase Analytics powered by Looker

Naoki Ainoya
December 07, 2020

Scalebase Analytics powered by Looker

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

Naoki Ainoya

December 07, 2020
Tweet

More Decks by Naoki Ainoya

Other Decks in Technology

Transcript

  1. Scalebaseにおける
    Looker組み込みアナリティクスを活用した
    分析サービスの展開
    2020/12/07
    Year End Looker Meetup 2020
    Naoki Ainoya / Alp, Inc.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide