AWSでストリームデータを扱うためのメッセージングサービス一覧（KDS, MSK, SQS, SNS, MQ）

著者: 伊藤 雅博, 株式会社日立製作所

# はじめに
AWSでストリーム処理を実現する際は、データをキューイングするメッセージングサービスと、キューイングしたデータをストリーム処理するサービスを組み合わせることが一般的です。本投稿では、AWSが提供する各メッセージングサービスの概要と、ストリームデータを扱う際の選択基準を紹介します。

なお、本投稿の内容は2020年中頃の調査結果をベースに、いくつか更新を加えたものです。AWSのサービス仕様は随時更新されるため、最新の仕様とは異なる場合があります。最新の情報はAWSの公式ドキュメントをご参照ください。

投稿一覧: 
1. AWSでストリームデータを扱うためのメッセージングサービス (本投稿)
2. [AWSのストリーム処理向けメッセージングサービスKDS(Kinesis)・MSK(Kafka)・SQSの特徴](https://qiita.com/sigmalist/items/1a65b0b0456516e2056b)
3. [AWSのKinesis Data Analytics、EMR Spark Streaming、Lambdaによるストリーム処理の特徴](https://qiita.com/sigmalist/items/6080df50091bfefa7cd5)


# ストリーム処理におけるメッセージキューの役割

ストリームデータとは、リアルタイムに生成される大量のデータのことです。例えば、IoTデバイスやコネクテッドカーのセンサデータや、業務システムが生成するログデータなどです。これらのデータは常時・無制限に生成され、時期によりデータ流量が急増することもあります。

ストリーム処理では、このようなストリームデータを即時処理することで、バッチ処理では不可能なリアルタイム性の高いサービスを実現します。

![streamdata.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285851/735fe334-4ac4-ae9f-1d95-13fc943c5c56.png)

流量が不安定なストリームデータの処理では、データ流量が急増するとシステムの処理負荷が上昇します。その結果、サービスの稼働停止やデータ消失につながることがあります。そのため、まずメッセージキューでデータを一時的にキューイングして、データの受付と処理を非同期化することで、システムの処理負荷を平準化することが一般的です。

また、大量発生するストリームデータ（例えば毎秒100万件）を、単体のAmazon EC2インスタンスで処理するのは困難です。そのため、ストリーム処理のロジック（データ加工や異常検知、モニタリングなど）は並列分散処理フレームワークで実装したり、イベント駆動型のアプリケーションとして実装することが多いです。

このようにストリーム処理システムは、メッセージキューを提供するメッセージングサービスと、ストリーム処理サービスの組み合わせで実現することが一般的です。

![streaming.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285851/1743a87c-25fd-1447-23a2-872feffaa20d.png)

本投稿では、上記のうちメッセージングサービスについて紹介します。


# AWSが提供する主要なメッセージングサービス

AWSでは以下のようなメッセージングサービスを提供しています。

- Amazon Kinesis Data Streams (KDS) 
- Amazon Managed Streaming for Apache Kafka (MSK)
- Amazon Simple Queue Service (SQS)
- Amazon Simple Notification Service (SNS) 
- Amazon MQ

これらサービスの特徴を以下の表に示します。

![messaging_services.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285851/d0513edb-d4a1-6782-a171-20bec6b3531f.png)

各サービスの仕様は随時更新されるため、最新の情報はAWSの公式ドキュメントをご参照ください。また、AWSではサービスクォータの引き上げを申請することで、制限値の引き上げが可能な場合もあります。

各サービスの概要を以下に示します。

## Amazon Kinesis Data Streams (KDS) 

KDSは分散メッセージキューのマネージドサービスです。書き込み/読み出し性能をスケールアウトできるため、大量のストリームデータを扱うことができます。また、AWSの様々なサービスと連携することが可能です。対応するストリーム処理サービスには以下のようなものがあります。

- Kinesis Data Analytics (KDA: SQL/Javaによるストリーム処理が可能) 
- AWS EMR (Spark Streamingによるストリーム処理が可能)
- AWS Lambda (イベント駆動型の処理が可能) 

## Amazon Managed Streaming for Apache Kafka (MSK)

MSKはオープンソースであるApache Kafkaのマネージドサービスであり、分散型の高性能なメッセージングプラットフォームです。米国ではFortune 100の80%以上の企業がKafka利用しており、大量のストリーミングデータを扱うメッセージキューのデファクトスタンダードといえます。

機能的にはKDSと似ており、大量のストリーミングデータを扱う場合に使用されます。また、Kafkaを用いた既存システムの移行にも向いています。

## Amazon Simple Queue Service (SQS)

SQSはコンポーネント間の送受信を切り離して疎結合化するために使用されます。基本的にチューニング不要のため簡単に使えます。SQSには高性能な標準キューと、メッセージの順番を保証するFIFOキューの2種類があります。また、Lambdaによるイベント駆動処理にも対応しています。

## Amazon Simple Notification Service (SNS) 

SNSは通知のようにタイミングが重要なメッセージの配信に使用します。チューニング不要で簡単に使えるほか、プッシュ配信が可能なのが特徴です。

## Amazon MQ

MQはActive MQまたはRabbit MQと互換性のあるメッセージングサービスであり、業界標準のAPI/プロトコル（MQTT、AMQPなど）を用いた既存システムの移行に向いています。AWSで新規にアプリケーションを構築する場合は他のメッセージキューを推奨します。

単一インスタンス構成または2つのAZ(Availability Zone)におけるアクティブ/スタンバイ構成が可能です。スケールアウトは出来ないため、大量のストリーミングデータを扱うのには向いていません。

# AWSにおけるストリーム処理の基本構成

上記の特徴から、ストリーム処理向けのメッセージングサービスにはKDSとMSKが適していると言えます。また、いくつか制限はありますがSQSも活用できそうです。ストリーム処理システムを構成するAWSサービスとその組み合わせを以下の図に示します。

![aws_streaming.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285851/e6908a5e-ff8c-4a6e-11e6-34f29ced42bc.png)

ストリーム処理システムでは、ストリームデータを受信するためのインタフェースを用意する必要があります。外部（IoTデバイスなど）からデータを受信する場合は、セキュリティ確保のためAPI Gatewayを経由することが多いです。内部（業務システムなど）から受信する場合は、各サービスのクライアント（Producer）で直接書き込むことも可能です。

# おわりに

本投稿では、AWSが提供する各メッセージングサービスの概要と、ストリームデータを扱う際の選択基準を紹介しました。ストリームデータを扱う際にはKDS、MSK、SQSといったメッセージングサービスがよく活用されています。

次回の投稿では、KDS、MSK、SQSの特徴とアーキテクチャの詳細を紹介します。

- 第2回: [AWSのストリーム処理向けメッセージングサービスKDS(Kinesis)・MSK(Kafka)・SQSの特徴](https://qiita.com/sigmalist/items/1a65b0b0456516e2056b)