Amazon Web Services ブログ

Kinesis Client Library 3.0 を活用してストリーム処理アプリケーションのコンピューティングコストを削減しましょう

本記事は、2024/11/06 に公開された Reduce your compute costs for stream processing applications with Kinesis Client Library 3.0 の翻訳記事です。翻訳は Solutions Architect の Rui Lee が担当しました。

Amazon Kinesis Data Streams は、あらゆる規模のストリーミングデータを容易にキャプチャ、格納できるサーバレスのデータストリーミングサービスです。Kinesis Data Streams は、すぐに利用可能な多くの統合を使用してストリームに送信されたデータを処理する柔軟性を提供するだけではありません。コンピューティングフリートにデプロイ可能な、カスタムストリーム処理アプリケーションを構築する機能も提供しています。

カスタムストリーム処理アプリケーションを構築する際、開発者は通常、リアルタイムで高スループットデータを処理するために必要な分散コンピューティングの管理に課題に直面します。この課題に対処するのが Kinesis Client Library (KCL) です。多くの AWS 顧客が、KCL を活用して分散システムの複雑さを気にすることなく、Kinesis Data Streams でカスタムストリーム処理アプリケーションを運用しています。KCL は Kinesis Data Streams API を使用してストリームからデータを読み取り、複数のワーカー間でのストリーム処理のロードバランシング、フェイルオーバーの管理、処理済みレコードのチェックポインティングなどの複雑な処理の実装を肩代わりしてくれます。KCL はこれらの複雑な処理を開発者の代わりにハンドリングすることで、開発者がストリーミングデータ処理のコアビジネスロジックの実装に集中できるようになります。

アプリケーションが処理する時間あたりのデータ量が増加するにつれて、顧客はストリーム処理アプリケーションの計算コストを削減したいと考えるようになります。以前のバージョンの KCL と比較し、最大 33% のストリーム処理コストを削減することが可能な、Kinesis Client Library 3.0 のリリースを紹介できることを喜ばしく思います。KCL 3.0 は、新しいロードバランシングアルゴリズムを採用しています。このアルゴリズムは、ワーカーのリソース利用状況を継続的に監視し、処理を均等に再配布することで、同じデータをより少ない計算リソースで処理できるようにします。

この投稿では、サンプルワークロードをベースにストリーム処理におけるロードバランシングの課題について説明し、ワーカー間での不均一なロード分散がどのように処理コストを増加させるかを示します。次に、KCL 3.0 がこの課題にどのように対処して計算コストを削減するかを示しつつ、KCL 2.x から 3.0 へ容易にアップグレードできる手順を説明します。さらに、KCL 3.0 が提供する追加の利点についても説明します。これには、AWS SDK for Java 2.x の使用と、AWS SDK for Java v1.x への依存の解消が含まれます。最後に、ストリーム処理アプリケーションを KCL 3.0 に移行する際のチェックリストも共有します。

カスタムストリーム処理アプリケーションの運用におけるロードバランシングの課題

リアルタイムのデータストリームを処理するお客様は、通常、高いスループットを並列処理するために、複数の計算リソースを利用します。例えば、Amazon Elastic Compute Cloud (Amazon EC2) などです。多くの場合、データストリームには、同じワーカーによって処理される必要があるレコードが含まれています。例えば、あるトラック会社が、数千台の車両から公開されるリアルタイムの位置座標を含むストリーミングデータを処理するために、それぞれ 1 つのワーカーを実行する複数の EC2 インスタンスを使用する場合があるとします。車両の経路を正確に追跡するには、各トラックの位置情報は同じワーカーによって処理される必要があります。このようなユースケースでは、お客様はデータストリームに公開される各レコードに対して、車両 ID をパーティションキーとして指定します。順序どおりに処理するために、Kinesis Data Streams は同じパーティションキーに属するデータレコードを単一のシャード (Kinesis Data Streams の基本的なスループット単位) に書き込みます。

ただし、ストリームのデータはパーティションキーに関連するトラフィックの変動により、シャード間で不均等に分散することがよくあります。たとえば、稼働中の車両は位置更新を頻繁に送信しますが、待機中の車両は更新頻度が低いといったことが考えられます。以前の KCL バージョンでは、ストリーム処理アプリケーションで各ワーカーが同数のシャードを並列処理していました。その結果、データの多いシャードを処理するワーカーはデータ処理の限界に達する一方で、データの少ないシャードを処理するワーカーは十分に活用されていませんでした。このワークロードの不均衡は、リソース活用とストリーム処理の効率化を目指すお客様にとって課題となっていました。

トラフィックがストリーム内のシャードで不均一な場合のサンプルワークロードを例として、KCL 2.6 でコンピューティングリソースの利用が不均一になる理由と、それがコストの増加につながる理由を一緒に見ていきましょう。

