Amazon SES でメールを送信していますが、失敗した場合の再試行を適切に処理する方法を考えています。
POSTアクションにリクエストを発行したSendEmailが、タイムアウトを受け取ったとします。メッセージが送信されたかどうかを知る方法はありません。
各メールで一意の識別子を送信して、このメールの送信を安全に再試行し、SES にメールを送信するか、既に送信されていることを通知させることはできますか?
あるいは、ネットワーク エラーが発生した場合に、電子メールを 2 回送信する危険を冒すか、電子メールをまったく送信しないかを選択する必要があります。
SendRawEmail のSES API リファレンスによると、リクエストの一部として指定するパラメーターは、受信者のリスト、メール本文、送信元アドレスだけです。残念ながら、SES からの応答ではなくタイムアウトを受け取った場合、その特定の電子メールが送信されたかどうかを知る方法がないことは明らかです。私はそれが非常に動揺していることを知っています。私もそういう状況になったら嫌です。
ただし、このジレンマに対する最も実用的な解決策を見つけるには、いくつかの選択肢があります。再試行しないという包括的な決定を下し、未送信のメッセージが重複したメッセージよりも優れていると想定することができます。また、メールの重複は完全に許容できるという包括的な決定を下すこともできます。しかし、私が好んで推奨するアプローチは、学術的に満足度は低いものの、実用的な中間点です。説明させてください。
新しいサービスと統合し、処理方法がわからないが頻繁には発生しないと思われるエッジ ケースを見つけた場合、最善の方法は、より多くの情報を収集し、その間に手動で処理することです。ローマは一日にして成らず、クラウド サービスは、電源を入れたその日に完全に機能するわけではありません。代わりに、タイムアウトになったらログに記録し、後でそのメールを再送信するために必要になる可能性のあるものをすべて保存してください。
ここで、コーディングと統合テストがすべて完了し、本番環境でサービスを有効にしたと想像してください。初日、あなたは 100,000 通のメールを送信しようとします。1000 回のタイムアウトが発生した場合、何か非常に奇妙なことが起こっており、ネットワークを調査する必要があることがわかります。代わりに、1 日目にタイムアウトが 0 で、2 日目も同じで、7 日目には 1 週間の 700,000 回の試行のうち、タイムアウトが 1 回しかなかったらどうなるでしょうか。必要に応じて、その 1 人のお客様に電話して、「お手数をおかけして申し訳ありませんが、信頼性に万全を期しておりますが、技術的な問題が発生しました。[XYZ] の領収書メールが届いていることを確認したかったのです。 " 彼らが「いいえ」と言った場合は、戻ってコードを変更し、タイムアウトが発生したときに おそらくうまくいくことがわかっているので、数秒待ってから再試行してください。その間の何に対しても同じ考え。
ここでのポイントは、人間の知性をミステリーに適用するということです。多くの場合、未知のものの裏をかこうとしない方が簡単であることがわかりました。何が起こっても対処できるように自分を準備し、問題が実際にどのように見えるかを知ったときに何をするのが賢明かを理解してください.
(他の誰かが書いた「エッジケースを処理しない」についてのこのブログ投稿をお楽しみください。)