SaaSをGoogle Marketplaceで売る

販売したいSaaS製品があるなら、Google Cloud Marketplaceは有力な販売チャネルになります。顧客はGoogleの請求書でまとめて支払えるため、購入のハードルが大きく下がります。

本記事は、Marketplaceソリューションを構築するエンジニア向けの概要ガイドです。MarketplaceではVMイメージやKubernetesコンテナも出品できますが、多くのベンダーが扱うのはSaaSなので、本稿でもそこに絞ります。網羅性や細部にはこだわらず、公式ドキュメントだけでは見えにくい、つまずきやすいポイントに絞って取り上げます。

製品を市場へ届ける

通常のGoogle Cloud Platformの利用では、公開されたクラウドAPIを呼び出すだけで済みます。一方、Marketplaceの販売者システムとの統合はこれとはまったく性質が異なり、エンタープライズ統合に近いものです。自社とGoogleの間のビジネス上の合意に沿って進められ、技術面では自社システムがGoogleのビジネスシステムと双方向・複数ステップのワークフローを構成します。コアGCPに比べると、ドキュメントや公開フォーラムから得られる情報も格段に少ないのが実情です。

統合作業に着手する前に、Googleからの承認を得る必要があります。承認が下りるまで、エンジニアリングチームは事実上手を止めて待つことになります。

承認を得るためには、自社のビジネス担当者がPartner Advantageプログラムを通じてGoogleとやり取りを進めます。通常、このプロセスには数週間かかります。DoiT Cloud Solveをご利用の場合は、当社のアカウントマネージャーがチームの伴走役となります。

このような承認プロセスがあるのは、Googleが品質を維持したいと考えているからです。数年前のGoogle Marketplaceは、ベンダーがGoogleシステムとの統合に手を付けず放置されたかのような出品が氾濫していました。現在では、Googleは出品を厳格に審査し、選び抜かれた高品質・大量取引のソリューションだけを受け入れています。

承認が下りたかどうかは、ソリューションを設定するProducer Portal( https://console.cloud.google.com/producer-portal?project=PROJECT_ID )にアクセスできるようになることで分かります。

承認後は、API呼び出しやProducer Portalの組み込み機能を使って、プレビュー、テスト、プライベートデプロイが行えるようになります。それまでは、アーキテクチャの学習で準備を進めましょう。ドキュメントを一読し、GitHubプロジェクトのDoiT-Easilyから学ぶことをおすすめします。

DoiT-Easilyは、統合の進め方を示すオープンソースプロジェクトです。DoiTから複数のコントリビューターが参加していますが、サポート対象の製品でも、本番投入できるフル機能のシステムでもありません。あくまで動作する統合実装の一例として、学習やフォークの土台にしていただくものです。DoiT-Easilyのドキュメントには分かりやすい概要があり、より上位の解説についてはこちらのブログ記事もご参照ください。

Procurement APIとの統合は必須ですが、Service Control(Usage)APIの利用は任意です。

Procurement APIは、ユーザーのサインアップとキャンセル、そしてエンタイトルメント(=ユーザーがサービスやサービスレベルを購入した際の利用権)を管理します。このAPIは、自社アプリケーションとGoogleのシステムの両方がエンタイトルメントを承認する必要のある複数ステップのフローで呼び出されます。詳細は後述します。

Service Control APIは、課金対象のリソースがどれだけ利用されたかをGoogleに報告し、顧客への請求につなげるために使います。たとえば、処理したメビバイト数、オンライン時間、API呼び出し回数などです。使用量を追跡しない料金プランも提供できるので、最小限の初期実装ではこのAPIを省略することもできます。

DoiT Marketplaceのアーキテクチャ図に各コンポーネントが整理されています。

Marketplace統合アーキテクチャ

統合の対象は、フロントエンドとバックエンドの両方のアプリケーションです。これらは専用のMarketplaceプロジェクトで稼働させますが、統合専用以外のクラウドコンポーネントは、このプロジェクトでも別プロジェクトでも構いません。Marketplaceの出品が複数ある場合は、いずれもこの同じ統合プロジェクトを使ってください。

フロントエンド

フロントエンドは、ユーザーがログイン・サインアップを行い、サービスのサブスクリプション(=「エンタイトルメント」)を購入できるようにする部分です。フロントエンドは自社のWebアプリで、見た目や使い心地は自社のものがそのまま反映されます。

ユーザーが登録ボタンをクリックすると、Google Marketplaceのページから、Marketplaceに登録済みの公開URL(=自社のフロントエンド)へ遷移します。このリクエストには、Googleが署名したJWTトークンが含まれており、その遷移が確かにGoogle Marketplace経由であることを認証できます。自社のフロントエンドのクライアント・サーバーアプリでユーザーを自社システムに登録したうえで、Procurement APIを介してGoogleに通知します。

バックエンド

ユーザーがGoogle MarketplaceのUIで料金プランを選択すると、GoogleがPub/Subにエンタイトルメントイベントを発行し、自社のバックエンドがそれを受信します。

そのうえで、このエンタイトルメント(購入)を承認するか却下するかを判断します。承認は即時・自動で行うこともできますし、人手による確認を挟むこともできます。承認に時間がかかる場合は、Procurement APIを呼び出してユーザーにステータスメッセージを送ります。判断が確定したら、バックエンドからProcurement APIを呼び出してエンタイトルメントを承認または却下します。

製品はいくつかの料金モデルで提供でき、選択したモデルによって統合の複雑さも変わります。無料提供や月額サブスクリプションで課金する場合は、使用量を報告する必要はありません。ストレージ時間、処理データ量、独自のカスタムメトリクスなど、使用量ベースで課金する場合は、それをService Control APIに報告するための統合を別途実装する必要があります。

プライベートオファーのみで販売するなら、フロントエンドの開発をスキップできます。プライベートオファーでは、ユーザーがGoogle Marketplaceサイト上でオファーを選ぶのではなく、特定の顧客向けに料金を個別に設定します。これにより、GoogleからのPub/Subメッセージを受けてバックエンドで直接アカウントを承認できるため、フロントエンド統合の一部が不要になります。ただし、プライベートオファーを提供する場合は少なくとも1つのパブリックオファーも併せて用意する必要があります(この要件はGoogleに免除を申請できます)。もう一つの課題は、プライベートオファーを作成・提示するための仕組み(多くの場合は社内Webアプリ)を自前で用意する必要があることです。

さらに自動承認(プライベートオファー専用の機能)を有効にすれば、バックエンドの開発もほぼ不要になります。

Googleと自社という2社・2つのプロジェクトが関わるため、双方向で権限を付与する必要があります。

自社のサービスアカウント

まず自社のプロジェクトでサービスアカウントを作成します。製品定義の一部としてProducer Portalにそのサービスアカウントを登録し、Procurement APIの呼び出しと、Googleから送られてくるエンタイトルメントイベントのCloud Pub/Subサブスクライブを許可します。

ソリューションをデプロイするユーザーは、serviceAccountTokenCreatorを使ってこのサービスアカウントになりすませる(代理実行できる)必要があります。

Googleのサービスアカウント

自社プロジェクトのIAMで、Googleのサービスアカウントがプロジェクトにアクセスできるようロールを付与します。本番用に3つ( 詳細はこちら)、テスト用に1つ(こちらを参照)が必要です。

統合の開発とテストが完了した後も、リリース前にGoogleによるレビューを受ける必要があるため、そのための時間も見込んでおきましょう。