Rta 広告テクノロジーの実装と SaaS の考え方

[[433078]]

RTA の背景

RTA 配信モデルは過去 2 年間で徐々に人気が高まり、現在では国内の主流の交通メディアすべてがこの機能を導入しています。例えば、テンセント/Toutiaoは、顧客の広告配信の精度をさらに向上させるために、2020年にこのサービスを正式に開始しました。

RTA (正式名称 Real-Time API) は、リアルタイム API インターフェースであり、メディアと広告主間の通信のためのインターフェース サービスのセットです。主なプロセスは次のとおりです。

• アクティベーション後、各メディアがユーザーに広告を表示する前に、メディアは RTA インターフェイスを通じて広告主にこの表示に参加する (競合する) かどうかを尋ねます。
• 広告主はリクエストを受諾後、自社のデータと戦略情報を組み合わせて、露出（コンペ参加）の可否や、さらなる判断結果を返します。
• メディアは広告主の成果情報に基づいて最適な選択を行い、最終的に広告主の広告効果を向上させます。

RTA には多くのビジネス価値があります。例えば、シーンに応じてパーソナライズされた最適化を行ったり、広告主に広告露出の決定に参加する機会を提供したりすることができます。

ほとんどのお客様にとって、個人データは非常に貴重であり、RTA は個人データを非常に適切に保護できます。通常、広告主はトラフィックをフィルタリングしたいと考えています。たとえば、特定のグループの人々をターゲットにしたり除外したりしたいと考えています。従来のやり方では、ターゲットを絞ったデータをパッケージ化し、ターゲット配信データ パッケージとしてメディアの DMP プラットフォームにアップロードしていました。この方法では、データをリアルタイムに更新することができず、操作が面倒です。最も重要なのは、広告主のデータがメディアに直接公開されることです。多くの場合、データは企業にとって非常に重要な資産であり、特にデータに敏感な金融業界ではそれが顕著です。一部のデータは提供するのが不便ですが、RTA はこの問題を非常にうまく解決できます。

RTA アクセス要件

RTA のビジネス価値は明らかですが、メディアは RTA にアクセスできる広告主に対してかなりの障壁を設けています。ここでは主に技術的な障壁について説明します。

メディアはリアルタイムの競争に参加する必要があるため、広告主には一定の技術的およびデータ的能力、つまり大量の同時トラフィックに直面したときに迅速に意思決定を行い、リアルタイムの対応を提供できる能力が求められます。以下は、Toutiao が広告主に満たすことを要求する厳格な技術指標です。

• インターフェース応答時間は60ms以内（ネットワークと処理時間を含む）
• 残業率は2%未満にすべきである
• ピーク流量は10w/s～12w/sに達すると予想されます。

Tencent、Kuaishou、Baidu などの他のメディアにも同様の要件があります。インターフェースの応答時間は 60 ミリ秒以内で、高い QPS をサポートできる必要があります。実際のトラフィック制限はビジネスシナリオによって異なります。ただし、メディアには通常、タイムアウト レートのしきい値が設定されています。しきい値が満たされない場合、メディアにはダウングレードと最終的な撤回のメカニズム（つまり、広告主の RTA アクセス チャネルの閉鎖）が存在します。

ToB RTAのビジネスシナリオ

上記のRTAの背景を理解することで、RTAが精密マーケティングと個人データの漏洩防止において優れた実績を上げていることがわかります。しかし、RTA の参入障壁は比較的高く、ほとんどの中小企業にはこの技術にアクセスする能力がありません。さらに、マーケティング SaaS プラットフォームと連携する場合、通常、SaaS サービス プロバイダーとの共同モデリング アプローチを採用しますが、これは個人データに対して特に敏感ではありません。通常の実装は次のとおりです。

• 広告主はオーディエンス パッケージをマーケティング SaaS プロバイダーにアップロードし、プロバイダーはオーディエンス分析と RTA インターフェイスを提供します。
• 広告主はメディア側でアカウントを開設し、入札に関する情報を設定します。 SaaS プロビジョニング RTA インターフェイスをポリシーとして構成します。

RTA 実装

API インターフェースのデータ交換形式は http-protobuf に基づいています。 Tencent と Toutiao はどちらもこの方式を採用しています。 Protobuf シリアル化により、優れた圧縮コスト効率を実現できます。契約はメディア側が行い、契約内容に従ってインターフェースサービスが開発・提供されます。これは比較的簡単です。

データストレージの選択

