Amazon Kinesis Streamsのサービス制限について
Amazon Kinesis Streamsを構築・運用すると、思いもかけないサービス制限に遭遇することがあります。 本日は2016年05月時点でのサービス制限についてご紹介します。
シャード数上限
東京リージョンの場合、リージョンあたりのシャード数のデフォルト上限値は25です。
この値はストリームごとのシャード数ではなく、リージョンごとのシャード総数です。 例えば、シャード数上限25のリージョンで、シャード数10のストリームを1個作成している場合、新規ストリームのシャード数上限は25−10＝15です。
また、ACTIVE(=データを新規に受け付ける)シャードだけが上限対象としてカウントされます。
例えば、シャード数10のストリームをシャード分割してシャード数20にする場合、
- ACTIVE シャード : 20
- CLOSED シャード : 10
となりACTIVE/CLOSEDなシャード総数は30となりますが、ACTIVEシャードだけをカウントすると20のため、上限の25には引っかかりません。
上限緩和申請により、上限を増やせます。 上限に関するマニュアルには"There is no upper limit to the number of shards in a stream or account."とあるのでハードリミットは存在しないようです。
シャード数の上限緩和はElastic IPの上限緩和などより時間がかかる傾向があるため(2016/04時点)、大規模にKinesisを使うとわかっている場合は、余裕を持って緩和申請すると良いでしょう。
データ保持期間
デフォルトのデータ保持期間(retention period)は24時間です。 最大で168時間(7日)まで延長できます。
Consumer の処理遅延や処理停止リスクに備えて、保持期間は長めに設定しておくのが良いでしょう。
保持期間の延長方法は次のURLを参照ください。
- http://docs.aws.amazon.com/streams/latest/dev/kinesis-extended-retention.html
- https://dev.classmethod.jp/cloud/kinesis-increase-stream-retention/
保持期間の延長に伴い、追加料金が発生します。 運用費については次のURLを参照ください。
操作APIの呼び出し制限
API の呼び出し頻度については以下の制限がありあます。
5 transactions/second の API
- CreateStream
- DeleteStream
- ListStrems
- GetRecords
- MergeShards
- SplitShard
更新中(UPDAINTG)のストリームは別の項新処理を行えません。そのため、シャード分割を並行で行うことはできません。 この制限にひかかることはほぼ無いでしょう。
10 transactions/second の API
- DescribeStream
備考
PutRecord/PutRecords など、残りのAPIについては、呼び出し頻度の制限に関する記述が見当たりません。
書き込み制限
シャードあたりの書き込み制限は以下がありあます。
- 1000 records/second
- 1 MB/second
この制限に引っかかると、スロットルされ、ProvisionedThroughputExceededException エラーが発生します。
仮に秒間あたり10000 レコードの追加が必要な場合、10シャードを用意し、ストリーム全体として 10000 records/second のスループットを確保します。
レコードについては以下の制限があります。
- 1 MB/record(base64エンコード前)
- 5 MB/transaction(
PutRecordsの場合) - 500 records/transaction(
PutRecordsの場合)
レコードをシリアライズしたり、複数レコードをPutRecords API でまとめて送ることによって、より効率的に書き込めます。
読み込み制限
シャードあたりの読み込み制限は以下があります。
- 2 MB/second
この制限に引っかかると、スロットルされ、ProvisionedThroughputExceededException エラーが発生します。
レコードについては以下の制限があります。
- 1 MB/record
- 10000 records/transaction
- 10 MB/transaction
仮に1回の GetRecords API 呼び出しで 10 MB かえってきた場合、「2 MB/second」のスロットル制限により、次の5秒間に再び GetRecords APIを呼び出すと ProvisionedThroughputExceededException エラーが発生します。
GetRecords 時の LIMIT パラメーター(AWS Lambda の場合は BatchSize)を調整し、スロットルされないようにしましょう。
一方で、LIMIT を絞り過ぎると、ingress に対して egress が足りず、レコード処理の遅延につながります。LIMIT を十分な大きさにする、LIMIT の変更が難しい場合はシャード数を増やす、と言った対応が必要です。
大量のデータを処理する場合はさじ加減に注意しましょう。
シャード・イテレーターの有効期間
GetShardIterator API を呼び出すと、シャードのイテレーターのポインターを取得できます。
このイテレーターは5分でタイムアウトします。
最後に
今回は Amazon Kinesis Streams の制限を一通り紹介しました。
非常に優秀な Amazon Kinesis も使い方を誤るとサービス制限に引っかかって本来の性能を発揮できません。
Kinesis Streams にはProducer(ingress)とConsumer(egress)が必ずついてまわります。 パフォーマンスチューニングやトラブルシュートの際には、Kinesis Streamsを中心にその前後のシステムを注意深く観察すると、思わぬ制限にひっかかっていたことに気づくかもしれません。
