kashinoki38 blog

something like tech blog

トップ > AWS > Kinesis, Lambdaのボトルネック解析時の考慮点

Kinesis, Lambdaのボトルネック解析時の考慮点

AWS

Kinesis, Lambdaのボトルネック解析時の考慮点をまとめてみました。

Kinesis

監視

CloudWatchで以下メトリクスを確認する。

docs.aws.amazon.com

呼び出しメトリクス

  • IncomingRecords, GetRecords.Records
    • 統計：合計
    • Kinesisストリームに正常に送信されたレコード数、シャードから取得したレコード数
  • PutRecord.Success / PutRecords.Success, GetRecords.Success
    • 統計：平均合計
    • ストリームごとの成功したPutRecordsオペレーションの数、ストリームごとの成功したGetRecordsオペレーションの数
    • 平均の統計はPutRecord / PutRecords / GetRecordsオペレーションでのレコード数
  • IncomingBytes, PuRecord/PuRecords.Bytes, GetRecords.Bytes
    • 統計：平均、合計
    • Kinesisストリームに正常に送信されたバイト数、Kinesisストリームから取得したバイト数
    • 平均の統計はPutRecord / PutRecords / GetRecordsオペレーションでのバイト数

パフォーマンスメトリクス

  • GetRecords.IteratorAgeMilliseconds
    • 統計：平均、最大、P90
  • ReadProvisionedThroughputExceeded / WriteProvisionedThroughputExceeded
    • 統計：平均
    • 0じゃない場合、Kinesisのスループット上限に達して調整が行われたことを意味する
    • シャードあたりの上限抵触の場合、シャード分割する
    • レコードあたりの上限抵触の場合、
      • 書き込み：レコードをシリアライズしたり、複数レコードをPutRecords API でまとめて送ることによって、より効率的に書き込む
      • 読み込み：GetRecords時のLIMITパラメーター(AWS Lambda の場合は BatchSize)を調整する
  • PutRecord.Latency / PutRecords.Latency / GetRecords.Latency
    • 統計：平均、最大、P90
    • PutRecord / PutRecords / GetRecordsオペレーションにかかった時間

上限

dev.classmethod.jp

docs.aws.amazon.com

基本的にシャードあたり、レコードあたりの上限に引っかからなければ、シャードを増やす水平スケールでどこまでもスケールできる。懸念はお金だけ。

  • シャード数上限
    • デフォルトのシャードクォータは 200 （リージョンごと）
    • だが、ハードリミットはなく上限緩和申請でどこまでもいける
  • データ保持期間
    • デフォルト24時間
    • 最大で7日間
  • 操作API呼び出し制限
    • 更新中(UPDAINTG)のストリームは別の項新処理を行えません。そのため、シャード分割を並行で行うことはできません。 この制限にひかかることはほぼ無いでしょう。
    • 5 transactions/second の API
      • CreateStream
      • DeleteStream
      • ListStrems
      • GetRecords
      • MergeShards
      • SplitShard
    • 10 transactions/secondのAPI
      • DescribeStream
  • 書き込み制限
    • シャードあたり
      • 1000 records/second
      • 1 MB/second
      • 引っかかるとProvisionedThroughputExceededException
    • レコードあたり
  • 読み込み制限
    • シャードあたり
      • 2 MB/second
      • 引っかかるとProvisionedThroughputExceededException
    • レコードあたり
      • 1 MB/record
      • 10000 records/transaction
      • 10 MB/transaction
  • シャードイテレータ

Lambda

監視

CloudWatchで以下メトリクスを確認する。

docs.aws.amazon.com

呼び出しメトリクス

  • Invocations
    • 統計：合計
    • Lambda実行数、処理量の確認
    • エラーも含む
  • Errors
    • 統計：合計
    • エラー発生していないか
    • エラーが発生すると再実行になるので、ストリーミングにおいて回避しないと待ち行列増加につながる
  • Throttles
    • 統計：合計
    • スロットリングが起こっていないか
    • スロットルが起きている場合、InvocationにもErrorsにもカウントされない

パフォーマンスメトリクス

  • Duration
    • 統計：平均、最大、P90
    • 処理時間
  • IteratorAge
    • 統計：平均、最大、P90
    • Kinesis/dynamoDBとストリームでのみ利用
    • ストリームから読み取るイベントソースマッピングの場合、イベントの最後のレコードの所要時間。所要時間は、ストリームがレコードを受信してから、イベントソースマッピングがイベントを関数に送信するまでの時間です。
    • 要は、KinesisやDynamoDB内に滞留している時間。ストリームベースの場合Durationと共に重要。
    • これが増加している場合、Lambdaの遅延やスループットが足りないことが想定されるので、Durationを上げる、シャード増やして同時実行数あげる、エラーを回避する等の対応が必要。

同時実行メトリクス

  • ConcurrentExecutions
    • 統計：平均、最大
    • 同時実行数が上限行っていないか。
    • 関数の同時実行数設定、アカウント内のリージョン上限、Kinesisシャード数×並列化係数あたりが上限。
    • 関数の同時実行数設定、アカウント内のリージョン上限に達する場合スロットリングが発生する

上限

docs.aws.amazon.com

Kinesis同様、同時実行数を増やす水平スケールでどこまでもスケールできる。懸念はお金だけ。

前まではENIが以下の式の分用意されていたのでIP枯渇がスケール限界の1観点だったが、2019年11月からはHyperplane ENIを使用して共通のENI、IPアドレスをリージョン×関数ごとに1つだけ用意されるようになったのでスケール限界としては考慮不要になった。

ENI = Projected peak concurrent executions * (Memory in GB / 3GB)

# Projected peak concurrent executions: 関数がサポートする必要がある同時実行の数
# Memory: Lambda 関数用に設定したメモリの容量

aws.amazon.com

参考

www.slideshare.net