Amazon Simple Notification Service(SNS)のHTTP/HTTPS通知はもっと使えるサービスのはず

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Amazon SNS について

AWSSNSが世の中でどれくらい周知されているか、どれくらい使われているか知りませんが、自分はSimple Notification Serviceという名前から察するに、何かあった時にメールでお知らせするサービスくらいにしか感じてませんでした。ただ、最近はもっと使い道がありそうな雰囲気をバシバシ感じているので紹介します。 詳しくは http://aws.amazon.com/jp/sns/ を参照してもらうとして、SNSをざっくり説明するとPub/SubメッセージングモデルでHTTP/HTTPSEメールSMS(東京リージョンでは提供なし)、SQSの各サービスへプッシュ通知するサービスです。

Pub/Subとは

古くは(2000年くらい?)から存在するらしいアーキテクチャパターンです。古くはJavaのJMSからWeblogicWAS等のJavaのWebコンテナ、最近ではPostgreSQLRedisØMQpubsub.ioなどがあります。
Publisher(発行者)/Subscriber(購読者)からなる仕組みで、新聞を定期購読する事をに例えるとわかりやすいと思います。 SNSの用語でいうとPublisherは新聞社、Subscriberは新聞を定期購読したい読者、Topicは何新聞かです。ここでPub/Subプロバイダ(SNS)は街の新聞屋になります。

新聞の場合

  1. 読者は街の新聞屋に対して購読を申し込みます。
  2. 街の新聞屋は購読者の住所/氏名と何新聞を届けるかを聞き、購読者リストに追加します。
  3. 毎朝/夕に新聞社→(印刷所)→街の新聞屋に新聞が配送されます。
  4. 新聞屋は購読者リストを元に新聞を配ります。

Pub/Subの場合

  1. SubscriberはPub/Subプロバイダに対してSubscribe登録をします。
  2. Pub/SubプロバイダはSubscriberからの登録時に何の情報(Topic)が欲しいか、と配信して欲しいURL又はメールアドレス等を情報として受け取ります。
  3. PublisherはPub/Subに対して情報を発行します。
  4. Pub/Subプロバイダは登録されたSubscriberに対してPOST又はメールを発行します。

という流れになります。これで何がうれしいのかというと、

  • 購読者(Subscriber)が増えた場合には街の新聞屋(Pub/Subプロバイダ)に登録すれば配信されます。
      → 簡単にスケールできるZ!
  • 新聞社(Publisher)は購読者(Subscriber)を直接は知らないし、逆も然り。ただ、購読者が欲しいと思える情報を渡すべきです。
      → 疎結合だZ!

ということでSNSの使い道の妄想

HTTP/HTTPS(POST)

WebSocketサーバーのスケール

 

 
 RedisやØMQでのスケールの情報が多いですが、SNSでもコンテンツ提供者がPublisher、WebSocketサーバーがSubscriberで、WebSocketサーバーがスケールアウトした時にSubscriber登録することで実現できます。スケールしたWebSocketサーバーに対してメッセージを配信します。
[Node.js]Amazon SNSでHTTPを使って通知を受け取る[aws-sdk-js]
Node.jsの場合は↑の記事が参考になると思います。
他のサービスに処理の終了通知

例えば画面からのユーザー登録などの入力に対して複数のサブシステム(Webインターフェースがあれば言語は問わない)がありそれらに同時に全く別の処理させたい場合です。画面アプリをPublisher、サブシステムをSubscriberとして登録し、入力が完了した時点でここではユーザーの与信チェックとレコメンドの計算の2つの全く別の仕事をさせます。さらにメールを送信して通知する事もできます。

HTTP/HTTPSとSQSと併用

 

複数のエンコードの並列処理

 

 
Amazon Elastic Transcoder という動画変換サービスを出しましたがそれはそれで置いといて。。例えばあるタイミングで複数の重いエンコードや重いバッチ処理等をしたい場合。1インスタンスにつき1つのエンコード、それを別EC2インスタンスで走らせたい場合などに、エンコードの種類(mp4とか)別にSNSからキューを作成することで使えそうです。

まとめ

数あるPub/Subの実装の中でもSNSの強みは他の(EC2以外の)サービスと同様にスケーラブル/低コスト/高可用性という点だと思います。Pub/Subの冗長化構成を考えた場合、Active-Active構成もActive-Inactive構成も結構工夫しないと組みづらいなと思いました。 それもあって、このSNSが提供する機能で要件を満たせるならば、使わない手はないと思いました。

SNS(紫?)推しな記事でした。