データ ストレージの選択に関しては、このシナリオでは純粋なインメモリ データベースが実際に最も適していますが、アプリケーションの実装にもトレードオフが必要です。会社のインフラストラクチャの完成度を考慮すると、Hbase と Aerospike のどちらかを選択する必要があります。まず、Hbase は最悪の場合数秒の遅延が発生する可能性があるため、適切な選択ではありません。ただし、kv などのストレージ タイプの場合、v が比較的小さいと、Aerospike のディスク使用率は非常に低くなります。クラウドベンダーが提供する kv データベースの使用を検討しましたが、セキュリティによって拒否されました。データセキュリティは何よりも重要です!!!

最後に、データ ストレージ層として独自に構築した Redis クラスターを採用しました。

アプリケーションアーキテクチャの実装原則

RTA の高度な同時実行性とリアルタイムのビジネス要件に基づいて、当社は早い段階でセキュリティ/運用と保守/DBA/基本コンポーネントの同僚とコミュニケーションを取り、インフラストラクチャが効果的に同時実行性を実行できることを確認しました。同時に、RTAが他の事業に影響を及ぼさないように、一部の施設で効果的なリソース分離を実施しました。

総合的に検討した結果、次の選択と主な設計原則を採用しました。

• コンピュータ ルームの分離: 同社の業務のほとんどは杭州のコンピュータ ルームで行われるため、効果的な分離を確保するために、RTA アプリケーションは上海のコンピュータ ルームに展開されています。
• ブロック/時間のかかる操作を避ける: 非同期メソッドを使用できます。下流のQPSを削減する必要がある場所では、キュー、キャッシュ、バッチ操作などを使用して最適化できます。
• タイムアウトの低下: 一部のリクエストでは不具合が発生し、タイムアウトと帯域幅の輻輳によって雪崩が発生する可能性があります。タイムアウト要求をダウングレードする必要があります。
• リソース保護/詳細最適化: たとえば、システム境界を越えた呼び出しや危険なローカル コード ブロックをリソースとして保護し、効果的なダウングレード メカニズムを提供できます。コードを最適化すると、メソッドのインライン化を通じて呼び出しコストを削減できます。

システムビュー

主なサービスは次のとおりです。

• rta-uig: フロントエンドでリクエストを受信し、バックエンド アプリケーションで負荷分散を実行します。
• config: 分散構成センター。ビジネス担当者が各 RTA 要求に対する戦略を策定し、公開する (競争に参加する) かどうか、およびデータの変更を通知するかどうかを決定します。
• rtaapp: rta コア サービス。顧客の構成情報をキャッシュし、要求を処理し、競合データを返します。
• データ転送: 広告主データの処理と、Redis クラスターへのデータの定期的な同期。

API インターフェースの主な処理フローは次のとおりです。

HTTP スレッドがブロックされないようにするには、可能な限り非同期処理が優先されます。さらに、API が直接依存する 2 つのデータ ソースは Redis と JVM メモリであり、これらはリアルタイム要件を満たすことができます。

ネットワークの問題

インターフェースの応答時間は 60 ミリ秒以内でなければならないと前述したので、ネットワークの問題は大きな影響を与えます。

実際、私たちはほとんどの時間をインターネット上で過ごしており、距離はネットワークの遅延に直接影響します。現在接続されているいくつかのメディアから判断すると、北京から上海までのインターフェース消費時間は約30ms、上海パブリッククラウドから会社のコンピュータールームまでの専用回線は約2msかかります。オンラインになった後、メディア要求の数が増えると、ネットワーク ジッターによって TCP 再送信が発生し、帯域幅が瞬時に完全に使用され、すべての要求が拒否されました。より帯域幅の広いデバイスに交換した後、問題は軽減されましたが、帯域幅のコストは非常に高額になりました。後ほど、セキュリティ部門と交渉して、データのセキュリティ レベルを分類できるかどうかを確認したいと考えています。一部のデータはパブリック クラウドにアップロードできるため、メディア側のコンピューター ルームの近くにデータを展開できます。

資源保護

資源を保護し、効果的に分解することは非常に重要です。保護ポイントは主にビジネス上の考慮事項に基づいて決定され、任意のコード スニペットにすることができます。主力事業に影響が出ないよう、可能な限りの格下げ措置を講じる必要がある。依存するダウンストリーム サービスがダウンした場合、または GC によってプロセスが中断された場合は、要求をタイムアウトにしてダウングレードする必要があります。大量のリクエストのタイムアウト処理では、タイムホイールの原理を学び、時間計算量を O(1) に制御することで、パフォーマンスを大幅に向上させることができます。詳細は前回の記事をご覧ください。

RTA SaaSについての考察

