9
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

【Amazon SES】同一のメール配信リクエストに対するメールイベントの発生のしかたについて調べてみた

Last updated at Posted at 2023-06-16

はじめに

はじめまして、qiitaに初投稿します。
普段はネットプロテクションズのNP掛け払いでプロダクト作りをしています。

この度テックブログを書くことになり、このテーマを選ぶことにしました。
元々事業企画からシステムに異動したこともあり、生粋のエンジニアではないので、
純粋に技術に関する話というより、少し事業やプロダクト目線が多めの内容になっております。
システムは日々勉強中ですので、温かい目で見守っていただけると幸いです。

調べた経緯

弊社のNP掛け払いというサービスは、
法人間決済の請求業務をまるっと代行できるサービスです。
BtoB・企業間後払い決済/請求代行サービス「NP掛け払い」
今回SESを利用したのは、PDF形式の請求書をメールで送付する部分になります。
(請求書送付方法は郵送など他手段もあります)
それまでメール配信は外部サービスを使っていたのですが、
内製で作り直す機会があったので、Amazon SESを作って再構築しました。

請求書を送付するという業務性質上、確実に届けることと、
請求書の到着、開封状況を把握することが重要になります。
Amazon SESでは送信リクエスト後にメールイベントが取得できるため、これを利用することにしました。
ただ、1リクエストに対してどのイベントが発生するのか、重複するのかに関して、
いくら調べても出てこなかったので自分で実際にリクエストを送りながら調べてみました。
備忘も兼ねてこちらに記載できればと思います。

注意
  • サブスクリプションイベントは当時、利用予定がなかったので調べられておりません
  • 自分の手で調べたものなので、情報の正確性は当てにしないでください
    心配なかたはご自身で調べていただけると幸いです
    もし記載内容に間違いがあればコメントでご指摘いただけると嬉しいです
  • 調べたのは2021年の8月ごろですので、現在の仕様は変わっているかもしれません
  • イベントの中身はawsの公式ドキュメントをご参考ください
    参考:Amazon SES が Amazon SNS に発行するイベントデータのコンテンツ

同一リクエストに対する、イベントの被り

ddafc372d149fed7b2239400d2e0d5f8.png

はい、こんな感じでした。
これだけみても良くわからないと思うので、
イベントを取得できる時系列で少し補足してみます。
(rejectなど再現ができず少し怪しい部分は「?」をつけています)

  1. メール送信リクエストをしたものはまず、rejectかsendのイベントが取得できます
    (弊社ではrejectは実運用ではめったに発生しないので、99.99%sendです)
  2. sendされたものは、renderingfailure,delivery,bounce,deliverydelayのいずれかのイベントが取得されます
  3. deliveryされたものは、complaint,open,click,subscriptionなどが取得できます

なお、この中で一番厄介なのがdeliverydelayでして、
・deliverydelayのあとにdeliveryが取得できるケース
・deliverydelayのあとにsoft bounceが取得できるケース
がありえます。
この辺を気にしながら取得イベントの選定、実装する必要があります。
なお、SESで取得できるメールイベントは、SESのconfiguration setで設定できます。
 参考:Amazon SES でのイベント送信先の作成

おすすめのイベント取得の組み合わせ

最後に、用途別おすすめのイベントの組み合わせを記載しておきます。

textメールしか送らない場合

  • reject
  • renderingfailure
  • delivery/bounce
  • complaint

reject
 SES内でウィルス検知されたケースのもので、滅多に(というか過去一度も)発生したことはありません。
 ただ、発生した場合は、社内にセキュリティリスクがあることが考えられますので、
 受け取ることが必要かなと考えます。

renderingfailure
 メールテンプレートとパラメータが噛み合わない場合などに発生します。
 当然メールも遅れません。
 これは結構トラップなのですが、sesにsdk経由でrequestするタイミングでは正常終了するんですね。
 なので、イベントとして受け取らないと、実は送れていないのに気づけないということが発生します。
 結構な罠です。

delivery/bounce
 請求書の送付という業務性質上、極力到着率を高める必要があります。
 ただメールという基盤は、到着するかどうかがいろんな要素に左右される不安定なものでもあります。
 誰もが使える一方で、悪用する人が多いので、受信側でしっかり制御をかけてるからですね。
 (到着率を高めるための工夫も結構あるのですが、記事が長くなるのでまたの機会に)
 なので、到着/未着のデータはしっかりとって、DBに刻むようにしています。
 この未着履歴をもとに、別の媒体(SMSやオートコールなど)で連絡を取るようにしています。

htmlメールを送る場合

  • reject
  • renderingfailure
  • delivery
  • bounce
  • complaint
  • open
  • click

open/click
 htmlメール限定でとれるイベントです。
 今どきはほとんどのサービスがhtmlメールを送ってると思いますが、
 メールを送った後に、受信側の動向が探れる唯一のものですので、
 ぜひ受け取りたいですね。
 ただ、htmlメールを開けないクライアントを利用されてる受信者の方もいらっしゃるので、
 open/clickだけですべてのお客さんをカバーできてるわけではありません。

イベント受け取りのアーキテクチャ

最後に、簡単ではありますが、イベント受け取り周りのアーキテクチャを貼っておきます。

f261cae8ca8237b918a7fecaf3a93fd1.png

なおSESからのイベントの受け取りはSNSでFIFOが使えないので、スタンダードで対応してます。
配信結果テーブルへの登録時に冪等チェックをするようにしています。
冪等チェックでは、宛先メールアドレスと、
sesへの送信リクエスト時に送れるtagsを使ってます。
 参考:Amazon SES イベント発行を使用して E メール送信をモニタリングする
tagsに差し込んだkvのセットと、宛先メアドをdynamoのパーティションキーとソートキーにして、
それで冪等チェックをするようにしています。

拙い内容でしたが、自分が実装するときはこの情報が調べてもヒットしなかったので、
ここに残しておきます。
どなたかの参考になれば幸いです。

9
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?