Encraft#16での「マネーフォワードを支えるメール配信基盤」の登壇で話しきれなかったメール配信基盤の歴史について

はじめに

こんにちは。CTO室基盤アプリケーション部の斉藤(x-color)です。
先月末の7/29にプロダクトを支えるコアシステム - Encraft #16に登壇してきました。少々遅くなってしまいましたが、本ブログでは時間の都合上、登壇時に触れなかった部分を紹介していきたいと思います。

そもそも何に登壇してきたの？

「Encraft」という株式会社ナレッジワーク様が主催している勉強会に登壇してきました。こちらは月1回のペースで開催されている（過去の配信アーカイブはこちら）イベントであり、毎月異なるテーマで行われます。今回は「プロダクトを支えるコアシステム」といったテーマで実施され、会社経由でお声がけいただき、登壇する運びとなりました。

登壇内容について

今回私は、「マネーフォワードを支えるメール配信基盤」といったタイトルで登壇させていただきました（ライブ配信のアーカイブはこちら）。
マネーフォワードではさまざまなサービスを提供していますが、それらは毎日大量のメールをユーザーに配信しています。前回の登壇では、この大量のメール配信を支えるための基盤の紹介と、そこで活躍しているマイクロサービスの技術的改善について発表しました。

なお、登壇資料はSpeaker Deckにアップロードしてありますので、興味がある方はぜひご覧ください。

ここからは、登壇時には時間の都合でお話しできなかったメール配信基盤の歴史や、そのほかのことについて紹介していきます。

メール配信基盤の歴史

歴史の話をする前に、まずは発表の中で紹介した新旧のメール配信基盤の構成図について見ていきましょう。下記が構成図です。

旧メール配信基盤の構成図新メール配信基盤の構成図

アーキテクチャ変更によって変更されたのは、主に下記です。

メール配信の責務を持つサービスが一つになった
共通DBへの依存がなくなった
バウンス管理の自動化

（実際には、まだ旧サービス群から少しだけメールが送られていますが、これらは徐々にメール配信マイクロサービスに切り替えられています）

ここに至る歴史について話すと時間がいくらあっても足りないため、発表時にはあえて触れませんでした。そこで、この場を借りて改めてご紹介しようと思います。

混沌としていたメール配信サービス群

初期には旧アーキテクチャに存在する「メール配信機能」だけが存在していました。こちらは、とある別用途のコアシステムでメール配信が必要なために構築された機能で、DBにメール情報を書き込んでおくと、順番にメールが配送されるというシンプルな仕組みで稼働していました。このコアシステムとプロダクトはDBを共有していたので、そのプロダクトがメールを送りたい場合はDBにメールを書き込み、この機能に相乗りする形でメール配信が行われていました。

上記の機能では、プロダクト側が送信先の決定やメール内容の構築、配送日程の制御などを行う必要がありました。マーケティングメールのような指定した条件に合致するユーザーに一括で大量のメールを送るユースケースをサポートするために「一括メール配信専用サービス」が生まれました。このサービスは、ユーザーの条件（例：年齢、居住地域）を指定することで、配信対象ユーザーを自動で絞り込み、大量の同一メールの配信予約をすることができます。

バウンス管理については明確にどのタイミングから運用されていたのかは不明なのですが、おそらく初期の頃からあったはずです。バウンスメール受信用のメールサーバーを借りて、そちらに届いたメールを定期的に手動で取得し、bounceHammerというメール解析システムで解析、その結果を共通DBへ格納していました。
（なお2024年8月現在、bounceHammerはすでにEOLとなっています）

当分の間、上記構成で運用されていたのですが、メール配信機能が別のコアシステムの上で動いているのは責務の観点から相応しくありません。また、メール周りがごちゃついているのは課題として認識されていました。ということで、メール配信機能に特化したマイクロサービスを作り、全社のメール配信を担い、メール配信機能をコアシステムから剥がす取り組みが始まりました。（余談ですが、これは新卒入社したエンジニアがシニアエンジニアのサポートを受けながら始動したプロジェクトです）
そうして出来上がったのが、「メール配信マイクロサービス」になります。仕組みは既存のものをほとんど踏襲していましたが、マイクロサービスとして分離しており、HTTP APIを経由してメール送信をリクエストする形になっていました。

