SQSの設計

このレッスンを終えると、要件の文にある「順序」「重複」「急な増加」「詰まる」という言葉から、標準キューか FIFO キューか、そしてデッドレターキューを足すかどうかを、その場で決められるようになります。

要件の文から入ります

ある EC 事業者が、注文を受け付ける Web サーバーと、在庫を引き当てて出荷指示を作るバックエンドを直接つないで動かしています。ここで2つの事故が起きました。

1つ目は、セール開始の直後に注文が平常時の数十倍になり、バックエンドが処理しきれず、Web 側までエラーを返すようになったことです。2つ目は、ある1件の壊れた注文データで処理が必ず失敗し、それが再試行され続けて、後ろに並んだ注文がまったく進まなくなったことです。

SAA ではこの2つが別々の設問として出ます。前者は「スパイクを吸収する」話で、後者は「毒メッセージを隔離する」話です。同じ SQS でも答えが違います。

標準キューと FIFO キューの線引き

Web とバックエンドの間に SQS を挟むと、Web は注文をキューに入れた時点で応答を返せます。バックエンドは自分の処理できる速さで取り出せばよく、あふれた分はキューに溜まって待ちます。これがバッファとしての使い方です。

では標準と FIFO のどちらかという話になります。要件語で切り分けます。

判断は単純です。「順序が保証される必要がある」「重複して処理されてはならない」という文が要件にあれば FIFO、「急激な増加を受け止めたい」「できるだけ多くさばきたい」なら標準です。両方書いてあるときは FIFO を選び、スループットの上限が問題になるならメッセージグループ ID を分けて並列度を上げる、という順で考えます。

注意したいのは、標準キューを選んだ場合はアプリ側が同じメッセージを2回受け取っても壊れないように作る必要がある、という点です。受信のたびに残高を足すような処理は、標準キューでは必ず事故ります。試験ではこの「アプリを冪等に作る」という選択肢が正解になることもあります。

可視性タイムアウトは処理時間から決めます

コンシューマーがメッセージを受け取ると、そのメッセージは一定時間だけ他のコンシューマーから見えなくなります。これが可視性タイムアウトです。処理が終わって削除すればそこで消え、削除されないまま時間が切れると、また見えるようになって別のコンシューマーが拾います。

ここが設計判断です。可視性タイムアウトが実際の処理時間より短いと、まだ処理中なのに別のコンシューマーが同じメッセージを拾い、二重処理になります。 動画の変換に平均5分かかるのに可視性タイムアウトが既定のままだと、変換が終わる前に2本目、3本目が走り始めます。

対策は2つあります。処理時間より十分長い値を設定する方法と、処理が長引いたときにアプリから可視性タイムアウトを延長する方法です。後者は処理時間のばらつきが大きいときに向きます。逆に長すぎると、コンシューマーが落ちたときに再処理が始まるまで待たされます。

何度やっても失敗するメッセージはデッドレターキューへ

冒頭の2つ目の事故がこれです。壊れたメッセージは何回再試行しても失敗し、そのたびにキューへ戻ってきて、他の処理を圧迫します。

デッドレターキューを設定し、最大受信回数を決めておくと、その回数を超えたメッセージは自動的に別のキューへ移されます。本流のキューは詰まらなくなり、隔離された側を後から人が調べられます。「特定のメッセージが何度も失敗して処理が滞る」「失敗したメッセージを後で調査したい」という要件が出たら、答えはデッドレターキューです。

要件語から構成への対応

よくある引っ掛け

1つ目は、二重処理の相談に対して「デッドレターキューを設定する」という選択肢です。デッドレターキューは失敗の隔離であって、二重処理は防ぎません。処理時間と可視性タイムアウトの関係を疑うのが先です。

2つ目は、順序の要件に対して「標準キューにタイムスタンプを持たせてアプリで並べ替える」という選択肢です。動きはしますが、アプリの改修が必要で、運用の手間も増えます。「アプリを改修せずに」という制約が付いていたら確実に落ちます。

まとめ

• 順序と重複排除が要件なら FIFO、スパイク吸収と量が要件なら標準を選びます
• 標準キューを選んだら、アプリは同じメッセージを2回受けても壊れない作りにします
• 可視性タイムアウトは実処理時間より長くします。短いと二重処理になります
• 失敗し続けるメッセージはデッドレターキューへ逃がし、本流を詰まらせません
• キューの深さでワーカーをスケールさせると、送信側と処理側が独立して伸びます