はじめに
この記事は、先日某LT大会に筆者が表題で登壇した際に話した内容について、補足情報などを添えてまとめるものとなります。
LT大会登壇資料リンク
https://speakerdeck.com/shinyayoshidao/ji-tian-ltda-hui-20240226
ストリームデータ処理のニーズの高まり
あらゆる物事の変化スピードが加速する世の中で、様々なソースから発生するリアルタイムデータの件数が増加しています。
そのようなデータから意味のあるものを取り込み、必要な処理や分析を行うことで、意思決定を迅速化するニーズが高まっています。
それを実現する一つの手段が、ストリームデータ処理です。
参考：なぜ今データ処理の「リアルタイム性」が求められているのか？
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
Amazon MSK
上流のProducer(※後述)からデータを受信し、下流のConsumer(※後述)のためにトピックという機能でデータを保存します。
Apache Kafka を使ってストリーミングデータを処理するアプリケーションの構築および実行を可能にする、フルマネージドサービスです。Amazon MSK は、クラスターの作成、更新、削除などに用いられるコントロールプレーンオペレーションを提供します。
トピックはパーティションに分割されますが、このパーティションはAmazon Kinesis Data Streams のシャードに該当します。
メッセージングサービス
一方で、AWSには似た様な役割を担う「キューサービス」(= Amazon SQS)がありますが、「ストリームデータ処理サービス」と「キューサービス」の違いは何なのでしょうか？
「ストリームデータ処理サービス」「キューサービス」はともに、「メッセージングサービス」としてまとめられることがあります。
「メッセージングサービス」の概要は次の通りで、上記の他には「トピックサービス」「バスサービス」が挙げられます。
複数の異なるアプリケーション、システム、ドメインにおいて、(主に非
同期で) 相互に通信を行うための1つの方法
メッセージングサービスではデータを「メッセージ」と呼び、メッセージングサービス自体を「ブローカー(イベントストア/イベントルータ ＝メッセージの保存場所)」と呼びます。
また、メッセージの発行元を「送信者(Sender/Publisher/Producer)」、メッセージの受取手を「受信者(Receiver/Subscriber/Consumer)」などと呼びます。
Amazon MSK が基盤とする Apache Kafkaを例にまとめてみました。
話は少しそれましたが、同じメッセージングサービスに分類される「ストリームデータ処理サービス」と「キューサービス」の相違点の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型（送信者側で受信者を決めてデータを送り付ける）