はじめに
この記事は、先日某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 があります。
これらの概要や相違点は次の通りです。
一方で、AWSには似た様な役割を実現する「キューサービス」がありますが、これとの違いは何なのでしょうか？
そもそも、「ストリームデータ処理サービス」「キューサービス」はともに、「メッセージングサービス」にまとめられることがあります。
「メッセージングサービス」の概要は次の通りです。
メッセージングサービスではストリームデータを「メッセージ」と呼び、メッセージングサービス自体を「ブローカー」と呼びます。
また、メッセージの発行元を「送信者(Sender/Publisher/Producer)」、メッセージの受取手を「受信者(Receiver/Subscriber/Consumer)」などと呼びます。
Amazon MSK が基盤とする Apache Kafkaを例にまとめてみました。
話は少しそれましたが、同じメッセージングサービスに分類される「ストリームデータ処理サービス」と「キューサービス」の違いは、ブローカーが受信者のメッセージ処理を見届けるか否か、です。
キューサービスでは、受信者にメッセージを配送した後受信者がメッセージの処理を完了するまで、ブローカーはメッセージを管理します。
ストリームデータ処理サービスでは、受信者にメッセージを配送した後は、受信者にてメッセージを管理することとしています。
したがって、
キューサービスはイベント駆動など、送信者と受信者がそれぞれ独立しており、メッセージの確実な配送が必要な場合に適しています。
ストリームデータ処理サービスはビッグデータの分散処理など、連続して発生するメッセージを同時並行的に処理する場合に適しています。
ちなみに、AWSのキューサービスは Amazon SQS です。
参考：「疎結合」を実現するメッセージングサービスの選択と利用 - 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サービスやその他の技術要素についても、その特徴や役割を学び、業務で活きる知識を身に付けて、最終的に業務でアウトプットすることです。