AWS Step Functions
開発者ガイド

アクティビティタスクポーリング時のレイテンシーを回避する

GetActivityTask API は、taskToken1 回だけ提供するように設計されています。アクティビティワーカーと通信している間に taskToken がドロップされた場合、GetActivityTask がタイムアウトするまで、レスポンスの待機のため複数の GetActivityTask リクエストが 60 秒ブロックされます。レスポンス待ちのポーリングが少数しかない場合、ブロックされたリクエストの後ろにすべてのリクエストが追加され、停止する可能性があります。ただし、各アクティビティ ARN に多数の未処理のポーリングがあり、リクエストの一部が待機中のままになる場合、taskToken を取得して処理を実行するリクエストがさらにたくさんあります。

本番稼働用システムでは、それぞれのアクティビティ ARN の各時点で少なくとも 100 のオープンポーリングを推奨します。1 つのポーリングがブロックされ、それらのポーリングの一部がその後ろに並んでいる場合、GetActivityTask のリクエストがブロックされている間に処理を実行するための taskToken を受け取るさらに多くのリクエストがあります。

タスクのポーリング時に、これらのレイテンシーの問題を回避する方法。

  • アクティビティワーカーの実装の作業とは別のスレッドとしてポーラーを実装します。

  • 各時点でのアクティビティ ARN あたり、少なくとも 100 のオープンポーリングが必要です。

    注記

    ARN あたり 100 のオープンポーリングにスケーリングすると、コストが高くなる可能性があります。たとえば、ARN あたり 100 の Lambda 関数でポーリングする場合、1 つの Lambda 関数で 100 のポーリングスレッドを実行するよりも 100 倍コストが高くなります。レイテンシーを短縮しながらコストを最小限に抑えるには、非同期 I/O を使用する言語により、ワーカーごとに複数のポーリングスレッドを実装します。ポーラースレッドとワークスレッドが異なるアクティビティワーカーの例については、「Ruby のサンプルアクティビティワーカー」を参照してください。

アクティビティおよびアクティビティワーカーの詳細については、「アクティビティ」を参照してください。