この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
この記事は、2021年6月22～23日開催の Looker BEACON 2021: Japan のオンラインセッション『Looker組み込みアナリティクスによるScalebase分析機能の展開』に関するセッションレポートです。
セッション概要
Scalebase（スケールベース）は、サブスクリプションビジネスの効率化・収益最大化プラットフォームです。本プロダクトではお客様のビジネスメトリクスの可視化・分析機能の実現のために、Looker組み込みアナリティクスを使用しました。本講演では、Lookerをソリューションとして選択した背景や、Looker導入後の変化や成果についてお話いたします。
登壇者
アルプ株式会社
開発部 チーフアーキテクト
相野谷 直樹 氏
アルプ社の提供するScalebaseというサービスの開発・運用をSREとして携わっていらっしゃいます。
サービス概要
Scalebaseとは？
アルプ社が提供するScalebaseというプロダクトは、サブスクリプションビジネス・SaaSなど、定期的な契約・請求を管理する必要がある企業向けのSaaSです。
多くのBtoBサービスでは、顧客ごとに異なる料金・値引きや決済手段が発生するケースがよくあり、契約管理や請求業務の煩雑化、また来月の売り上げ見込みの計算に多くの労力が必要となってしまいます。
上記課題に対してScalebaseでは、サブスクリプションサービスにおける複雑な契約・請求・分析のオペレーションを一括管理できるプラットフォームを提供しています。
Scalebaseの提供する分析機能
Scalebase内に顧客・契約・請求データを一元管理して持っているため、それらを横断して分析・可視化のできる機能を提供しており、この分析機能をLookerの組み込みアナリティクスで実装しています。
Lookerの組み込みアナリティクス
選定理由
Scalebaseでは組み込みが可能なBIツールを複数比較した結果、Lookerを採用しました。
採用にあたっての主な要件は以下の二つでした：
- 人・時間のリソースが限られている状況で素早く立ち上げられること
- 急激なサービスの成長にも耐えられる作りになっていること
開発生産性の高さ
LookerがSQLベースではなくLookMLという開発言語でダッシュボードやデータモデルを構築できる点は、限られた時間の中でMVP（Minimun Viable Produbt）を立ち上げ→改善を高速で回したかったSREである相野谷さんにとって、要件に非常にマッチしたものでした。
さらに、LookMLをGitで変更管理ができる点は、リリース後の運用保守コストの心配を軽減できたとして安心できた点でした。
ScalebaseのプラットフォームにLookerのダッシュボードを組み込むという要件に対して、簡単に実装できる点も評価のポイントでした。
スケーラビリティ（拡張性）
スタートアップの事業の立ち上げフェーズにいるScalebaseでは、今後のサービスの急成長を見据え、BIツールがパフォーマンスのボトルネックになってしまうことが懸念点としてありました。
その点、Lookerはデータを持たずデータベースに直接接続する仕組みのため、パフォーマンスはデータベースに依るところが大きく、状況に応じてデータウェアハウスのアーキテクチャを変更すればスケールできる点が安心材料となりました。
Looker組み込みアナリティクス
BIツール選定時にあった主な要件の他にも、下記二点においてもLookerの組み込みアナリティクスに優位性があったそうです。
- 自社サービスへの組み込み方法
- ユーザーアカウントのプロビジョニング方法
Lookerの組み込みアナリティクスの実装がいかにシンプルであるかを、実装の手順とともにご紹介します。
シンプルな実装
手順1. 組み込みURLをリクエスト
手順2. リクエストされたURLをScalebaseで生成する
ユーザーがScalebaseの分析画面を開くと、ダッシュボードのURLのリクエストを出します。Scalebaseサーバーはリクエストに応じてワンタイムのURLを払い出します。このURLは、あらかじめLookerで生成したAPIキー（秘密鍵）で署名をするため、安全性が確保されています。
また、URL生成の実装段階で、Lookerにおける外部ユーザーの権限やアクセスできるモデルなどの設定も盛り込んでいるため、組み込まれたコンテンツで外部ユーザーが許可されたもの以外のデータにアクセスをしたり、行動を取ったりすることはできません。
APIキーは事前にLooker側で生成してしまうので、URL生成のたびにLookerに問い合わせる必要がなく、アプリケーション側の実装コストが低く抑えられます。
手順3. 生成されたURLでブラウザがLookerのダッシュボードを呼び出す
手順2で払い出されたURLを利用して、ブラウザはiframeを利用してLookerのダッシュボードを表示します。
以上の通り、フロントエンド・バックエンドともにシンプルな実装でダッシュボードを組み込むことができる点がLooker採用のポイントになりました。
ユーザーのプロビジョニング
ScalebaseからLookerダッシュボードを見る外部ユーザーのLooker側のユーザーアカウントは上記手順3のiframeからのURL呼び出しのタイミングでLookerが自動生成します。
Scalebase側で事前にLookerにユーザー払い出し処理をする必要はありません。
選定開始からリリースまで
タイムライン
Lookerを選定してから1ヶ月間のPoC後、2〜3ヶ月の実装期間を経てリリースできました。
メンバー
- PM：1人
- デザイン：1人
- フロント：1人
- バックエンド：1人
- SRE：1人
全員兼務ありの少数精鋭チームでも、短期間で開発を進めリリースまで持っていくことができました。
全体構成・開発フロー
全体構成 - リリース直後
最初はデータ基盤がなく、データ規模も大きくなかったためLookerにAmazon Auroraを接続して利用を開始しました。
Auroraでは重たい集計計算が出てきたので、S3とAthenaを利用して集計したものをAuroraに再度入れて回避しました。
簡単なデータ整形の場合にはPDT（永続派生テーブル）も利用しました。
全体構成 - サービスの成長
Lookerの接続をAmazon Athenaに切り替えパフォーマンスを維持しながら、Federated Queryを利用してAurora上にある新しいデータを取り込めるようにしました。
Aurora → Athenaへの切り替えの際にLookMLの更新でかかった工数は、PDTの書き換えと接続情報の変更のみで、大きなものにはなりませんでした。
開発フロー
LookMLの開発は、Lookerの開発IDEを利用しました。また、LookerはGit連携をしてバージョン管理を行うため、GitHub上でCI/CDを構築して安全なリリースを行える環境を整えました。
具体的には、Lookerインスタンスを本番用と開発用の2つ用意し、それぞれのプロジェクトにgitリポジトリを用意しました。
2つのリポジトリの同期やリリース前のプロセスはGitHub Actionsを活用して運用の自動化をしているため、リリースプロセスに人手が入らない仕組みを実現しました。
デザイン
Lookerに元々ある可視化を利用する場合、ある程度はカスタマイズができますが妥協が必要な場面があります。しかし、ユーザー側で拡張できる余地があるため以下にScalebaseで行った拡張をご紹介します。
カスタムビジュアリゼーション
Lookerのマーケットプレイスで提供しているプラグインを入れることで、ビルトインの可視化以外も使用することができます。
上図は、Multiple Valuesというプラグインに手を加えてものです。
API・SDKによる拡張
JavaScriptでの開発が必要になりますが、iframeでLookerダッシュボードを表示する以外にも、Lookerの用意している豊富なAPIとSDKによって完全に自前のダッシュボードを実装することもできます。
Scalebaseでは、月と日の絞り込みやカレンダーによる日付範囲の指定をする部分に、独自デザインを組み込んでいます。
最初はミニマムにLookerのダッシュボードでリリースした後に、少しづつデザイン面を自分たちのデザインコンセプトに合った形で独自の可視化に切り替えていくことをお勧めします。
リリース後の反響
リリース後には多くのお客様から反響をいただきました。
可視化のニーズは多様で、経理・事業企画・経営者など可視化の切り口もさまざまであることを再確認し、要望に応えるべく新たな分析機能の提供を進めています。
まとめ
Sczlebaseの開発者の視点から見たLookerの利点がまとめられていたセッションでした。
Lookerの組み込みアナリティクスの実装が非常にシンプルで済む以外にも、Lookerと他ツールを連携をしたり、機能拡張ができたりと細部までカスタマイズが可能なLookerの柔軟性を知ることのできるセッションでした。
社外に向けてデータを提供したいとお考えの方には最高に参考になるセッションだったのではないでしょうか？
以上、最後までお読みいただきありがとうございました。
3
