Cloud Tasks で FIFO できないからどうしようか考える
Taichi MasuyamaCloud Pub/Sub はどうか？
Taichi Masuyamatopic を作って、SA 作って、Cloud Run を topic に subscribe させるだけ。
アプリケーションで publish すると、Cloud Run service がメッセージを受け取って処理することができる。
Taichi Masuyamaメッセージを Cloud Run (subscriber) に push し、失敗した場合、push を再試行できる。(Cloud Tasks と同じ感じ)
つまり最高。
Taichi Masuyamaメッセージの順序指定
順序指定キーを使用してリクエストを再試行する
メッセージの順序指定は Pub/Sub の機能の 1 つで、サブスクライバー クライアントで、パブリッシャー クライアントによってパブリッシュされた順序でメッセージを受信できます。
受信後、レスポンスを返すと受信完了判定になり、次のメッセージを受信する。
受信失敗のレスポンスを返すと、リトライ設定に基づいて再配信される。
キー内順序指定: 同じ順序指定キーを使用してパブリッシュされたメッセージは、順序どおりに受信されます。順序指定キー A に対して、メッセージ 1、2、3 をパブリッシュするとします。順序指定を有効にすると、1 は 2 より前に配信され、2 は 3 より前に配信されることが想定されます。
チャットアプリで考えると、チャットルームごとにキーを一意にしておけば、ルームごとにメッセージ受信の順序が保証されるという理解。
メッセージの再配信: Pub/Sub は各メッセージを少なくとも 1 回配信するため、Pub/Sub サービスがメッセージを再配信する場合があります。メッセージが再配信されると、そのキーに対する後続のすべてのメッセージ（確認済みメッセージも含む）の再配信がトリガーされます。サブスクライバー クライアントが特定の順序指定キーのメッセージ 1、2、3 を受信するとします。確認応答期限が切れた、または Pub/Sub でベスト エフォートの確認応答が保持されなかったために、メッセージ 2 が再配信される場合、メッセージ 3 も再配信されます。サブスクリプションでメッセージの順序指定とデッドレター トピックの両方が有効になっている場合、Pub/Sub はベスト エフォート方式でデッドレター トピックにメッセージを転送するため、正確でないこともあります。
リトライでなくても２回処理されることが稀にあるのでアプリケーション側で冪等性を担保しないといけない。
Taichi Masuyama結論
Pub/Sub で FIFO ありの Cloud Tasks 的なことが実現できそう。(多分。やってみないと確証はない)
ただし、重複対策は自前で実装しないといけない。 exactly-once できそう
Taichi Masuyamaexactly-once できそう
これで重複対策が不要になれば懸念がほぼなくなる。
Taichi MasuyamaAWS SQS FIFO キューはどうか？
これ簡単に Cloud Run と統合できたら使いたいが、どうだろうか？
- exactly-once
- FIFO
FIFO に関してはキーごとに並列実行できるかとかは要調査。