Spicy Mangoでは、お客様の進化するニーズに応えるため、常に製品の向上に努めています。当社のスポーツデータプラットフォームであるGamedayは、REST APIやWebhookを介したビジネスへのスポーツデータの取り込み、変換、配信において常に優れた実績を残してきました。しかし、D2C（Direct-to-Consumer）アプリケーション向けのリアルタイムのスポーツ速報に対する需要が高まるにつれ、低遅延でスケーラブルなソリューションの必要性を認識しました。これにより、得点情報やレーシングカー／バイクの位置情報などのライブアップデートを、数百万の接続されたクライアントに効率的に配信するための、WebSocketベースのパブリッシュ／サブスクライブ（pub/sub）メカニズムを模索することになりました。

この記事では、以下の内容について説明します。

• WebSocket技術の評価

• 導入と試行のために行った作業

• 独自のWebSocket実装への移行を選択した論理的根拠

• それに伴う課題と、それによってもたらされたメリット

専用のWebSocketベースD2C機能の必要性

スポーツファンは即時のアップデートを期待しています。現在、遅延は秒単位ではなくミリ秒単位で測定されます。当社の既存の配信方法（REST APIおよびWebhook）は、構造化されたデータ交換には優れていますが、大規模なリアルタイムのプッシュ更新向けには設計されていません。一方で、WebSocketは永続的な双方向通信チャネルを提供するため、世界中の何百万ものクライアントに瞬時にアップデートを届けるのに最適です。

この移行をサポートするために、MQTTのような市販のプロトコルを含む複数のアプローチを評価した上で、最終的にNode.jsで独自のWebSocketベースのpub/subソリューションを開発しました。

MQTTの試行：強力だが適合しなかったソリューション

MQTTは、IoTアプリケーションやリアルタイムメッセージングで広く使用されている、十分に確立されたパブリッシュ・サブスクライブプロトコルです。机上では、当社のニーズに対する有力な候補のように思われました。低帯域幅の環境をサポートし、QoS（サービス品質）レベルが組み込まれており、効率的なメッセージルーティングを促進します。しかし、試行中にいくつかの課題に直面し、GamedayのD2Cユースケースに採用するのは困難であると判断しました。

1. 大規模環境における複雑な構成と管理

   1. MQTTを大規模に展開することは困難であることが判明しました。複数のブローカーインスタンスの管理、高可用性の確保、トラフィックの急増に応じた動的なスケールアップには、多大な運用コストが必要でした。当社のDevOpsチームは、構成の微調整、クラスター管理の処理、負荷分散の最適化に時間を費やす必要があり、不要なオーバーヘッドが発生しました。

   2. また、独自のMosquittoインスタンスを管理する代わりに、HiveMQなどのサードパーティ製管理ソリューションも調査しました。しかし、大規模運用時のコストを考慮すると、当社のニーズには見合わない選択肢であることがすぐに分かりました。

      
      

2. 困難なモニタリングとレポート作成

   1. MQTTはメッセージの追跡とロギングをサポートしていますが、監視自体をMQTTメッセージ自体に大きく依存しています。MQTTブローカーは多くの場合、$SYSトピックなどの特別なトピックを利用して、内部のステータスやメトリクスをパブリッシュします。これらのブローカーを監視するには、これらのトピックをサブスクライブして、ブローカーの健全性とアクティビティに関する情報を収集する必要があります。このアプローチは、監視ツールがMQTTクライアントとして動作し、これらの内部トピックをサブスクライブしてメトリクスを収集する必要があることを意味し、監視セットアップが複雑になる可能性があります。この方法はMQTTエコシステム内では効果的ですが、HTTPなどの標準プロトコル経由でメトリクスを期待する外部の監視システムとシームレスに統合できない場合があります。このため、リアルタイムのレポート作成、デバッグ、アナリティクスが予想以上に困難になりました。当社は、接続の健全性、配信成功率、遅延メトリクスに対するより深い可観測性を提供するシステムを必要としていましたが、これらの機能は実装が複雑であるか、MQTTにネイティブに備わっていませんでした。

      
      

