同時接続 700 万、秒間 2 万通という Nintendo Switch 向けプッシュ通知システム NPNS の資料を読んで

すごすぎて悔しいので Erlang/OTP ユーザ視点で見てみます。

Erlang/OTP ユーザ視点

ぱっと資料を見ると ejabberd は自前で改造しているようです。改造内容が「プロセス構造」と書いてあり、いやそれ根本から修正しているじゃん。という恐ろしいオチ。

つまりただ使っているだけではなく、ゴリッゴリ Erlang/OTP を書いてチューニングというかリライトに当たるような感じも見受けられます。

さらにクラスター同期に利用される Mnesia も止めて自前で Consul の運用に切り替えています。これも現実的で良いです。

おそらく運用台数がかなり多いように感じます。Mnesia の同期はそれほど重いものではないのですが台数が多いとそれなりにしんどいので。

省メモリ化

FastTLS である NIF 実装に手を入れているようです。発表者のお一人が元組み込みって書かれているのでその辺はお手の物なのでしょう。

Hibernate を活用して接続したあとに寝かせておくという方針をとりメモリをとにかく減らしているのがわかります。Erlang/OTP は TCP のコネクション維持のためにかなりメモリを食べるためです。

大量切断

実はTCP 張りっぱなしで辛いのは大量切断です。メモリがはねます。これの対策が具体的に書かれていないので気になりました。

ログ出力

何を使っているかは書かれていませんが、crash.log で汚さないというのは本当に重要です。よく Erlang/OTP は困ったらクラッシュさせればいいとか言われますが、それはただの素人以下です。

実際はクラッシュログをいかに出さないようにコードを書くかです。クラッシュするのは「あくまで想定外が起きた時だけ」というように設計するべきです。クラッシュログを出さないのはとても重要になります。

独自機能

TCP の接続維持の話はとても勉強になりました。この辺の話が Erlang/OTP でどう実現したのかが書いてあったら・・・と思いましたが、AWS のイベントで Erlang/OTP の話をするのは微妙と判断されたのでしょう。

hot code loading

衝撃だったのはこれです。つまり Erlang/VM を落とさずにアップデートする仕組みです。TCP コネクションも切れません。

緊急時とはいえこれを採用できるくらい考えられた設計ということなのでしょう。正直頭が上がりません。

まとめ

安全に寄せながらも一億台という要件に答えるための仕組みを作り上げて、今も元気に可動しているということでしょう。

どのくらいかかって、何名でという話が書いていないのでわかりませんが、これほど素晴らしいシステムを作り上げるのはとても大変だったように思います。

今後 Nintendo Switch は右肩上がりで売れていくとなるとこのシステムの負荷もガンガン上がっていくことになります。それを Erlang/OTP で設計された仕組みが安定してプッシュ通知を提供していると胸が熱くなります。

何より Nintendo は世界の Nintendo ということは、世界中にプッシュ通知を送っているわけです。24/365 止まってはいけないシステム、まさに Erlang/OTP が得意とする世界です。Erlang/OTP 素晴らしい事例の一つに思えます。

本当に素敵な事例をありがとうございます。胸をときめかせながら資料を読ませていただきました！