はじめに
こんにちは、SAYJOY です。
Kinesis の種類が多くても、まったく困ることは無い今日このごろ。ｗ
AWS の学習を進めるなかで「Kinesis わからなすぎる」と思ったのでざっくり情報を整理しておくことにしました。
とりあえず今回は、
Kinesis とはナニをするものなのか、どんな種類があるのか、あたりについて整理していこうと思います。
Kinesis 4種類
まずは種類について。
Kinesis って色々な種類があって混乱しますよね。
え。しませんか？そうですか。。
今のところKinesis を使う場面に巡り合うことが出来ていないので、私は超絶混乱していました。ｗ
- Amazon Kinesis Video Streams
- Amazon Kinesis Data Streams
- Amazon Kinesis Data Firehose
- Amazon Kinesis Data Analytics
どれも「ストリーミングデータを取り扱う」という共通点があるようですね。（そりゃそうだ）
それぞれ特徴があるので簡単に（本当に簡単に）触れていきます。
※以下で使用する画像の出典はこちら→「Amazon Kinesis の概要 (公式)」
● Video Streams
動画の「ストリーミング」を行う。
● Data Streams
データの「ストリーミング」を行う。
● Data Firehose
ストリーミングデータの「ロード」を行う。
● Data Analytics
標準SQL による「データ分析」を行う。
ついでに用語整理
Kinesis の種類と、それぞれの役割がなーんとなく分かったところで、
Kinesis の説明に出てくるコトバについて学んでいきましょう。
出典：「Kinesis Data Streams のアーキテクチャの概要 (公式)」
Kinesis Data Stream
Kinesis data stream は、シャードのセットです。各シャードにはデータレコードのシーケンスがあります。各データレコードには、Kinesis Data Streams によってシーケンス番号が割り当てられます。
データレコード
データレコードは、Kinesis data stream に保存されたデータの単位です。データレコードは、シーケンス番号、パーティションキー、データ BLOB (イミュータブルなバイトシーケンス) で構成されます。Kinesis Data Streams で BLOB 内のデータが検査、解釈、変更されることは一切ありません。データ BLOB は 最大 1 MB にすることができます。
プロデューサー（データ送信側）
プロデューサーは、データレコードを Amazon Kinesis データストリームに送信します。たとえば、Kinesis data stream にログデータを送信するウェブサーバーはプロデューサーです。コンシューマーは、ストリームのデータレコードを処理します。
コンシューマー（データ処理側）
コンシューマーは、Amazon Kinesis Data Streams からレコードを取得して処理します。これらのコンシューマーは Amazon Kinesis Data Streams Application と呼ばれます。
Amazon S3、Amazon Redshift、Amazon ES、Splunk などのサービスに直接ストリームレコードを送信する場合は、コンシューマーアプリケーションを作成する代わりに Kinesis Data Firehose 配信ストリームを使用できます。
シャード
シャードは、ストリーム内の一意に識別されたデータレコードのシーケンスです。ストリームは複数のシャードで構成され、各シャードが容量の 1 単位になります。
ストリームのデータ容量は、ストリームに指定したシャードの数によって決まります。ストリームの総容量はシャードの容量の合計です。
データ転送速度が増加した場合、ストリームに割り当てられたシャード数を増やしたり、減らしたりできます。
パーティションキー
パーティションキーは、ストリーム内のデータをシャード別にグループ化します。Kinesis Data Streams は、ストリームに属するデータレコードを複数のシャードに分離します。この際、各データレコードに関連付けられたパーティションキーを使用して、配分先のシャードを決定します。
アプリケーションは、ストリームにデータを配置するときに、パーティションキーを指定する必要があります。
シーケンス番号
各データレコードには、シャード内のパーティションキーごとに一意のシーケンス番号が割り当てられます。
まとめ
今回は、4種類のKinesis について学びました。
結局のところ
取り扱うデータの違い（Video／Data）や、
アーキテクチャにおける役割の違い（ストリーミング(Streams)／ロード(Firehose)／分析(Analytics) ）
がポイントと言えるのではないでしょうか。
なお、
肝心な「（自分の身近なところでの）使い所」に関しては、今のところ「まだピンときていない」というのが正直な感想です。ｗ
プロデューサーから送信されるデータの例としては、以下のようなパターンがあるようですね。
- IT インフラストラクチャのログデータ
- アプリケーションのログ
- ソーシャルメディア
- マーケットデータフィード
- ウェブのクリックストリームデータ
リアルタイム性が求められるソリューションでの活用が有効ということは理解できたので、そのような案件に関われるように精進するのみです！ｗ
ということで今日はここまで。
最後まで読んでいただきありがとうございます。
