事例公開日：2022年1月20日
オスロに本社を置くOperaは、Webのイノベーションをグローバルに展開するNASDAQ上場企業です。数億人規模の月間アクティブユーザーが、優れたインターネットエクスペリエンスを求めて増え続けています。Operaは現在、PCやモバイルブラウザ、ニュースリーダーのOpera Newsのほか、ゲーム、eコマース、クラシファイドに特化したアプリなど、多様な製品とサービスを世界中のユーザーに提供しています。
また誕生から2年が経過したOpera Adsも存在感を増しています。Opera AdsはOperaのグローバルなサービス群と製品ポートフォリオ、そしてパートナー企業のサービスをベースにして、世界中の何百万人ものOperaユーザーに、コンテンツベースの革新的な広告エクスペリエンスを提供しています。
この記事では、Opera Adsがデータ管理プラットフォーム（DMP）に関する課題を解決するうえで、分散SQLデータベースであるTiDBがどのように役立ったかを見ていきます。
Operaのビジネス上の課題を把握する
Opera Adsでは当初、バックエンドストレージをMySQLで構築していました。しかし処理が必要なデータ量が膨大になり、MySQLでは要求に応えられなくなってしまいました。ここで必要になるのは、DMPに十分に対応できるだけの優れたデータ管理ソリューションですが、主に2つのシナリオに関連する課題がありました。
- オーディエンス分析: このビジネスシナリオでは、Opera Adsがジェンダー、年齢、国籍、言語などのタグを設定して、ターゲットオーディエンス数を推計します。この推定値に基づいて、広告の対象となるオーディエンスの範囲と数を把握します。
- ターゲティング: このシナリオでは、ユーザープロファイルデータや、関心や好みなどに関するファーストパーティシグナルを活用して、Opera Adsが広告のターゲティングを行います。そしてDMPがデータの分類と分析を行い、Opera Adsがターゲティング設定を更新して、類似する広告がターゲットオーディエンスに繰り返し配信されるようにします。
データ量の爆発的な増大
これら2つのシナリオに共通する大きな課題は、高頻度の読み取り/書き込みに起因する、データ量の幾何級数的な増大です。たとえば、大規模なテーブルでは何兆行ものデータを扱う必要があり、全体のデータ量が10 TBに達する場合もあります。
リアルタイムの計算
オーディエンス分析では、数秒でオフラインとリアルタイムの計算を行い、ターゲティング広告の対象にすることができるオーディエンス数を特定します。広告事業者はこの計算結果に基づき、広告の構成の妥当性を確認したうえで掲載できます。
ソリューションを選ぶための調査
Opera Adsはストレージと計算に関するニーズを基準にして、MongoDB、Hbase、Hbase+ES、ClickHouseなどのデータベースソリューションについて調査しましたが、どれも要求を満たすものではありませんでした。そしてさらに調査とテストを行った結果、最終的に選んだのがTiDBでした。
MONGODB
Operaは他のプロジェクトで、データの保存と分析レポートの作成にMongoDBを使用していました。しかしデータ量が増大するに従い、パフォーマンスが急速に低下することがわかりました。データの行数が1兆を超えた時点で、MongoDBのパフォーマンスでは、Opera Adsが必要とする大規模なストレージとリアルタイムの計算には対応できないことが判明しました。
HBASEとESの組み合わせ
Opera Adsは、MongoDBをHBaseに置き換えて、ユーザーデータをHadoopに保存することも検討しました。HBaseは大量のデータに対応できますが、その使用と維持が比較的複雑なデータベースです。多数の変動要素を調査する必要があるため、トラブルシューティングにも手間がかかります。
これに加えて、Opera Adsはリアルタイムの計算用にElasticSearch（ES）も試してみました。高いパフォーマンスを維持しながらESを通じてクエリを行うには、キャッシュ用に大量のメモリを必要とします。HBaseとESを併せて使用すると、コストが増大してしまいます。Opera Adsが求めているのは、ストレージのスケーラビリティに優れたSQL指向のソリューションでした。そのため、HBaseとESの組み合わせも要件にかなうものではありませんでした。
CLICKHOUSE
広告業界で広く使用されているClickHouseは、Opera Adsにとっても魅力のあるソリューションでした。それは、オーディエンス分析でのリアルタイム計算で大量に使用されるビットマップが、ネイティブでサポートされているためです。ClickHouseでは、データをビットマップとして直接保存できるのです。CMS（コンテンツ管理システム）で、2つのビットマップに対応するユーザーグループの共通項や全体についてクエリを行う場合にも、基盤にあるデータベースから直接ビットマップを読み取ることができます。
しかし、ClickHouseはOLAP（オンライン分析処理）用に設計されたものであり、データの更新処理には対応できません。Opera Adsではユーザーデータを毎日更新する必要があります。全体の挿入処理よりも更新処理のほうが多いことから、ClickHouseもニーズに適したものではありませんでした。
最終的な選択: TIDB
TiDBについてOpera Adsは当初、「水平的なスケーラビリティを備えた大規模なMySQLデータベース」であると認識していました。その時点ではTiDBがニーズを満たすものであるか判断できなかったため、まずはTiDBとMySQLの比較を行いました。TiDBは特に高速であるとは言えませんでしたが、データ量が増加してもパフォーマンスが安定していました。たとえば、テスト時のテーブル数が100万行から1兆行に増えたときにも、全体的なパフォーマンスのばらつきは小さなものでした。つまり、スケーラビリティとパフォーマンスの両方の問題を解決できるソリューションであるということです。
Opera AdsがTiDBに注目したもう一つの大きな要素は、TiDBとビットマップの組み合わせが、ビットマップを使用したリアルタイム計算に大きく依存するビジネスシナリオによく適合することでした。またTiDBはMySQLとの互換性を備えているため、習得のためのコストや運用コストが新たに発生しないことも魅力でした。
Opera Adsは、テストを開始してからわずか1週間後にTiDBの導入を決めました。
TiDBの導入と最適化
TiDBのテスト
Opera AdsはTiDB 2.14を導入しましたが、さまざまな課題に直面することになります。TiDBをインストールしたところ、SSDのものを含め、さまざまなマシンでのパフォーマンスをテストする、プリインストールスクリプトの処理が必要になったのです。このスクリプトは、純粋な読み取り処理の場合に40,000 OPS（1秒あたり処理数）、またランダムな読み取り/書き込み処理に10,000 OPSを必要としました。しかしその時点のマシンは、ハードウェア構成が十分でなく、パフォーマンスチェックにも合格しないものでした。Opera Adsは、TiDBを再利用可能な仮想マシンにインストールすることになります。そしてさまざまな調整を行った結果、純粋な読み取りOPSが20,000に、ランダムな読み取り/書き込みOPSが3,000にまで低下し、すべてのマシンがパフォーマンスチェックに合格しました。
最適化
Opera AdsはTiDBの導入後、いくつかの最適化を行っています。たとえば、シリアルスキャンによって完全なテーブルスキャンを行った場合のパフォーマンスが低かったことも一因です。オフライン計算では、完全なスキャン、あるいは数十兆の行数がある4つまたは5つのテーブルのスキャンが必要でした。最大級のテーブルには30を超える列がありました。このように大きな負荷が発生するため、オフライン計算には3～4日かかっていました。そこで並行処理を強化してスキャンを行うようにしたところ、パフォーマンスが最適化されました。たとえば、32のスレッドを使用して1兆行のテーブルをスキャンし、各スレッドのスキャン数が全体の1/32になるようにしたのです。この方法をとったところ、TiDBのパフォーマンスが向上し、オフライン計算でも安定性が得られました。現在では、TiDBはOpera Adsでのデータ増大に十分に対応できるようになっています。
最終的なアーキテクチャ
Opera AdsはTiDBの導入後、TiDB、ビットマップ、Redisを組み合わせてアーキテクチャを構築することにしました。オーディエンス分析シナリオでは、リアルタイム計算によってターゲットオーディエンスの範囲を特定しますが、ビットマップ関連のターゲット広告ではオフライン計算を使用します。
次の図は、Opera Adsの広告ビジネスのデータ処理アーキテクチャを示しています。各種のソースから取得したデータがTiDBに書き込まれると、そこから2つのフローに分かれます。1つのフローは、Operaが開発したオフライン計算ツールであるTag Toolsを使用するものです。TiDBは、関連するすべてのデータをこのツールに書き込みます。そのデータはRedisによってオフラインでキャッシュされ、DMPサーバーでオフライン計算が実行されて、ユーザープロファイルデータが広告エンジンに渡されます。Redisから最終的なデータを読み取ることで、広告エンジンはデータをリアルタイムで取得できます。ユーザーデータには多数のソースがありますが、各種のチャネルを通じて送信されたデータは、最終的にTiDBに取り込まれるほか、一部のデータはRedisに直接書き込まれます。TiDBは、ユーザー数1兆、約2 TBのデータとなる、すべてのユーザーデータとタグデータを保存します。
Opera AdsのDMPアーキテクチャ
TiDBは、リーチされたオーディエンスの計算にも使用されています。広告事業者がOpera Adsプラットフォームで広告キャンペーンを設定すると、ビットマップに基づくリアルタイム計算によって推定オーディエンス数が直ちに示されます。データベース内の各タグはビットマップに対応しており、各ビットマップにはすべてのユーザーが同じタグの下で保存されます。ビットマップはTiDBからのデータに基づいてオフラインで生成され、1つのファイルに保存されます。このビットマップファイルをCMSメモリに読み込んで、オーディエンスのリアルタイム計算を行います。そして数秒以内に計算結果が得られます。
Opera AdsでTiDBを使用するメリット
使用と維持が簡単
Opera AdsにはMySQLとの互換性があるため、習得のための追加コストを必要とせずに、TiDBを容易に導入できました。TiDBには非常に強固なコミュニティエコシステムがあるため、コミュニティの支援によってほとんどの問題がすみやかに解決します。さらに、導入、運用、アップグレードの各フェーズでは、PingCAPがテクニカルサポートをタイムリーに提供することができます。
シャーディングを必要とせずに水平的かつ弾力的なスケールアウトが可能
もう一つの明確なメリットは、Opera AdsのDBAでテーブル内のデータ量を気にする必要がなくなったことです。MySQLを使用していたときは、テーブルのデータ量が過大になっていないか、あるいはテーブルのシャーディングが必要かどうか、常に注意していなければなりませんでした。シャーディングはコードを記述するデベロッパーにとって負担であるばかりか、DBAでのトラブルの原因にもなります。TiDBを導入して以降、Opera Adsではこれらの問題が解消されました。
分析シナリオにおけるリアルタイム計算
TiDBは分析シナリオでも威力を発揮します。Opera Adsのビジネスシナリオではほとんどの場合、大量のデータの分析が必要になります。データが増大するにつれ、読み取り/書き込みのパフォーマンスに対する影響も大きくなります。そのようなシナリオでスタンドアロンのデータベースであるMySQLを使用すると、データが膨大になったときに計算に時間がかかり、デメリットが目立つようになります。結局MySQLでは単一点での計算しかできないため、OOM（メモリ不足）エラーが避けられません。
TiDBの場合は、データが増大しても読み取り/書き込みのパフォーマンスが安定しています。加えて、TiDB 5.0で導入されたMassively Parallel Processing（MPP）機能により、リアルタイムシナリオにおけるパフォーマンスはさらに向上しました。
将来的な展望
TiDBコミュニティによる継続的なサポートにより、Opera AdsはTiDBのバージョンを2.14から4.0にまでアップグレードすることができました。今後はハードウェアをアップグレードしたうえで、TiDB 5.0への完全なアップグレードを計画しています。TiDB 5.0は現行バージョンに比べて、パフォーマンスと安定性がさらに向上しています。Operaのシニアエンジニアリングディレクター、Yuanlin Zhou氏は次のように述べています。「Operaでは、TiDBのHybrid Transactional and Analytical Processing（HTAP）機能を通じて、データ管理プラットフォーム全体のアップグレードを行うことを目指しています。それにより、当社の広告プラットフォームはさらにリアルタイムなものになり、また正確性と効率性が向上することでしょう。」
