Amazon Kinesis StreamとAmazon Kinesis FirehoseのAPIを比較する #reinvent

2015.10.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

re:invent 2015 では Amazon Kinesis の兄弟サービス Amazon Kinesis Firehose が発表されました。

本稿では、新旧 Kinesis の API を比較したいと思います。

サービス名

旧 Kinesis は Kinesis Streams というサービス名にリブランディング?され、新 Kinesis は Kinesis Firehose というサービス名で発表されています。

API としては Kinesis Streams は kinesis、新 Kinesis は firehose と名前空間が切られています。この違いは管理画面の URL でも確認可能です。

ストリーム操作

 API Kinesis Streams Kinesis Firehose
ストリーム一覧を表示 list-streams list-delivery-streams
ストリームを作成 create-stream create-delivery-stream
 ストリームを作成 delete-stream delete-delivery-stream
ストリームを表示 describe-stream describe-delivery-stream
ログ保存期間の増加 increase-stream-retention-period  存在しない
ログ保存期間の減少 decrease-stream-retention-period 存在しない

stream と delivery-stream という名前の違いがあります。

ログ保存期間(retention period)に関し、 Kinesis Firehose は24時間固定で、Kinesis Streams は24時間から7日までの間で変更可能です。Kinesis Firehose が発表されるまでは Kinesis  Stream も24時間固定でした。

タグ操作

API Kinesis Streams Kinesis Firehose
タグ追加 add-tags-to-stream 存在しない
タグ削除 remove-tags-from-stream 存在しない
タグ一覧 list-tags-for-stream 存在しない

Kinesis Firehose のストリームはタグ操作に対応していません。

こちらはほどなく機能追加されるのではないでしょうか。

シャードの操作

API Kinesis Streams Kinesis Firehose
シャードの分割 split-shard 存在しない
シャードの結合 merge-shards 存在しない

Kinesis Streams ではシャードごとの処理能力が明確に定義され、メトリクスをモニタリングしながら、データ量に応じてリシャーディング処理が必要でした。

Kinesis Firehose では AWS がこのめんどくさいリシャード処理をいい感じ運用してくれます(Keynote では "elastically scale" とおなじみの表現が使われていましたね)。Kinesis Firehose の製品ページから引用します。

The service takes care of stream management, including all the scaling, sharding, and monitoring, needed to continuously load the data to destinations at the intervals you specify.

レコード追加

API Kinesis Streams Kinesis Firehose
単一レコード追加 put-record 同じ
複数レコード追加 put-records 同じ

このAPIは同じです。

レコード処理

API Kinesis Streams Kinesis Firehose
イテレーター取得 get-shard-iterator 存在しない
レコード取得 get-records 存在しない
レコード連携先指定 存在しない update-destination

Kinesis 系はレコードが一定期間バッファリングされ、保存期間内であれば何回でも取得可能です。

Kinesis Streams はレコード取得処理が煩雑

そのため、Kinesis Streams からレコード取得する際は

  1. レコードの位置を取得(get-shard-iterator)
  2. 位置からN件レコードを取得(get-records)

という2段階の処理が必要でした。

また、Kinesis Streams のレコード取得は (ストリーム, シャード)単位で行われるため、リシャーディングでシャードが増減すると、アプリケーション側も増減したシャードを検知してレコード処理しなければなりません。そのため、Kinesis Client Library のようにリシャーディングと連動し、取得したレコードの処理(ビジネスロジック)に注力できるライブラリが必須でした。

Kinesis Firehose はレコード取得処理から開放してくれる

Kinesis Firehoseではユーザーはデータの連携先を指定する(update-destination)だけです。

S3・Redshift にデータ加工せずに連携するだけであれば、Kinesis Firehose は

  • リシャーディング
  • レコードの処理

の煩わしさから開放してくれます。

なんだか都元のJava SDK から Kinesis Firehose をさわってみた記事と同じような結論となりました。

Amazon Kinesis Firehoseに対する各操作をJavaから行う #reinvent | Developers.IO