ABEMAのCM配信を支えるスケーラブルな分散カウンタの実装

AbemaTV, Inc. All Rights Reserved  AbemaTV, Inc. All Rights Reserved 
1 ABEMAのCM配信を支えるスケーラブルな分散カウンタの実装 2025 November 19 Honoka Toda

AbemaTV, Inc. All Rights Reserved  戸田朋花 Honoka Toda 株式会社CyberAgent
/ 株式会社AbemaTV CM配信システムのバックエンドの開発を担当 2 Proﬁle hono0130__ hono0130 2025年未踏IT 曾川PMプロジェクトのクリエイター

AbemaTV, Inc. All Rights Reserved  ABEMA 無料すべてのひとが楽しめる⽣中継ライブならではの臨場感
同時性⽇本のイマを捉え流⾏をつくる報道常に新鮮なニュース利便性時間と場所からの開放 ABOUT ABEMA

AbemaTV, Inc. All Rights Reserved  6 1. CM配信における課題 2. カウンターの設計
3. Google Cloud上での実装 4. 様々な種類のカウンターの実装 5. さらなるスループットの向上 INDEX

CM配信における課題 8 ABEMAのCM配信はパーソナライズ可能多種多様なイベントを処理しないといけない候補A 0回視聴候補B 1回視聴候補A 30代女性候補B 20代女性候補C 20代男性ユーザーの視聴履歴に基づく広告配信ユーザーの属性に基づく広告配信

CM配信における課題 9 目標インプレッションに近づけるように配信を制御する広告A: 目標200 広告A: 実績50 広告配信サーバーカウント現在の広告Aの実績は？ 50 インプレッション=広告の表示回数

CM配信における課題 10 目標インプレッションに近づけるように配信を制御する広告A: 目標200 広告A: 実績50 広告配信サーバーカウント 50 広告Aを計150人に配信現在の広告Aの実績は？

CM配信における課題 11 大量のインプレッションで処理が詰まると計測が遅れる広告A: 目標200 広告A: 実績50 広告配信サーバーカウント広告Aに+125 インプレッションが発火処理が詰まると計測が遅れる +1 +1 +1

CM配信における課題 12 計測が遅れた状態で配信制御すると実績と目標が乖離する広告A: 目標200 広告A: 実績100 広告配信サーバーカウント 100 過小な実績を返却（本当は175）現在の広告Aの実績は？

CM配信における課題 13 広告A: 目標200 広告配信サーバーカウント広告Aを計100人に配信広告A: 実績100 100 過小な実績を返却（本当は175）現在の広告Aの実績は？計測が遅れた状態で配信制御すると実績と目標が乖離する

合計250 目標オーバー💥 CM配信における課題 14 広告A: 目標200 広告A: 実績175 広告配信サーバーカウント広告Aに+75 インプレッションが発火計測が遅れた状態で配信制御すると実績と目標が乖離する

CM配信における課題 15 人気番組の生放送ではトラフィックがスパイクする広告配信サーバーのあるサービスのRPS 広告配信サーバーにリクエストがくるのは広告配信前後だけ人気番組の生放送時は広告前後で急激にスパイクする 1分で約200倍にスパイク

CM配信における課題 16 高スループット多様で大量のイベントをリアルタイムに捌く必要がある読み取りも書き込みもスケーラブル高カーディナリティなデータも扱える

カウンターの設計 18

カウンターの設計 19 値の正確性を犠牲にする代わりに高速に書き込むレイヤー

カウンターの設計 20 定期的にデータを確定させて値を補正するレイヤー

カウンターの設計 21 ホットストレージとコールドストレージを使った読み取り

Google Cloud 上での実装 23

Google Cloud 上での実装 25 ストリームはPub/Subを採用複数サブスクリプションを作ればファンアウトできるストリーム

Google Cloud 上での実装 27 ホットストレージはマネージドのValkey Cluster を利用ホットストレージ

Google Cloud 上での実装 28 Valkey Cluster は in-memory key/value store の Valkey のクラスタ構成 in-memory store なので高スループットクラスタ構成では読み書きの水平スケールが可能ホットストレージ

Google Cloud 上での実装 29 Valkey Cluster は key のハッシュ値でシャーディングするノードが水平スケールし読み書きの負荷分散が可能ホットストレージ

Google Cloud 上での実装 30 リードレプリカで読み取りのスケールが可能リードレプリカを追加することで読み取りの負荷を分散できるホットストレージ

Google Cloud 上での実装 32 イベントストレージは BigQuery を利用イベントストレージ

Google Cloud 上での実装 33 BigQuery は Partitioning によりスキャン範囲を減らせる Column1でPartitioningした例カラムの値によってテーブルが物理的に分割されるクエリの際は該当するPartitionしかスキャンされないイベントストレージ

Google Cloud 上での実装 34 カウント時刻で Partitioning してクエリを効率化スキャン範囲を絞ってコストとパフォーマンスを最適化イベントストレージ

Google Cloud 上での実装 35 BigQuery は Clustering によりデータの並び替えができる Column1でClusteringした例レコードがカラムの値の順序で並び替えられて配置されるスキャン範囲の最適化や集約の効率化が可能になるイベントストレージ

Google Cloud 上での実装 36 カウンターのキーで Clustering してクエリを効率化イベントストレージ

Google Cloud 上での実装 38 コールドストレージは Spanner を利用コールドストレージ

Google Cloud 上での実装 39 Spanner は Google Cloud で利用できる分散 RDB 処理性能やストレージの増減が簡単にできるマネージドサービスなのでメンテナンス不要コールドストレージ

