AWSにおけるストリームデータ処理サービス概要 Amazon MSK / Amazon Kinesis Data Streams (KDS)

## はじめに

この記事は、先日某LT大会に筆者が表題で登壇した際に話した内容について、補足情報などを添えてまとめるものとなります。

**LT大会登壇資料リンク**
https://speakerdeck.com/shinyayoshidao/ji-tian-ltda-hui-20240226


## ストリームデータ処理のニーズの高まり

あらゆる物事の変化スピードが加速する世の中で、様々なソースから発生するリアルタイムデータの件数が増加しています。
そのようなデータから意味のあるものを取り込み、必要な処理や分析を行うことで、意思決定を迅速化するニーズが高まっています。

それを実現する一つの手段が、ストリームデータ処理です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3467546/5b365994-405c-c3f5-c694-812c0dca110c.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3467546/25518994-2040-7dc6-3e3a-809066b9b8ea.png)

**参考：なぜ今データ処理の「リアルタイム性」が求められているのか？**
https://www.fujitsu.com/downloads/blog/jp/journal/2018-06-19-01.pdf

# AWSにおけるストリームデータ処理サービス（＋キューサービスとの違い）

Amazon MSK と Amazon Kinesis Data Streams があります。
これらの概要や相違点は次の通りです。

### Amazon Kinesis Data Streams
上流のProducer(※後述)からデータを受信し、下流のConsumer(※後述)のために**ストリーム**という機能でデータを保存します。
>ストリームは、スループットとデータ管理を最適化するために**シャード**という単位に編成されます。
>シャードとは、ストリーム内で一意に識別されるデータ レコードのシーケンスです。ストリームは 1 つ以上のシャードで構成され、各シャードは固定単位の容量を提供します。ストリームの容量を増やすには、シャードの数を増やす必要があります。ストリームに割り当てられるシャードの数を増減すると、ストリームのデータ レート容量が制御されます。
>Kinesis Data Streams は、重要なストリーミング ワークロードの構成、デプロイ、スケーリング、セキュリティを管理する、完全に管理されたサービスです。

引用：[Building a Streaming Data Pipeline Solution](https://explore.skillbuilder.aws/learn/course/19779/play/130000/building-a-streaming-data-pipeline-solution)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3467546/18e1703b-001b-b7bb-d553-3f98f25fc569.png)

### Amazon MSK
上流のProducer(※後述)からデータを受信し、下流のConsumer(※後述)のために**トピック**という機能でデータを保存します。
>Apache Kafka を使ってストリーミングデータを処理するアプリケーションの構築および実行を可能にする、フルマネージドサービスです。Amazon MSK は、クラスターの作成、更新、削除などに用いられるコントロールプレーンオペレーションを提供します。

引用：[Amazon MSK デベロッパーガイドへようこそ](https://docs.aws.amazon.com/ja_jp/msk/latest/developerguide/what-is-msk.html)

トピックは**パーティション**に分割されますが、このパーティションはAmazon Kinesis Data Streams のシャードに該当します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3467546/4c4c875a-50f7-9615-3ea5-c235a8149393.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3467546/57d6817d-1e8e-dbf9-c98e-b41005c6136d.png)


## メッセージングサービス
一方で、AWSには似た様な役割を担う「キューサービス」(= Amazon SQS)がありますが、「ストリームデータ処理サービス」と「キューサービス」の違いは何なのでしょうか？

「ストリームデータ処理サービス」「キューサービス」はともに、「メッセージングサービス」としてまとめられることがあります。
「メッセージングサービス」の概要は次の通りで、上記の他には「トピックサービス」「バスサービス」が挙げられます。

**複数の異なるアプリケーション、システム、ドメインにおいて、(主に非
同期で) 相互に通信を行うための1つの方法**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3467546/3ad0315d-4622-1e3f-9e3c-b98154b9d41d.png)

メッセージングサービスではデータを「メッセージ」と呼び、メッセージングサービス自体を「ブローカー(イベントストア/イベントルータ ＝メッセージの保存場所)」と呼びます。
また、メッセージの発行元を「送信者(Sender/Publisher/Producer)」、メッセージの受取手を「受信者(Receiver/Subscriber/Consumer)」などと呼びます。

Amazon MSK が基盤とする Apache Kafkaを例にまとめてみました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3467546/15d5b161-2082-da3e-f9ce-f605ea3f774c.png)


話は少しそれましたが、同じメッセージングサービスに分類される「ストリームデータ処理サービス」と「キューサービス」の相違点の1つは、**ブローカーが受信者のメッセージ処理を見届けるか否か**、です。

キューサービスでは、受信者にメッセージを配送した後**受信者がメッセージの処理を完了するまで、ブローカーはメッセージを管理します**。
ストリームデータ処理サービスでは、受信者にメッセージを配送した後は、**受信者にてメッセージを管理することとしています**。

したがって、
キューサービスは**イベント駆動(※後述)など、送信者と受信者がそれぞれ独立しており、メッセージの確実な配送が必要な場合**に適しています。
ストリームデータ処理サービスは**ビッグデータの分散処理など、連続して発生するメッセージを同時並行的に処理する場合**に適しています。

**参考：「疎結合」を実現するメッセージングサービスの選択と利用 - AWS DevAx::Connect On-demand　※P10～17**
https://pages.awscloud.com/rs/112-TZM-766/images/DevAx_connect_season1_Day2_MessagingService_%E9%85%8D%E5%B8%83.pdf


## まとめ
この記事では、AWSにおけるストリームデータ処理サービスについて、筆者がLT大会で話したときの資料をベースにしつつ、補足情報を加えてご紹介しました。

今回、AWSのストリームデータ処理サービスを調べてまとめたきっかけは、**担当する業務でお客様が Amazon MSK を使ったストリームデータ処理を実現されており、Amazon MSK の仕組みや役割を理解したい！** と思ったことでした。

こうしたことがきっかけで外部への発信を行うことで、
①当該サービスについて正確に理解して整理することができた
②当該サービスや似た周辺サービスをまとめて学ぶことができた
③お客様との会話で自信をもって話せるようになった
などたくさんのメリットがありました。

今後チャレンジしたいことは、**業務と関連した他のAWSサービスやその他の技術要素についても、その特徴や役割を学び、業務で活きる知識を身に付けて、最終的に業務でアウトプットする**ことです。


## 参考情報
■イベント駆動型処理（イベントルータ）のメリット
- プロデューサとコンシューマは互いを意識しない
- 非同期化による応答性の改善、依存性の削減（後続のシステムが処理を完了するまで処理を待つ必要がない）
- 弾力性の向上、独立したスケーラビリティ（後続のシステムがすぐに処理を開始できない場合、バッファ機能を提供する）

■「受信者(Receiver/Subscriber/Consumer)」に対するメッセージ配信方法
「ストリームデータ処理サービス」「キューサービス」→ **Pull型**（受信者側でポーリングなどによりデータを取りに行く動作が必要）
「トピックサービス」→ **Push型**（送信者側で受信者を決めてデータを送り付ける）