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

Scalebase Analytics powered by Looker

E32fe793290d1e72b0a78648da9c687b?s=47 Naoki Ainoya
December 07, 2020

Scalebase Analytics powered by Looker

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

E32fe793290d1e72b0a78648da9c687b?s=128

Naoki Ainoya

December 07, 2020
Tweet

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