非同期化はスケールと信頼性の入り口
同期処理の限界（タイムアウト・障害伝播）を解消する一手がキューによる非同期化です。本記事では編集部の視点で、主要キューシステムの使い分けと、冪等性・順序保証・再送の設計を公開情報をもとに整理します。イベント駆動アーキテクチャ も合わせてどうぞ。
3タイプのキューを使い分ける
(1) マネージドキュー：SQS / Cloud Tasks / Service Bus。運用負荷が最小。(2) Pub/Sub 型：Cloud Pub/Sub / SNS+SQS / Kafka。複数Subscriberへ配信。(3) ストリーミング型：Kafka / Kinesis。順序保証 + 長期保持 + リプレイ。(4) 判断軸：1対1の単純キューはSQS、ファンアウトはPub/Sub、順序とリプレイが必須ならKafka。gRPC 実践 も同期/非同期の判断に役立ちます。
冪等性（at-least-once 前提）
(1) 原則 at-least-once：重複配信は前提として設計する。(2) 冪等キー：メッセージID + 業務キーで重複を弾く。(3) DB制約で守る：UNIQUE 制約 + INSERT ... ON CONFLICT。(4) 処理済みストア：Redis/DynamoDB に処理済みIDを保持。(5) 副作用の集約：副作用は1箇所にまとめてリトライ容易に。
順序保証が必要なときの選択
(1) FIFO キュー(SQS FIFO/Service Bus セッション)：パーティション単位で順序保証。(2) Kafka パーティション：キー単位で順序保証。(3) 順序が崩れる前提で設計：可能なら順序非依存に再構成。(4) スループットとのトレードオフ：FIFO は標準より遅い。(5) パーティション数の見積もり：将来の増加を見越して大きめに。
再送・DLQ 設計
(1) 再送回数の上限：3〜5回程度が一般的。(2) 指数バックオフ：1s, 2s, 4s, 8s と段階的に。(3) DLQ (Dead Letter Queue)：失敗続きのメッセージを退避。(4) DLQ の監視：件数がアラート対象。(5) 再投入の運用：DLQ→本キューへ手動/自動再投入。Observability 実践 で再送状況も可視化。
運用で陥りやすい罠
(1) at-most-once と思って設計：実は重複が起きて二重課金。(2) 遅延に気付かない：キュー深さの監視がない。(3) 順序前提のコードが at-least-once で壊れる。(4) DLQ放置で問題が見えなくなる。(5) パーティション偏り：特定キーに集中してスループット出ず。対策は、(1)冪等性必須、(2)キュー深さアラート、(3)順序非依存設計、(4)DLQ常時監視、(5)キー分散の検証、です。
コストと運用の見積もり
(1) メッセージ数課金：SQS/Cloud Tasks。月数億件で数十万円規模(公開情報をもとに)。(2) スループット課金：Kafka マネージド。(3) セルフホスト Kafka：運用工数が高く、最低 SRE 1人想定。(4) 監視コスト：メトリクス・ログ送信も無視できない。(5) 最新の料金は各クラウド公式情報をご確認ください。