Amazon Kinesis StreamsとAmazon Kinesis Firehoseは何が違うのか
こんにちは、せーのです。 先日のRe:InventでKinesisの体系が変わりまして、「Kinesis Family」「Kinesis三兄弟」なんて言われるようになりました。 今まではKinesisの一機能として「Kinesis Streams」というのがあったのですが、それがメインのサービスとして昇華し、新たに「Kinesis Firehose」「Kinesis Analytics」が増えて現在の形になりました。 今回はそのうち混同しやすい「Kinesis Firehose」と「Kinesis Streams」の使い分けについてご紹介したいと思います。
やろうと思えば両方できる
Kinesis Streamsは次々と送られる大量のデータをリアルタイムに収集、次のサービスに配送するためのサービスです。一方Kinesis Firehoseは同じく次々と送られる大量のデータをRedShiftやS3に流し込むサービスです。 しかし今までもKinesis StreamsにLambdaをつけてS3やRedshiftに流したりしていましたし、FirehoseでS3に流したデータをevent notificationでLambdaを起動させてDynamoDBやEC2に流すことだってできます。 では一体この2つのサービスは何が違うのでしょう。
Kinesis Streamsは「リアルタイム」「カスタム」
Kinesis Streamsの最大の特徴は「レイテンシの速さ」です。Kinesis Firehoseがデータロードまで60秒を見ているのに対しKinesis Streamsはsub-1、つまり1秒以下でのデータロードにて設計されています。 Kinesis Streamsの使いドコロとしては「次々に上がってくるデータの内容をリアルタイムに加工、表示させたい」というニーズに対応させるのが良いでしょう。LambdaやEC2でStreamsのレコードを拾えるのもすぐに加工してダッシュボード等に表示しやすくするためです。
Streamsは「小川」という意味です。流れてくる水を洗濯に使うのか、何かモノを冷やすのか、車を洗うのに使うのか、、、どう使うかはユーザー次第ということですね。
Kinesis Firehoseは「Zero Administration」「ダイレクト」
Kinesis Firehoseの特徴としては「Zero Administration(ゼロ管理)」というのが挙げられます。Kinesis Streamsとは違い、EC2からポーリングしたりLambdaのコードを書く必要は一切ありません。設定を行うだけでS3やRedshiftにデータがそのまま流れます。 S3やRedshiftに大量のデータを溜める目的は何か。それはズバリ「分析用途」です。各種BIツールでデータをわかりやすく表示し、様々なクエリをかけて多様な切り口からデータを分析するためにRedshiftのようなDWHは存在します。 分析するのにデータがputされてから処理するまでのスピードはそれほど求められません。逆に求められるのは大量のデータを効率よく格納する圧縮技術やいかにセキュアにデータを保持するか、という暗号化技術です。 FirehoseはGZIPやSNAPPYといった圧縮アルゴリズムが使えますし、KMSを使った暗号化も可能になっています。
Firehoseは「消化ホース」という意味です。火事の家一点目掛けて大量に水をかける、という一つの目的にしか使えませんがホースを向けたら後は放っといてもいつまでも水をかけ続けることができる、ということです。
まとめ
いかがでしたでしょうか。Kinesis StreamsとKinesis Firehoseの違いを簡単にまとめてみました。 もちろんFirehose -> S3 -> Lambda、という流れを作っても全く問題はないのですが、上のように何故Firehoseというサービスがあるのか、という点を抑えておけばLambdaやEC2の中も分析やETL処理と言った用途に限定されていくのではないでしょうか。適材適所な使い方をするのがいいですね。
