API リファレンス
Class: AWS.SQS — AWS SDK for JavaScript
送信/受信/削除
AWS SDK for Node.js を用いた SQS の操作 – ゴミ箱
FIFO になって情報古くなってる面もあるが有益な情報
【AWS】SQS をただただ触ってみただけの話 - ニクニクドットミー Amazon SQS を利用する前に抑えておくべき 7 つのポイント - Qiita Amazon SQS を使う前に知っておきたい基本的なこと - Qiita Schoo の非同期パイプライン処理について - Qiita
『ロングポーリングして』という話は下記でも触れてる(一番下の方) フレクトのクラウド blog(New): lambda から lambda を起動するリレー方式 SQS コンシューマ
ショートポーリングの場合、キュー内のメッセージ数が少ない(1000以下など)場合、
キュー内のメッセージ数で重み付けされたサンプル数のサーバにしか問い合わせにいかないため、
MaxNumberOfMessagesに指定した数より少ないメッセージしか返ってこず、
キュー内のメッセージ数が極めて少ない場合、メッセージが返却されないことがあるため、
繰り返しreceiveMessageを発行する必要がある。
という理解であってるんですかね？
ロングポーリングの場合はどうなんでしょうか？ 次の記述が見つかりました。
どうやらロングポーリングの場合、上記の問題は発生しないようです。
(receiveMessageのWaitTimeSecondsを1以上にすると、ロングポーリングになる)
Lambdaはコンピューティング時間で課金されるため、なるべく「待ち」の時間は減らしたいところですが、ショートポーリングで1,2件づつメッセージを処理するよりは効率が良さそうです。
ロングポーリングを利用する(これは必須。劇的にリクエスト数が改善されます)
ロングポーリングは管理画面から設定できるので簡単。
送信側はバッチリクエストを利用すると良い(SendMessageBatch)
受信側も複数メッセージを一度に受信すると良い(MaxNumberOfMessages)
FIFO に関する情報
【新機能】Amazon SQS に FIFO が追加されました！（重複削除/単一実行/順序取得に対応） ｜ Developers.IO FIFO/重複排除のイメージがつかみやすい
SQS パラメータ検討
http://blog.nikuniku.me/entry/2015/12/23/141000
DelaySeconds（遅延キュー）は『キューに追加されてから非表示になる時間』(0〜15 分)
メッセージタイマー
上の DelaySeconds に似てる。メッセージに紐づく遅延表示設定、DelaySeconds より優先される。
Visibility Timeout（可視性タイムアウト）
あるコンポーネント A がメッセージを取得したら、他コンポーネントに見せない時間。個人的には、これはロックの仕組みに近い気がする。 Visibility Timeout は延長が可能。なので、例えば lambda で処理が長引く場合は、延長することができる、というのもロックに近い。 が、このデザインは、例えば『プロセスは死ぬ可能性がある』という前提に立ってる気がする。プロセスが時間がかかっても(延長がされないのであれば)処理のハンドルというか、ロックは SQS に戻ってくるのだ。
ロングポーリング
WaitTimeSecondsで設定した秒数待機する事で、メッセージが空の場合でもメッセージが入ってくるまでWaitTimeSecondsの秒数まで待機し、その間にメッセージが入ってくれば取得する事が出来ます。
実装例
lambda から 5 分おきに処理する
SQS のメッセージを Lambda で 5 分おきに処理する(Scheduled Event) | cloudpack.media