【Google Cloud Next Tokyo 2025】月間動画再生数約 5 億回を誇る TVer の、広告配信基盤における Memorystore & Bigtable 併用戦略と実践的チューニング：講演レポート

Google Cloud Next Tokyo 2025とは？

Google Cloud Next は、Google Cloud が主催する大規模なオンサイトイベントです。2025年8月5(火)と6日(水)の2日間、東京ビッグサイトで開催され、オンラインでのライブ配信も行われます。

本イベントでは、最新のクラウド技術や生成 AI ソリューションが紹介され、業界リーダーによるセッション、革新的なデモ、ネットワーキングの機会を通じて、Google Cloud が実現する未来を体験可能です。

セッション情報

セッション名	月間動画再生数約 5 億回を誇る TVer の、広告配信基盤における Memorystore & Bigtable 併用戦略と実践的チューニング
セッション概要	TVer は広告型の完全無料でお楽しみいただける民放公式テレビ配信サービスです。2024 年 12 月に月間動画再生数 4.96 億回を記録し、その成長は現在も加速しています。 大量の広告リクエストを低レイテンシーで処理する TVer の広告配信基盤では、Memorystore for Redis Cluster と Bigtable を要件に応じて戦略的に併用しています。 本セッションでは、広告配信基盤のような高パフォーマンスが要求されるシステム設計において、NoSQL データベース選定プロセスから設計思想、そしてマネージドサービスの性能を最大限に引き出すための実践的なパフォーマンス チューニングまで、開発者とアーキテクトの皆様に役立つノウハウを余すところなくお伝えします。

はじめに

本講演では、民放公式テレビ配信サービスの広告配信基盤が、大量のトラフィックをどのように処理しているか、その裏側にあるデータベース戦略について解説されていました。

具体的には、Memorystore for Redis ClusterとBigtableを併用する巧妙なアーキテクチャと、Bigtableの性能を最大限に引き出すための実践的なチューニング方法を、実際の事例を基に詳しく紹介されています。

配信サービスに限らず、さまざまな業界で低レイテンシと高い拡張性が求められるシステムにおいて、最適なデータベースを選定し、使いこなすためのヒントが得られると感じました。ぜひ最後までご覧ください。

大規模配信サービスを支えるDB技術 ━低レイテンシと拡張性の両立

本講演で紹介された民放公式テレビ配信サービスは、月間動画再生数が4億9600万回、月間ユニークブラウザ数が4120万を超える大規模なサービスです。このサービスを支える広告は、広告主向けに提供される運用型広告商品であり、その配信基盤には極めて高いパフォーマンスが求められます。

本配信サービスの広告には、ユーザー体験と広告効果を高めるための特徴があります。

特徴	内容
広告の受容性の高さ	地上波テレビCMのように、自然なタイミングで広告が挿入されるため、違和感や嫌悪感が低いとされています。
ファーストパーティデータ活用	ユーザーのアンケート情報（生年月日、性別など）に基づいた、精度の高いターゲティング配信が可能です。
ブランドセーフティ	第三者機関の基準を満たした安全なコンテンツにのみ広告が配信されるため、広告主は安心して出稿できます。

キーバリュー型のDBを選定した理由：「低レイテンシ」と「高い拡張性」

本広告配信サービスでは、月間5億回の動画再生から25億回以上の広告リクエストが発生し、実際にはさらに多くのトラフィックを処理します。この膨大なリクエストを、アドサーバーが要求する数百ミリ秒という非常に厳しいタイムアウト期間内に処理し、応答を返さなければなりません。

この要求に応えるため、広告配信基盤はGoogle Kubernetes Engine (GKE) 上のバックエンドサーバーと、データベースとしてBigtableおよびMemorystoreを採用しました。私たちがリレーショナルデータベースではなく、キーバリュー型のNoSQLデータベースを選択した理由は、「低レイテンシ」と「高い拡張性」という二つの要件に集約されます。

