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

GetActivityTask API は、taskToken を 1 回のみ提供するように設計されています。アクティビティワーカーと通信している間に taskToken がドロップされた場合、GetActivityTask がタイムアウトするまで、レスポンスの待機のため複数の GetActivityTask リクエストが 60 秒ブロックされます。

レスポンス待ちのポーリングが少数しかない場合、ブロックされたリクエストの後ろにすべてのリクエストが追加され、停止する可能性があります。ただし、各アクティビティ Amazon リソースネーム (ARN) に多数の未処理のポーリングがあり、リクエストの一部が待機中のままになる場合、taskToken を取得して処理の実行を開始するリクエストがさらにたくさんあります。

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

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

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

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

  注記

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

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