メール / メール運用
再送とは
Retry。一時失敗した配送や処理を、一定時間後にもう一度試す動作です。
用語集内のカードを見るメール / メール運用
Retry。一時失敗した配送や処理を、一定時間後にもう一度試す動作です。
用語集内のカードを見る再送を、定義だけで終わらせず、現場で出てくる場面、確認材料、見落としやすい点、関連語とのつながりまで順に確認できます。
実務メモ
再送はSMTP 4xx、相手先メンテナンス、API一時失敗、イベント処理の一時障害で効きます。メール配送ではキュー保持と再試行、アプリではリトライポリシーとして現れます。
証跡には初回失敗時刻、失敗理由、再送回数、次回予定、最大保持時間、成功または最終失敗時刻、Message-IDや処理ID、利用者影響を残します。
宛先不明や入力ミスのような恒久失敗を再送し続けても成功しません。重複送信、順序逆転、相手先への負荷集中を見ないと、復旧後に別の障害を作ります。手動再送は対象を限定します。
再送(Retry)は、一時的に失敗した配送や処理を一定時間後にもう一度試す動作です。メール配送では、SMTP 4xxや相手先一時障害でMTAがキューに保持し、後で再試行します。
実務では、再送間隔、最大回数、最大保持時間、重複送信、冪等性、バウンス化条件、利用者通知、バックプレッシャーを合わせて確認します。
証跡には、対象処理、初回失敗時刻、失敗理由、再送回数、次回予定、成功/最終失敗時刻、利用者影響、確認時刻を残します。
再送は、一時失敗に対して意味があります。恒久失敗や入力ミスを何度再送しても成功しないため、SMTPステータスコードやエラー分類を確認します。
メールでは4xxが再送対象になりやすく、5xxはバウンス化しやすいです。APIやイベント処理でも、タイムアウト、一時的な429/503、相手側メンテナンスなど再送すべき条件を決めます。
再送では、同じメールや通知が複数回届く可能性があります。業務アプリやイベント処理では、重複実行、順序逆転、二重登録、二重請求などのリスクを確認します。
メール通知でも、再送後に相手先へ複数通届いたように見えることがあります。Message-ID、キューID、アプリ側IDで同じ処理か別処理かを突合します。
再送間隔が短すぎると相手先をさらに圧迫し、長すぎると復旧後の回復が遅くなります。指数バックオフや最大回数、最大保持時間を確認します。
メールキューでは、いつまで再送し、いつバウンスへ切り替えるかが利用者説明に必要です。監視では、再送回数や滞留時間の増加を見ます。
再送設計や障害対応では、対象処理、失敗理由、再送方針、上限、重複対策、手動再送の条件、利用者連絡、戻し条件を残します。
引き継ぎでは、アプリ所有者、メール基盤管理者、監視担当、関連語としてSMTPステータスコード、メールキュー、バウンスメール、バックプレッシャーを残すと確認しやすくなります。
同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。