SendGridが独自に開発したMTAとその歴史

SendGridが独自に開発したMTAとその歴史

この記事は Confirming Why SendGrid Built Its Own MTA の抄訳です。

SendGridでは独自に開発したMTAを利用していますが、なぜ既存の商用MTAを使わなかったのでしょうか?
これは、SendGridの社内外からもよく聞かれる質問です。近頃のMTAベンダの吸収合併に関するニュースも踏まえて、本件に関する私(Tim Jenkins、SendGrid社CTO、Co-founder)の考えをお伝えしたいと思います。

SendGridの開発初期

当初、SendGridはメールの送受信にPostfix(最もポピュラーなオープンソースMTAの1つ)をカスタマイズして使っていました。何の問題もなく機能していたのですが、ある時スケーリングの限界に達してしまいました。Postfixは本当に素晴らしいMTAですが、我々の規模のスケーリングでは運用が難しかったのです。例えば、あるバイラルなキャンペーンを実施していたお客様では、1日あたり1万通の送信量だったのがわずか数日で1000万通になるということもありました。顧客が見込んでいた送信量との相違もあり、深刻な問題となっていました。

KAMTAの開発

この問題を軽減するために、SendGridは独自のMTAの開発に乗り出しました。話はSendGridのシリーズA時代に遡ります。その時はまだ純粋に利益をあげるためのシステムを運用することに奔走しており、スケーラブルな商用MTAを購入するような金銭的余裕はありませんでした。

MTAに必要とされるものは何なのか?我々はその豊富な経験を活かし、マルチテナントのクラウドメールIaaSで必要な「スケーラブルかつ他システムとの連携が容易なMTA」を独自に開発することにしました。こうして、かつて経験していたようなMTAのボトルネックを解消しようとしたのです。
開発したMTAのβテスト時のパフォーマンスはこれまで経験したことがないほど高く、お客様からは「これはまさに “Kick Ass MTA(超すごいMTA)” と呼ぶにふさわしい」とのお言葉をいただきました。
この「KAMTA」のおかげで深刻なボトルネックは解消され、MTAのスケーラビリティについての心配をすることなく、システム開発をする余裕を取り戻すことができました。

開発するか、購入するか

最終的にSendGridは資金調達をすることができ、ここでKAMTAを商用のMTAに置き換えるかどうかが検討されました。優れた商用製品を利用することもできたのですが、メールを届けることはこのビジネスにとって非常にコアな部分のため、インフラの中枢部分のカスタマイズ性を諦めたくないという思いがありました。また、何の問題もなく動作しているシステムを切り離して、新しい製品とのインテグレートを考えるというのもナンセンスでした。商用MTAのメリットよりも、インテグレートのための時間、コスト、リスクの方が上回っていたのです。一連の独自技術も無駄にしたくありませんでした。

この判断は正しかったのか?

冒頭でお話した通り、いまでも「これは正しい判断だったのか?」と聞かれることがあります。私が確実に言えるのは、クラウド型のメールインフラサービスとしては「正しかった」ということです。SendGridが持つ一連の技術は、過去数年で次のような多数のイノベーションを生み出しました。

  • SendGridは、Gmailのフィードバックループに対応した最初のESPです。このことは、望まれないメールを送信しているユーザを特定するのに役立っています。
  • Enforced TLSを選択できるようにしたことで、メール業界において暗号化の必要性を周知するのに一役買っています。
  • SendGridという大規模なクラウドメール配信サービスにおいて、全てのユーザで日和見暗号化TLSを有効化し、メール転送におけるセキュリティとプライバシーを向上させました。

日和見暗号化TLSの件は、自社のMTAを持つことの優位性をよく示しています。以前のブログでもお話したように、日和見暗号化機能が期待通りに動作するかを確認するために、SendGridはインターネット上の180万以上の異なるメールサーバに対してテストを実施しました。結果、90%以上のトラフィックが暗号化されました。

この機能のリリース後、ある競合他社が同じことを行いましたが、「ドメインの検証は手動で実施し、暗号化されたのは25%だけだった」というブログ記事を出していました。

商用MTA業界ではここ数年の間に買収や競合となるサービスのリリースなど様々な変化がありました。もし私達が商用のMTAを選択していたら、その提供元と競合になっていたかもしれません。そういう点からも独自にMTAを開発するという選択は間違っていなかったと考えています。