3. 柔軟な認証および認可の欠如

   1. 最も重大な欠点の1つは、認証と認可の管理における柔軟性の欠如でした。MQTTブローカーは認証メカニズムを提供していますが、プレミアム層とフリー層のサブスクライバーの区別など、異なるクラスのユーザーに対してきめ細かなアクセス制御を実装することは複雑であることが判明しました。さらに、Mosquitto内のサードパーティ製プラグインへの依存は、制御が制限される外部依存関係を導入することになるため、懸念材料となりました。さらに、複雑な認証および認可の要件により、これらのプロセスをSpicy Mangoが開発・保守する別のサービスにオフロードしてプロキシする必要が生じたため、パフォーマンスの低下が見られました。これにより不要な遅延と複雑さが加わり、より統合され、効率的なソリューションを追求するという当社の決定を後押しすることになりました。

      
      

4. 当社の開発スタックとの不一致

   1. MQTTは堅牢ですが、そのエコシステムは主にIoTや産業用アプリケーション向けに構築されており、ブローカーはC（Mosquitto）、Erlang（emqttd）、Java（Moquette）などの言語で書かれていることがよくあります。当社のエンジニアリングチームは主にNode.jsを使用してバックエンドを開発しているため、MQTTソリューションを維持するには、スタックに新しい技術を導入するか、サードパーティのブローカーに依存する必要があり、どちらも長期的な保守性の観点からは理想的ではありませんでした。

      
      

5. 当社のユースケースにおける不要なオーバーヘッド

   1. MQTTは、制約のあるデバイスや不安定なネットワークなど、幅広いリアルタイムメッセージングのユースケース向けに設計されています。そのようなシナリオでは非常に優れていますが、当社の主な目標は、安定したインターネット接続を介してスポーツのメタデータを効率的かつスケーラブルにリアルタイム配信することでした。メッセージ保持や複雑なQoS処理など、MQTTの追加機能は、相応のメリットをもたらすことなく、当社のインフラストラクチャに不要なオーバーヘッドと複雑さを加えるだけでした。

独自のWebSocketベースPub/Subソリューションの開発

MQTTを徹底的に評価した結果、Node.jsを使用して独自のWebSocketベースのpub/subシステムを構築するという戦略的決定を下しました。この決定により、技術スタックの一貫性と保守性を維持しながら、特定のニーズに合わせて最適化することができました。自社開発のソリューションが正しい選択であった理由は以下の通りです。

1. Gamedayの既存アーキテクチャとのシームレスな統合

   1. 当社のプラットフォームはすでにNode.jsで動作しているため、既存のマイクロサービスとシームレスに統合するWebSocketサービスを開発することは容易でした。これにより、エンジニアのオンボーディング時間が短縮され、継続的なメンテナンスが簡素化されました。

      
      

2. 軽量でスポーツメタデータに最適化

   1. 実装をコントロールすることで、スポーツデータに合わせたメッセージ構造とペイロードサイズを最適化できました。当社が必要としないさまざまなQoSレベルをサポートするMQTTとは異なり、当社のWebSocketソリューションは最小限の処理オーバーヘッドでアップデートを配信します。

      
      

3. 拡張性と容易な管理

   1. 独自のソリューションにより、Elastic Load Balancingやオートスケーリング機能などのAWSサービスを活用して、スムーズなスケーリングを確保できました。ニーズに合わせた監視ツールを構築し、接続の安定性、アクティブなサブスクライバー、メッセージ配信時間に関するリアルタイムのインサイトを生成し、標準のロギングフレームワークとも統合しました。

      
      

