「私たちは2ペタバイトを超える分析データと数テラバイトのトランザクションデータをクエリし、毎日10億件のイベントを処理しています。Apache Beamにより、データ処理の並列化、スループットの最大化、これらのデータセットの移動/ETLの高速化が可能になりました。」
Booking.comにおけるBeamを用いた大規模広告入札
背景
Booking.comは、旅行の手間を省き、誰もが世界を体験しやすくするテクノロジーに投資することで、何百万人もの旅行者と記憶に残る体験をシームレスにつないでいます。Booking.comは、消費者と地域のパートナーにオンライン旅行および関連サービスを提供する世界最大のプロバイダーであるBooking Holdingsのブランドです。220以上の国と地域で人々が目的地を発見できるよう、Booking Holdings全体では、2022年に59億9000万ドルをマーケティングに費やし、Booking.comはGoogle Pay Per Click（PPC）検索広告の主要な旅行広告主となっています。
Booking.comのマーケティングテクノロジー部門のPPCチームは、この規模でPPC広告を掲載するために必要なインフラストラクチャと社内ツールを担当しています。PPCチームの主な目標は、すべての検索エンジン プロバイダーでPPCを確実かつ効率的に最適化し、広告パフォーマンスデータを測定および分析し、広告階層を管理し、広告基準を調整することです。Apache Beamは、非常に大規模で信頼性が高く、パフォーマンスが高く、費用対効果の高いデータ処理インフラストラクチャを構築するのに役立つ効果的な抽象化を提供することにより、この目標をサポートします。
Beamへの道のり
PPC広告は、Booking.comのマーケティングにとってビジネスに不可欠なプロモーションチャネルです。検索エンジンでは1日に数十億件の検索が行われているため、PPC検索広告を使用して、ユーザーが検索結果で最も関連性の高いオファーを取得できるようにしています。舞台裏では、PPCチームは、広告パフォーマンスフィードバックを処理し、過去の掲載結果を評価し、入札を生成する機械学習操作をサポートし、入札を検索エンジン プロバイダーに伝達するための運用インフラストラクチャを管理しています.
Booking.comの大規模広告入札の以前の実装は、MySQLデータストレージ、cronスケジューリング、およびビジネスロジックを実装するためのPerlスクリプトを使用したカスタムスタックバッチパイプラインでした。この設計は最終的に、1秒あたりの入札に対するスループットの需要の増加に対応するのが困難なパフォーマンスのボトルネックに陥りました。複雑さを維持するためのコストと相まって、機会損失コストは完全な書き換えのコストよりも大きくなりました。
大規模入札インフラストラクチャは、Apache Beamが登場する前に何度か書き直されています。PPCチームによるApache Beamを搭載したデータエコシステムの最新実装の背後にある中心的なアイデアは、2020年後半に生まれました。Beam SummitとBeam Collegeのコミュニティイベントに参加することで、チームはDataflowランナーでマネージドサービスとしても利用できるオープンソースのApache Beam抽象化モデルについて学ぶことができました。
チームの他のメンバーにアイデアを紹介するのは簡単でした。Apache Beamモデルはビジネスロジックを分離し、メンタルモデルの構築に役立つため、理解しやすいです。
PPCチームは、広告掲載結果レポートをダウンロードする新しいプロトタイプJavaパイプラインを作成することで、このフレームワークを試験的に導入することを決定しました。
Apache Beamを使用することで、開発時間で数倍のスピードアップを実現しました。わずか3週間で1つのパイプラインを実際に提供することができました。他のフレームワークを使用してパイプラインを実装する必要があった場合は、3か月かかっていたでしょう。
最初のPOCが成功したことが証明されると、PPCチームはApache Beamをデータインフラストラクチャの中心に据えました。Dataflowマネージドサービスをスピンアップすることで、独自のコンピューティングおよびストレージインフラストラクチャを維持する代わりに、新しい機能に集中する機会が得られました。ランタイム実装の詳細からのApache Beamの抽象化により、PPCチームはビジネスロジックに集中し、並列処理を活用して簡単に水平方向にスケーリングできます。さまざまなGCP製品のヘビーユーザーである彼らは、Apache BeamのI/Oコネクタを活用して、BiqQuery、Firestore、Spannerなどのさまざまなシンクとソースとネイティブに統合しました.
Apache Beamは、データインフラストラクチャと処理のための効果的な抽象化として機能します。Dataflowランナーを使用すると、ランタイムとストレージインフラストラクチャの維持、およびクラウドプロバイダーのロックインについて心配する必要もありません。
ドキュメントの質、活気のあるApache Beamオープンソースコミュニティ、メーリングリストでの活発な議論、ユーザーが作成した豊富なコンテンツにより、新しいユースケースを非常に簡単に導入できました。
新しいエコシステムの設計と実装において、Apache Beamオープンソースコミュニティ、ドキュメント、YouTubeコンテンツは非常に役立ちました。
現在、Apache Beamは、PPCチームの大規模広告入札インフラストラクチャのバッチおよびストリーミングパイプラインを強化しています.
大規模広告入札
概念的には、大規模広告入札インフラストラクチャは、広告入札リクエストとアセットを受け入れ、複数のサービスに送信するためのステージングを提供し、大規模な広告掲載結果を処理します。広告入札インフラストラクチャは、Apache Beamバッチおよびストリーミングパイプラインに依存して、Big Query、Spanner、Firestore、Pub/Subソースとシンクと対話し、広告サービスAPI呼び出しにBeamのステートフル処理を使用します.
データインフラストラクチャを設計する際、PPCチームの主な目標は、検索エンジンの広告APIによってアカウントレベルに課せられるリクエストレート制限を尊重しながら、1秒あたりの入札のスループットを最大化することでした。PPCチームは、キー付きのPCollectionを利用して送信広告の変更をアカウントID別にクラスタリングし、バッチにグループ化し、データ処理を並列で実行するストリーミングApache Beamパイプラインを実装しました。このアプローチは、チームの数千の広告アカウントのスループットを最適化し、大規模なパフォーマンスと信頼性を向上させるのに役立ちました.
Apache Beamにより、データ処理を並列化し、非常に大規模なスループットを最大化することができました。
PPCチームは、内部APIインターフェースを使用して、大規模入札インフラストラクチャにクエリを送信します。このインフラストラクチャは、GoogleとBingのそれぞれの広告入札パイプラインにクエリをルーティングします。Googleブランチの場合、APIはInvokerクラウド関数を呼び出します。この関数はBigQueryからデータを読み取り、集計して分析を実行してから、中間結果をBigQueryのステージングテーブルに格納します。次に、InvokerはIngestor Apache Beamバッチパイプラインを呼び出し、Pub/Subにデータを公開します.
一方、Google Ad Mutator Apache Beamストリーミングパイプラインは、1日あたり10億を超えるPub/Subイベントをリッスンし、対応するリクエストをGoogle Ads APIに送信します。このジョブは、バックプレッシャーを念頭に置いて設計されており、パーティショニング、並列処理、キー順序の配信保証などの要素を考慮しながら、最適なパフォーマンスを確保します。結果はBigQueryの結果テーブルとSpannerのインベントリに書き込まれ、1日あたり100 GBを超えるデータが処理されます.
最後に、Daily Importer Apache Beamバッチパイプラインはインベントリデータを取得し、ダウンストリームタスクに配信し、1日あたり100 GBも処理します。次に、データアナリストは、ホテル予約の着信ストリームと、広告された内容のインベントリデータとを照合し、PPC広告のパフォーマンスを評価します.
Apache Beamフレームワークの汎用性と柔軟性は、プロセス全体にとって重要です。バッチ処理とストリーミング処理を統合されたフローに結合できるだけでなく、特性とセマンティクスが異なる幅広いソースとデスティネーションとの統合も可能になるためです。また、このフレームワークは、配信と順序の保証を提供します。すべて大規模で、ストリーミング処理に最適なトレードオフを実現します.
Google Ads MutatorパイプラインとBing Ads Mutatorパイプラインは、Booking.comの大規模入札インフラストラクチャの不可欠な部分です。これらのストリーミングApache Beamパイプラインは、検索エンジンの広告APIとの間でやり取りされるすべてのデータを処理し、Cloud Spannerのインベントリに大規模な広告掲載結果レポートを書き込みます。Apache Beam組み込みのCloud Spanner SpannerIO。書き込み変換により、ミューテーションをグループ化してバッチ処理することで、Spannerのトランザクションごとの制限を尊重しながらスループットを最大化し、データをより効率的に書き込むことができます。Apache Beamがミューテーションのキー範囲を縮小することで、PPCチームはSpannerのコスト最適化を実現し、処理パフォーマンスを向上させることができました.
同様に、Ads APIのレート制限レベル内に収まるように、PPCチームはApache Beamのタイムリーおよびステートフル処理と、入札のレート制限を維持するRedisベースのマイクロサービスを活用しています。PPCチームは、バッファがいっぱいになるまで着信ミューテーションコマンドを蓄積するカスタムの「集約と送信」関数を持っています。この関数は、レートリミッターからミューテーションクォータを要求し、Ads APIにリクエストを送信します。内部レートリミッターまたはAds APIが待機を要求した場合、関数は再試行タイマーを開始し、着信コマンドのバッファリングを続けます。待機するリクエストがない場合、関数はコマンドバッファをクリアし、クエリをPub/Subにパブリッシュします。
Apache Beamは、ウィンドウ化された集約を提供してミューテーションコマンドを事前に集約し、タイマーとステートフル操作を使用して配信保証を保証します。BagStateを使用することにより、Apache Beamはコレクションに要素を追加して、順序付けられていないミューテーションのセットを蓄積できます。一方、ValueStateは、DoFnのProcessElementメソッドおよびOnTimerメソッド内で読み取りおよび変更できるバッチ、バッチサイズ、およびバッファサイズの型付き値を格納します。
ページ読み取りをサポートするランナーは、使用可能なメモリよりも大きい個々のバッグを処理できます。Apache Beam再試行タイマーは、一定の処理時間後に状態にバッファリングされたデータを出力するために使用されます。フラッシュタイマーは、コマンドがバッファに長時間残らないようにするために使用されます。特に、コマンドがまれでバッファを満たすことができない場合に役立ちます。
Beamモデルのステートフル機能により、着信データを消費できるまでバッファリングすることで、1秒あたりの入札をきめ細かく制御し、他の潜在的なソリューションよりも高い処理パフォーマンスを維持することができました。
可観測性を高め、ユーザーに送信ステータスを監視する方法を提供するために、PPCチームは、受信および送信されたリクエストの数をカウントするためのカスタムキーを持つメトリクスを生成するカスタム関数も開発しました。Apache Beamの拡張性により、PPCチームはこの補足的な監視ツールをAd Mutatorパイプライン内に追加ブロックとして実装することができました。
結果
Apache Beamは、Booking.comの大規模なパフォーマンスマーケティング「フライホイール」の背後にあるデータロジスティクスを支えています。複数のデータシステムで月間100万件以上のクエリを実行し、2PB以上の分析データとテラバイト単位のトランザクションデータを毎日スキャンし、ピーク時には毎秒数千のメッセージで10億件以上のイベントを処理しています。広告入札ワークフローを実現しています。
Apache Beamは、Booking.comの何千もの広告アカウントの処理を並列化し、コストを最適化し、大規模な広告入札処理のパフォーマンスと信頼性を確保するために、非常に必要とされる並列処理、接続性、パーティション分割機能、および強力なキー順序の配信保証を提供しました。
Apache Beamは、ストリーミングパイプラインの処理時間を6時間から10分に短縮しました。これは、実行時間を36倍も短縮した驚くべき結果です。高性能で高速なPPC広告入札インフラストラクチャは、現在、検索広告から毎日200万泊以上の予約を促進しています。Apache Beamの抽象化により、新しいチームメンバーのオンボーディングが簡素化され、パイプラインの作成と保守が容易になり、設計ドキュメントから本番環境への稼働までの市場投入までの時間を最大4倍短縮できます。
PPCチームは、Apache Beamの統合処理機能の使用を拡張して、複数のバッチおよびストリーミングパイプラインを単一のパイプラインに結合することを計画しています。
Apache Beamは、ビジネスロジックを非常に宣言的な方法で記述できるモデルです。次の開発イテレーションでは、複数のAds Mutatorパイプラインを単一のストリーミングパイプラインに結合することを計画しています。
この情報は役に立ちましたか？