ただ出来上がったのはいいものの運用があまりうまく回らず、一部プロダクトからのみ利用され、日に数百メール送ればいいほうといった感じでした。もちろん、当初の目的だったメール機能の取り外しまでいけず、そのままとなっていました。

ここまでが一旦、発表で「旧アーキテクチャ」と呼んでいたものです。この頃は、メール配信サービスがそれぞれのチームの目的に合わせて運用されており、混沌としていました。プロダクト側も、どのサービス経由で送られているのかがよくわからないケースがあったようで、たまに別のサービス経由のメールの状態について問い合わせが来ていました。

メール配信基盤が整理されるまで

2年ほど前、メール配信マイクロサービスの運用の健全化のために私が所属する部でサービスを引き受けることになりました。その時は小さなサービスだったので片手間に運用を始めましたが、その後すぐに大量のメールをこのマイクロサービス経由で配信したい要望が生まれ、急遽性能と品質の向上を目的としたプロジェクトが始動しました。この件については、「マネーフォワードのこれからのメール送信を支えるマイクロサービス開発」で詳しく書かれています。

このプロジェクトを乗り越えた後は、このマイクロサービスの当初の目的である「全社のメール配信を支える」に立ち返り、将来的なメール基盤のための新アーキテクチャ検討が開始されました。これと並行して、全てのメールを捌けるだけの性能を求めて改善が繰り返されることになります。最も大きな変更を行った話は「メール送信基盤の最適化：アーキテクチャ再設計で達成した劇的なパフォーマンス改善」でまとめられていますので、こちらもご覧ください。

そうしてまず、メール配信マイクロサービスを強固なサービスにしていきました。改善を繰り返している間にも、社内にプロモーションを行うことで着実に利用プロダクトを増やしていました。メール配信機能を利用したプロダクトもクライアントとして取り込み、コアシステムからの機能取り外しも進んでいました。

上記で挙げたアーキテクチャ再設計のプロジェクトの前に、バウンス管理の健全化プロジェクトが行われました。
手動で行われていたバウンス情報の更新作業ですが、作業が属人化してしまい、かつ運用者が利用されていない機能だと思いこんでおり、長い間運用されていないことがわかりました。バウンス情報が管理されていないと、存在しないメールアドレスなどの、到達しないメールアドレスにもメールを送ってしまうことになります。これはメール配信者の評価（ドメインレピュテーション）を下げ、ユーザーへのメール到達率を著しく損なうものです。
マイクロサービス運用中にメンバーがエラーに気づき、なんとか関係者を探し出して（ドキュメントなどが何も残っておらず、古い情報を知っていそうな人にコンタクトを取ってヒアリングしました。。。）状況の整理などを行いました。結果、だいぶまずい状態だったので、その期に計画していた全てのプロジェクトを停止して、我々のチームがバウンス情報管理の健全化に注力することにしました。

前述した通り、当初バウンス情報は手動で共通DBに格納されており、この点も旧アーキテクチャの問題点でした。
そこで私たちは、専用のDBを用いてバウンス情報を完全に自動で管理するマイクロサービスを開発することを決定し、問題解決に向けて進めていきました。既存の管理方法を少ない情報から明らかにするなど、他プロダクトとのデータ整合性を持ったまま運用を開始するのに苦戦しましたが、最終的に完全に独立したマイクロサービスを開発することに成功しました。これにより、バウンス情報関連処理の共通DBからの脱却はもちろんのこと、手動作業が完全に不要になりました。HTTP APIも提供しており、バウンス情報の取得、バウンス状態を到達不可から可能にする機能の提供など、今まではDBを直接書き換える必要があった作業がAPI経由で容易に実施できるようになりました。
バウンス情報管理のためのマイクロサービスの話は、またいずれ書く機会があったら記事にしようと思います。

メール配信マイクロサービスが十分な性能を発揮し、バウンス管理も健全化されたタイミングで、一括メール配信サービスはこのマイクロサービスを利用するように切り替えを行いました。安全に切り替えるため、カナリアリリースのようにメールの配信量を段階的に調整しながら、一定期間をかけて移行を進めました。

最終的に、マイクロサービスへの流入を100％に切り替えた後、一定期間様子を見て問題がないことを確認し、独自の配信機能を停止して完全な切り替えを完了しました。

