Wunderkind 社が Google Cloud を使用して毎秒 20 万件までリクエストをスケールアップした方法

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

編集者注: マーテック プロバイダである Wunderkind 社が、複数のユースケースにおいて Cloud Bigtable と他の Google Cloud データ ソリューションを使用して、顧客増加に伴い拡大していく需要に容易に対応した方法についてお話を伺いました。

Wunderkind はパフォーマンス マーケティング チャネルであり、主に 2 種類のお客様を抱えています。1 つはオンライン小売業、もう 1 つはギズモード メディア グループ、リーダーズ ダイジェスト、ニューヨーク ポストなどのニュース メディアです。小売業のお客様にはメール、SMS、オンサイト、広告向けに設計されたリアルタイム メッセージ ソリューションを提供し、e コマースの収益増加をお手伝いしています。ブランドはより多くの顧客に 1 対 1 の体験を提供したいと考えています。当社はメール マーケティングとテクノロジーのベスト プラクティスを備えた豊富な経験を活かして、ブランドがターゲットを絞ったメッセージとパーソナライズされたショッピング体験を通じてより多くの顧客にリーチできるよう手助けします。ニュース メディアのお客様には、異なる価値を提案します。同じプラットフォームを使用して、ニュース メディアのウェブサイト向けに途絶えることのないパーソナライズド広告体験を提供します。たとえば、以前ニュース メディアのサイトを訪れたユーザーが再度訪れたときに、（キャンペーンに応じて）ユーザーに合わせた広告を表示できます。

従来のデータベース システムの限界に達したところで、当社は Cloud Bigtable と Google Cloud に移行しました。これにより、高いトラフィックの需要に対してより柔軟かつ容易にスケールすることができました。毎秒 4 万件のリクエストが安定して可能になり、増え続けるデータ ユースケースのニーズを満たすことができます。

3 つの異なるデータベースが主力サービスを強化

当社が提供する主力サービスでは、各企業が自社サイトから当社にユーザー イベントを送信します。これらのイベントを保管し、その後、お客様に代わってユーザーにアプローチするか、その方法はどうするかを（独自のノウハウにより）決めます。小売業のお客様が多くいらっしゃるので、ブラック フライデーやサイバー マンデーは当社にとってもトラフィックが多い日になります。このような日には 310 億件のイベントが発生し、毎秒 20 万件ものイベントを受信することもあります。16 億回のインプレッションがあり、ページビューは 10 億回近くに達します。最終的には、約 1 億通のメールを安全に送信しています。選挙期間中にも同様に、トラフィック量が同程度に達することがわかっています。当社は、このレベルのトラフィックをサポートするスケーラブルなソリューションと、使用した分だけ支払うことができる柔軟性を必要としていました。そこで採用したのが Google Cloud です。

では、その仕組みについて説明します。Google Kubernetes Engine 上で実行される当社の外部向け API が、最高で毎秒数十万件のユーザー イベントを受信します。アーキテクチャのすべてのコンポーネントで、これだけの量を処理できる能力が必要です。イベントは、これらの API から Pub/Sub、Dataflow に移動し、そこから Bigtable と BigQuery（Google Cloud のサーバーレスで高度にスケーラブルなデータ ウェアハウス）に書き込まれます。このビジネス ユーザー アクティビティ データは、当社のほぼすべてのサービスの基盤となります。イベントには、商品の閲覧やショッピング カートへの追加などがあり、Bigtable にこのデータを保管する際には、メールアドレスとお客様 ID を Bigtable キーとして使用してイベントの詳細をレコードに記録します。

次に、この情報をどのように取り扱うかです。重要なことは、Memorystore for Redis（Google Cloud のフルマネージド Redis サービス）にユーザーに関するイベントを最後に受信した時刻もマークすることです。これは、別のサービスで Memorystore を定期的にチェックして、キャンペーンごとに一定の期間（たとえば 30 分間）アクティブでないユーザーがいないか確認したうえで、ユーザーにアプローチするかどうかを決定しているためです。

このアプローチするタイミングは、チャネル、メッセージ、商品などに基づいて決定されており、当社のサービスにおけるインテリジェンスを必要とする部分です。Memorystore for Redis は、アプローチの際のレート制限やトークン バケットとして使用されています。API リクエストの送信先となるメールやテキスト メッセージのプロバイダに、リクエストが過剰に送られないように Memorystore を使用して制御します（後でエラーを処理するのではなく、送信する API リクエストを事前にスロットリングする方法を取っています）。

