インフラ用語集へ戻る

メール / メール運用

再送とは

Retry。一時失敗した配送や処理を、一定時間後にもう一度試す動作です。

用語集内のカードを見る

詳細な図解

一時失敗を再試行する制御
初回失敗4xxや一時障害を検知
再送待ち間隔と回数を決めて待機
再試行同じ処理IDで再実行
成功/停止成功または上限到達で停止
  • 恒久失敗は再送し続けない
  • 重複と順序逆転を確認
  • 相手先復旧後の流量集中に注意

この記事で学べること

再送を、定義だけで終わらせず、現場で出てくる場面、確認材料、見落としやすい点、関連語とのつながりまで順に確認できます。

  1. 再送を読むときの前提
  2. 一時失敗と再送対象を分ける
  3. 重複と順序を確認する
  4. 再送間隔と上限を見る
  5. 変更証跡と引き継ぎ

実務メモ

一時失敗だけを再送対象にし、重複影響を先に見る

どこで効くか

再送はSMTP 4xx、相手先メンテナンス、API一時失敗、イベント処理の一時障害で効きます。メール配送ではキュー保持と再試行、アプリではリトライポリシーとして現れます。

残す証跡

証跡には初回失敗時刻、失敗理由、再送回数、次回予定、最大保持時間、成功または最終失敗時刻、Message-IDや処理ID、利用者影響を残します。

避けたい誤解

宛先不明や入力ミスのような恒久失敗を再送し続けても成功しません。重複送信、順序逆転、相手先への負荷集中を見ないと、復旧後に別の障害を作ります。手動再送は対象を限定します。

まず確認すること

  • 一時失敗か恒久失敗か確認する
  • 再送間隔と最大回数を確認する
  • 重複時の業務影響を確認する

再送を読むときの前提

再送(Retry)は、一時的に失敗した配送や処理を一定時間後にもう一度試す動作です。メール配送では、SMTP 4xxや相手先一時障害でMTAがキューに保持し、後で再試行します。

実務では、再送間隔、最大回数、最大保持時間、重複送信、冪等性、バウンス化条件、利用者通知、バックプレッシャーを合わせて確認します。

証跡には、対象処理、初回失敗時刻、失敗理由、再送回数、次回予定、成功/最終失敗時刻、利用者影響、確認時刻を残します。

一時失敗と再送対象を分ける

再送は、一時失敗に対して意味があります。恒久失敗や入力ミスを何度再送しても成功しないため、SMTPステータスコードやエラー分類を確認します。

メールでは4xxが再送対象になりやすく、5xxはバウンス化しやすいです。APIやイベント処理でも、タイムアウト、一時的な429/503、相手側メンテナンスなど再送すべき条件を決めます。

  • 一時失敗か恒久失敗か分類する。
  • 再送対象にする条件を確認する。
  • 入力ミスや宛先不明を再送し続けない。

重複と順序を確認する

再送では、同じメールや通知が複数回届く可能性があります。業務アプリやイベント処理では、重複実行、順序逆転、二重登録、二重請求などのリスクを確認します。

メール通知でも、再送後に相手先へ複数通届いたように見えることがあります。Message-ID、キューID、アプリ側IDで同じ処理か別処理かを突合します。

  • 重複しても問題ない設計か確認する。
  • Message-IDや処理IDで突合する。
  • 順序が崩れた場合の影響を見る。

再送間隔と上限を見る

再送間隔が短すぎると相手先をさらに圧迫し、長すぎると復旧後の回復が遅くなります。指数バックオフや最大回数、最大保持時間を確認します。

メールキューでは、いつまで再送し、いつバウンスへ切り替えるかが利用者説明に必要です。監視では、再送回数や滞留時間の増加を見ます。

  • 再送間隔と最大回数を確認する。
  • 最終失敗化する条件を記録する。
  • 相手先復旧後の流量集中に注意する。

変更証跡と引き継ぎ

再送設計や障害対応では、対象処理、失敗理由、再送方針、上限、重複対策、手動再送の条件、利用者連絡、戻し条件を残します。

引き継ぎでは、アプリ所有者、メール基盤管理者、監視担当、関連語としてSMTPステータスコード、メールキュー、バウンスメール、バックプレッシャーを残すと確認しやすくなります。

  • 再送条件と停止条件を明記する。
  • 手動再送の対象と結果を記録する。
  • 重複時の業務影響を確認する。

関連語

同じ主要カテゴリの用語

メールの学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能