AWSのSQS FIFOキューをプロダクションで利用してみた感想とか
SQS について
AWSのサービスの一つでメッセージキューイングのマネージドサービス。 FIFOキューを選択するとメッセージの取り出しがFIFO（先入れ先出し）が保証されます。
安価に性能保証されたFIFOのメッセージキューが利用できたので、かなり良かったです。
FIFOとスケール
メッセージがFIFOだと大量にエンキューしても1個ずつしか処理されない（FIFOなので当然）のでスループット全然出ない状況になります。。
これはメッセージに適切なグループIDをつけることで解決できます。 このグループID単位でFIFOが保証されるので、リソースの更新キューであれば、リソースIDなどを設定しておけば、そのリソースに対する更新処理はFIFOで処理されるのでとても便利でした。
例えば、商品Aの価格を更新するキューがあるとして、キャンペーン価格の100円に更新するメッセージAと通常価格の200円に更新するメッセージBがあるときに、 A -> B の順番にエンキューされたら A -> B の順番に取り出されて更新されないと最終的に商品Aは200円になってくれません。（標準キューでは B -> A の順番に取り出される可能性があり、その場合商品Aは古い価格の100円のままになってしまいます、、） なので、A,Bは商品AのIDをグループIDに指定して、このグループ単位でFIFOを保証されるように指定するのがよいのです。
また、開発中はこのグループIDの概念を理解しておらずすべてにランダムなIDを振ったところ、あたりまえですが全くFIFOにならなかったので注意が必要です。（後述の重複呼出削除機能だけ使いたければ、そうすればいいと思います。）
重複呼出削除機能
同じ内容のメッセージを送ってしまったときに削除してくれる機能です。デフォルトの設定では5分以内にそのように操作した際に最初のメッセージ以外をキューから削除してくれます。
仕様としてわかっていても、テスト中に2回送ったのに1度しか処理されなかった場面に直面したときにちょっとパニックになりました。（単体テストNGか、、、？スケジュールがやばい、など）
メッセージ数の制限について
FIFOキューでは2万メッセージが限界とドキュメントに書いてありましたが、オレゴンのFIFOキューをつかってみたところ、10万目メッセージくらい入りました。仕様外の動作なのでまったくおススメできないですが、障害発生時でメッセージ取得側が止まってエンキューだけ大量にされて、メッセージがたまっちゃったときに2万以上溜まっててくれたので復旧作業が楽でした。
For FIFO queues, there can be a maximum of 20,000 inflight messages per queue. If you reach this limit, Amazon SQS returns no error messages.
開発中の参考ページなど
公式のドキュメントのほかに、クラスメソッドさんのブログ記事が参考になりました。
