こんにちは、Diverse developer blogです。最近弊社では、メール配信基盤の移行作業を行いました。今回はその経緯についてご紹介いたします。

背景

弊社では、複数のメール配信サービスを利用しており、AWS EC2上に構築したメールサーバーで運用していました。しかし、複数のサービスを利用することでメールの管理が煩雑になっていました。

SendGridの選定理由

SendGridに移行した主な理由はコスト削減で、具体的には月額約10万円のコストが削減されます。一方、新しいメールサービスへの移行によるコストは増加しますが、これはメンテナンスと管理の効率化によって相殺されると見込んでいます。加えて、SendGridはサーバーレスであり、メール送信プロセスをAPIで統一できるため、AWS EC2のメールサーバー管理コストも削減されます。

sendgrid.kke.co.jp

移行手順

移行した手順と、進める際に留意したポイントについて以下でご紹介します。

1. 送信量とプランの適正確認

SendGridは、プランによって送信可能なメールの量が異なります。移行の検討段階で、現在の送信量とSendGridのプランを比較し、適切なプランを選択できるよう概算を立てました。

2. 独自ドメインの設定と認証

SendGrid上のドメイン設定（Domain Authentication）で、SPFやDKIM、DMARCに必要なDNSレコードをSendGridが自動的に生成します。それを弊社が管理するAmazon Route53へ登録します。手順詳細については、マニュアルが用意されているので、それに従ってスムーズに進めることができました。

独自ドメインを利用する - ドキュメント | SendGrid

3. APIの実装とテスト

既存のメールサービスの使用範囲を調査し、影響範囲が最小のサービスから開発環境でSendGridへの移行作業を開始しました。SendGridの公式ライブラリではサポート外のPerlで開発しているため、REST APIへ直接リクエストする形で実装しました。事前の調査で既存システムへ置き換えられるSendGridのAPIを検討していたため、スムーズに実装自体は進めることができました。

移行作業中に苦戦したこと

移行作業中、メール送信処理後にSendGrid側で受付完了したメールが宛先に届かない問題が発生しました。調査を行いましたが解決に至らず、問い合わせて判明した原因は、SendGridのアカウントが無効化されていたことでした。SendGridの管理画面上で警告があったのを見落としていたようで、しばらく使用していないアカウントだったのが原因というオチでした。問い合わせ後、回答が24時間以内で迅速に届いたので、今後トラブルが発生した際も迅速に対応してもらえそうです。

開発環境での実装に問題がないことを確認できた後は、SendGridを無料プランから有料プランへ切り替え、本番環境へリリースしました。