Amazon Kinesis Data Streams でパフォーマンスの問題が発生した際の調査方法を教えてください

Amazon Kinesis Data Streams でパフォーマンスの問題が発生した際の調査方法を教えてください

特定の問題に偏らず、Amazon Kinesis Data Streams で問題が発生した際の調査方法を AWS Black Belt を基に纏めました。トラブルシューティングについては、ドキュメントと AWS からの公式回答のある AWS re:Post を記載しています。
Clock Icon2023.05.08

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

困っていること

Amazon Kinesis Data Streams(大量のストリームデータをリアルタイムで収集するためのサーバーレスストリーミングデータサービス)を利用して、ストリーム処理によるリアルタイム分析を行っています。
運用開始後に暫くして、ダッシュボードのデータ反映が遅延していると報告がありました。また弊社で管理している他のアカウントでもパフォーマンスの問題が発生している状況です。原因を調査したいのですがどのように確認すれば良いか解りません。調査方法と参考となる対処法もあれば教えてください。

どう対応すればいいの?

調査方法としては参考情報に記載の通り、以下のような範囲で原因の切り分けを行います。

  • Source
  • Producer
  • Data Stream
  • Consumer
  • Target(Destination)

切り分けの認識後、AWS では 調査の一歩目として中央の Amazon Kinesis Data Streams を起点に確認することを提案しています。
AWS サービスが提供する Amazon CloudWatch メトリクスは有用な情報が数多く含まれているため、対象範囲の使用しているサービスを CloudWatch メトリクスで調査します。
調査の際、エラーによって処理が滞留しているのか、スペック不足(スループット不足)によって処理が滞留しているのか等を確認後、有効な対処法を実施します。

参考情報 (以後全て同一の参考情報)

調査と監視のポイント

  • タイムラグ
    Point : アプリケーションによるイベントを生成してから、宛先にデータが取り込まれるまでのタイムラグは SLA 内か、タイムラグの継続的な増加はみられるかを確認します。

  • スループット
    Point : スループットの急激な増加、あるいは低下は発生しているか、トラフィックの継続的な増加はみられるかを確認します。

  • キャパシティ、リソース使用率
    Point : リソース使用率が上限に達していないか、割り当てリソースに対する使用率が極端に低くないかを確認します。

Amazon Kinesis Data Streams の CloudWatch メトリクス確認

以下ドキュメントと参考情報に記載の通り、ストリーム自体のエラー発生状況に加えて、コンシューマーの処理遅延などもモニタリングが可能です。 メトリクスを見るだけでなく、全てのシャードが同様のトレンドを示しているか、特定シャードに偏って異常が見られないかを確認してください。

  • ReadProvisionedThroughputExceeded
  • WriteProvisionedThroughputExceeded
  • GetRecords.Success, PutRecord.Success, PutRecords.Success

Kinesis Data Streams のトラブルシューティングに役立つ主要なメトリクスについて、以下 AWS re:Post で端的に纏められているのでご参考にしてください。

WriteProvisionedThroughputExceeded > 1 について

単純にキャパシティ不足に起因していることが多いが、書き込みが特定シャードに偏っている可能性があります。その場合、AWS ではクライアントの実装見直しを推奨しています。

以下 AWS re:Post も参考にご検討ください。

ReadProvisionedThroughputExceeded > 1 について

読み取り処理のスロットリングは、3 つ以上のコンシューマーが同一のシャードからデータを取得している場合に発生しやすいです。

以下 AWS re:Post を参考にご対応ください。

Target と Consumer の遅延が疑われる場合

Consumer で問題が発生しているのか、Target(Destination) のデータストアで問題が発生しているかを確認します。 以下の参考情報では、一例として Amazon OpenSearch Service と AWS Lambda について紹介しています。こちらを参考にご利用のサービスに合わせて確認してください。
冒頭での記載通り、対象サービスの CloudWatch メトリクスを調査してエラーによって処理が滞留しているのか、スペック不足(スループット不足)によって処理が滞留しているのか等を確認することで対処法を考えます。

更なる Data Streams 調査

問題の発生個所だけでなく、ストリーム全体(Kinesis Data Streams)で同様の傾向にあるか、特定シャードで偏った傾向がみられるかを合わせて切り分けるとよいとされています。

IteratorAgeMilliseconds のトラブルシューティングについて

Kinesis Data Streams の IteratorAgeMilliseconds 値が増加し続ける場合は、以下 AWS re:Post を参考にご対応ください。

Producer の遅延が疑われる場合

Producer(プロデューサー)が生成したイベントを、遅延・エラーなくデータストリームに送信できているか調査してください。以下の参考情報では、Amazon Kinesis Producer Library(KPL)を使用した Producer の確認方法を記載しています。
ほとんどのユースケースでは、Kinesis Data Streams KPL ライブラリを使用しますが、AWS SDK for Java を利用したプロデューサーの開発 もあるのでご自身の環境について認識してください。

プロデューサーに関するメトリクスについては、ドキュメントをご確認ください。

Producer のトラブルシューティングについて

以下ドキュメントのトラブルシューティングより解消される場合があるので、ご参考に対応してください。

参考資料

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.