このページの本文へ

前へ 1 2 3 次へ

「AWS Summit Japan 2024」レポート

AWS Fargateを使った大規模常時接続に立ちはだかった壁の数々

「1億台の常時接続」を実現せよ! Nintendo Switchのプッシュ通知システム全面刷新の裏側

2024年06月27日 15時00分更新

文● 福澤陽介/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

 アマゾン ウェブ サービス ジャパンは、2024年6月20日と21日、国内最大の年次イベントである「AWS Summit Japan」をハイブリッドで開催。150を超えるセッションが展開された。

 本記事では、ニンテンドーシステムズによるセッション「Nintendo Switch向けプッシュ通知システムのリプレイス事例」をレポートする。登壇したのは、同社 システム開発部の林愛美氏と坂東聖博氏だ。

 2017年のNintendo Switchの発売とあわせてリリースされた「プッシュ通知システム」。同社は、長期運用を見据えて、よりクラウドネイティブなシステムへのリプレイスを決定するが、大量のTCP接続を維持するための様々な課題が立ちふさがった。

 本セッションでは、AWS FargateやNetwork Load Balancer(NLB)といったAWSのマネージドサービスを用いた、“最大1億台”級のスケーラビリティを持つ大規模常時接続の実現までの道のりが紹介された。

ニンテンドーシステムズ システム開発部 林愛美氏

増え続ける同時接続、長期運用を見据えてリプレイスを決意

 Nintendo Switch向けのネットワークサービスは、本体と常時接続される「プッシュ通知システム」を経由して、任意のタイミングで通知を送信している。フレンドがゲームを遊び始めた時のオンライン通知、本体更新の通知、ニュース配信などが同システムを利用しており、ゲーム購入時にダウンロード開始を指示する機能も同システムによるものだ。

プッシュ通知システムを利用するネットワークサービス

 既存のプッシュ通知システムは、XMPPサーバーである「ejabberd」を利用して、複数クラスタで構成。AWSのAmazon EC2やAmazon RDSなど、実績のある安定したサービスを採用していたという。

既存のプッシュ通知システム

 一方で、Nintendo Switchでプレイするユーザー数は年々増加しており、2023年4月から2024年3月の期間には“1億2300万人”に到達。もちろんプッシュ通知システムへの同時接続数も増え続けていた。

 このような実情を踏まえ、今後の長期的な運用を見据えたリプレイスを決定。課題にあわせた以下の“4つのコンセプト”のもとで刷新が進められた。

・柔軟に機能追加できるよう、カスタマイズしたOSSの利用を止め、独自のアプリケーション開発に移行
・開発者の流動性を確保するべく、他システムで採用実績のある「Go」で開発
・開発/運用の効率を高めるべく、クラスタ構成を止めてシンプルなアーキテクチャーに
・運用工数を削減するために、サーバーレスサービスを積極的に採用

 本セッションでは主に、4つ目のコンセプトに関わる大規模常時接続実現に向けたサーバーレスサービスの活用について解説した。

常時接続サービスの性能要件は“一億台の同時接続”

 リプレイス後のシステムでは、ロードバランサーには「ELB(Elastic Load Balancing)」を、コンピューティングリソースにはサーバレスの「AWS Fargate(ECS on Fargate)」を、データベースには「DynamoDB」を採用した。

リプレイス後のプッシュ通知システムのシステム構成図

 Nintendo Switchがプッシュ通知システムに接続する流れは次のとおりだ。まず、ID払い出しサービスにアクセスして、プッシュ通知システム用のIDを作成する。その後、接続先振り分けサービスへアクセスし、接続する常時接続サービスのURLを取得する。そして、常時接続サービスが、Nintendo SwitchとTCPコネクションを確立、長時間接続を維持する。接続中には、HTTP/2を利用した独自プロトコルで双方向通信する。

 この常時接続サービスは、NLB(Network Load Balancer)とECSサービスをひとつのUnitとして、複数のUnitに分割されている。本サービスの性能要件は、“最大1億台の同時接続”に耐えうるスケーラビリティだ。

 「この要件をAWSに相談したところ、NLBに障害が発生した場合の影響範囲という観点から分割を推奨された」と林氏。あくまでNLB観点でのUnitの分割であるため、すべてのUnitは同じDynamoDBのテーブルを参照しており、シャーディングのようなデータベースの負荷分散はしていないという。

常時接続サービス

 逆に、Nintendo Switchに通知が送られる流れは次のようになる。まずネットワークサービスが、プッシュ通知システムが用意する通知送信用APIを利用して通知を送信。正常に受け付けられた通知は、メッセージキューイングサービスである「Amazon SQS」に保存される。

 そして通知振り分けサービスがSQSから通知を受け取り、DynamoDB上のセッション情報を用いて、対象のNintendo Switchが接続する常時接続サービスのFargateのタスクを特定して通知を送る。最後に、通知を受け取った常時接続サービスが、対象のNintendo Switchに対して通知を届ける。

前へ 1 2 3 次へ

カテゴリートップへ

この連載の記事
  • 角川アスキー総合研究所
  • アスキーカード