また、この切り替えと同時並行で、共通DBを利用せずにHTTP API経由でメールアドレスを取得する方式に切り替えていました。これは、メールアドレスなどの個人情報を管理しているマイクロサービスと連携して実施しました。これによりメール送信周りの共通DBへの参照も無くすことができました。

これらの取り組みによりメール配信基盤は整理され、残りは旧アーキテクチャのメール配信機能をまだ利用しているプロダクトがマイクロサービスに完全に乗り換えてもらうだけです。

現時点でほぼ全てのプロダクトの切り替えが終わっていますが、実はまだほんの少しだけ残っています。現在も少しずつ切り替えてもらっています。

（再掲）現在のメール配信基盤の構成図

新メール配信基盤の構成図

というわけで、上記の取り組みを経て、現在のアーキテクチャに切り替えることができました。

登壇時に話せてなかったそのほかのこと

メール通数のモニタリング

登壇時にお伝えしたとおり、マネーフォワードでは毎月大量のメールを配信しています。

マネーフォワードが1ヶ月で送信するメール数は2.5億通以上

この登壇資料を作成するために改めて通数を確認したのですが、去年と比較して25％も増えていたので正直驚きました。
ちなみに、直近の比率では計測していないのですが、以前計測した際には、98%程度のメールは基盤を経由して配信されていることが確認されています。

また、当初はグラフを利用して視覚的に通数の上昇量をお伝えできたらと思っていました。しかし、発表でお話しした通り、旧基盤では各サービスがバラバラに開発運用されていたため、容易にメール数を計測する術がなく、去年と直近しか情報が取れず断念しました。。。
（ちなみに去年はメールサーバーのログの数から計算していました）
現在の基盤ではメールは基本的に単一のサービスを経由するので、サービス側でメール数が計測されています。そのため、今後はどの程度メール数が増えているかがDatadogのグラフを利用して確認できます。これも集約したことによるメリットですね。

メールの配信流量制御について

最後に、ドメインレピュテーション維持のためのメールの流量制御の仕組みについて軽く説明しようと思います。
下記は、メール配信マイクロサービスのメール配信処理を担うコンポーネントの簡易的な構成図です。

キューを利用した流量制御の構成図

このマイクロサービスでは、キュー（Amazon SNS と Amazon SQS）を利用してServerとSenderでメール情報を受け渡しています。Sender側がポーリングすることでキューからメール情報を取得しているので、Serverへのメール配信リクエスト量に依存しない速度でSenderは処理できます。また、内部処理は基本的にどのメールに対しても同じなので、内部処理時間は均一となり、キューからのメッセージポーリング速度も安定します。これらから、1つのSenderの配信流量は安定します。

この場合、単位時間の配信量を決めるのはSenderのPod数になります。これを利用して、全体のPod数を一定以下に保つことでメール流量が過剰にならないように制御されています。実際のPod数はHPA（Horizontal Pod Autoscaler）を利用して自動制御されているので、各メール種別用のSenderの最大Pod数を調整しておくことで、過剰なメール配信を防止しています。

このようにSenderのPodあたりの配信速度を安定させつつ、Pod数をインフラ側の設定からコントロールすることで、全体のメール配信流量を安定させています。

さいごに

以上が発表時に話せなかった主なことです。
基盤の歴史については、改めて振り返ってみると色々あったなと感慨深いですね。将来を想定して立てた当時の計画ですが、その通りになんてならなくて、課題が現れるたびに再修正しながら進めていました。この基盤は何を会社に提供するべきなのかといった、全体から見た最適な形を模索して基盤の整理を進めていたのでここまで来ることができて一安心です。
なお、まだまだメール配信基盤には色々と紹介できることがあるのですが、それは今後の執筆者に任せるとします。

ちなみに登壇については、当初はオフライン開催も企画されていたのですが、諸事情でオンラインのみとなってしまいました。登壇自体が初だったのでせっかくならオフラインでやってみたかった……!これはまた別の機会に挑戦することにします。

最後に自社カンファレンスの紹介と採用のお知らせをさせてください。

来月にマネーフォワードとして初となる自社カンファレンス「Money Forward Tech Day 2024」を開催します。

techday.moneyforward-dev.jp