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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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