4. カスタム認証および認可

   1. セキュリティは最大の関心事であり、当社のオーダーメイドのソリューションにより、きめ細かな認証および認可コントロールを実装することが可能になりました。当社の認証および認可システムは、Spicy Mangoが開発したソリューションであるAuthIDConnectによって動作しています。AuthIDConnectは、登録ユーザーがパスワードまたはTOTPを介してログインすることをサポートし、有効期限の短いアクセストークンと有効期限の長いリフレッシュトークン（いずれも署名付きJWT）を発行します。ユーザーはリフレッシュトークンを使用してアクセストークンを更新し、安全かつ継続的なアクセスを維持できます。アクセストークンには、ユーザーの認可を定義するクレームが含まれています。

   2. AuthIDConnectは匿名ユーザーもサポートしています。これは、Gamedayのスポーツメタデータを自社のソリューションに統合するサードパーティ企業にとって不可欠な機能です。このモデルでは、匿名のエンドユーザーがサードパーティのサービスを使用することを認可されると、認証リクエストはサードパーティによってセッションIDとともにAuthIDConnectにプロキシされます。その後、AuthIDConnectはセッションIDを含む署名付きの匿名アクセストークンを発行し、エンドユーザーはこれを使用してGamedayのAPIおよびWebSocket pub/subサービスへのアクセスを認証および認可します。

   3. 当社のWebSocketソリューションは、これらのトークンを効率的かつ迅速に検証するように設計されており、遅延を最小限に抑え、接続されているすべてのクライアントにシームレスなエクスペリエンスを保証します。

      
      

5. インフラストラクチャの複雑さの軽減

   1. 追加のプロトコル層を避けることで、不要な依存関係を排除し、運用オーバーヘッドを簡素化しました。当社のWebSocketサービスは既存のAWSインフラストラクチャ内に収まるため、追加のメンテナンスやサードパーティの依存関係の必要性が軽減されます。

      
      

6. Well-Architected フレームワークの柱を満たす

   1. 当社のソリューションは、AWSのWell-Architectedフレームワークの主要な柱に沿っています。

      1. 優れた運用性（Operational Excellence）: 独自に構築したオブザーバビリティ（可観測性）ツールにより、管理と監視を簡素化しました。

      2. セキュリティ（Security）: アクセスを制御し、不正なデータ漏洩を防ぐためのきめ細かな認証と認可。

      3. 信頼性（Reliability）: AWSのオートスケーリングと管理されたWebSocket APIにより、高い可用性と耐障害性を確保します。

      4. パフォーマンス効率（Performance Efficiency）: 最小限の処理オーバーヘッドと最適化されたメッセージ構造により、遅延と応答時間を改善します。

      5. コスト最適化（Cost Optimization）: サードパーティへの依存を排除することで、ライセンスコストとインフラストラクチャのオーバーヘッドを削減します。

      6. 持続可能性（Sustainability）: 運用の複雑さを軽減し、リソースを効率的に使用することで、持続可能なアーキテクチャの維持に貢献します。

全体像（10,000フィートからの視点）

私たちが作成したものの（非常に）大まかな全体図は以下の通りです。極めて重要なのは、認証と認可のすべてがAuthIDConnectトークンで実行される一方で、多くのアベイラビリティゾーンやリージョンにわたってウェブソケット配信ソリューションのスケールを管理できることです。必要に応じて、オリジンサーバーとエッジサーバーのファンアウトパターンで展開し、任意のリージョンでの需要に合わせて拡張することができます。これらはすべて同じWebSocketサーバー実装で実現可能です。

学んだ教訓とまとめ

WebSocketベースのD2Cソリューションへの道のりは、私たちに貴重な教訓を与えてくれました。MQTTは強力で汎用性の高いプロトコルであり、IoTやマシン間（M2M）通信に適しています。しかし、スケーラビリティ、低遅延メッセージング、Node.jsスタックとの統合、きめ細かなセキュリティ制御といったGamedayの特定の要件においては、カスタム構築したWebSocketソリューションが最適でした。

この経験により、当社のコア技術や運用の目標に合致した技術を選択することの重要性が再確認されました。独自のソリューションを開発したことで、現在、最小限の遅延で何百万ものユーザーにリアルタイムのスポーツメタデータ更新を配信する、高度に最適化され、スケーラブルで安全なシステムを構築することができました。

Gamedayが進化し続ける中、私たちはプラットフォームを強化するための新しい方法を模索し続けます。WebSocketインフラストラクチャのさらなる最適化、エッジコンピューティングの組み込み、あるいは新しいクラウド技術の活用など、私たちの目標は常に変わりません。それは、可能な限り最高のリアルタイムスポーツデータ体験を提供することです。