サンプルのワークロードでは、プロデューサーアプリケーションが 4 つのシャードに 2.5MBps のデータを発行しています。ただし、パーティションキーに関連するトラフィックパターンに基づいて、2 つのシャードが 1MBps ずつ、他の 2 つのシャードが 0.25MBps ずつ受け取っています。例のトラック運送会社であれば、2 つのシャードは稼働中の車両から、残りの 2 つのシャードは待機中の車両からデータを保存していると考えられます。このサンプルのワークロードでは、3 台の EC2 インスタンス (それぞれ 1 つのワーカーを実行) を使用して、KCL 2.6 でこのデータを処理しました。

最初は、3 つのワーカーに負荷が分散され、CPU 使用率は 50%、50%、25% で平均で 42% でした (次の図の 12:18 – 12:29 の時間枠を参照)。EC2 フリートが十分に活用されていないため、コスト効率を高めるために 1 つの EC2 インスタンス (ワーカー) をフリートから削除し、2 つのワーカーで運用してみました。しかし、ワーカーを削除すると、1 つの EC2 インスタンスの CPU 使用率がほぼ 100% に増加してしまいました。

これは、KCL 2.6 以前のバージョンでは、スループットやワーカーの CPU 使用率に関係なく、各ワーカーが同じ数のシャードを処理するように負荷を分散するためです。この場合、1 つのワーカーが 2 つの高スループットシャードを処理し、CPU 使用率が 100% に達し、別のワーカーが 2 つの低スループットシャードを処理し、CPU 使用率が 25% にとどまっていました。

一部のワーカーが過剰に利用され処理が遅延する可能性があるため、この CPU 使用率の不均衡によりワーカーコンピューティングフリートをスケールダウンできません。全体としてはフリートが十分に活用されていませんが、負荷の偏りがフリートのスケールダウンを妨げています。これにより、ストリーム処理アプリケーションの計算リソース費用が増えています。

次に、KCL 3.0 がこれらのロードバランシング課題にどのように対処しているかを見ていきたいと思います。

KCL 3.0 によるロードバランシングの改善

KCL 3.0 では、KCL ワーカーの CPU 使用率を監視し、ストリーム処理の負荷を再分散する新しいロードバランシングアルゴリズムが導入されました。新しいロードバランシングアルゴリズムでは、ワーカーがデータの処理限界に近いことや、ワーカー間の CPU 使用率の分散が大きいことを検知した場合、過剰に使用されているワーカーから使用率の低いワーカーへ負荷を再分散します。これにより、すべてのワーカー間でストリーム処理の負荷が均等化されます。その結果、ワーカー間の CPU 使用率の不均衡による過剰なキャパシティのプロビジョニングを回避でき、コンピューティングキャパシティを適切にサイジングすることで、コストを節約できます。

次の図は、KCL 2.6 と同じシミュレーション設定で KCL 3.0 の結果を示しています。

3 つのワーカーがある場合、KCL 3.0 は当初 KCL 2.6 と同様に負荷を分配し、平均 CPU 使用率は 42% でした (20:35 – 20:55 の時間枠)。しかし、1 つのワーカーを削除すると (赤い垂直点線で示されています)、KCL 3.0 はシャードの数だけでなく、シャードのスループット変動性も考慮して、1 つのワーカーから他の 2 つのワーカーに負荷を再配分しました。その結果、2 つのワーカーの CPU 使用率は約 65% となり、パフォーマンスリスクなしで計算リソースを安全にスケールダウンできました。

このシナリオでは、コンピューティングフリートのサイズを 3 つのワーカーから 2 つのワーカーに削減することができ、KCL 2.6 に比べて 33% のコンピューティングコストの削減を実現しました。これはあくまでサンプルワークロードですが、1 秒あたり数ギガバイトのデータをストリーミングし、それを数百の EC2 インスタンスで処理する場合の潜在的なコスト節約効果はより高いものになるでしょう。同じコスト削減の恩恵を、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS)、AWS Fargate、または自身で管理する Kubernetes クラスターなどのコンテナ化された環境にデプロイされた KCL 3.0 アプリケーションでも実現できます。

その他の KCL 3.0 の利点

ストリーム処理コストの削減に加えて、KCL 3.0 にはいくつかの利点があります:

  • Amazon DynamoDB の読み取り容量ユニット (RCU) の削減 – KCL 3.0 は、メタデータを格納する DynamoDB テーブルに対する読み取り操作を最適化により、KCL に関連する Amazon DynamoDB のコストを削減します。KCL は、シャードとワーカーの割り当てやチェックポイントなどのメタデータを DynamoDB に格納しています。
  • ワーカー間でのシャードの円滑な引き継ぎ – KCL 3.0 は、リバランシングやデプロイ時に、ある 1 つのワーカーから別のワーカーにシャードの処理が引き継がれる際のデータの再処理を最小限に抑えます。現在のワーカーが処理済みのレコードのチェックポイントを完了し、新しいワーカーが前のワーカーの最新のチェックポイントから作業を引き継ぐことができます。
  • AWS SDK for Java 1.x への依存関係の除去 – KCL 3.0 は、AWS SDK for Java 1.x への依存関係を完全に除去し、AWS の最新の SDK バージョンの使用を推奨しています。この変更により、KCL アプリケーションのパフォーマンス、セキュリティ、保守性が向上します。AWS SDK for Java 2.x の利点の詳細については、AWS SDK for Java 2.x の機能を使用するを参照してください。

