[レポート] ARC334: Scaling Push Messaging for Millions of Netflix Devices #reinvent

はじめに

本記事はAWS re:Invent 2018のセッション「ARC334 - Scaling Push Messaging for Millions of Netflix Devices」のレポートです。

Netflix built Zuul Push, a massively scalable push messaging service that handles millions of always-on, persistent connections to proactively push time-sensitive data, like personalized movie recommendations, from the AWS Cloud to devices. This helped reduce Netflix’s notification latency and the Amazon EC2 footprint by eliminating wasteful polling requests.

スピーカーはNetflixのエンジニアSusheel Aroskarさん。

レポート

• Netfilxのユーザのうち、映画を探してる時間がが7割
• これを解決するためにpush messagesはソリューションの一つ
• Push通知にはZuulを使っている
  • 自社開発のOSS
  • https://github.com/Netflix/zuul/wiki/Push-Messaging
• Push配信を行う場合にはユーザリポジトリがあるはず
  • 上記に必須なのはLow レイテンシー、Auto Expiration、レプリケーション
  • DynamoDBは相性がいい
  • かつては自社でDynomiteを開発してた
• QueueにはKafkaを使ってた
  • 優先度によって、Queueを使いわけるのはポイント
• スケールを容易にするため 、Message Processorを並列で動かしてた
• Push通知のインフラ構築で大事なこと
  • まずはでかいサーバを準備
  • 小さいサーバを複数つかうより、でかいサーバを1つ使うほうが実はコスパがいい
• AutoScalingで見るメトリクス
  • Request per Second? CPU利用率？そうじゃない
  • Number of Connections per Serverこそ大事
• WebSocketのLBするにはALB使いましょう
  • CLBはQWebSocketをproxyできないので

まとめ

スケーラブルな設計をするうえで大事なポイントを、紹介していました。 Push配信はコネクション周りをしっかり意識する必要があり、これをうまくコントロールすることで、非常に多数のメッセージ配信を実現しているようです。 特に、見るべきメトリクスなどは大事だと思いました。