(レポート) MBL307: スケーラブルなメッセージングアーキテクチャ – モバイル向けのビジネスとエンタープライズでどのように Amazon SNS を利用するか #reinvent

スケーラブルなメッセージングアーキテクチャ - モバイル向けのビジネスとエンタープライズでどのように Amazon SNS を利用するか

この記事は「MBL307 - Scalable Messaging Architectures: How Mobile Businesses and Enterprises Use Amazon SNS to Power Their Messaging Needs」のレポートです。セッションには参加できなかったので、セッションの動画とスライドの内容のまとめになります。

前半はモバイルプッシュの話、後半は主に ESB として利用するシステムの話で構成された、Amazon SNS を題材にした非常に内容の濃いセッションです。

[slideshare id=53717866&doc=mbl307-151009002742-lva1-app6891]

スピーカーは次の方々です。

• Arjun Cholkar - Principal Product Manager, Amazon Web Services

• Asha Chakrabarty - Solutions Architect, Amazon Web Services

• Fabricio Pettena - MD & COO at Rocket Internet Latam, Rocket Internet Latam

• Edward Dingels - Architect, Earth Networks, Inc

Amazon SNS とは

• 任意のデバイスまたはエンドポイントにメッセージを送信
• モバイルプッシュ
• Eメール
• HTTP
• SMS
• Amazon SQS
• AWS Lambda
• グローバル、そして迅速に高スケールに送信
• 1日あたり10億ものメッセージが低レイテンシで世界に送られている
• マルチプラットフォーム、フレームワークをサポート
• Java, Python, PHP, Node.js, Objective-C, .Net

1,000 ものモバイルアプリ、エンタープライズで利用

Amazon SNS はもはやスタンダートになりつつある通知サービスです。1,000 以上のモバイルアプリまたはエンタープライズで利用されています。国内でも利用しているという話をよく聞きます。

• Periscope
• yelp
• EASY TAXY
• hike messenger
• doapp
• Jobvite
• Earth Networks
• ABC
• Yik Yak
• shazam
• real eyes
• JustGiving
• mobstac
• Omnifone
• VidRoll
• Delaware North
• Plumbee
• intuit
• Punjab Kesari Group
• peak GAMES

1つのAPIで複数の送信先の種類に送信可能

Amazon SNS は大規模で利用することを前提としたサービスです。そのため、様々な種類のエンドポイントを対象にできるほか、トピックを使うことで多くのサブスクライバに対するメッセージの送信が簡潔に行えるようになっています。

• デバイスからデバイスにダイレクトに送信
• endpointArn を指定して、iOS / Android / Fire OS / Windows に送信
• バックエンドのシステムからトピックに向けて送信
• 1つの Topic にモバイル / SQS / HTTP / SMS / Eメール / Lambda をサブスクライブさせることができる
• デフォルトでは1アカウントあたり10万トピックまで作成可能
• 10万トピック x 1,000万サブスクリプション = 1兆サブスクライブがデフォルトで可能

3つのステップでメッセージを Publish

ダイレクト Publish

1. PlatformApplication を作る
2. PlatformEndpoint を作る
3. PlatformEndpoint に向けて Publish する

トピック Publish

1. Topic を作る
2. Subscription を作る (Topic を Subscribe する)
3. Topic に向けて Publish する

Amazon SNS のカスタマーはどのようにモバイルプッシュを利用しているか？

Plumbee の場合

Plumbee はソーシャルカジノゲームをメインに開発している企業です。モバイルアプリから収集したログを Redshift に流し込み、マーケッターがクエリを通してユーザーをターゲッティングし、きめ細かいプッシュ通知を実現しています。

Easy Taxi の場合

Easy Taxi は素早くタクシーを利用することができる、2,000万人以上のユーザーが利用しているアプリです。30カ国、420以上の地域で利用できます。搭乗者とドライバーはモバイルプッシュを使ってマッチングさせています。

Amazon SNS は乗車フローの一部

Easy Taxy では次のような乗車フローで利用しますが、このフローの一部で Amazon SNS が利用されています。

1. 乗車依頼が承認される
2. Taxi が来る
3. Taxi に乗る
4. 料金を支払う
5. 乗り心地を評価する

顧客管理 (CRM)

CRM チームが100万人の搭乗者、40万以上のドライバーを援助しています。

• プロモーションコード
• トラフィックのアラート
• キャンペーン
• "care days"
• パートナープログラム

Amazon SNS を利用した乗車ワークフロー

EC2 の API サーバーにより乗車依頼を受付け、内部システムにより「タクシーが到着した」「料金を支払った」などといったイベントをキーにプッシュ通知を送っています。

モバイルプッシュを通じた CRM の活動の有効化

マーケティングチームからの CRM 活動は EC2 上のアプリケーションで登録し、スケジューリングされ、最終的にはプッシュ通知でエンドユーザーに伝えられます。送信対象となるエンドユーザーは、地域やエリア、搭乗者またはドライバーといった具合の粒度でセグメントが可能です。プッシュ通知にはディープリンクが含まれ、開くとキャンペーンページなどに遷移します。

