1. はじめに
こんにちは、クラウドインテグレーション事業部のMitsuoです。
皆さん、Amazon SESのメトリクスは何を監視していますか？
担当案件で監視設計を行った時に学びになった点を記事にしてみます。
2. 対象読者
- Amazon SESを触ったことがある人
- ソフトバウンス、ハードバウンス、苦情メールなどメール配信に関する用語を理解している人
3. サプレッションリストについて
本題に入る前に簡単な概要説明です。
一言で言うと「Amazon SESにおける配信停止のメールアドレス一覧」です。
デフォルトで有効化されており、バウンス、苦情メールの発生時にリストへと追加されます。
SES は、アカウントレベルのサプレッションリストのアドレスに送信したメッセージを、アカウントのバウンス率または苦情率に対してカウントしません。
参考：Amazon SES アカウントレベルのサプレッションリストに関する考慮事項
サプレッションリストについては、同じ事業部の松木さんのブログが参考になります。
余談ですが、suppressionが「抑制」という意味なので直感的で好きな機能名だったりします。
4. Amazon SESのベストプラクティス
概要説明に加えて、ベストプラクティスの話も少しだけ補足します。
ベストプラクティスでは、以下のようなメトリクスを観測するべきだと記載があります。
- バウンス率(Reputation.BounceRate)
- 苦情率(Reputation.ComplaintRate)
バウンス率が10% を超えた場合、AWSアカウント上の E メール送信機能が一時的に停止される可能性があるためです。AWS公式は、5%未満に抑えるべきとしています。
ですので、バウンス率が5%を超えたらアラームを発報するような設定とします。あるいは、早期にバウンスの予兆に気づくために2〜3%にする方もいると思います。
苦情率に関しても、0.1%未満にするべきと記載があります。
アラーム設定については、バウンス率と同じ考えになります。
5. サプレッションリストを有効化していれば、メトリクス監視が不要になる？
ここからが本題です。
ふと、こんな疑問が浮かびました。
サプレッションリストが有効化されていれば、自動でバウンスメールや苦情メールがリストに入り、メトリクスとしてカウントされなくなるのであれば、監視自体が不要ではないのか？
SES は、アカウントレベルのサプレッションリストのアドレスに送信したメッセージを、アカウントのバウンス率または苦情率に対してカウントしません。
勿論「不安要素があれば監視はしておくべき」という考えもありますが、
起こり得るか分からないものを監視するのか、無駄に運用者の負担を増やすのか、という考えもあります。
6. サポート問い合わせの結果
要約すると以下のとおりです。
- バウンスの発生や苦情のフィードバックループを把握した際に速やかにアカウントレベルのサプレッションリストに追加されることが期待されるが、実際に追加されるまでの時間はドキュメントで公開されていない
- Eメールの送信先が不特定多数、特定多数に関わらず監視をしておけば、想定と異なる要因でバウンスや苦情が発生している場合でもその予兆を早い段階で検知出来る
メール送信機能が停止することを天秤にかけると監視しておくことに越したことはないという話なのでしょうか。
7. サプレッションリストに追加される前はメトリクスにカウントされるのか
たとえ、サプレッションリストに入るメールアドレスでも、サプレッションリストに入るまでは、メトリクスとしてカウントします。
以下は同僚が検証したスクリーションショットで、バウンスメールを発生させ、サプレッションリストに入れたものです。
メトリクスにバウンス率がカウントされている事を確認しています。
サプレッションリストによってバウンス、苦情率を緩和するは出来ますが、
完全に防げる訳ではないことが分かります。
8. まとめ
筆者は以下のように理解しました。
- Amazon SESを利用する場合、バウンス率や苦情率を監視するか困ったら、とりあえず監視しておき実際に運用時に必要可否を判断すれば良い
- バウンス、苦情メール発生時のサプレッションリストへの登録は必ずしも即時ではない
- 不特定多数に送信する場合、サプレッションリストに入る前にバウンス率・苦情率が閾値を超過する可能性があるので、監視は必須だと考える
- 特定多数でバウンスがあまり起きない場合だとバウンス率・苦情率が閾値超過する可能性は少ないので、監視は必須ではないと考える
- サプレッションリストに追加した後、メトリクスとしてカウントされない反面、バウンスや苦情に気づけないデメリットがあるため、発生時に通知する仕組みであったり、定期的にサプレッションリストの棚卸しを行う運用設計が必要と考える。（ただし、通知件数が多いアカウントだとそれ自体がノイズになり得るため注意すること）
参考：Amazon SNSを使用したAmazon SES通知の受信
いかがだったでしょうか。
繰り返しになりますが、正解がないと思うので、他の方が同じ題材で全く違うことを言うかもしれません。
要件を自分なりに咀嚼して監視設計する事と、メトリクスの状態を観測し、継続的な監視の見直しをすることが大事だと考えています。
Mitsuoでした。
おまけ
ここは筆者の推察になりますが・・・
公式ドキュメントに以下の記載があるので、代表ボリュームの算出後にサプレッションリストに入るのではないかと思ってます。
正直ここは、たまたまそうなっただけであって、処理に前後関係があるかは分からないですが…
Q5. バウンス率の計算対象となる期間はどれくらいですか?
バウンス率の計算は固定期間に基づいて行われるわけではありません。これは、さまざまな送信者が異なる割合で送信を行うためです。代わりに、代表ボリューム (典型的な通常の E メール送信量) を調べます。大量のメールの送信者と少量のメールの送信者を公平に扱うために、代表的ボリュームはユーザーごとに異なっており、ユーザーの送信パターンの変化に伴い代表的ボリュームも変わります。
