Zenn
Closed1

"Nintendo Switch™ 向けプッシュ通知システムのリプレイス事例" の感想

voluntasvoluntas

AWS については利用していないのでよくわからない。あくまで Erlang/OTP で書かれたミドルウェアのリプレイス事例として感想を雑に書く。ちなみに、現地で発表を聞いている。

一般的な感想

  • 自分のような AWS 素人が見てもわかりやすいシンプルなシステムになっていた
  • HTTP/2 を利用した独自プロトコルでの双方向通信が気になる
  • TCP/IP を利用した大量の常時接続は本当に大変だとおもう
  • カーネルパラメーターチューニング！
  • 少ないリソースで、たくさんの接続を担う ゴールが素晴らしい
  • デプロイの自動化を GitHub Actions でやってるのやっぱりいい
    • 負荷試験にて1億台の接続を維持した状態で挙動が問題ないことを確認 最高
  • Graviton ベースの Fargate の活用
    • Go であれば arm64 向けバイナリがサクッと生成されるのは良い

Erlang/OTP から Go への切り替えについての感想

  • もともと Erlang/OTP で書かれている ejabbered という XMPP サーバーを利用していた
  • 今回は Erlang/OTP から Go への切り替え
  • 前回は AWS 自体の機能利用は最小限で、ejabbered カスタマイズで実現していた
    • そもそもロードバランサーが採用できていない
  • 今回は Go と AWS をうまく組み合わせてシンプルな仕組みで実現していた
  • OSS の改造から、独自アプリケーション開発に
    • これは当たり前の判断で、独自でやれるならやるべき
  • 他システムで採用実績のある Go で開発
    • これも正しい判断、Erlang/OTP の最大の課題は採用ではなく キャリア だと思ってる
      • Erlang/OTP でのキャリアを積みたい人は少ない
      • Erlang/OTP 自体は簡単なのである程度の開発者なら誰でもすぐ覚えられる
  • クラスタ構成をやめ、シンプルなアーキテクチャーに
    • これは AWS でうまく利用する事でシンプルにしているのはさすがとしか言い様がない

リリースに間に合わせて Erlang/OTP ベースのミドルウェアソフトウェアで実現するのは担当されたエンジニアの方々の腕力が素晴らしいとしか言い様がない。その後、しっかり Go + AWS の組み合わせでシンプルな構成にする判断ができるのも正しい判断。

最初から完璧なシステムを作ることは難しいので、まずは凄腕エンジニアたちの腕力でサービスを実現しそれを、最終的に AWS をうまく利用したシンプルな構成でリプレイスする。理想的なやりかただとおもう。

資料

以前の発表

以前書いた

このスクラップは3ヶ月前にクローズされました