ABC の場合

ABC ではニュース速報を迅速に伝えるために Amazon SNS を利用しています。トピックのサブスクライブまでは Amazon Cognito を利用してサーバーレスに行い、プッシュ通知はサーバーから Topic に向けて行います。送信ログは CloudWatch -> Kinesis -> Sumo Logic を通してダッシュボードで見えるようにしています。

なお、トピックを用いたモバイルプッシュの仕組みは Mobile Hub を使うと簡単にプロビジョニング可能です。

Punjab Kesari Group の場合

Pubjab Kesari はインドでヒンディー語の新聞を発行している企業です。モバイルアプリを展開しており、こちらで Amazon SNS を利用したモバイルプッシュを利用されています。

印刷からデジタルへ

1948年に設立され、印刷業では2015年までにデイリーで130万部発行していました。デジタルによるコンテンツ配信は2009年に始まり、デイリーで1億5,000万PVものアクセスがあります。

• モバイルに参入できたが…
• スケーラビリティへの挑戦
• 高レイテンシ
• Font の制約
• ユーザー管理上の課題
• デバイス管理上の課題
• これらの課題を解決するため、Amazon SNS を利用
• Amazon SNS のマイグレートを通して
• 72% のプッシュ通知の規模アップ
• 89% のインストール数アップ
• 204% の広告のインプレッション数アップ

Amazon SNS の様々な使いみち

Amazon SNS はモバイルプッシュだけではなく、いろいろなシステム、アプリケーション、アーキテクチャで活躍します。

S3 のイベント通知のための SNS のファンアウト

• イベントドリブンなアーキテクチャ
• 1つのデータソースでパラレルに処理
• S3 のイベントを SNS を通して異なるサブスクライバへ通知
• 各サブスクライバはデータを独立して処理
• データは選択したコンポーネントのストレージに格納

SNS と Lambda を利用したタスクの自動化

1. CloudWatch の Alarm をきっかけに SNS の Topic に Publish

- EC2 メトリクス : CPU, ディスク, ネットワーク, ヘルス - EBS メトリクス : 読み書き, byte/ops - ELB メトリクス : HTTP コード - S3 メトリクス : NumberObjects, BucketSize - DynamoDB メトリクス : 読み書きのキャパシティ - カスタムのメトリクス・アラーム 2. Lambda function でタスクを自動で実行 - インスタンス/タスク/アプリの起動 - テーブル/シャード/ストレージのプロビジョニング - 外部エンドポイントの呼び出し

メッセージングバスとしての利用

• アーキテクチャを SNS を使って分離する
• 即時/遅延の処理のために信頼性の高いメッセージングとして Amazon SQS を利用

Earth Networks の Amazon SNS 活用事例

Earth Networks は WeatherBug をメインに提供している企業です。

Earth Networks の ESB

• 要望 : 分離したサービスと層の間で信頼できる通知を送りたい
• 提案 : SNS + SQS = Simple ESB

層レイヤー

• アラートで表面上の観察を実施
• 複数のサブスクライバへの複数の Publish
• 個別のサブスクライバでも、サブスクライバのセットでも、各メッセージの処理が可能
• サブスクライバで異常が発生した場合、キューのメッセージから離脱可能
• 特定のサブスクライバに依存しない構成としている

データの取り込み

• FTP や UDP、ETL によって得られたデータを SNS Topic を通して DynamoDB や Redshift に格納
• 1日あたり 500万の ESB のためのメッセージを処理

ファンアウト

• ドメイン/ディメンションのデータをゆっくりと移動
• 地理情報(GIS)のマッピング
• 複数のサブスクライバに1つの Publish
• 複数のサブスクライバに一貫性のあるファンアウトが可能
• 各サブスクライバが最終的に一貫性を保証 (どのサブスクライバが処理しても同様の結果が得られる)

データパイプラインのマッピング

• 30の異なるデータを処理するトピックを扱っている
• マッピングを行うインスタンスが S3 を参照しつつ、データ処理のトピックをサブスクライブ
• 表側では CloudFront でキャッシュ

データの集約

• レポートと KPI を実施する
• 1つのサブスクライバに複数の Publish
• 複数のソースからのデータを損失なしに集約・同期
• サブスクライバは1台に限定した冗長構成
• クライアントのトラブルシュートも追加可能

Earth Networks での Amazon SNS

• ソリッドな通知基盤
• 内部メッセージングでの利用
• SQS との組み合わせによる複雑なパターンの解決
• シームレスなスケーリング

まとめ

Amazon SNS はモバイルプッシュの側面が目立っていますが、元々は Pub/Sub モデルに基づく通知サービス。システムの内部で利用するケースは今後も頻繁に発生すると思います。そういった意味でも、このセッションでは Amazon SNS を利用する様々なパターンが学べる良いセッションでした。

Amazon SNS はシンプルゆえに活用方法も自由自在。このセッションで紹介された事例を参考に、今後も Amazon SNS を活用していきましょう！