広告を選択するロジックは、ユーザー属性や視聴コンテンツによって動的に変わるため、複雑なクエリを発行するリレーショナルデータベースではタイムアウトに間に合いません。必要なデータをミリ秒単位で高速に取得し、広告選択の計算に多くの時間を割り当てる必要がありました。

また、事業成長に伴い増加し続けるトラフィックとデータ量に対して、合理的なコストで、かつ運用負荷を低く保ちながら水平にスケールできるアーキテクチャが不可欠でした。これらの理由から、分散型のキーバリューデータベースが最適な選択肢であると判断しました。

Bigtableのレプリケーションレイテンシー問題

ここで注目したいのが、当初の設計で直面した「Bigtableのレプリケーションレイテンシー」の問題です。これは、分散システムにおけるデータストア選定の難しさと、その解決策を示す好例と言えます。

一言で言うと、この問題は「システムの可用性を高めるためのマルチクラスター構成が、逆にデータの整合性を一時的に損なう」というジレンマの現れです。高可用性を目指して複数の地域にBigtableクラスターを配置すると、あるクラスターへの書き込みが他のクラスターへ複製（レプリケーション）されるまでに、数秒から数分の遅延が生じます。広告配信サーバーがセッション情報を書き込んだ直後に、別のクラスターに接続した計測サーバーがその情報を読み取ろうとしても、まだデータが届いておらず「見つからない」という事象が発生したのです。

この課題は、広告配信というユースケースにおいて「書き込み後、数十ミリ秒以内にそのデータが読み取れること」という非常に厳しい整合性の要件が潜んでいたことを明らかにしました。この要件を満たすため、Bigtableの利用を諦めるのではなく、データの特性に応じて役割を分担させるという戦略をとりました。

すなわち、この厳しい整合性が求められるセッションデータやフリークエンシーデータは、インメモリで高速に動作し、ゾーン障害への耐性も持つMemorystore for Redis Clusterへ移行させました。一方で、数秒の遅延を許容でき、将来的にテラバイト級にまで膨れあがる可能性のあるユーザーセグメントデータは、安価でストレージ上限が高いBigtableに引き続き格納することにしたのです。

これは、システムの要件を深く理解し、各データストアの特性を最大限に活かした、現実的で優れた解決策と言えるでしょう。

MemorystoreとBigtableの戦略的使い分け

データベースの選定プロセスでは、データデザイン、プロトタイプ実装、そして性能評価というステップを繰り返しました。特にデータデザインでは、扱うデータの「全体のデータサイズ」と「秒間クエリ数（QPS）」という二つの側面から分析を行いました。

広告視聴セッションのようにキー空間が数千万にも広がり、全体のデータサイズが大きくなるデータはストレージ上限が高いデータベースへ、一方で予算消化データのようにキー空間が狭く、特定のキーにアクセスが集中する（ホットキー）可能性があるデータは、その対策が可能なデータベースへと、特性に応じた選定が求められました。

比較検討の結果、Memorystore for Redis Cluster (MRC) とBigtableの併用という構成に行き着きました。MRCは、シャードを増やすことで読み書き双方のスループットがスケールし、レプリカによって耐久性と可用性も高められる点が優れています。対するBigtableは、高いパフォーマンスと拡張性に加え、コンピューティングノードとストレージが分離していることによるデータの永続化や、CPU・ストレージ使用率に基づくオートスケーリングが可能な点が魅力でした。

最終的に、私たちのデータストアの使い分けは以下のようになりました。 数十ミリ秒という短い時間で整合性を取る必要があるデータ（広告視聴セッションやフリークエンシーキャップ情報）はMRCに格納します。一方で、数秒から数分のレプリケーションレイテンシーを許容でき、かつ安価で膨大なストレージ容量を必要とする可能性のあるデータ（ユーザーセグメント情報）はBigtableに格納するという戦略です。この使い分けにより、MRCが導入され、計測サーバーがセッションデータを読み取れないという問題は解消されました。

