[AWS Black Belt Onine Seminar] Amazon Kinesis
こんにちは、パートナーソリューションアーキテクト（PSA)の相澤です。
先日開催致しました AWS Black Belt Online Seminar 「Amazon Kinesis」の資料を公開いたしました。当日参加者の皆様から頂いたQAの回答と併せてご紹介致します。
今後のAWS Black Belt Online Seminarのスケジュールは こちら です。皆様のご参加をお待ちしております。
過去の資料や、動画もこちらから視聴可能ですので、そちらもご参照ください
Q1 Kinesis FirehoseからS3やESにデータ転送する際に、S3の書き込み制限やESの処理キューの状態などは加味されますでしょうか。
A1 おそらく、S3のバケットポリシーやACL、または、Amazon Elasticsearch Service（以下、ES）のスレッドプールのキャパシティ不足などに関する質問だと思います
S3のバケットポリシーやACLがFirehoseに書き込みなどの権限を与えていない場合には、リトライを試みた上でエラーとなります
また、Amazon Elasticsearch Serviceのキャパシティ不足などで書き込みが失敗した場合も、リトライを試みた上でエラーとなります
S3バケットのポリシーなどの設定をご確認の上、CloudWatchなどを活用して、FirehoseやESの状態を監視して対処してください
http://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#retry
Q2 CloudWatchLogsのサブスクリプションからKinesis Firehoseへの連携はできますでしょうか。
A2 はい、CLIを利用して設定可能です
http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs//SubscriptionFilters.html#FirehoseExample
Q3 VPCフローログを解析する際に、CloudWatchのマネジメントコンソール 「Amazon Elasticsearch Serviceへのストリーミングの開始」を選択してAmazonESへ送る場合と、Kinesis Firehose を経由してAmazonESへ送る場合ではどのような違いがありますでしょうか？
A3 Firehoseを経由することでLambdaによるデータレコードの変換処理をAmazon Elasticsearch Service（以下、ES）へ書き込む前に実行できます
さらに、ESへ書き込みつつ、Analyticsを利用してストリーム処理を実行し続けることができますので、VPCフローログの解析の幅を広げることができると考えられます
Q4 Kinesis StreamsからLambdaへはストリームデータを一定間隔で自動的にLambdaをキックする事ができたと思いますが、その場合のデータの流れは、DynamoDB StreamからLambdaが呼ばれるときと同様でしょうか？
A4 Kinesis StreamsとDynamoDB Streamsは異なるサービスですので、データの流れが厳密に同じとは言い切れません
ただし、Lambdaから見た場合、どちらもStreams based event sourcingとなりますので、同じイベントソースの受け渡し方といえます
Q5 FirehoseでS3に出力する場合、S3のPUT料金はどの程度を見込めばよいのでしょうか。
A5 Firehoseは一定時間または一定量のバッファリーングをした後に、S3へオブジェクトをputします
ですから、Firehose配信ストリームにputするデータレコードの流量とそれらのバッファリングのバランスにより料金も決定されます
http://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#frequency
Q6 KinesisよりもSQSが向いているユースケースはどういったものですか？また、その逆も教えていただきたいです。
A6 本来的にKinesisはストリームデータやストリーム処理用のサービスであるのに対して、SQSはキューイング用のサービスです
ですから、Kinesisの方がより大量のスループット、低いレイテンシーでデータを処理することに長けています
その一方、SQSは、Streamsのように任意の後続処理に連携することができ、Firehoseのようにキャパシティの管理をする必要がありません
ただし、Streamsのような順序保証であったり、タイムスタンプを利用した時系列処理をサポートしません
（SQSにはFIFOオプションがありますが、FIFOを選択するとQPSは限定的になるため、Kinesisの比較対象となり得ません）
https://aws.amazon.com/kinesis/streams/faqs/
また、SQSがキューの処理状態をSQSサービス側で管理するのに対し、Kinesisの場合にはKCLが行なっているようにコンシューマー側で管理します
その結果、基本的に、SQSキューとそのキューワーカーの比率は1:1になり、Kinesisストリームとそのコンシュマーの比率は1:Nになります
Q7 Kinesis AnalyticsのＳＱＬクエリーでしか時系列を制御できませんか？
A7 いいえ、Analytics以外にも、例えばOSSのApache FlinkやApache SparkのStructured Streamingでタイムスタンプを扱うことができます
（Structured StreamingではなくSpark Streamingの場合には、厳密にはタイムスタンプを扱うことができません）
現時点ではFlinkとSpark Streaming用にKinesis Connectorが公開されていますので、それらを活用していただくことができます
https://ci.apache.org/projects/flink/flink-docs-release-1.3/dev/connectors/kinesis.html
http://spark.apache.org/docs/2.2.0/streaming-kinesis-integration.html
Q8 kinesis firehoseでストリームデータを解析して、出力先s３のバケットを変更できますか？
A8 おそらく、Firehoseに対してAnalyticsのクエリで分析をしてFirehoseの出力先のバケットを変更できるか、というご質問だと思います
入力となっているFirehoseの配信先を変更することはできません
しかし、クエリ結果は入力となったFirehoseとは異なるストリーム（StreamsまたはFirehose）に出力することができます
これを利用してストリームデータの流れを分岐させることができます（ただし最大数はAnalyticsアプリケーションごとに3つです）
以上です。
コメント