「ScalebaseにおけるLooker 組込みアナリティクスを活用した顧客向け分析サービスの展開」 Year End Looker Meetup 2020 発表資料 https://discover.looker.com/2020yearendmeetup_ja.html
ScalebaseにおけるLooker組み込みアナリティクスを活用した分析サービスの展開2020/12/07Year End Looker Meetup 2020Naoki Ainoya / Alp, Inc.
View Slide
自己紹介● Naoki Ainoya● SRE @ Alp, Inc.● Scalebaseの開発・運用
本日お話することScalebaseに分析機能を実装するにあたり…● Lookerの選定理由● 組み込みAnalyticsの実装方式と構成● 実運用・開発フロー
サブスクリプションビジネス効率化・収益最大化プラットフォーム
Scalebaseが対象とするビジネスモデル
契約・請求・分析のオペレーションを一気通貫で管理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