データベース

Kochava のモバイル分析プラットフォームを強化した Cloud Spanner

2023年3月23日

Google Cloud Japan Team

※この投稿は米国時間 2023 年 3 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

Kochava は、データドリブンなマーケターやパブリッシャーに先進的なオムニチャネル測定ソリューションやアトリビューションソリューションを提供するリアルタイムデータ企業です。

お客様情報、測定、データ管理をシームレスに統合および管理するプラットフォーム、Marketers Operating System™（m/OS）によって、マーケターに実用的なデータをもたらします。すべてのデータと重要なオムニチャネルソリューションをオペレーションシステム内の 1 か所で俯瞰できるため、単なるデータ集計やとレポート以上の機能を果たします。m/OS は、データを利用しやすく実用的なものにして投資収益率の最大化を図ることで、成功を促進するよう設計されています。

Kochava は、マーケターが必要とするときに必要なものを提供し、プライバシー最優先の世界でお客様の特徴とセグメントの特定を可能にしてオーディエンスを活性化します。

Kochava が Cloud Spanner を利用するようになった経緯

Kochava が擁するお客様は数千社に上ります。その中には、1 社で毎分数百万回のクリックとインプレッションを処理するお客様も存在します。広告シグナルの種類、お客様の種類、使われている特定のプロダクトに応じて、そうしたデータは、オンプレミスの MySQL、または垂直方向にスケールされたレガシーシステム内の Aerospike のクラスタで処理および保存されていました。使用するシステムによってお客様が利用できる機能が異なるため、お客様のユーザーエクスペリエンスには一貫性がありませんでした。レガシーデータベースはピーク時のシステムパフォーマンスにおいてボトルネックを生み出しており、簡単にはスケールアウトできませんでした。当社は、開発中のものを含むさまざまな分野の機能を利用しやすくし、スケーリングによってリアルタイムの処理要件を満たせる、単一の統合ソリューションを必要としていました。そして、Cloud Spanner を選択しました。

アーキテクチャ

マルチテナントアカウント作成フロー

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_Kovacha_mobile.max-2000x2000.jpg

Kochava では、お客様のデータをそれぞれ固有のデータベースに保存する必要があります。これを実現するため、Kochava のお客様アカウントをプロビジョニングする際、自動的に Spanner リソースを作成します。アカウントが作成されると、データベース 1 つ分のスペースがある既存の Spanner インスタンスを探します。存在しない場合は、新しい Spanner インスタンスを作成します。新しい Spanner インスタンスを作成する際は、自動スケーリングするリソースと、データベースにアクセスするためのアカウント固有のサービスアカウントも作成します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_Kovacha_mobile.max-1100x1100.jpg

アカウントと対応する Spanner リソースが作成されたら、データを取り込んで処理します。広告シグナルデータはアカウントごとにリアルタイムで処理され、リアルタイムアトリビューション用とレポート用としてそれぞれ Cloud Spanner と BigQuery に保存されます。イベントアトリビューションのためにリアルタイムの広告シグナルデータを確認する必要がある他のシステムは、Cloud Spanner で Ads Storage API を使用してリアルタイムで読み取りを行います。

Cloud Spanner を選ぶメリット

データベースの統合

これまで、広告シグナルデータは MySQL、Aerospike、Spanner に保存されていました。各ストレージエンジンには、固有のスキーマ、管理機能、アプリケーションがあります。すべてのリアルタイムアクセスストレージを Spanner に統合することで、これらの各領域を簡素化しました。関連するシステムが少ないため、オンコールやトレーニングの際に特に有効です。この統合により、複数のシステムにまたがるプロダクト機能の保守や開発に要する時間が大幅に短縮されました。

実環境で試されたパフォーマンス

調査の一環で、（今後の広告シグナルシステムの移行プロジェクトとして）スループットやアクセスパターンが似ているリリース予定のプロダクトをデータベース候補のテストベッドとして使用しました。さまざまなデータベースを試したところ、Spanner が最も実装が容易で、最良のパフォーマンスと優れたマネージドサービスを提供していました。このプロジェクトを立ち上げ、2 年間本番環境で運用してきた私たちは、このテクノロジーは大規模な移行プロジェクトに必要なものを提供してくれるものと確信し、信頼しています。

パフォーマンステストには、費用を抑えるためのスケールアップとスケールダウンを行うと同時に、複数のシステムにまたがるすべてのデータ処理パイプラインにおいて、ダウンタイムを発生させることなくリアルタイムで低いレイテンシと高いスループットを維持するというものも含まれました。これらすべてを実現し、ACID 特性を備えている Spanner なら、信頼してデータを保存できます。

SQL

当社は、多種多様なデータベースに MySQL を使用しています。社内の開発者は SQL の書き方を知っていますし、私たちが直接移行しようとしているデータベースの一つは MySQL ベースです。すでによく知っている使い慣れたクエリ言語を使用できることは、開発者の生産性を向上させます。たとえば Aerospike の場合、Aerospike の社内エキスパートからチームの他のメンバーに指導してもらう必要がありました。Cloud Spanner は ANSI-SQL に準拠しているため、開発者は各自で対応できます。

フルマネージド

お客様の数が増えるにつれ、個々のお客様のトラフィックが予測不可能なこともあって、当社はレガシーデータベースのスケーラビリティの問題に直面しました。緊急に新しいクラスタをスピンアップしたり、ダウンタイムなしで既存のクラスタを増強したりしなければならないこともありました。そのためにオペレーションエンジニアがデータセンターに出向き、データベース管理者がデータベースクラスタの交換やデータの移行を定期的に行っていました。今では、新しい Spanner インスタンスが必要な場合は、Terraform を使って作成するだけです。Spanner インスタンスは、使用するノード数を構成して水平方向にスケールできます。このスケーリングは、Spanner 用のオートスケーラーを使用することで、負荷に応じて動的に行うことができます。オートスケーラーを利用することにより、ワークロードのニーズを綿密に把握して費用を最適化できるようになり、ピーク負荷に対応したプロビジョニングを常に行う必要がなくなりました。その結果、使用量の少ない時間帯の消費量を 30% 削減できました。レガシーデータベースがスケーラビリティの限界に達して慌てることがなくなり、データベースを使ってアプリケーションを構築することにエネルギーを集中させられるようになりました。

エンタープライズグレードの機能

Spanner は、有効期間（TTL）のようなエンタープライズグレードの機能を多数サポートしています。TTL を使用すると、特定のしきい値より古いデータは自動的にテーブルから削除されます。これにより、テーブルを小さくしてストレージ費用を抑えるために、削除可能なデータを 1 行ずつチェックするバックグラウンドプログラムを実行する必要がなくなりました。