Google Cloud 上での実装 40 Spanner は比較的小規模から利用可能で低コストに使える最小単位の100Unitではコンピュート料金月$85 簡単にデプロイできるオートスケーラーがある同じSLAの場合CloudSQLで最低月$480、AlloyDBで$581 オートスケールを活用すれば比較的安価に利用できる全て東京リージョン - Spanner は Standard Edition で 100 unitsの場合 - CloudSQL は Enterprise Plus Edition で HA 構成有効、db-perf-optimized-N-2 が 1 ノードの場合 - AlloyDB は 2vCPU で HA 構成が有効の場合参考コールドストレージ

Google Cloud 上での実装 41 Spanner では主キーの順でレコードが物理配置される Primary key1と Primary key2の複合主キーの場合コールドストレージ

Google Cloud 上での実装 42 カウンターのキーとカウント時刻を主キーにすることで時間範囲のクエリを効率的に行うことが可能コールドストレージ

Google Cloud 上での実装 44 ライターと補正バッチはGKE上のPod / CronJob コンピュート

Google Cloud 上での実践 46 • カウンター • 時系列カウンター • ユニークカウンターカウンターの種類として以下を設計

様々な種類のカウンターの実装 48 カウンターはKeyに対して値を数え上げるカウンタークライアント keyがuser1のカウント値は？ 1 keyがuser1:20250101のカウント値は？ 5 カウンター

様々な種類のカウンターの実装 49 Valkey 上では String 型によって表現できるカウンター

様々な種類のカウンターの実装 50 INCRBY でカウントアップし、GETで値を取得カウンター

様々な種類のカウンターの実装 52 時系列カウンターは時間範囲での取得が可能なカウンターカウンタークライアント keyがcampaign1の直近1分のカウント値は？ 13 時系列カウンター

様々な種類のカウンターの実装 53 Valkey では Sorted Set 型を使うと範囲取得が可能になる $ ZRANGEBYSCORE key1 1 10 member1 member2 member3 時系列カウンター

様々な種類のカウンターの実装 54 Score を UNIX タイムスタンプ、Memberをカウント値にすれば範囲取得が可能しかし、このままだとカウント値をインクリメントできない… 時系列カウンター

様々な種類のカウンターの実装 55 Hash型は1つの key に複数の key value を持たせられる型時系列カウンター

様々な種類のカウンターの実装 56 書き込み時に Hash を利用することでインクリメント可能時系列カウンター

様々な種類のカウンターの実装 57 Hash で書き込んで定期的に Sorted Set に変換することで時系列カウンターを実現可能！時系列カウンター

様々な種類のカウンターの実装 58 Valkey の Functions 機能を使うことで高速に変換できる Functions は Valkey に事前に関数を登録するとその関数を呼び出すことで指定の処理ができる機能ノード上で実行されるので、同じノードに存在しているデータのみ取り扱える時系列カウンター

様々な種類のカウンターの実装 60 ユニークカウンターはユニーク数を数えるカウンターユニークユーザーの計測等に活用できるカウンタークライアント keyがcampaign1のユニークな値の数は？ 3 ユニークカウンター

様々な種類のカウンターの実装 61 ユニーク数を愚直に数えるには全ての値を持つ必要があるカーディナリティが高い場合にデータ量が大きくなるカウンタークライアント key1にvalue5を登録 value1 value4 +value5 key1にvalue4を登録 value1 value4 value5 既にあるので何も行わないユニークカウンター

様々な種類のカウンターの実装 62 ユニーク数は HyperLogLog で効率的に表現できる HyperLogLogとは集合のカーディナリティを推定できる確率的データ構造データ量が小さく済む代わりに誤差が発生するユニークカウンター

様々な種類のカウンターの実装 63 Valkey の HyperLogLog 型を利用するだけで実装可能ユニークカウンター

さらなるスループットの向上 65 Valkey は同じキーの書き込みに対してはスケールできない特定のキーへの書き込みが集中する場合複数ノードでの負荷分散ができないため単一ノードの性能以上はでない

さらなるスループットの向上 66 異なる Key に分割して書き込んで後からそれをマージできれば書き込みがスケールするはず key1をkey1:1とkey1:2に分割

さらなるスループットの向上 67 CRDT (Conﬂict-free Replicated Data Type)とは「コンフリクトの生じないデータ型」複数の場所で同じデータに対して更新が独立に行われてもそれらの変更をコンフリクトせずにマージ可能な型これを活用することで結果整合性を持たせられる

さらなるスループットの向上 68 加算のみ可能なカウンターは GCounter と呼ばれ代表的なCRDTである

さらなるスループットの向上 69 GCounterは加算しかしないので単調増加するノード間で状態が異なる場合は最大値をとってマージ

さらなるスループットの向上 70 データ構造を工夫すれば Valkey 上でGCounterを表現可能 Keyのハッシュ値でシャーディングするので Keyのサフィックスに論理的なパーティションをつけてノード間で分散させる

さらなるスループットの向上 71 イベントは 1 つの論理パーティションにのみ書き込める

さらなるスループットの向上 72 定期的に各パーティションの値をマージする 1. 全てのパーティションの値を取得する

さらなるスループットの向上 73 定期的に各パーティションの値をマージする 2. 各パーティションについて　最大の値で上書きする

さらなるスループットの向上 74 クライアントはどれかの論理パーティションからGETし各カウンターの値を足し合わせれば最終的な値が得られる

さらなるスループットの向上 75 GCounterとしてキーを分割することで Valkey 単体性能を超えた性能を出すことができる！ GCounterで学ぶ、CRDTによるスケーラブルな書き込み処理と結果整合性 | CyberAgent Developers Blog 以前ブログでも解説しているのでよかったら読んでください🙏

ABEMAのCM配信を支えるスケーラブルな分散カウンタの実装

ABEMAのCM配信を支えるスケーラブルな分散カウンタの実装

More Decks by Honoka Toda

Other Decks in Technology

Featured

Transcript