MLB がファンと試合のつながりを維持する方法 - 一度に 1 つのキャッシュ ヒットを

※この投稿は米国時間 2025 年 8 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: Major League Baseball（MLB）は、球速から選手のポジションまで、あらゆるデータをトラッキングして、リアルタイムで数百万人のファン、アプリ、放送局に配信しています。これに対応するため、Baseball Data Platform チームは、Google Cloud のフルマネージド インメモリ データサービスである Memorystore for Valkey を採用しました。これにより MLB は、1 日に何十億件ものリクエストを処理し、数秒でサービスの停止から復旧し、インフラストラクチャ管理よりもイノベーションに注力できるようになりました。

野球には「1 インチの差が勝敗を分ける」という言葉があります。ボールが数本の芝生の上に着地すればフェアボールとなったり、ランナーのスパイクの端がベースに触れることでセーフになったりするなど、わずかな差がすべてを変えることがあります。

Major League Baseball（MLB）の Baseball Data Platform チームにとっても、ミリ秒単位の戦いです。私たちのチームは、MLB のデータ配信プラットフォームのバックボーンである Stats API の構築と保守を担当しています。Stats API により、ライブ試合のトラッカーから放送局向けのグラフィック、社内アプリなど、あらゆるものを実現しています。忙しい日には、エッジで約 100 億件のリクエストを処理し、ピーク負荷時には 1 秒あたり 15,000 件の API リクエストを処理します。

アプリ、スタジアムのスクリーン、自宅のセカンド スクリーン エクスペリエンスのいずれからでも、ファンにデータが正確かつ瞬時に表示されるようにするのが私たちの仕事です。そしてMemorystore for Valkey がその実現に一役買っています。

基礎データを読み込むとキャッシュが満杯に

当初、キャッシュ レイヤは、セルフマネージドの Memcached VM 上に構築されていました。ですが、データのニーズが進化するにつれて、システムへの負荷も増大しました。VM での処理が失敗すると、キャッシュに保存されたデータが失われ、復旧に数時間かかることがありました。その間、トラフィックをバックアップ リージョンに転送してキャッシュを再構築しますが、2 回目の障害が発生するリスクは高まります。

この状況の中、データはより複雑になっていました。私たちはフィールドから大量のテレメトリーをストリーミングしていました。これには、各アスリートの体に 29 個のポイントをマッピングして得られる選手の動きのデータが含まれており、3D 空間で 30 フレーム/秒で取得されます。このデータの膨大な量と速度により、当社のスタックの限界が試されることになったのです。

このような経緯を経て、私たちは Valkey をベースに構築された Google Cloud のマネージド インメモリ サービスである Memorystore for Valkey を採用することにしました。まず際立っていたのは、組み込みの高可用性、クロスリージョン レプリケーション、ダウンタイムなしでクラスタをスケーリングできる機能でした。そしてマネージド サービスであるため、キャッシュ インフラストラクチャのメンテナンスに追われていたチームが、キャッシュ インフラストラクチャを中心としたエクスペリエンスの最適化にようやく注力できるようになりました。

Memorystore for Valkey でフィールドをカバー

現在、最も重要なデータフローの一部は Memorystore for Valkey を介して実行されています。Memorystore for Valkey を最大限に活用するために、3 つの主要なユースケースを中心にキャッシュ戦略を開発しました。

1. 球場バッファリング

これは、Google Distributed Cloud に直接スタジアム レベルで導入したエッジレイヤ キャッシュ保存システムです。ここでは、オペレーターが生成したメタデータとリアルタイムのトラッキング データを処理して一時的に保存してから、クラウド サービスにプッシュします。このシステムでは、Memorystore for Valkey はメッセージ バッファとして機能します。これにより、球場のシステムとバックエンドの間に保護レイヤが設けられます。この方法のおかげで、ネットワークに一時的な問題が発生してもデータが失われることはありません。接続が復元されたら、再度キャッシュからデータを取得するだけです。

私たちはこれを Valkey 8.0 で実行しており、試合中のレイテンシは 1 ～ 2 ミリ秒と低く、ピーク時のコマンドのボリュームは 1 秒あたり約 11,000 です。高速で信頼性が高く、当然のことながらスタンドにいる人は気づかないレベルのレイテンシです。

2. ライブ GUMBO をすばやく提供

私たちは GUMBO と呼んでいますが、ガンボシチューのことではありません。これは、ライブ試合の完全な状態を表す JSON 構造である、Grand Unified Master Baseball Object を指します。これには、プレー毎の最新情報、投球データ、選手のポジションなどが含まれます。投球やプレーのたびに GUMBO が更新されます。ファンであれ社内システムであれ、場所を問わず最新のデータを迅速に利用できる必要があります。そのため、GUMBO にはマルチリージョン読み取り設定を使用し、Memorystore for Valkey を活用することで、リージョン間の可用性に関する 2 秒未満の SLA を満たしています。

以前は、これを実現するために、独自のレプリケーション パイプラインを構築して管理する必要がありました。そこで私たちは、Memorystore for Valkey のクロスリージョン レプリケーション（CRR）を活用し、カスタム インフラストラクチャをより高速で操作が簡単な組み込み機能に置き換えることで、スタックを簡素化することから着手しました。

3. その他: 統計、名簿、スコアボード

すべてのデータがリアルタイムではありません。数秒ごとに更新されるものもあれば、数分ごとに更新されるもの、試合後に更新されるものもあります。ですが、打撃成績、選手名簿、順位、スケジュールなど、すべての情報をリクエストに応じて迅速に提供する必要があります。これらの準ライブ データセットとコアデータセットには、リードスルー キャッシュ モデルを使用しています。ユーザーのリクエストが空のキャッシュにヒットした場合、システムはデータベースからデータを取得し、キャッシュを更新して、結果を返します。

また私たちは、リージョンごとに 2 つの Memorystore クラスタを構成しました。1 つは「通常」クラスタ、もう 1 つは「高負荷」クラスタです。これら 2 つのクラスタを組み合わせることで、平均メモリ使用率が 75% 未満で、1 秒あたり 20 万件以上のコマンドを処理しています。まだ改善の余地があると考えています。

一歩先を歩み続ける

キャッシュ戦略の中核に Memorystore for Valkey を据えることで、パフォーマンス、信頼性、運用効率の改善に積極的に取り組んできました。

マネージド キャッシュに移行したことで、チームは次のステップに集中できるようになりました。そして私たちは、パフォーマンスのチューニング、キャッシュ パターンの改良、オブザーバビリティを深化させるためのツールの構築に、より多くの投資を行っています。また、ボトルネックになる前にホットスポットを検出できるよう、クラスタ内のキー配布とスロットのアクティビティをモニタリングするより良い方法を模索し始めました。

シーズンを通してクラスタをスケーリングする方法を自動化することにも関心があります。試合スケジュールはトラフィックに予測可能な影響を与えるため、（手動またはルールベースのアプローチにより）キャッシュサイズを動的に調整できることで、インフラストラクチャのサイズをさらに正確に調整できるようになる可能性があります。

Memorystore for Valkey を使用することで、私たちはより迅速に動き、よりスマートに構築し、スタンドのファンから放送局、アナリスト、クラブスタッフまで、私たちのデータに依存するすべての人々により良いエクスペリエンスを提供できるようになっています。

Major League Baseball の商標および著作権は、Major League Baseball の許可を得て使用されています。MLB.com をご覧ください。

-Major League Baseball、プリンシパル ソフトウェア エンジニア、Rahul Joshi 氏