Amazon SESのSMTPインタフェースが登場！だが、しかし・・・

記事詳細

2012年01月05日(Thu)

2011年12月、Amazon Simple Email Service (SES)に
SMTPインタフェースが追加されてものすっごく便利になりました！！

あ、ちなみに、Amazon SESとは端的に言えば従量課金のMTAです。
面倒なセットアップや、煩雑なセキュリティ設定から開放されます。

SMTPインタフェースが追加されたことによって、
既存のメール系システムと違和感なく連携することもできますし、
また、Thunderbird等のメールソフトからも利用できるようになりました。

これまでは、他のAmazonクラウドのサービスと同様に
WebベースのAPIを使ってメールを送信する方法しかありませんでした。

■ただ、便利になることと送信速度とが天秤にかかっています。

  Amazon SESを使ってメールの高速配信をしようと考える場合に、
  このSMTPインターフェースを安易に利用するとケガするかもしれません。

  では、すこし考えてみましょう。

■現在、Amazon SESのエンドポイントはUS East (N. Virginia)のみ

  もちろん、今後、東京をはじめとする各リージョンにエンドポイントが
  追加されることを期待していますが、現在はUS Eastのみです。

  つまり・・・
  （日本から）遠ぉい！！

  エンドポイント（つまり、SMTPサーバ）が日本から遠いことによって、
  SMTPインタフェースを活用したメールの送信には注意が必要なのです。

■SMTPプロトコルは手続きが多い！

  SMTPプロトコルは、もうね・・・手続きが多いんですよ・・・。

  たった1通のメールを送るのに、
  5回も6回もリクエストを送らなければなりません。

  当然、リクエストのたびにネットワーク遅延が発生するので、
  高速配信を考えるときには、この遅延が最大のコストになります。

■東京リージョン？いやいや、US East (N. Virginia)最高！！？

  そのため、たとえば東京リージョンのEC2に構築したサービスから
  SMTPインタフェースで高速配信しようするなら、もう大変です・・・。

  日本とUS Eastのネットワーク遅延が180～200 ms前後のようなので、
  1通のメールを送信するのに1秒程度かかることになります。（遅い！）

  そこで、ネットワーク遅延を極小化するという目的においては、
  US EastのEC2を使うのがよいのではないかと思いつくわけです。

  と、ここまでは理論的なお話。

■実験

  では、実際に東京リージョンとUS EastのそれぞれのEC2から
  SMTPインターフェースを使った場合の配信速度を比べてみましょう。

      ・  EC2は、Amazon Linuxのsmallインスタンスを使います。
      ・  実験時のAmazon SESの制限は5 emails/secondです。
      ・  SMTPの並列度は1です。
      ・  1回の接続で3通を続けて送信します。
      ・  TLSで接続してから応答があるまでは除いています。
      ・  メールの内容はごくごく小さいテスト用です。
      ・  結果は3セットの平均です。

	東京から	US Eastから
EHLOに対する応答	201 ms	5 ms
AUTH PLAINに対する応答	200 ms	7 ms
認証に対する応答	230 ms	30 ms
MAIL FROMに対する応答	199 ms	2 ms
RCPT TOに対する応答	200 ms	2 ms
DATAに対する応答	200 ms	2 ms
メール内容に対する応答	562 ms	189 ms

  やはり、US Eastからの方が何倍どころじゃなく断然はやいですね！

■大量メールの高速配信サービスの構成案

  つまり、日本国内向けのサービスを考える場合、
  次のような構成にするのがよさそうです。

      ・  ユーザインターフェースには東京リージョン等の国内サーバを使う。

      ・  大量メールの高速配信をSMTPインターフェースでおこなうならば、
          配信データをUS Eastにまとめて転送して、そこからAmazon SESを使う。

■さて、

  WebベースのAPIとSMTPインタフェースとの比較は？？？
  とか、
  並列度をあげたらどうなる？？？

  とかが気になるところですが、
  それはまた別のお話ということで。