Nintendo Switchのプッシュ通知を支えるテクノロジー
■ このスレッドは過去ログ倉庫に格納されています
テクノロジーに興味がある人なら、身近な製品の裏側って気になるもの。
そんな知的欲求を満たしてくれるセッションが、re:Union 2018 Osakaには用意されていた。
Nintendo Switchの裏側にあるシステムを紹介する「Nintendo Switch向けプッシュ通知システム『NPNS』」と題して、
任天堂 ネットワークシステム部の渡邉 大洋さんが語ったセッションだ。
フレンド登録したユーザーのゲームプレイ通知など、見慣れたあのメッセージは、こうやって送られていたのだ。
想定同時接続数1億台のリアルタイム通信インフラをAWSに構築
「実はこのセッション、AWS Summit Tokyoでもやったので聴いたことがある人がいるかもしれません。
が、そこは今日初めて聴いたようなテンションで聴いてください」（渡邉さん）
という出足で会場の笑いをさらった渡邉さんにならって私も書いておこう。
実はこのイベント、記事より何ヶ月も前に開催されたものなのですでに同じ話を他で聴いたことがある人がいるかもしれない。
が、そこは初めて知る情報のようなテンションで読んでいただきたい。
さて、話題の中心はセッションタイトルにある通り、Nintendo Switchのプッシュ通知システムだ。
Nintendo Switchについてはいまさら紹介しなければならないような製品ではないだろう。
すでに世界で2000万台以上を販売している、あのゲーム機だ。
プッシュ通知は、フレンドがオンラインになったときのほか、スマートフォンやPCで購入したアプリのダウンロード開始、完了通知などに使われる。
ちょっと面白いところでは、保護者が子どものゲーム利用状況を管理、監視できるNintendoみまもりSwitchからの設定変更通知などにも、同じプッシュ通知システムが使われている。
Nintendo Push Notification Serviceを略して、社内では「NPNS」と呼ばれているそうだ。
「フレンドの状況などを伝えるという性質上、リアルタイム性が重視されます。
そこで定期的なポーリングではなく常時接続を前提にシステムを構築しました。
求めたのは、1億台の常時接続に耐えるスケーラビリティ、無停止デプロイが可能な運用性です」（渡邉さん）
リアルタイムといっても、フレンドがオンラインになったことをミリ秒単位で正確に知る必要はない。
数秒以内に通知が届けば正常、システム異常時でも数分程度の遅延に抑えるという、ベストエフォート型の性能基準を採用し、インフラコストを抑えている。
http://ascii.jp/elem/000/001/796/1796780/ ロードバランサー不使用、ヘルスチェックとスケーリングに一工夫
1億台の常時接続に耐えるスケーラビリティと聞き、ロードバランサー配下にサーバーが並んでいる構成を思い浮かべた読者は少なくないのではないだろうか。
筆者もそのひとりで、こりゃ大型のロードバランサーが必要だなと反射的に考えた。が、NPNSではロードバランサーを使っていないという。
「AWSには3つのロードバランサーがありますが、いずれも今回の案件には合いませんでした。
そこでRoute53に全ノードのAレコードを列記してラウンドロビンで回しています。
外部向けのインターフェイスを増やしたくなかったので、ディスカバリも使っていません」（渡邉さん）
そんな装備で大丈夫か？と思ってしまったが、これで充分に求める性能を出しているそうだ。
プッシュ通知に使っているのは、メッセンジャーなどにも使われるリアルタイム通信プロトコルであるXMPP。
独自プロトコルを使うよりも既存プロトコルを利用した方が安定性が高いと判断した。
プッシュ通知を扱うXMPPクラスターの他に、ID管理などに使うConsumer APIとサーバー間連携などに使うProvider APIを用意した。
ちなみにロードバランサーを使わなかった理由は次の3つ。
まずClassic Load Balancerは、常時接続には向いていないと公式にアナウンスされている。
Application Load BalancerはHTTPに特化しているので、XMPPを使う今回の要件には見合わなかった。
さらにNetwork Load Balancerはリリースタイミングの兼ね合いで検証時間が取れそうにないことから、採用を見送ったという。
ロードバランサーを使っていないので、ヘルスチェックや接続先の移行なども自前で構築しなければならない。
NPNSではConsulとAuto Scalingを使ってサーバーのヘルスチェックを行なっている。
Consulがアンヘルシーなサーバーを検知すると、Route53から該当IPアドレスを削除する。
このときAuto Scaling側でもアンヘルシーな状態を検知し、同じXMPPクラスター内に新しくサーバーを立ち上げる。
Consulが新しいサーバーのヘルスチェックを行い、クリアすればRoute53に新サーバーのIPアドレスが書き込まれ、旧サーバーから新サーバーへの移行が始まる。
課題は、一時的ではあるが移行中にサーバーコストが二重にかかってしまうことと、ユーザーが増えるにしたがってドリップ処理に要する時間が長くなってしまうこと。
現状で約2時間かかっており、この処理の自動化が進められている。 既存プロトコルの良さを活かしつつ細かく通信をチューニング
XNPPクラスターを構築するために使っているのは、ejabberd。
クラスタリングに対応しており、大規模な利用実績があったことから選択された。
セキュリティを確保するため、通信はXMPP on TLSで行なわれる。
計算上はt3.largeで1サーバー辺り72万接続程度まで耐えられると考えたが、CPUとメモリに余裕があるのに同時接続数が伸びないという現象に見舞われた。
「調べてみたところ、Security Groupで設定されているセッション数の上限に引っかかっていました。
限界まで接続数を増やすためにSecurity Groupを無効にし、代わりにNetwork ACLsで外部からのアクセスを制限することにしました」（渡邉さん）
実際に運用し始めてから悩まされたのは、TCP切断対策だ。
常時接続を維持するために定期的にKeep Aliveのパケットを送信するのだが、これが多すぎると通信コストがかさみ、少なすぎると切断される端末が多くなってしまう。
本番環境で探りながら最適値を求め、ピーク時の切断を40%削減できたが、ユーザーの増加と共に最適値は変わるため最適化は今も続けられている。
「本番環境で運用し始めてわかったことは、L4のKeep Aliveパケットだけでは切断されるNintendo Switchが多いということでした。
恐らくプロバイダー側で通信を最適化するため、無意味なパケットを落としているのだと思います。
それに対応するため、データを入れたパケットを送信するL7のKeep Alive処理を行なうことにしました。これで切断を50%削減できています」（渡邉さん）
同時接続数は増え続けているが、通知送信処理の見直しにより、通知送信数は抑えられているという。
同時接続数は700万台、ピーク時の通信は毎秒2万通、毎月コンスタントに約200億通の通知が送信されている。
「今後はNetwork Load Balancerの採用を検討しています。
Network Load Balancerを組組むことでConsulを外してシンプルな構成にできるのではないかと期待しています」（渡邉さん）
最後にejabberdの改造点について紹介されたが、テクニカルすぎて筆者にはさっぱり。
エンジニアリング的な興味がある方は、このスライドから読み解いて欲しい。健闘を祈る。 なるほど分からん
つーかあれプッシュ通知だったのな >>5
常時1億台接続というプッシュ通知するだけには見合わない巨大な性能要件を満たすためにサーバーを大量に用意したけど
何故かXMPPという死んだプロトコルを使ってしまったがために一般的な負荷分散装置が使えなかったので
DNS(IPとサーバー名を紐付けるシステム)のホスト名にたくさんIPアドレスを登録してDNS問い合わせの時に偶然引かれたIPアドレスのサーバーに対して処理をさせる(DNSラウンドロビン)ことで事実上負荷を分散させている
DNSが偶然引いたIPにアクセスさせるとそのサーバーが死んでてもお構い無しにアクセスされてしまうので死んだサーバーがいたらDNSサーバーの該当IPのレコードを削除するという新人が考えついたような滅茶苦茶な処理を自前で用意してる
要するに技術力のなさを無理矢理な方法で解決したのをどや顔で語ってる恥ずかしいフォーラム 負荷分散装置ってのは配下に紐付けたサーバー群の状態を監視して死んでたら自動で切り離したり負荷が低いところに処理を回したりってのを自動でやってくれる装置で大量のサーバーを冗長化するならほぼ必須の装置
それに比べてDNSラウンドロビンはDNSが適当に引いたIPに接続させる方法でDNSサーバーに無駄に負荷がかかるし死んでようが負荷が高かろうがお構い無しに振られるので20年ぐらい前には大企業ではほぼ死滅した方法
負荷分散装置を付けられない零細企業とかがとりあえず負荷分散しないといけなくて泣く泣くやるような手法 例えると
仕事を振られる時に
一体管理職に仕事が振られたあとに管理職がその人の負荷や休み状況を見て適切な人に仕事を振るのが負荷分散装置で
くじ引きで仕事の担当を決めて終わりなのがDNSラウンドロビン
任天堂は休んでる人がいたらくじ引きの箱からくじを抜くという方法を取ってるということ あともう一つこの構成で問題なのはDNSの登録はユーザーの端末が参照しているDNSに伝播されるまでにかなり時間がかかるということ
死んだことを検知してレコードを削除してもユーザーが見てるDNSはすぐに削除が反映されないので障害が起きたサーバーに聞きに行きつづけるということになりかねない
TTL値という伝播間隔を短くする方法でなるべく早く反映させる方法もあるがそれでもそれなりに遅れるし全世界のDNSサーバーに無駄な負荷をかけるので普通はやらない データセンター作りたいんじゃないんだから
要求仕様を理解してない無知をさらしただけだな
情報の取捨選択すらできてないから
任天堂批判ありきで必死こいて調べただけかな >>17
もしかして俺のことか？
抽象的過ぎるから具体的に反論頼む
出来るだけ分かりやすく書いたつもりだがそれでも分からないなら何が分からないか言ってくれ
負荷分散装置を使わずDNSラウンドロビンで負荷分散してるという事実は変えようがないわけで俺が知らないDNSラウンドロビンで構成することの優位性があるなら是非教えてくれ
ちなみに最近よく聞くDNS書き換え攻撃に関して言ってもTTL値を下げるのは推奨されない
すぐにユーザーに影響するから攻撃検知しても対策が間に合わないから 任天堂のAWSの運用って明言してないけど
明らかに「いざとなったらAWSから抜けられる構造」が前提になってるのよね
だからIaaSとせいぜいSaaSはストレージ程度って構造になってる
過度な最適化は危険 >>10
専門外なんだけど今の大企業は何使うの？
想定同時接続数1億台クラスだとDNSラウンドロビン方式に対して負荷分散装置(ロードバランサー)ってどれくらいコスト増加するもんなの？ >>20
うちも使ってるけど業界シェア的にもやっぱりBigipが多いんじゃないかな
常時1億だと専用機用意するレベルだと思うがそれでも数千万〜億レベルだよ
AWSだと従量課金だから一概に言えないけど数年運用してもそこまでいかないと思う ■ このスレッドは過去ログ倉庫に格納されています
