Amazon Web Services(AWS)は先頃、Amazon SNSがAmazon Kinesis Data Firehoseサブスクリプションをサポートし、"カスタムコードを書く必要なく[...]データレイク(data lake)、データストア、およびアナリティクスサービス"へのメッセージ送信を可能にすると発表した。新たなイベント送信先が加わることで、サードパーティサービスプロバイダのインテグレーションも容易になる。
Amazon Simple Notification Service (Amazon SNS)は、"アプリケーション・ツー・アプリケーション(A2A)とアプリケーション・ツー・パーソン(A2P)という2つのコミュニケーションを対象とした"、パブリッシャからサブスクライバへの同期メッセージ配信を提供するマネージドサービスである。高スループットかつ低レイテンシなイベント駆動アーキテクチャ(以前の記事)を実装するために、幅広いネイティブAWSイベントソースをサポートする。
Amazon Kinesis Data Firehoseは、"データストアとアナリティクスサービスに対するリアルタイムデータストリームをセットアップし、データをロードする"マネージドサービスである。オプションとして使用可能なAWS Lambda関数(以前の記事)によるサーバレスデータ変換を除けば、コード実装は一切必要としない。
Amazon SNSではこれまで、Amazon SQS、AWS Lambda、SNS対応のHTTP/Sエンドポイントといった汎用目的のA2Aイベントデスティネーションをサポートしていたが、より具体的な要件を備えた通常のデスティネーションのためには、独自のソリューションを用意する必要があった。今回、Amazon Kinesis Data Firehoseイベントデスティネーションが加わったことで、レコードをAmazon S3、Amazon Redshift、Amazon Elastic Service、および"自身が所有する任意のHTTPエンドポイントあるいはサードパーティサービスエンドポイント"を含むストリームデスティネーションに配信できるようになる。組み込みで備えるKinesis Data Firehoseデータ変換機能と組み合わせることで、デスティネーションにルートされる"データをキャプチャ、変換、バッファリング、圧縮、アップロード"するカスタムコードの大部分が不要になる。
/filters:no_upscale()/news/2021/07/amazon-sns-kinesis-data-firehose/ja/resources/1amazon-sns-delivery-protocols-small-1622507528857.png){kind=link}
イメージ: Amazon SNSイベントデスティネーション(AWSドキュメントより)
ブログの紹介記事では、実現が容易になるユースケースの例がいくつか紹介されている。
- Amazon S3デスティネーションによるSNSメッセージの保存とクエリ — S3バケットにデータをバックアップおよびアーカイブし、SQLを使用してAmazon Athenaで分析する。
- Amazon ESデスティネーションによるSNSメッセージのインデクスと検索 — Amazon Elasticsearch Serviceにデータをパブリッシュして、Kibanaによる探索と視覚化を行う。
- Amazon RedshiftデスティネーションによるSNSメッセージの分析 — データをRedshiftデータウェアハウスにパブリッシュして、Amazon RedshiftでSQLを使用して分析する。
- HTTPデスティネーションによるSNSメッセージのフォワード — データを独自エンドポイントやサードパーティサービスプロバイダにルートする。
- Kinesis Data Firehose変換によるSNSメッセージの変換 — redact personally identifiable information(PII)などのLambda関数でデータを処理する。
新たなKinesis Data Firehoseインテグレーションでは、dead-letter queues(DLQs)やメッセージフィルタリングといった通常のSNS機能がサポートされているため、"メッセージのフィルタリングロジックをサブスクライバから、メッセージルーティングロジックをパブリッシャから、それぞれオフロードする"ことが可能になる。
注目すべきなのは、イベントバスベースのAmazon EventBridgeサービスも同じようにDLQs、コンテントフィルタリング、入力変換を提供し、イベントのアーカイブおよびリプレイ機能(以前の記事)をネイティブに備えていることだ。AWS ServerlessのプリンシパルデベロッパアドボケートであるJames Beswick氏は、ブログ記事"choosing between messaging services"の中で、"SNSとEventBridgeには多くの共通点がある"ことを認めている。
どちらもパブリッシャとサブスクライバの分離、メッセージあるいはイベントのフィルタリングに使用可能で、ファンイン(fan-in)およびファンアウト(fan-out)機能を備えています。その一方で、ターゲットリストや各サービスの機能には違いがあります。どちらのサービスを選択するかは、ユースケースの要件次第でしょう。
記事では続いて、EventBridge独自の機能であるSaaSパートナイベントソースとスキーマレジストリについて説明した上で、詳細な機能比較表を紹介している。さらに、続く記事"building resilient serverless patterns"においては、2つのサービスを組み合わせたユースケースの例を取り上げている。
関連するニュースとして、Amazon SNSは先頃、メッセージフィルタリング機能として新たなオペレータを導入すると同時に、米国内のSMS送信用に10桁ロングコードと無料番号をサポートした。さらにAmazon CloudWatchモニタリングサービスも改善され、1分単位でメトリクスを公開できるようになった。
Amazon SNSのドキュメントにある開発者ガイドにはメッセージのアーカイブとアナリティクスの章がある他、AWS CLIリファレンス、APIリファレンスなども掲載されている。Amazon SNSは使用量ベース料金の対象となっている。主として通知量に基づくが、デスティネーションによっても異なっている。Amazon SQS、Amazon Lambda、Amazon Kinesis Data Firehoseなど、デスティネーションサービスに関わる料金は別請求になる。サポートはAmazon SNSフォーラム経由で行われる。