既存プロトコルの良さを活かしつつ細かく通信をチューニング

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の改造点について紹介されたが、テクニカルすぎて筆者にはさっぱり。
エンジニアリング的な興味がある方は、このスライドから読み解いて欲しい。健闘を祈る。