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/ なるほど分からん
つーかあれプッシュ通知だったのな >>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だと従量課金だから一概に言えないけど数年運用してもそこまでいかないと思う ■ このスレッドは過去ログ倉庫に格納されています
