ロードバランサー不使用、ヘルスチェックとスケーリングに一工夫

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時間かかっており、この処理の自動化が進められている。