ビジネスの発展と接続顧客の増加に伴い、製品 SaaS がトレンドになっています。 SaaS は、マルチテナント データの分離とデータ量の急速な増加に直面することになります。これらの問題にどのように対処し、コストを削減して効率を高め、少量のリソースを使用してより多くのことを実行し、さまざまなパフォーマンス指標を満たすかは、検討する価値のある問題です。

Redis メモリ

Redis に保存された業務データについては、業務データの特性と組み合わせることで、hash/zset ストレージ構造を使用し、キーの数と長さを制限し、ziplist を使用してメモリの大部分を節約し、コストを節約できます。二次コーディング方式を使用します。ハッシュ ストレージを全体的に採用した後、100 万件のレコードをクエリするのに必要な時間は 500 ミリ秒未満しか増加しませんでした。詳細は前回の記事をご覧ください。

以下の要件では、デバイスの数に応じて、メディア露出をデバイスあたり 1 日あたり一定量に制限するために、露出されるデバイスに対していくつかの戦略を実装する必要があります。今後は複数のメディアに接続し、デバイス露出リクエストデータの総量は1日あたり数百億回に達する可能性があります。毎日数十億のデバイスが重複排除されると予想されます。事業の特性と組み合わせると、設計は次のようになります。

• デバイスには同時実行性があるため、アトミック操作が必要であり、INCR コマンド (文字列、ハッシュ、zset) のみを選択できます。
• メディアデバイスは個別にカウントされ、ビジネスルールに従ってメディアデバイスごとに1日のカウント上限が設けられています（1日10回以内）。これは、各カウンターが到達できる最大カウント値が決定されていることを意味します。つまり、カウンターに必要なビット数は有限かつ固定されています。

たとえば、Redis の整数型に使用される内部エンコーディングは int エンコーディングであり、これは Java の long 型に対応し、8 バイトを占めます。 8 バイトのデータは分割され、適切なビット数がメディア カウントとして使用されます。これをハッシュストレージと組み合わせると、スペースを数倍節約できます。

ホットスポットデータの最適化

当社のビジネスの特性上、大量のデータ保存のニーズに直面しており、ビジネスにおける小さなルールが大量のストレージ リソースを消費する可能性があります。これには、データストレージを慎重に設計し、効率的なアクセス構造を見つける必要があります。

ビジネスで使用されるデータは、次の 2 種類のストレージに分類できます。

• JVM ローカル ストレージ: システム ビジネス構成、ビジネス ルール戦略、ビジネス制御情報、ホット キー、ブラックリストなど。
• Redisストレージ: 戦略計算にはさまざまなデータが必要であり、データ量は比較的大きく、各データは数十億に上ります。

JVM ローカル ストレージの場合、ホット キーの処理を例として説明します。ホットキーとは、メディアによって繰り返し発行される同じデバイス番号の露出要求を指します。事業開始当初は、多くのデバイス リクエストが何度も送信され、1 日に数千万回に及ぶものもあり、処理リソースが浪費されており、何らかの対処戦略が必要であることがわかりました。この目的のために、フィードバックを収集する方法を設計しました。具体的なプロセスは次のとおりです: API インスタンス ローカル LFU キュー [LFU (Least frequently used) アルゴリズムは、データの履歴アクセス頻度に基づいてデータを削除します。その中心となる考え方は、「データが過去に何度もアクセスされた場合、将来はより頻繁にアクセスされる」というものです。 】次の図に示すように、収集->レポート->統計->API インスタンスへのフィードバック:

要約する

RAT はしばらく正常に動作していましたが、動作中にいくつかの問題が見つかりました。現在、システムは比較的安定して稼働しています。モデルの効果が検証された後、SaaS の進化を開始できます。このプロジェクトを推進する過程から、アプリケーション側コンピュータ室の選択が非常に重要であり、データの配置はメディア側コンピュータ室からあまり離れてはいけないことがわかります。インターフェース設計に関しては、可能な限りシンプルにし、帯域幅を節約するために不要な戻りフィールドと応答ヘッダーを可能な限り削除します（帯域幅は比較的高価です）。データストレージに関しては、インメモリデータベースを使用し、ストレージタイプのデータ構造を検討し、合理的なデータ構造を使用してストレージコストを節約します。インターフェースのタイムアウトの低下を適切に処理し、効率的なタイムアウト判定メカニズムを使用してアプリケーション パフォーマンスの低下を最小限に抑えます。

この記事はWeChatの公開アカウント「Xiao Wangge Writes Code」から転載したものです。以下のQRコードからフォローできます。この記事を転載する場合は、Xiao Wangge のコード執筆公開アカウントにご連絡ください。