Amazon DynamoDB: アドテックのユースケースと設計パターン

広告技術 (アドテック) 企業は、Amazon DynamoDB を使用して、ユーザープロファイル、ユーザーイベント、クリック数、訪問済みリンクなどのさまざまな種類のマーケティングデータを保存します。用途としては、リアルタイム入札 (RTB)、広告ターゲティング、アトリビューションなどがあります。このブログ記事では、DynamoDBを使用するアドテック企業の最も一般的なユースケースと設計パターンを特定します。

こうしたユースケースでは、高いリクエスト率 (1 秒あたり数百万件のリクエスト)、低くて予測可能なレイテンシー、および信頼性が必要です。大規模な読み取りボリュームがある場合、またはミリ秒未満の読み取りレイテンシーが必要な場合、企業は DynamoDB Accelerator (DAX) によるキャッシングを利用します。ますます多くのアドテック企業が、複数の地域で RTB や広告ターゲティングプラットフォームをデプロイしており、これには AWS リージョン間でのデータレプリケーションが必要になります。

完全マネージド型サービスである DynamoDB を使用すると、アドテック企業はデータベースの運用にリソースを投資することなく、こうした要件をすべて満たすことができます。また、こうした企業は、DynamoDB への移行によってデータベースの支出が削減されるため、DynamoDB の費用対効果も高いことに気付きます。たとえば、GumGum が自社のデジタル広告プラットフォームを DynamoDB に移行したとき、古いデータベースに比べてコストが 65〜70％ 削減されたと推定しています。

この記事で使用される用語

この記事では、以下のデータモデリングと設計パターンの用語を使用します。

• 1:1 モデリング: パーティションキーをプライマリキーとして使用する 1 対 1 関係のモデリング。
• 1:M モデリング: パーティションキーとソートキーをプライマリキーとして使用する 1 対多関係のモデリング。
• DAX によるキャッシング: DynamoDB の前で読み取りキャッシュとして DAX を使用すると、読み取りのレイテンシーを短縮できるだけでなく、頻繁にアクセスされるアイテムに対する高い読み取り負荷を費用効果の高い方法で処理することができます。

アドテックのユースケースと設計パターン

ユースケース: リアルタイム入札 (RTB) および広告ターゲティングでのユーザープロファイルの保存

RTB や広告ターゲティングのユースケースでは、100 ミリ秒以下のリアルタイムレスポンスのレイテンシーが必要です。この低レイテンシーを保証するために、アドテック企業はデータベースアクセスを含む処理フローの各ステップのレイテンシーを管理する必要があります。さらに、1 日あたり約 1,000 億のインプレッションを処理する RTB プラットフォームでは、毎秒数百万のリクエストを処理し、数十億のユーザープロファイルや数百テラバイトのデータを保存するデータベースが必要です。このような規模では、ごくわずかな入札に回答できないだけでも、100 万ドルの損失になる可能性があります。こうした理由から、AdRoll などのアドテック企業は DynamoDB を利用して、1 桁台のミリ秒のレイテンシーをあらゆる規模で実現しています。

設計パターン: ユーザープロファイルは、1:1 または 1:M のモデリングを使用して DynamoDB のテーブルに保存されます。1:1 モデリングによるアプローチでは、ユーザープロファイルはユーザー ID によって分割およびアクセスされます。よりきめの細かいアクセスが必要な場合は、1:M モデリングによるアプローチを使用し、ユーザー ID をパーティションキー、セグメントをソートキーとして、ユーザープロファイルをセグメント化してアイテム階層として保存します。Query API は、ユーザープロファイルのすべてのセグメントを集約して取得するために使用されます。ソートキーを使用してプロファイルデータをさらに階層へセグメント化する場合は、begins_with フィルターに一致するプロファイルの部分へのきめ細かいアクセスに、begins_with 関数を使用したキー条件式を使用します。

ユースケース: ユーザーイベント、クリックストリーム、インプレッションデータの保存