KCL 3.0 への移行

現在 KCL 2.x バージョンを使用している場合、アプリケーションコードを変更する必要はありません! 次の手順で KCL 3.0 に移行できます。

  1. Maven (またはビルド環境) の依存関係を KCL 3.0 に更新してください。
  2. clientVersionConfig を CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X に設定してください。
  3. コードをビルドしてデプロイしてください。

すべての KCL ワーカーが更新されると、KCL 3.0 は自動的に新しいロードバランシングアルゴリズムを実行し、ワーカーのリソースを平準化します。詳細な移行手順については、以前の KCL バージョンからの移行をご覧ください。

KCL 3.0 を使用する際の主なチェックリスト

ストリーム処理アプリケーションで Kinesis Client Library (KCL) 3.0 を使用することを決めた場合、次の点を確認することをお勧めします:

  • KCL 3.0 に必要な適切な権限を追加したことを確認してください。KCL 3.0 は、DynamoDB で 2 つの新しいメタデータテーブル (worker metrics table, coordinator state table) とリーステーブルのグローバルセカンダリインデックスを作成および管理します。追加する必要がある詳細な権限設定については、KCL コンシューマーアプリケーションに必要な IAM 権限を参照してください。
  • KCL 3.0 で導入された新しいロードバランシングアルゴリズムは、ワーカー間の CPU 使用率を均等にすることを目指しており、ワーカーごとのリース数を均等にすることを目指すわけではありません。maxLeasesForWorker パラメーターを低く設定すると、KCL のワークロードバランシング効果が制限される可能性があります。maxLeasesForWorker パラメーターを使用する場合は、最適なロード分散のために、その値を増やすことを検討してください。
  • KCL アプリケーションで自動スケーリングを使用している場合、KCL 3.0 にアップグレードした後はスケーリングポリシーを見直すことが重要です。具体的には、平均 CPU 使用率をスケーリングのしきい値として使用している場合、この値を再評価する必要があります。ロードバランシングの不均衡により、一部のワーカーが高負荷になることを防ぐために、必要以上に高いしきい値を設定していた場合、この値を調整できるかもしれません。KCL 3.0 では、ロードバランシングが改善されているため、ワーカー間のワークロードがより均等に分散されます。KCL 3.0 を展開した後、ワーカーの CPU 使用率を監視し、パフォーマンスを維持しながら、リソース使用量とコストを最適化するためにスケーリングのしきい値を下げられるかどうかを確認してください。この手順により、KCL 3.0 の強化されたロードバランシング機能を最大限に活用できるようになります。
  • リースを適切に他のワーカーに引き継ぐために、RecordProcessor クラスの shutdownRequested() メソッド内にチェックポインティングロジックを実装していることを確認してください。詳細については、KCL 2.x から KCL 3.x への移行のステップ 4 を参照してください。

まとめ

KCL 3.0 のリリースでは、KCL アプリケーションのコスト効率とパフォーマンスを最適化できる大幅な機能強化が導入されました。新しいロードバランシングアルゴリズムにより、ワーカーインスタンス間の CPU 使用率がより均等になるため、適切なサイズのストリーム処理システムを構築し、コストを最適化できる可能性があります。チェックリストを確認しつつ、KCL 3.0 の機能を最大限に活用し、Kinesis Data Streams で効率的で信頼性の高いコスト最適化されたストリーム処理アプリケーションを構築しましょう。

著者について

Minu Hong は、AWS の Amazon Kinesis Data Streams のシニアプロダクトマネージャーです。ストリーミングデータに関する顧客の課題を理解し、最適なソリューションを開発することに情熱を注いでいます。仕事以外では、旅行、テニス、スキー、料理を楽しんでいます。

Pratik Patel は、シニアテクニカルアカウントマネージャーであり、ストリーミング分析の専門家です。AWS 顧客と協力し、ベストプラクティスを使用してソリューションを計画および構築するための継続的なサポートとテクニカルガイダンスを提供し、顧客の AWS 環境を運用上健全に保つのを積極的に支援しています。

Priyanka Chaudhary はシニアソリューションアーキテクトでデータ分析の専門家です。顧客の信頼できるアドバイザーとして、ウェルアーキテクトされた革新的な業界ソリューションを構築するための技術的なガイダンスとサポートを提供しています。