Bigtableの性能を最大限に引き出す実践的チューニング

システムの性能をさらに向上させるため、私たちはGoogle Cloudのプロフェッショナルサービスチームと協力し、数ヶ月にわたる徹底的な負荷試験と最適化を行いました。その中で得られた、Bigtableの性能を引き出すための二つの重要な知見をご紹介します。

ウォームアップの重要性

一つ目は「ウォームアップ」の重要性です。Bigtableは、アクセスパターンを学習し、テーブルの特定範囲（タブレット）を各ノードに再配置することで、約10分かけて処理を最適化します。そのため、性能を正しく評価するには、負荷試験の最中にノード数を変更せず、試験開始前に本番同様のアクセスパターンで10分以上の負荷をかけて「ウォームアップ」を完了させておくことが不可欠です。

gRPCコネクションプールサイズの調整

二つ目の、そして特に重要な知見が「gRPCコネクションプールサイズ」の調整です。これは、データベースのパフォーマンスチューニングが、サーバー側だけでなくクライアント側の設定にも大きく左右されることを示す典型的な例です。

一言で言うと、この問題は「クライアントアプリケーションがデータベースに接続する際の”窓口”が、リクエストの殺到に対応しきれず、クライアント内部で行列を作ってしまった」状態です。Bigtableのクライアントライブラリは、内部にAPIリクエストを同時に処理するためのコネクションプールを持っています。このプールのサイズが、アプリケーションが生成する同時リクエスト数に対して不足すると、処理待ちのリクエストがクライアントのメモリ上に溜まっていきます。

その結果、Bigtableサーバー側の処理（サーバーサイドレイテンシ）は数ミリ秒で完了しているにもかかわらず、クライアント側で観測されるレイテンシは、この待ち時間を含んで数十秒にも悪化するという現象が発生しました。さらに、溜まったリクエストは大量のメモリを消費し、アプリケーションが強制終了する原因にもなっていたのです。

この問題は、Cloud Profilerのようなプロファイリングツールを用いてアプリケーションのメモリ使用状況を詳細に分析することで発見されました。そして、コネクションプールサイズを適切に調整した結果は劇的でした。読み取りリクエストの95パーセンタイルレイテンシは49秒から7ミリ秒へと約7000倍も改善し、コンテナのメモリ使用量も37GiBから523MiBへと98%以上削減できたのです。この事例は、パフォーマンス問題のトラブルシューティングにおいて、サーバー側のメトリクスだけに囚われず、クライアントライブラリの設定やクライアント側の各種指標を注意深く観察することの決定的な重要性を教えてくれます。

まとめ

本記事では、広告配信サービスの広告配信基盤を例に、MemorystoreとBigtableを併用する戦略と、Bigtableの性能を最大限に引き出すための実践的なチューニング手法について解説されていました。

数十ミリ秒の整合性が求められるデータはMRCへ、大容量でレイテンシを許容できるデータはBigtableへという使い分けは、システムの要件を深く理解した上での優れた判断です。また、Bigtableのウォームアップや、見落としがちなクライアントサイドのコネクションプールサイズ調整が、パフォーマンスに劇的な改善をもたらすことも示されました。

この記事を読んだ皆様が次にとるべきアクションとして、まずはご自身のシステムで扱うデータの特性、特に「整合性」と「レイテンシ」の要件を改めて整理し、現在のデータストア選定が最適か再検討してみてはいかがでしょうか。

その上で、Bigtableのような高度なデータベースを利用する際は、公式ドキュメントで推奨されているスキーマ設計やウォームアップといったベストプラクティスを確認し、クライアントライブラリの設定値にも目を向けてみることもお勧めです。小さな調整が、システムのパフォーマンスを飛躍的に向上させる鍵となるかもしれません。