モバイルサイトの運用をしており、約10万会員に対しメール配信をしているのですが、配送中の負荷がボトルネックになっており、改善方法を模索しています。


現在のサーバの構成、と言うようなもんじゃないですが、postfix, postgres, apache, php がすべて1サーバに入っています。

同様のサイトで外部のメール配送エンジン(sendmagicなど)を導入することで改善した事例があるので、メール配送後にアクセスが集中したことによる負荷がメインではないことは確認済みです。vmstat などでの調査によると、特に disk に負荷がかかっているようです。

できる限り、アプリケーション側(PHP)での解決を望んでいますが、メールサーバを分け、SMTPを直接喋るのが良いのでしょうか。
私の認識では、アプリケーションと同じサーバに入っているMTAに mail関数 で配送を依頼するのと、SMTPで接続して HELO...QUIT するのとでは差はない、と認識していますが間違っていませんでしょうか。

また、よくあるモバイル向けメール配送エンジン流量調整をどのような方法で行い、高速大量配送(1IPで数万通/h)を実現しているのかについても、方法がわかればトライしたいと思っています。

よろしくお願いします。

回答の条件
  • URL必須
  • 1人5回まで
  • 登録:
  • 終了:2006/12/28 11:10:43
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

回答7件)

id:hamster009 No.1

回答回数3431ベストアンサー獲得回数50

ポイント16pt

これは製品ですか、こういう風にCPUの使用率を制限して、他に支障の出ないようにsendmail(postfix)を動かしたらどうですか?

http://hitachisoft.jp/Products/Sendmail/products/switch/index.ht...

製品を使わなくても、テクニック的にはもっと簡単にできると思うのですが。

id:ariacompany

すみません、書き漏れましたができれば現状の配信数をさらに増やしたい、つまり、より高速・大量を目指すこともしたいです。なので、稼働率を下げるのはちょっと違います。

2006/12/26 22:58:41
id:hamster009 No.2

回答回数3431ベストアンサー獲得回数50

ポイント16pt

このあたりのpostfixの設定で、メモリやプロセス数などを制限できるようなのですが。リソース制限および速度制限というところです。

http://www.kobitosan.net/postfix/jhtml/resource.html

id:ariacompany

postfix 自体のチューニングは詳しくないですが、

CPUの使用というよりは通信・ディスクに問題が出るんじゃないでしょうか。

2006/12/26 23:02:13
id:hamster009 No.3

回答回数3431ベストアンサー獲得回数50

ポイント16pt

これは一般的な設定での注意事項なので、サイト側が多量のメールを送る場合ではないのですが、留意点としてはやはりメモリやCPUの制限、プロセス数などが挙げられています。

http://www.math.kobe-u.ac.jp/~kodama/tips-postfix-load.html

id:ariacompany

いろいろありがとうございます。

少しプロセス数を絞ってみるなどの実験は必要そうですね。

もうちょっと設定まわり見直してみたいと思います。

2006/12/26 23:07:02
id:hamster008 No.4

回答回数116ベストアンサー獲得回数1

ポイント8pt

postfixボトルネックの分析

http://www.kobitosan.net/postfix/trans-2.1/jhtml/QSHAPE_README.h...

たとえば、届かないメールがあると、キューにたまって何回も配送を試みるので、負荷がかかりやすくなる、これをなんとかするなどの話です。

id:ariacompany

ありがとうございます。

エラーメールは当然クリーニングしているので、届かないメールは最小限に抑えられています。

2006/12/26 23:19:16
id:b-wind No.5

回答回数3344ベストアンサー獲得回数440

ポイント24pt

アプリケーションと同じサーバに入っているMTAに mail関数 で配送を依頼するのと、SMTPで接続して HELO...QUIT するのとでは差はない

技術的な差は当然あります。

mail 関数では sendmail 互換インターフェイスを使って(大抵 /usr/sbin/sendmail )送信するのに比べ、SMTP をしゃべる場合は当然 smtp デーモンと通信する事になります。

ただ、同一サーバー上にあるのであればその差はあまり大きくはありません。


現時点ではディスクに負荷がかかっているとの事なのでまずはディスクの増設をオススメします。

以下は qmail の例ですが、ログの書き込み負荷を抑えることで高速化を実現しています。

http://www.drk7.jp/MT/archives/001098.html


Postfix が原因となっているのであれば

/var/spool/postfix

以下とログの書き込みディレクトリを別ディスクにするだけでも効果はあると思われます。


また一般的な携帯あてのメール配信のコツですが、キャリア側では同一IPアドレスからのコネクションを絞っているような節があるので固定IPアドレスを複数用意しておき、それぞれのIPアドレスからのコネクション数は少なめに制限して並列に送る形を良く見ました。

この意味からは外部のメールサーバーに投げられるようにプログラムを変更しておけば対応が容易になる事が考えられます。

ただし、自分のやっていたのは半年以上前なので現状では変わっているかもしれません。

id:ariacompany

ありがとうございます。

同一サーバ上MTAでの負荷について確認できてよかったです。もちろん技術的な差はありますね^^;

ディスクの増設は確かに。。DBも動いていることを考えると、RAID5や10の検討もいいですね。

URLにある、tmpfs 化はやってみる価値ありそうだと思いました。この場合、ログについて設定しているようですが、/var/spool/postfix でも面白いかもしれません。

モバイルメール配信新でIPを複数用意する方法は知っていますが、「ひとつのIP」でもそれなりの通数をはくことができるというのが気になっています。

キャリアの機嫌をうかがって通数を調整しているようなのですが、方法は見当もつきません。。

2006/12/26 23:28:37
id:b-wind No.6

回答回数3344ベストアンサー獲得回数440

ポイント16pt

http://k-tai.impress.co.jp/cda/article/news_toppage/8366.html

少し気になったのですが、ドコモの特定接続サービスは利用されていますか?

10万会員というのが総ユーザー数であれば、これを2~4セッションほど契約するだけで相当の効果がありますよ。


ただ、送信するメールの From 部分が限定されると言う欠点はありますが。

id:ariacompany

利用したことはないです。

キャリア別メールサーバを別に用意する、とアプリケーションから見ればそういう感じですね。

お墨付きを貰えるなら、ランニングコスト的にも安いかもしれません。

これを各キャリア導入して、複数の MAIL~DATA を送りつける、とかが解決法の1つでしょうか。

とても参考になります。

2006/12/26 23:57:05
id:b-wind No.7

回答回数3344ベストアンサー獲得回数440

ポイント24pt

これを各キャリア導入して

この類のサービスが存在するのはドコモとソフトバンクのみです。

ドコモは存在しないメールアドレスが多いと(SPAM とみなされる)契約を一方的に解除されるという欠点はありますが効果は絶大です。


ソフトバンク版は利用した事はありませんが、あまり変わらないという噂は聞いた事があります。


AU/TUKA はそもそも全てのメールを受け取ってから処理を行っているようなので、サービス自体存在しませんし必要もないようです。


複数の MAIL~DATA を送りつける

Postfix であれば、transport テーブルの設定だけで対応できます。

http://www.postfix-jp.info/trans-2.2/jhtml/transport.5.html

id:ariacompany

なるほど、知らなかったです!

2006/12/27 04:30:49

コメントはまだありません

この質問への反応(ブックマークコメント)

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません