著名サービスのメルマガ配信環境についてお知恵を拝借したいのと、メルマガ配信サーバを高速化したい

Question

お世話になります。

Webサービスの開発に携わるものです。
最近なメールサーバー周りで悩ましい問題があります。

メルマガを一週間に一度、７０００通ぐらい送っています。
その配信スピードは、全体に行き渡るまで20時間をぐらい要します。
なぜ20時間かかるかといいますと、Cronで1分間に10通ずつ、SMTPに接続して送信するスクリプトを使っていて、
実際には、SMTPサーバーの接続待ち時間があり、処理時間としては、1分間に５通というところです。
チームメンバーからは、もっと早くしたいとの要望があり、どうしたものかというところです。

そこで、みなさんにお聞きしたいのですが、著名なサービスのメルマガ配信環境ってどういった構成ですか？
また、仮にその構成で、１万通メルマガ配信を行った場合、どのくらいの時間で処理できますか？

それこそ、Teratailのメルマガ配信メールサーバーの構成、もしくは、利用しているSMTPサービスをお聞きしたいです。処理時間も含め。

利用しているメールサーバーの構成
１台のPostfix(2.11.0)
送信ドメイン認証：Dkim SPF
メモリ１GBのVPS

Comments

[ikedas]

メールの内容には、宛先毎に違いがありますか。それとも、全く同じ内容を送るのですか。

[usop]

メルマガに関しては、同じ内容です。

Answer 1

SendGridエバンジェリストの中井と申します。

皆さんおっしゃる通りやはり専用のサービスをお使いいただくのがもっとも楽かと思います。確かに有料ではありますが、送信を早くするためにやらなければならないこと、エラーへの対応等を考えていると十分ペイするコストだと思います。
メール周りは宛先ISPの都合で色々とトラブルが発生しやすいですが、そのへんも含めて全て任せられるので運用の事自体をほとんど気にする必要もなくなります。

大量送信時に具体的に考慮しなければならないのは、

• 同時コネクション数
• 1コネクションあたりの送信メッセージ数
• 時間あたりの送信数
• 4xxのレスポンスがあったときの再送頻度、間隔

あたりです。

これらは各ISPによって異なりますし、送信元のレピュテーションによっても変動するので自分たちで最適値を導き出すのはかなり難易度が高いと思います。メール送信サービスは、それまでのノウハウを蓄積しているので強いわけです。

SendGridのプランで考えると4万通まで送信可能なBronzeプラン（月額1,180円）になると思いますが、移行は一番シンプルな方法だと、今の送信先としているSMTPサーバをSendGridにするだけで終えることが可能です。
しかしそれでも一通ずつリクエストを投げるという方法だと時間がかかってしまうので、理想的にはAPIを使って送信部分を実装することをおすすめします。1リクエストで1,000の宛先までいけるので7リクエストで終わります。どんなに遅くても送信処理自体は1分もかからなくなると思います。到達までも数分みておけば十分かと思います。

Comments

[ikedas]

自分で回答しているときに思ったのですが、キューイングが完了するまでの時間と、実際に相手先サーバへの配送が完了するまでの時間は違いますよね。

送信先サーバでの流量規制を考慮すると、配送の送信レートの制御が必要になると思います。SendGridでキューイングが速くなるのはわかりますが、配送レート制御はどんなことをやっているのでしょうか。可能なら回答に追記いただければ。

Answer 2

特定のサービス名を上げるのは避けますが、素直に、有料の配信サービスを使った方が良いと思います。
下手なことをするとブラックリストに載ってしまう可能性があります。
大量のメール配信はそれれなりにノウハウが必要だと思いますが、そういった手間よりも配信サービスを使った方があるかに安価です。

Comments

[usop]

ありがとうございます。
サービスの種類含めて、検討します。

[usop]

ちなみに、SendGrid等の有料サービスで、仮に１万ユーザにメールを送る場合、１万人にどのくらいの時間で到達するものですか？
一瞬ですか？

[CodeLab]

SendGridは使ったことがないのでわかりませんが、ほかのサービスでですが、時間指定で1万件程度をおくるのに、数分以内で送信結果が出ていました。
SendGridについてもここに記載があるので参考になるのではないかと思います。
https://sendgrid.kke.co.jp/case/%E6%9C%89%E9%99%90%E4%BC%9A%E7%A4%BE%E3%82%B5%E3%83%BC%E3%82%AF%E3%83%AB%E3%83%BB%E3%83%89%E3%83%83%E3%83%88%E3%83%BB%E3%82%A8%E3%83%A0%E3%82%A8%E3%82%B9/

こういったサービスは、複数のSMTPサーバーで平行して送る＆1サーバーあたりで迷惑メールにならない範囲で連続して送信する、といったことをしているのではないかと思います。

Answer 3

※注意 Postfix / メルマガの知識は全くありません。

メルマガの仕組みはよくわかりませんが、
メーリングリストに配信者のアドレスを管理して配信するのではないでしょうか。

「postfix mail magazine」で検索した所、
「SendGrid」というのが良さそうです。

自社管理のpostfixメールサーバーをSendGridに移行してみた

Comments

[usop]

ご回答ありがとうございます。
「SendGrid」は知っていますが、有料のサービスですよね。。

また、メーリングリスト化する事によって、送信スピードってSMTPのコネクションを張る分だけ、速くなりそうですが、結局のところ、メーリングリストからの送信って、一つ一つのメールドメインのSMTPサーバーに送信していると思っているため、そんなに劇的にスピードがアップするとは思えないのですが。。

Answer 4

これ以上ペースを上げるとさばききれないということでしょうか。
明らかに時間がかかりすぎています。
identの設定を確認することをお勧めします。

http://www.allied-fan.com/qa5.html

Comments

[usop]

identプロトコルって初めて知りました。
ただ、発信元のFWの113ポートを開けたくはありません。
なので、そもそもidentに接続しようとする設定をなくしたいのですが、
以下のリンクだとsendmailとqmailは設定できるようですが、postfixが見つからない状態です。

http://www.egserve.com/egv/menu02-4.htm

[katsuya141]

タイムアウトするまでダンマリだと時間がかかるので、113をリジェクトしてしまえばポートを空けなくて、タイムアウトまでまつこともありません

[usop]

なるほど。ありがとうございます！リジェクトは接続できないと応答を返すものですね。
メルマガを送るスクリプトを実行する、メールサーバーに接続するサーバーに以下のFW設定を適応しました。
[root@xxx-xxx-xxx-xxx ec2-user]# iptables -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset

これで様子をみます！

[usop]

先程の、FWの設定ですが、そもそも、最初からリジェクトしておりました。。AWSのセキュリティグループで許可しておりません（rejectしております）。原因は、別のようです。

[katsuya141]

あとは自分が経験したのはDNSの解決が遅いとかですねー

[usop]

あ、やっぱり間違いの間違いでした笑　AWSのセキュリティグループで許可していない場合は、おそらくDropで、一旦113を許可して、インスタンス（サーバー）で明示的にREJECTしないと、検証できないですね笑

DNSの解決が遅いのは、どうなおしたらいいんでしょうか。

[usop]

とりあえず、REJECT設定したので、様子を見ます！

（可能なら、DNSの解決が遅い問題の解決の仕方も教えてくれると助かります！）

[katsuya141]

nslookが遅くなければ大丈夫だと思いますけど。
あて先ドメイン順にソートしておくと、DNSキャッシュが利いて速くなるという細かすぎるテクニックもありましたが。
ボトルネックがどこなのかにもよりますが、リストを分割してパラレルに投げてみたらどうですかねー

Answer 5

大手のメールサービスなどでは、同じサーバから短時間に多数のメッセージが送られてくると、自動的にそのサーバからの配信を拒否する仕組みを持っています。質問者さんのシステムで、待ち時間をとってメッセージを送っているのは、この制限にひっかからないための対策でしょう。

送信先ドメイン多重化

上記のことを逆に考えると、別々のドメイン宛てに配信するものは一緒に送ってしまっても問題ないですね。それぞれ別々のメールサーバに送られるので、各々のメールサーバでの制限にひっかからなければ問題はありません。

宛先をドメイン毎にまとめる

(本節は、コメントに基づき追記しました)

メッセージの内容が全く同じで送信先アドレスのみ異なる場合は、一回のSMTPセッションで複数の宛先を指定して送ることができます (ただし内容が同じでも、VERPなどでエンヴェロープFromを変えている場合はこの方法は使えません)。Postfixにメッセージを送る際に、同じドメインの宛先アドレスを複数まとめて指定すればいいです。

1セッションあたりの宛先数の上限もメールサーバによって異なりますので、どこまで増やせるかは宛先ドメイン毎に実際に試すか、送信先サイトに個別に問い合わせることで決定します。一般に、10宛先くらいまでなら問題はないでしょう。

また多くのメールサーバでは、宛先数上限を超えたらそれ以前の宛先のみ受け付け、残りの宛先には再送するよう送信元のPostfixに促します (たまに、上限を超えるとそれ以前のものも含め全ての宛先を拒否するサーバもあります)。

送信先サーバ毎の閾値に合わせて送る

1通送信するたびに待ち時間を取るのは、あまりよい考えではないです。上で述べた「短時間に多数のメッセージ」の閾値を超えない数だけ、同じドメイン宛てのものを連続して送ってしまい (Postfixのキューに投入してしまい)、そのあとで待ち時間をとるのがいいです (待ち時間は、キューに入ったメッセージがほとんど配送できるまでどのくらいかかるかを計測して決めます。この値は送信先メールサーバ毎に異なってくるでしょう)。

また、ご質問の条件だと、送信先メールサーバあたり1分間に数通 (宛先ドメインによっては1通以下) 程度しか送っていません。もっと増やしても大丈夫でしょう。ただし、上述の閾値はメールサーバ毎に異なります。どこまで増やせるかは宛先ドメイン毎に実際に試すか、送信先サイトに個別に問い合わせることで決定します。

SMTPセッション多重化

以上説明してきたのは、Postfixのキューにメッセージを投入するタイミングを調整することで効率的に配送できるようにする方法ですが、キューに入った後の挙動もチューニングできます。

同じ送信先メールサーバに複数のメッセージを配送するとき、Postfixはサーバに複数のSMTPセッションを確立し、同時に複数の宛先に配送するようになります。この同時接続数にも、メールサーバ毎に制限があります。SMTP同時接続数の上限はsmtp_destination_concurrency_limitパラメータで調整できます。特に上限が大きかったり小さかったりする宛先ドメインについては、別個にsmtpトランスポートを定義してパラメータを変えればいいでしょう。

---

以上、かなりざっくりですが、回答してみました。回線事情が極端に悪いとかでもないかぎり、上記のうち最初の2点だけやるだけでも、2、3桁は速くなるのではないですか。