アプローチの際には、特定の商品の詳細が必要になることがよくあります。たとえば、小売店のウェブサイトの場合、通常はさまざまなチャネルを通して小売店からその情報を入手し、Cloud SQL for MySQL に商品情報を保管します。メールに商品情報を掲載して送信する必要がある場合に、その情報を引き出します。商品の多くは繰り返し呼び出されるので、Memorystore for Redis を使用してその情報をキャッシュに保存しておきます。当社の Cloud SQL インスタンスは 16 台の vCPU、60 GB のメモリ、0.5 TB のディスク容量を備えており、商品情報を更新する際には、毎秒約 1,000 回の書き込みトランザクションが発生します。さらに、セルフ マネージド型の MySQL インスタンスから一部のテーブルを移行中であり、Datastream を使用してそれらのテーブルを Cloud SQL と継続的に同期しています。

当社ではもともと AWS DynamoDB にユーザー履歴データベースを保管していたのですが、データの構築方法に関連して問題が起こりホットシャードが頻繁に発生しました。しかし、その原因や経緯を特定することができず、Bigtable に移行することにしたのです。移行のセットアップ時には、まず Pub/Sub から 2 つの場所にデータを書き込むようにしました。稼働開始までの間にデータのバックフィルを行ったうえで、読み込み作業を開始しました。これらの作業を数か月足らずで行い、すべてを Bigtable に切り替えました。

先に述べたように、今では複数のデータベースを対象に Bigtable を使用しており、ユーザー イベントを保管するインスタンスは約 50 ノードで 30 TB 近くに達しています。

プロファイルの管理

Bigtable の 2 つ目のユースケースは、ユーザー プロファイル管理です。たとえばサブスクリプション アクティビティに基づいたユーザー属性や、さまざまなリストに対しオプトイン / オプトアウトのどちらを選択しているかをトラッキングし、ユーザーにどのターゲティング メールを送信するかを決定するリストごとのルールをどのように適用するか、といった管理を行います。

独自の短縮 URL

Bigtable の 3 つ目のユースケースは URL の短縮です。お客様がキャンペーンを作成して URL を選ぶ際、その URL のクエリ文字列にトラッキング情報を加えると、URL が長くなります。SMS テキストで何度も送信するので、URL を短くする必要があります。もともと外部ソリューションを使用していましたが、そのソリューションでは将来の需要をサポートできないと判断しました。キャンペーンの特性上、呼び出しが過度に集中する傾向があり、将来的により高いスループットをサポートできるようにする必要があるのです。そこで、この短縮した URL 用に Bigtable 内で独立したテーブルを使用しました。62 ビットでエンコードされた短いスラッグを生成し、行キーとして使用します。行セルの 1 つでは、長いスラッグを Protobuf でエンコードされたデータ構造として使用し、使用回数をカウントするためのセルも用意しました。Bigtable のアトミックなインクリメント処理でカウンタの値を増やし、短いスラッグの使用回数をトラッキングします。

ユーザーがスマートフォンでテキスト メッセージを受信して短縮 URL をクリックします。そのアクセスが当社に送られ、Bigtable から長いスラッグに展開されて適切なサイト ロケーションにリダイレクトされます。当然、短縮 URL のユースケースの場合、直ちにコンバージョンを行う必要があります。Bigtable はレイテンシが少ないので、この要求に応えることができ、さらにスケールアップして高いスループット要求に応えることが可能になります。

Google Cloud で将来に備える

当社のビジネスは大幅に成長しており、新たなクライアントと次々と契約しています。その結果、スケールアップが必要になりますが、Bigtable は当社のスケーリング要求に容易に応えています。Bigtable と合わせて他の Google Cloud プロダクトも使用してデータ アーキテクチャを強化することで、昨年のブラック フライデーやサイバー マンデーのような非常にトラフィックの多い日でもリクエストに対応できました。こうしたイベントのトラフィックは想定を大きく上回りましたが、Bigtable によりオンデマンドでのスケーリングをスムーズに行うことができました。

当社では、さらにクラウド ネイティブなアプローチの活用と、GKE、Dataflow、Pub/Sub、Cloud SQL、Memorystore、BigQuery などの Google Cloud マネージド サービスの利用に取り組んでいます。Google はこれらのプロダクトを自ら開発しており、各ソリューションの展開や管理を当社が行う必要はありません。

Google Cloud を導入した結果、高い信頼性と柔軟性を備えたデータ ソリューションを手にすることができました。これにより、増大するカスタマー ベースのニーズに応え、迅速な対応が可能なパーソナライズされたショッピング メッセージとエクスペリエンスで、ユーザーの満足度を上げることができました。

Wunderkind の詳細についてはこちら、Cloud Bigtable の詳細についてはこちらをご覧ください。また、Bigtable と BigQuery の違いについて解説した最近のブログもご確認ください。

-Wunderkind 共同創立者兼エンジニアリング担当バイス プレジデント Namik Abdulzade