アドテック企業は、ユーザーや時間で素早くアクセスできるように、クリックやインプレッションなどのユーザーイベントを DynamoDB に保存します。たとえば、DataXu は DynamoDB を使用して RTB プラットフォームのアトリビューションエンジンにユーザーイベントを保存しています。彼らが DynamoDB を選んだのは、必要な種類の規模とパフォーマンスを提供する完全マネージド型で費用効果が高いサービスであるからです。DynamoDB を使用すると、ノードの追加などの拡張作業を管理する必要がなく、1 日あたり数億のリクエストに簡単に拡張することができます。

設計パターン: ユーザーイベントは、ユーザー ID をパーティションキー、タイムスタンプをプライマリキーのソートキーとするキーと値のペア (1:M モデリングパターン) として保存されます。書き込みおよび読み取りの容量とストレージを節約するために、データは圧縮されたバイナリペイロードとして保存できます。通常、データは 1 か月などの限られた期間の間、保存されます。不要になったデータを DynamoDB から削除するには、有効期限が切れたときにデータを自動的に削除するために追加料金なしで Time To Live (TTL) を使用します。

ユースケース: アセットのメタデータの保存

また、アドテック企業は DynamoDB を使用して、画像、ページ、リンクなどのアセットのメタデータも保存しています。たとえば、ユーザープロファイルに加えて、GumGum は同社の広告ターゲティングプラットフォームで DynamoDB を使用して、画像やページのメタデータを保存しています。同社のユースケースでは、地理的な境界を越える複数のデータセンターにまたがって、低いレイテンシーで高いトラフィックを処理できる大規模なデータストアが必要です。GumGum が DynamoDB を選択したのは、DynamoDB がこうした基準を満たしており、費用対効果が高く、サーバーレスであり、開発者がプラットフォームを簡単に拡張および維持できるためです。

別の例として、モバイルマーケティングおよびリンクプラットフォームである Branch は、ディープリンクプラットフォームのデータベースとして DynamoDB を使用しています。このプラットフォームは、製品ウェブページへのディープリンクならびにリンク分析を提供および管理するための統合ソリューションとなります。このプラットフォームには、数十テラバイトのデータとなる数百億のリンクとそれに関連するメタデータを保存する、高性能でスケーラブルで信頼性が高いキーバリュー型データベースが必要です。こうした要件を満たし、費用対効果が高く、予測可能なコストモデルを備えているため、Branch は DynamoDB を使用します。完全マネージド型サービスとして、DynamoDB は Branch の運用チームから運用に関する負担を取り除きます。

設計パターン: ページ、画像、ディープリンクなどのさまざまなアセットのメタデータは、アセットごとに区切られた DynamoDB テーブルに保存されます (1:1 モデリングパターン)。

ユースケース: 人気があるアイテムのキャッシュ

このユースケースは、以前の「アセットのメタデータの保存」のユースケースと密接に関係しています。DynamoDB で DAX を使用すると、ホットアイテムに対する大量の読み取りスパイクが解決され、読み取りレイテンシーが短縮されます。DynamoDB の読み込み負荷を軽減することで、DAX は DynamoDB への支出を削減するのにも役立ちます。

設計パターン: Branch のユースケースでは、ディープリンクプラットフォームは DynamoDB を使用してリンクと関連するメタデータを保存し、DAX を使用して新しくて人気があるリンクをキャッシュします。データは、プライマリキー (1:1 モデリングパターン) として使用される一意のリンク ID でパーティション化されたテーブルに保存されます。すべてのリンクが高速アクセス可能でなければなりませんが、少数のリンクは毎日高い率でアクセスされます。そうしたリンクは DAX にキャッシュされており、効率的でミリ秒レベルのレイテンシーでのアクセスが可能であり、読み込みの負荷とコストを削減できます。

まとめ

このブログ記事では、アドテック企業が DynamoDB を使用する最も一般的な方法について説明しています。AWS のアドテックソリューションの詳細については、デジタルマーケティング向け AWS を参照してください。コメントは以下から送信でき、DynamoDB forum で新しいスレッドを開始することも可能です。

著者について

Edin Zulich は AWS のシニア NoSQL スペシャリストソリューションアーキテクトで、困難なデータ管理問題に対するスケーラブルでコスト効率性に優れたソリューションを設計できるように、あらゆる業界のお客様を助けています。2016 年に AWS に入社した Edin は、2005 年以来ずっと分散型データテクノロジーに携わっています。