ベルリンを拠点とするグローバルモバイル計測および不正防止企業のAdjust GmbH(以下Adjust)は、1分間に約5200万件のリクエストを処理し、約450億件のレコードを保存しています。
Adjustは、2024年6月に開催されたThe Real-Time Data Summitバーチャルイベントで、同社の成功事例について講演してくれました。
本記事では、同社のチームが採用した戦略や膨大なデータセットマネジメントから学んだ教訓、そしてRedisからAerospikeに移行した経緯を探ります。
規模の理解
Adjustは、ソーシャルメディアプラットフォーム全体でのユーザーインタラクションを監視することにより、クライアントのマーケティングチャネルの効果を追跡する支援を行っています。
「クライアントはキャンペーンを作成し、Facebook、Twitter、LinkedIn、TikTok—人々にマーケティングしたいどこにでも配置します」と、同社シニアソフトウェアエンジニアのBubunyo Nyavorは説明します。
「私たちは、人々がこれらのキャンペーンリンクをどのようにクリックしているか、そしてこれらのキャンペーンリンクが使用しているプラットフォームに応じてどのように変換されているかを追跡する手助けをしています。」
これらの毎分約5200万件のリクエストのそれぞれが、リアルタイムで保存・処理する必要のあるデータを生成します。
そして、このリクエスト量は堅牢でスケーラブルなデータベースを必要であることを意味します。
Redisの課題解決：Aerospikeのパワーを探る
450億件のレコードを処理するためのAdjustのデータストレージのスケーリングには課題がありました。
それは、アップグレードと運用モードの理解に関してです。
同社がRedisを使い始めた当初は、32 GBのRAMと2 TBのHDDストレージを持つ単一のサーバーで、Adjustの1秒あたり40,000リクエストの負荷を容易に処理できました。
実際、その時点では、サーバーは過剰なプロビジョニングでした、とAdjustのエンジニアリング担当VP、Robert Abrahamは以前のサミットで述べています。
会社が成長し始めた初期は、最大384 GBのRAMまでサーバーにメモリを追加することで対応できました。
しかし、最終的にはハードウェアの制限に直面したのです。
シングルスレッドデータベースとして、Redisはマルチコアのメリットを活かせません。
また、単一のサーバーが保持できるメモリ量にも物理的な制限がありました、とAbrahamは説明しました。
その時点で、Adjustは「センチネルモードで起動された複数のRedisインスタンスで構成された分散システム」であるRedis Sentinelを追加し、単一のサーバーからRedisクラスターへと移行しました。
これは、しばらくの間機能したものの、レイテンシーとキャッシュミスの問題も発生し始め、運用オーバーヘッドが増加しました。
「Redisはまだインメモリデータベースであり、私たちの絶えず成長するデータセットをRAMに保持するコストが爆発的に増加していました」とAbrahamは言いました。
「より多くのRAMが必要になり、それはかなり高価でした。また、書き込みが増加したため、ピーク時にはレイテンシーと不安定性が増加しました。これはまた、レプリケーションストリームが追いつかないことを意味し、全体として、私たちにとって理想的ではない状況を生み出しました。」
まず、Aerospikeのアーキテクチャはクラスタリングをネイティブにサポートしていますが、Redisは追加のSentinelコンポーネントと別の設定を必要とします。
次に、Aerospikeははるかに少ないメモリでリアルタイムのパフォーマンスを実現できます。
例えば、インデックスをメモリに置き、実際のデータをディスクに置くことができます。
「これは、データの大部分を[Redisのコストの]10分の1のコストのストレージに保持できることを意味します」とAbrahamは述べます。
結果、必要なサーバー数を40台から6台に削減できました。
「インフラコストを約85%削減でき、保守の必要性も大幅に減りました。新機能や製品を開発するためのリソースがより多く利用可能になり、データが増加しても操作のレイテンシーは安定していました。」
新しいインフラストラクチャとセットアップ
現在、同社のデータストレージインフラストラクチャはAerospike上に構築されています。
45億件のレコードを管理するために、Adjustは世界中の3つの論理データセンターにAerospikeクラスターを展開しました。
「各データセンターには、Gentooオペレーティングシステムを実行するベアメタルセットアップで動作する約64ノードを持つAerospikeクラスターがあります」とBubunyoは説明します。
ハードウェアには、各ノードに平均70個のCPU、400 GBのRAM、約16 TBのハードディスクが含まれています。
この構成により、高可用性と冗長性が確保されます。
Adjustは、ユースケースに応じて、一部のネームスペースでは複製係数2を、他では3を使用しています。ここでAerospikeの柔軟性の恩恵を受け、重大なデータ損失なしに障害に対処できます。
「3つのデータセンターすべてがクロスデータセンターレプリケーション（XDR）を使用してセットアップされています」とBubunyoは言います。「これはメッシュアクティブ-アクティブトポロジーで、1つのクラスターに到達したリクエストが、バックアップされる別のクラスターに送信されます。」
低レイテンシーと一貫性のための設計
XDRはまた、Adjustがレイテンシーを管理するのにも役立ちます。
「私たちはレイテンシーに多大な注意を払う必要があります」とBubunyoは言います。
1つのデータセンターにリクエストが来て、次のリクエストが次のデータセンターに行く場合、高いレイテンシーは各リクエストが別個のエンティティとして見なされることを意味します。
「これをベースに構築するのが難しくなります。」
さらに、高いレイテンシーはフェイルオーバーを問題にします。
なぜなら、潜在的に、すべてのデータが他のデータセンターへの複製のために送られないからです。
Aerospikeを使用すると、現在、会社のリクエストの50%が500マイクロ秒未満で処理されるとBubunyoは言います。
「私たちがクエリするデータの膨大さとクラスターの規模を考えると、これは実際にかなり印象的です。」
強一貫性と可用性モード
分散データベースアーキテクチャは一貫性と可用性のバランスを取る必要があり（CAPの定理による）、特定のタスクは一方をより多く必要とします。
しかし、Aerospikeを使用することで、Adjustはニーズに応じて両方を可能にします。
「一貫性を可用性よりも重視するデータセットもあれば、可用性を一貫性よりも重視するネームスペースもあります」とBubunyoは説明します。
「Aerospikeはこれらの両方の運用モードを可能にし、私たちは異なる理由で異なるネームスペースに対してそれらを使用しています。すべての設定を理解することが、この野獣のような技術を活用するための鍵となります。Aerospikeは、クラスターを要件に合わせて管理するために必要な細かい制御を提供してくれます。」
混合ワークロード全体での効率的なデータ操作
Adjustはデータセットに対していくつかの種類のデータベース操作を実行します。
「各リクエストはAerospikeで操作を呼び出します」とBubunyoは言います。
「操作の内容に応じて、データを取得したり、データを書き込んだりします。時にはバッチで書き込み、時には削除し、そしてこれらのリクエストに対する応答を返します。」
読み取りと書き込み操作
Adjustは1秒間に100万回以上の読み取りと書き込み操作を実行し、各クリックと各インプレッションに対して書き込みを行い、アトリビューション操作を強化し、これらの読み取りをクライアントに提供します。
混合ワークロード全体でのAerospikeのパフォーマンスを高く評価し、実際に読み取りよりも書き込みの方が多くなっています。
同社はSmart Clientsを活用して適切なノードにリクエストをルーティングし、効率的な分散と高いスループットを実現しています。
Smart Clientsは「クラスターを認識し、各リクエストをパーティションのリーダーであるノードに送信します」とBubunyoは説明します。
「このようにして、リクエストを送信する必要があるノードにのみリクエストを送信することで、分散ノードと高スループットを実現できます。」
インデックス管理
すべてをメモリに保存し、結果として高いインフラコストを課す一部のデータベースとは異なり、AerospikeはAdjustがセカンダリインデックスをNVMeとSSDに保存することを可能にし、コストとパフォーマンスを最適化します。
「我々はこのメリットを活かして、セカンダリインデックスをNVMeとSSDに保存しています。そうしなければ、メモリ内に持つインデックスの数を保存するために高い代価を払わなければなりません」とBubunyoは言います。
特定の操作における優先度の低下
さらに、定期的にデータセットをスキャンし、古くなったり関連性のなくなったレコードを削除するためのデータメンテナンスとコンプライアンスを行っています。
合計352テラバイト（TB）です。これらのリソース集約型スキャンは、リアルタイム操作への影響を最小限に抑えるように管理する必要があります。
「クラスター全体のスキャンには約3日かかり、スキャンにはたくさんのリソースが必要なため、非常に遅く集中的なプロセスです。幸運なことに、Aerospikeは’get’や’write’操作よりもスキャンの優先度を下げるのに役立ちます。」
スケーラビリティを問題にしないために
リアルタイムのユースケースで450億件のレコードを保存し管理するには、堅牢なインフラストラクチャ、インテリジェントなデータ操作、一貫性と可用性の間の戦略的トレードオフの組み合わせが必要です。
Aerospikeを使うことで、Adjustは急速に成長する顧客ベースの不正対策とマーケティング努力を最適化するための、スケーラブルで高性能なシステムを構築しました。
トライアルはこちら
