エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

メール配信システムを SaaS から新規社内システムへ移行した

AWS Infrastructure Serverless

この記事はエムスリーAdvent Calendar 2023の20日目の記事です。

エムスリーエンジニアリングG コンシューマチームの松原(@ma2ge)です。 今回はコンシューマチームで利用していたSaaSのメール配信システムを、新規に開発した社内システムに移行した経緯や設計時に意識したことなどについて紹介します。

最近使っているキーボードの様子
最近使っているキーボードの様子

背景

今回移行する契機となったのはメールの配信数増加に伴うSaaSの利用料金増です。 特に定期的に送るメルマガ配信については、配信量も多く利用コストを押し上げる要因となっていました。 そのためメルマガ配信で大量に使用する部分についてのシステム移行検討が始まりました。

移行検討

SaaSから移行後のシステムについて試算すると、システムの開発や利用料といったコスト面では社内で構築したシステムの方が大幅にコストが下がることがわかりました。 しかしながらメールサーバーを含めて丸ごとメール配信システムを作るのはチームにとってはそれなりに負荷があります。 特に今のチームは主にサービスを開発しているチームであるためメール周りの知見はほとんどありません。 例えばIPのレピュテーションを高めることにどれくらいの力を入れるのか、バウンスの対応はどのように行っていくのかなど、考えるべきことはいくつもあり開発、運用ともに時間も手間も取られそうなことが予想できました。 利用料を削減したいとはいえ、肝心のサービス開発に使う時間が減少してしまっては、削減で得られる利益よりも機会損失による利益の減少の方が大きくなり本末転倒となる可能性もあります。

そのため今回は丸ごと全てを作るのではなく、メールサーバー部分については社内のものを利用することにしました。 エムスリーも長いことサービスを運営しており、社内横断のSREチームが運用しているメール配信用の社内メールサーバーがあります。 そちらを利用することで、メールサーバー周りの運用をSREチームに見てもらうことで負担を一部軽減し、今回開発するメール配信システム部分をチーム内で見るようにすることで運用負荷も現実的な範囲にできそうと判断しました。 移行対象のメルマガはそれなりに配信量も多く社内メールサーバーの負荷も心配でしたが、幸いメールサーバーを強化することで配信量はカバーできそうとの見込みを立ててもらうことができ、この案で開発を進めることになりました。

設計時に意識したこと

ということで社内メールサーバーを利用することで方針は決まったので、次は設計の方針です。 要件としてはSaaSで利用していた下記機能をまずは必要な分満たすことです。

  • メール配信速度を段階的にあげていきサービスに必要な配信速度を目指す
  • メール配信に伴う配信状況、クリック数等の計測

メールの配信速度については、専門的なサービスとして提供しているSaaSに追いつくことは難しいです。そのため自サービスで求めている配信速度を目指すことにし、配信速度も段階的に高めていくことで調整がつきました。 移行後は送信量も多くなるのでIPレピュテーションのリスクも高まります。その意味でもここは一気に速度をあげていくということはせずに徐々に進めていく必要があります。

開発周りについては先日の記事「AWS Lambda でも Rails で Web 開発」をご覧いただいて、今回は運用と独立性について記します。

運用楽に

設計で意識したことの1点目は運用が楽になるようにしたことです。移行検討にも記載しましたが、サービス開発に集中できるよう運用は楽であればあるほど良いです。

メール配信については社内メールサーバーの強化やメルマガ配信の量によって、ある程度柔軟に配信速度を調節できると運用コストが下がることが見込めたので、スケーラビリティを高めるためにSQSとAWS Lambdaを組み合わせて採用することにしました。 この連携ではSQSをイベントソースとしたときの最大同時実行数も制御できるので、この数値を変動させるだけで簡易的に処理速度をスケールさせることができます。 また最大で1000まで同時実行数をスケールさせることもできるため、1関数あたりでそれなりの量を処理できれば、今後メール配信が増えたとしても十分に処理できるだけの能力が見込めます。

メールの配信状況やクリック数の測定に関してはできるだけサーバー管理不要なAWSサービスを組み合わせることにしました。 AWS LambdaからCloudWatch Logs経由でイベントを出力しておいて、Firehoseを経由しS3へログファイルを出力し、その後AWS Glueを使用して社内の共通DWH基盤であるBigQueryへとデータ連携するような仕組みを構築しました。 AWS Glueは初めて使用するAWSのサービスではあったのですが、サーバーレスで運用周りを任せられそうだったことから選定することにしました。社内的にはEmbulkを使っているものも多いのですが、サーバーを共用していたりQA用のリソースがそれほど多くないことが懸念となり今回のプロジェクトでは見送ることにしました。

独立性

2点目は配信システムの独立性で、マイクロサービスとして切り出して開発するようにしたことです。 メール周りに関してこのシステムに切り出すことで、サービス部分は自分たちのビジネスロジックに集中できます。 また今はまだ開発できていないのですが将来的に予約送信等の機能も入れば、サービス部分で予約にまつわる余計な複雑さを抱える必要もなくなります。

ということで今回はこのような構成でシステムを構築しました（メール送信から配信状況の計測まで）

システムへのメール送信リクエストから配送状況をデータとして格納する部分までの構成
システムへのメール送信リクエストから配送状況をデータとして格納する部分までの構成

本記事では紹介できませんでしたが、メールサーバー周りの運用についてはSREチームの記事がありますので興味のある方はぜひご覧になってください。

www.m3tech.blog

www.m3tech.blog

結果

このような構成、意図で設計した結果ですが、本システムの運用で逼迫することもなくサービス開発も引き続き実施できています。

SQSとAWS Lambdaの組み合わせは見込み通り、同時実行数の制御を使うことで柔軟な運用ができてとても便利でした。特にメールサーバーの配信処理性能が向上することに合わせてこちらの処理速度も追従させる必要があったため、設定値の変更のみで追従できるのは非常に楽でした。 AWS Glueは初めて触るサービスでしたが運用してみると管理するサーバーも必要なく、スケジュール実行できたり、ログも最初から吐いてくれたりと運用目線で楽ができてよかったです。一方でAWS Glueは開発で結構ハマってしまったり、Sparkになれていなかったりで手間取った部分もありました。

独立性については元々SaaSを使っていたこともあり、比較的分けやすくAPIを呼び分けるだけで移行もしやすい状態にできたかと思います。メール配信に特化させたためもしかしたら将来的には別のサービスで同じシステムを使い回すということもできるかもしれません。

当初目的であるコストダウンについても月間で約100万円ほど削減できました。

We are hiring!

今回は直近で担当したメール配信システムの移行について振り返りつつ記録してみました。 開発の意思決定について日常の様子が少しでも伝わればと思います。

エムスリーでは開発から運用まで一気通貫で担当したい技術好きなエンジニアを募集しております。ご興味がありましたら、お気軽にお問い合わせください。

jobs.m3.com