Virgin Media O2（VMO2）、Memorystore for Redis により数十億レコードの分析をミリ秒未満のレイテンシで実現
Google Cloud Japan Team
※この投稿は米国時間 2023 年 12 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。
Virgin Media O2（VMO2）は英国有数の通信プロバイダであり、ブロードバンド、モバイル、テレビ、固定電話といったサービスを展開しています。同社の優れたネットワークを利用しているユーザー数は 4,600 万にも上ります。非常に高速なインターネット速度を実現するブロードバンド インフラストラクチャと併せて、大規模で信頼性の高いモバイル ネットワークを提供することで知られています。
3 年前、VMO2 はデータ プラットフォームのモダナイズに着手し、従来のオンプレミス プラットフォームから Google Cloud 上に構築された統合データ プラットフォームに移行することを決断しました。このクラウドへの移行には、複数の Hadoop ベースのシステム、データ ウェアハウス、オペレーショナル データストアが含まれていました。
移行する主要なデータ プラットフォームの一つは Netpulse システムです。これは、顧客のネットワークとパフォーマンスの全体像を把握できる、ネットワーク データの分析およびモニタリング サービスで、利用頻度が非常に高いものです。
Netpulse は複数のソースシステムを組み合わせていますが、システムの核となるのはウェブログとロケーション フィードをニア リアルタイムで組み合わせることであり、GDPR やその他のデータ プライバシー ポリシーを確実に遵守するために匿名化されたデータを使用しています。ウェブログとロケーション フィード データセットは、ネットワーク分析と顧客分析の両方にとってどちらもそれぞれ大きな価値を持っています。これらのデータセットを融合して一元的な視点を持つことで、ネットワーク パフォーマンスの最適化、カスタマー エクスペリエンスの向上、発生し得る運用上の課題への迅速な対処など、VMO2 の能力強化の可能性が広がります。要するに、この強化は、より多くの情報に基づいたレスポンシブなネットワーク エコシステムへの極めて重要な一歩であり、VMO2 とその顧客の双方に多大な恩恵をもたらします。
Google Cloud チームは、Netpulse システムの精度、スケーラビリティ、レジリエンス、信頼性を向上させるため、クラウドベースのニア リアルタイム / リアルタイム システムへの移行に意欲的に取り組んでいました。ただし、まずは Google Cloud の高いパフォーマンス要件に基づいて、最適なサービスを見つける必要がありました。
オンプレミス Hadoop のスケーラビリティとレイテンシに関する課題
VMO2 は、増え続けるデータ量に既存のオンプレミス Hadoop クラスタで対応することに苦労していました。Hadoop はウェブログとロケーション フィードの両方を現在値でキャプチャしていますが、以下のような課題があったため、これらのフィードのリアルタイム分析は不可能でした。さらに、このシステムには障害復旧機能がなく、プラットフォームが停止した際には、データが長期間利用できなくなり、ダウンストリーム分析の使用に影響が出ていました。
既存のオンプレミス インフラストラクチャには、おおまかに次の課題が見られました。
- スケーラビリティの欠如
- 容量に限りがある
- 高額なアップグレード
- ソフトウェア ライセンスのコスト
- データセンターの拡張に制約がある
システムのサイジング
ソリューションを選択する前に、既存システムの範囲とパフォーマンス要件を理解する必要がありました。
VMO2 では、モバイル顧客のウェブ トラフィック アクティビティをウェブログで報告しており、これにはレイヤ 4 とレイヤ 7 両方でのやり取りが含まれます。ウェブログは毎日約 2.5 TB を生成する膨大なデータセットで、ピーク時には 15 億レコードが読み込まれて別のデータセットと結合されます。もう一つのアプリケーションである Mobility Management Entity（MME）は、コントロール プレーン データを生成し、VMO2 のモバイル顧客の地理的位置に関するリアルタイムの分析情報を提供します。MME では毎日さらに 2.1 TB のデータが生成され、ピーク時には 1 時間あたり 9 億回の書き込みが行われます。このユースケースでは、すべての受信ウェブログ レコードを MME データと結合しながら処理し、新しい MME レコードを保存して素早く検索できるようにする必要がありました。
ピーク時の 1 時間あたりの数値を見て、システムで以下をサポートする必要があると判断しました。
- ウェブログから読み込まれる 15 億レコード（1 秒あたり 42 万レコード）
- MME から書き込まれる 9 億レコード（1 秒あたり 25 万レコード）
これは、ピーク時にシステムが 1 秒あたり約 67 万回のオペレーションをサポートする必要があることを意味します。さらに、ヘッドルームを確保するために、1 秒あたり 75 万回のオペレーションをサポートできるようにサイズアップしたいと考えました。
また、Netpulse はニア リアルタイムのデータ変換を実行できる必要がある一方で、最大 10 時間（これを過ぎると MME レコードの有効期限が切れる）経過した MME データのルックアップも実行します。各 MME レコードのサブセットのみを保存する必要があり、サイズはレコードあたり 100 バイトほどです。ここで留意すべき点として、この 10 時間前のデータは、時折更新される同じ一意のレコードで構成されているため、全体のストレージ サイズとしてピーク時の 10 倍が必要というわけではありません。
つまり、各 MME レコードから保存する必要があるのは 100 バイト未満であり、そのときのすべてのレコードが一意であった場合、ピーク時には合計 9 億 × 100 バイト、つまり 90 GB になります。したがって、最大ストレージ要件はこの数値の 2 倍、つまり 10 時間に対して 180 GB に設定しておけば安全です。
これらの要件を満たすため、Key-Value ストアと高速検索サービスの両方の機能を備えたサービスが必要であると判断しました。システムの読み取り / 書き込み比率は少なく見積もって 2:1 で、3:1 まで増加する可能性がありました。また、このサービスは本番環境で 24 時間 365 日稼働する必要があるため、スケーラブルで耐障害性に優れた高スループットのシステムも必要でした。
ソリューションの選択
つまり、Netpulse には次の要件を満たすデータ ストレージと処理ソリューションが必要でした。
- ニア リアルタイムのデータ変換
- 過去のデータのルックアップ機能
- 高スループット
- スケーラビリティ
- フォールト トレランス
- 24 時間 365 日の可用性
パフォーマンスと可用性に関してこうした厳しい要件があることから、マネージド データベース サービスはいくつかの選択肢に絞られました。最終的に Google Cloud チームが選択したのは Memorystore for Redis でした。理由としては、ミリ秒未満のレイテンシで 1 秒あたり数百万回のオペレーションにまで簡単にスケールアップでき、高い SLA を提供できることに加えて、次のような点も挙げられます。
- ディスクベースのストレージを使用する代わりに、高速なメモリ内キャッシュを使用できる
- 並べ替え済みセットなど、理解しやすいストレージ セマンティクスを備えている
- 単一の Redis ノードでの小規模（1 KB 未満）の読み取り / 書き込みの場合、1 秒あたり 10万 リクエストまで拡張可能
- VMO2 チームが使い慣れている
さらに、データが充実したら、詳細な分析のために分析ストアに保存する必要があります。Google Cloud チームは、このデータセットと他のデータセットの分析を強化するために BigQuery を選択しました。
同様に、リアルタイムでデータを処理でき、需要に合わせてスケールできるという理由から、Dataflow を選びました。BigQuery 外部のアドホックなデータ処理については、すでに Dataflow を標準化していました。
Memorystore for Redis によるスケールの実証
処理されたデータを BigQuery のようなデータ ウェアハウスに保存することは、スケーリングの観点からは決して難しいことではありませんでした。また、たとえ大規模であっても、Dataflow によるデータ処理自体も難しくありませんでした。ただし、受信データの処理中に高速ルックアップを実行することは大きな課題であり、アーキテクチャを決定する前にそれを実証したいと考えていました。
まずは単一ノードの Memorystore for Redis インスタンスから始め、徐々にメモリを追加して、特定のメモリ量に対する最大書き込み量を把握しました。
Redis パイプラインを使用して、読み取りと書き込みの両方のリクエストをバッチ処理しました。このユースケースでは、書き込みと読み取りのデータサイズが小さかったため、Redis パイプラインが必要でした。このような少量のデータをネットワーク経由で送信すると、各 redis コマンドに関連するネットワーク ラウンド トリップにより、レコードごとのレイテンシが低下し、全体のスループットも低くなります。
レコードサイズが 100 バイト未満だったので、さまざまなテストを行った結果、パイプライン サイズとして 10,000 を採用しました。つまり、一度に約 1 MB のデータを Redis に送信できることになります。
処理される ZADD コマンド数
上図の緑色の線が ZADD
プライマリ インスタンスのメモリ使用量
ピンク色の線がインスタンスのメモリ、青色がメモリ使用量
テストの結果、予備容量で 1 秒あたり 10 万～11 万件の書き込みを処理できるため、64 GB が理想的な Redis インスタンス サイズであることがわかりました。
この情報から、毎秒 25 万件の書き込みをサポートするには、少なくとも 3 つの Memorystore for Redis インスタンスが必要で、それぞれにプライマリ ノード（および読み込みをサポートするためのリードレプリカ ノード）が必要であることがわかりました。
次に、読み取りと書き込みの同時オペレーションでシステムのパフォーマンスをテストしました。これにより、毎秒 50 万回の読み取りと 25 万回の書き込みをサポートするために必要なノード数を決定できました。
2 つのリードレプリカに対する ZREVRANGE 呼び出し
青色の線は 2 つのリードレプリカに対して実行された ZREVRANGE コマンドを示している
2 つのリードレプリカを持つ Memorystore for Redis インスタンスは、ノードごとに 1 秒あたり 20 万件の読み取りリクエスト、つまり 1 秒あたり合計 40 万件の読み取りリクエストを簡単に処理できました。
パフォーマンス テストの結果、本番環境には 3 つの Redis インスタンスが必要で、各インスタンスには書き込み用にプライマリ 1 つと読み取り用にリードレプリカ 2 つが必要であると判断しました。3 つのインスタンス間で書き込みをシャーディングするために、コンシステント ハッシュ法を使用しました。このインフラストラクチャは、1 秒あたり 30 万回の書き込みと 120 万回の読み取りを簡単に処理でき、このユースケースには十分な容量です。このバッチ ワークロードのレコードごとのレイテンシを計算すると、100 マイクロ秒未満のレイテンシになります。
このユースケースに必要なノードの総数は 9 つで、3 つの Redis インスタンスにまたがっており、それぞれに 1 つのプライマリと 3 つのリードレプリカが含まれます。
- プライマリごとに 1 秒あたり 10 万回の書き込み x 3 = 1 秒あたり 30 万回の書き込み
- レプリカごとに 1 秒あたり 20 万回の読み取り x 6 = 1 秒あたり 120 万回の読み取り
このアーキテクチャを証明するための詳細な概念実証のパターンは github で確認できます。
次のステップ - Memorystore for Redis Cluster
上で説明した Memorystore for Redis インスタンスを使用したアーキテクチャでは、プライマリ書き込みノード 1 つと複数のリードレプリカで十分に賄えるため、必要なスループットを達成するためにコンシステント ハッシュ法を使用する前述の設計に至りました。
また、最近の一般提供開始の前に、当初の設計で使用した方法論に従って、Memorystore for Redis Cluster をテストし、1 時間分の持続的な書き込みと読み取りの負荷に対してインフラストラクチャをテストしました。さまざまなシャード数でテストし、最終的に Memorystore for Redis Cluster インスタンスのシャードは 20 に落ち着きました。これにより、260 GB 以上の RAM が使用可能になり、シャーディング アーキテクチャよりも大幅に高いパフォーマンスが実現しました（以前の設計では、書き込みで RAM 192 GB、読み込みでそれを大きく上回る RAM を使用しており、この書き込み負荷をサポートするために、64 GB の Redis インスタンス 3 つとプライマリ 1 つが必要でした）。
さらに、Memorystore Redis Cluster の 99.99% の SLA により、シャードと呼ばれる複数の書き込みノードを簡単にプロビジョニングできます。これにより、スケーラビリティと信頼性が向上し、開発チームは Redis のインフラストラクチャ管理やキーのシャーディングよりも、重要なビジネス上の問題解決に集中できるようになります。
Memorystore for Redis Cluster のテスト
私たちは、Memorystore for Redis Cluster の広範なテストを実施し、クラスタがレコードごとの適切なレイテンシでスループットを処理できることを確認しました。
クラスタのメモリ使用量
テスト中にメモリ使用量が約 2～3% から 68% に増加していることがわかります。
クラスタでの読み取り / 書き込み呼び出し
青色の線は実行された読み取り（ZREVRANGE）コマンド、青緑色は書き込み（ZADD）コマンド
上図が示すように、25 万回以上の書き込みと 50 万回以上の読み取りの負荷を約 1 時間、余裕をもって処理できました。テスト中、単一コマンドの実行時間は依然として 100 マイクロ秒前後でしたが、メモリ使用量は 70% をはるかに下回っていました。言い換えると、クラスタを限界まで酷使してはいないということです。
この Memorystore for Redis Cluster の設計には、いくつかの利点があります。
- 水平方向のスケーリング - Redis クラスタのパフォーマンスは、クラスタにノードを追加するにつれて直線的にスケールされます。これは、垂直方向のスケーリングによって書き込みのリターンが減少するスタンドアロンの Redis とは対照的です。
- フルマネージド スケーリング - プライマリを追加する際に手動でキーを再シャーディングするのではなく、プライマリ数の増加に合わせて Memorystore for Redis Cluster が自動的にキーを再シャーディングします。
- SLA が 99.9% から 99.99% に向上しています。
- 大幅な費用の削減とパフォーマンスの向上 - 9 x 64 GB ノードから 20 x 13 GB ノードに変換することで、総費用を約 66% 節約でき、パフォーマンスは 3 倍向上しました。
Memorystore for Redis Cluster のこの結果から、本番環境で使用できるという確信を得て、先日ついに一般提供を開始できました。
Memorystore for Redis により大規模な分析を実現
Memorystore への移行により、ウェブログと MME データをリアルタイムでシームレスに統合するための基盤が整いました。この重要な開発により、VMO2 は、フルマネージド サービスへのオフロード、スケーラビリティ、SLA を満たす高耐久アーキテクチャなど、この革新的ソリューションに付随する幅広い機能を活用できるようになりました。同時に、Memorystore の強力な機能を使用できるように、チームのトレーニングにも注力しています。これにより、リアルタイム分析と超高速データ取り込みを前例のない規模と速度で実行できるようになります。また、ネットワーク パフォーマンス モニタリングやスマート メーターなど、いくつかの分析ユースケースで、Memorystore とともに BigQuery を使用する準備も整っています。
Memorystore for Redis Cluster の詳細については、ドキュメントをご覧ください。コンソールにアクセスすれば、すぐに利用を開始できます。
ー Google Cloud、データ分析スペシャリスト、Ravi Bhatt
ー VMO2、データ エンジニアリング担当シニア マネージャー、Chandu Bhuman 氏
