著者: 伊藤 雅博, 株式会社日立製作所
はじめに
AWSでストリーム処理を実現する際は、データをキューイングするメッセージングサービスと、キューイングしたデータをストリーム処理するサービスを組み合わせることが一般的です。本投稿では、AWSが提供する各メッセージングサービスの概要と、ストリームデータを扱う際の選択基準を紹介します。
なお、本投稿の内容は2020年中頃の調査結果をベースに、いくつか更新を加えたものです。AWSのサービス仕様は随時更新されるため、最新の仕様とは異なる場合があります。最新の情報はAWSの公式ドキュメントをご参照ください。
投稿一覧:
- AWSでストリームデータを扱うためのメッセージングサービス (本投稿)
- AWSのストリーム処理向けメッセージングサービスKDS(Kinesis)・MSK(Kafka)・SQSの特徴
- AWSのKinesis Data Analytics、EMR Spark Streaming、Lambdaによるストリーム処理の特徴
ストリーム処理におけるメッセージキューの役割
ストリームデータとは、リアルタイムに生成される大量のデータのことです。例えば、IoTデバイスやコネクテッドカーのセンサデータや、業務システムが生成するログデータなどです。これらのデータは常時・無制限に生成され、時期によりデータ流量が急増することもあります。
ストリーム処理では、このようなストリームデータを即時処理することで、バッチ処理では不可能なリアルタイム性の高いサービスを実現します。
流量が不安定なストリームデータの処理では、データ流量が急増するとシステムの処理負荷が上昇します。その結果、サービスの稼働停止やデータ消失につながることがあります。そのため、まずメッセージキューでデータを一時的にキューイングして、データの受付と処理を非同期化することで、システムの処理負荷を平準化することが一般的です。
また、大量発生するストリームデータ（例えば毎秒100万件）を、単体のAmazon EC2インスタンスで処理するのは困難です。そのため、ストリーム処理のロジック（データ加工や異常検知、モニタリングなど）は並列分散処理フレームワークで実装したり、イベント駆動型のアプリケーションとして実装することが多いです。
このようにストリーム処理システムは、メッセージキューを提供するメッセージングサービスと、ストリーム処理サービスの組み合わせで実現することが一般的です。
本投稿では、上記のうちメッセージングサービスについて紹介します。
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
これらサービスの特徴を以下の表に示します。
各サービスの仕様は随時更新されるため、最新の情報は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サービスとその組み合わせを以下の図に示します。
ストリーム処理システムでは、ストリームデータを受信するためのインタフェースを用意する必要があります。外部（IoTデバイスなど）からデータを受信する場合は、セキュリティ確保のためAPI Gatewayを経由することが多いです。内部（業務システムなど）から受信する場合は、各サービスのクライアント（Producer）で直接書き込むことも可能です。
おわりに
本投稿では、AWSが提供する各メッセージングサービスの概要と、ストリームデータを扱う際の選択基準を紹介しました。ストリームデータを扱う際にはKDS、MSK、SQSといったメッセージングサービスがよく活用されています。
次回の投稿では、KDS、MSK、SQSの特徴とアーキテクチャの詳細を紹介します。