どういう処理をキューに逃がすのが妥当ですか。
メール送信、外部APIの呼び出し、レポート生成など、レスポンスを待たせたくない処理です。ドライバは Redis があれば redis、無ければ database から始めるのが実務では無難です。
面接官が見ているのは非同期化の判断基準を持っているか。
よくある答えと、面談でどう見られるか
- メール送信や外部API呼び出しなど、レスポンスを待たせたくない処理
その通りです。ドライバは Redis があれば redis、無ければ database から始めるのが普通です。 - DB の SELECT など、読み取り処理全般
結果をその場で表示する必要があるので、非同期にすると成立しません。 - ユーザーの入力バリデーション
検証結果を即座に返さないとフォームとして機能しません。 - 数ミリ秒で終わる軽い処理も、まとめて逃がすと速くなる
逆にオーバーヘッドが増えます。キューは「重いから逃がす」ものです。
面接官は何を見ているか
- 何をキューに逃がしたか具体例を出せた
- ドライバ（database / redis / SQS）を挙げ、選定理由を言えた
- ワーカーの起動・常駐方法に触れた
模範解答
メール送信、外部APIの呼び出し、レポート生成など、レスポンスを待たせたくない処理を逃がします。ドライバは、既にRedisがあるなら redis、無ければ database で始めることが多いです。database は追加ミドルウェアが要らない代わりに、処理量が増えると DB を叩きます。ワーカーは supervisor や systemd で queue:work を常駐させ、デプロイ時に queue:restart で古いコードのワーカーを終了させます。ワーカーは長寿命プロセスなので、これを忘れると新しいコードを配置しても古いコードのまま動き続けます。queue:restart は「今のジョブを終えてから終了しろ」という指示なので、処理中のジョブが失われることはありません。ただし終了するだけなので、supervisor のようなプロセスマネージャで自動的に起動し直す必要があります。なお、この再起動シグナルはキャッシュ経由で伝わります。キャッシュドライバの設定が壊れていると、queue:restart を叩いてもワーカーが入れ替わりません。
ここからどう深掘りされるか
この問いに答えられた場合、面談は次の質問に進みます。
観点をすべて押さえられた場合
失敗したジョブはどうなりますか。一部しか触れられなかった場合
同期実行をキュー実行に変えると、ユーザーから見て何が変わりますか。