SendGrid利用時のエラー処理のベストプラクティス
サポートエンジニアの佐藤（@awwa500）です。アプリケーションからSendGridを使ってメールを送る場合、さまざまな原因によって発生するエラーを適切に処理することは運用上重要です。特に気をつけたいのは次の点を考慮してシステムを設計することです。
- リクエストは失敗する
- 「リクエストの成功」＝「メールが届いた」ということではない
- 問題に気づかなければ意味がない
今回は、こういった点を考慮した利用方法について詳しく見ていきます。
リクエストが失敗する前提で設計する
外部サービスへのリクエストが失敗することを前提にして、送信内容をログに残しいつでも再送できるようにしておきましょう。こうすることで、利用しているサービスの障害や途中のネットワーク障害にも対処できるようになります。
例えば、SendGridのAPIを利用してメール送信する場合、アプリケーションサーバとリクエスト処理サーバを分けて、キューを介してリクエストを送信し、リクエストの結果を送信ログとして保存する構成が考えられます。このような構成にすると次のようなメリットが得られます。
- アプリケーションサーバに影響を与えることなくリクエストの再送ができる
- メールの送信に失敗した場合、メール以外の手段で通知できる
- 送信ログからエラーの原因を調査できる
アプリケーションサーバから直接SendGridにリクエストを送信する構成と比較して、少し複雑にはなりますが、重要なメールを漏れなく処理するにはこういった配慮が必要になります。
リクエストが成功した場合でもメールが届かない可能性があることを前提に設計する
リクエストが成功したからといって、必ずしもメールが届いているわけではありません。アドレスが誤っていたり、宛先サーバが一時的にダウンしていたりといったケースがあるためです。こういったことに気づかないと、メールを送ったつもりになっているだけで実は相手には届いていない、といったことが起きてしまいます。このような事態を防ぐには、Event Webhookを利用する必要があります。具体的には、Event Webhookで配信系のイベントを記録しておき、Bounce、Deferred、Droppedなど想定していないイベントが発生したらアプリケーション側で対処できるようにしておきます。例えば、Bounceイベントが発生したら、宛先アドレスが誤っていると考えられるので、送信者にその旨を通知するといった対処につなげることができます。
問題が発生したときにすぐに対処できるようにしておく
せっかく上述のような対策をしても、問題が発生していることにすぐに気付けなければ意味がありません。問題の検知から対応までの時間をできるだけ短時間で実施できるような仕組みを用意しておくことが重要です。例えば、リクエスト処理サーバやWebhook受信サーバの処理状況を監視しておき、問題が発生したら運用担当者にチャットなどで通知するといった対策が考えられます。
さいごに
もちろん、エラーや障害は一切発生しないのが理想的ですが、実際の運用では「もしも」のときに備えておくことも重要です。このような対策を実際に行ったお客様の事例を含め、いくつか参考になる記事をご紹介しますのでぜひご覧ください。
