こんにちは！マネーフォワードエンジニアの木吉です。 CTO室マイクロサービス推進部で社内のさまざまなプロダクトから使われるマイクロサービスを開発しています。
今年6月にメール取込というサービスをリリースしました。 お知らせはこちらです。 今回はそのメール取込について紹介する記事になります。
メール取込とは？
メールの本文あるいは添付ファイルを解析した結果をデータとして提供することを目的としたプロダクトです。
背景
マネーフォワードでは、アカウントアグリゲーションという技術を強みとしています。 金融機関などのサービスと連携し、APIまたはスクレイピングを用いてデータの取得を行い、口座の入出金情報などのデータの取得を自動で行う仕組みです。
日々、連携できる金融機関やサービスは増えていきます。しかし、
- そもそもAPI連携できないサービス
- 複雑な認証フローを要求されるサービス
こういった特徴のサービスについては連携先として追加するのが難しく、ユーザに手入力でのデータ作成を強いてしまっている、というのがこれまでの現状でした。
新たな連携手段の検討
上記で述べたような背景から、新たな連携追加の手段がないか模索し始めました。 最近ではチャットツールなども積極的に活用されるようになってきましたが、ビジネスの世界ではまだまだ連絡の方法としてメールでのやりとりも主流です。 メール取込では、特に領収書などがメールで送受信されている点に着目しました。 メールのやりとりを起点としたアカウントアグリゲーションを実現し、より広範囲のサービスで連携先追加や会計データの作成などを自動化すること目指しています。
技術スタックなど
- 言語: Go
- インフラ: AWS/K8S(EKS)
- DB: RDS, DynamoDB
- CI/CD: CircleCI/ArgoCD
弊社では開発言語としてGoを選択したり、AWSの様々なサービス活用が活発に行われています。 理由は様々ありますが、マイクロサービス開発にGoが適している・チームにもGo経験のあるメンバーがいるという経緯で開発言語として採用しました(社内のGoの利用の活性化につなげていきたい、という思いもあります)
利用イメージ
メール取込の利用イメージは以下のようになります。
- ユーザ専用のメールアドレスを発行する
- 発行されたメールアドレスをサービスからのメール受信アドレスとして設定、または自動転送設定する
- メール取込にメールを送信する
- メール取込がメールの内容を解析する
- (以降) MFクラウド経費を通して明細情報を取得・利用する
アーキテクチャ(メール解析)
メール解析のためのアーキテクチャは以下のようになっています。
処理の流れ
1.SESがメールを受信し、メールオブジェクトがS3に保存される 2.S3 Putイベントを検知してLambdaによりメールの情報がDispatcherに受け渡される 3.Dispatcherがどのサービスのメールなのか判断して対象のParserに振り分ける 4.Parserがメールデータを解析し、解析結果を保存する
プロセスについて
- Dispatcher
- 受信したメールがどのサービスのものなのか振り分けるためのプロセス
- Parser
- メール(本文、添付ファイル)を解析し、データとして保存するためのプロセス
なぜこうなっているか
以下を意識したアーキテクチャ構成を取っています。
- メールをトリガとした処理はイベント駆動にして処理効率を高める
- プロセス同士の処理/責務を分離し疎結合にする
- 1サービスの解析処理による影響を他のサービスの解析に持ち込まないようにするため
- スケールを柔軟に行う
- 需要の高いサービスにフォーカスしてリソースを割り当て、スケールする仕組み
直面した課題
解析対象メールの判断基準をどうするか問題
メールを取り扱う上で、まず何を基準として解析対象のメールとして判断するのかという点が課題でした。 いったんメールを受け取り、メールヘッダの対象・内容を条件化した上で、どのサービスを対象としたメールか(または解析対象ではないメールなのか)を判断し、解析を行うフローとしました。この仕組みによって以下を担保することができます。
- 負荷分散
- スケーラビリティ
- 疎結合にして開発を並行で行えるようにする
- 解析処理の責務を分離し、別サービスのメール処理に影響を与えないようにする
メールのフォーマット変わる問題
当然とも言えますが、送られてくるメールの形式は、利用サービス側の都合で（こちらの意図しないタイミングで）変わります。 開発中に起こった事例としては
- メールのフォーマット自体が変わった
- メールを送信してくるアドレスが変わった
といったケースがありました。 想像するだけでも
- メールを送信してくるドメインが変わった
- これまでメール本文に明細の元となる情報が含まれていたが、添付ファイルによる記載になった
- 領収書はリンク先だけメールに記載されて送られてくるようになった
こういったケースが無数に想定されます。
この問題に立ち向かうために意識したことは「既存の仕組みやデータ構成に悪影響を及ぼさないようにする」ことでした。 曖昧な解析をして間違った金額で登録してしまう、といったことは絶対に避けなければなりません。仮に解析処理自体に誤りがあった場合に、間違いに気付いた後、各利用サービスにデータ修正が波及してしまうこととなってしまいます。
そのため解析後のバリデート処理を必須とし、領収書の項目として不適切な場合、解析処理を一時停止するようになっています。 停止中に開発者に通知をして対応するというフローになっており、その間受信されたメールについては再処理される仕組みを用意しています。 泥臭いともいえる作業を続けることになるため、こちらは将来的に人の手を煩わせず対応できるフローを目指しています。
まとめ
以上、メール取込の紹介でした。 サービスの構想からまずは初期リリースという山場を超えることができました。
一方でまだまだユーザには十分に価値を届けられていないと感じています。 これまでお伝えしてきたものもありますが、妥協した点やさらなる課題もあり、日々改善や技術検証を進めています！
- メール解析に回すための条件が限られているため、ユーザが利用開始するまでのハードルが高い(離脱率が高い)
- メールフォーマットが変更されることに対して柔軟な対応ができていない
- 十分な対応サービスの数を確保できていない
- メール取込を利用できるプロダクトが現状MFクラウド経費のみ
こういった、泥臭い課題とも向き合っていく必要のあるプロダクトですが、様々なユーザの課題を解決する上で将来性のあるプロダクトだと思っています。 これら課題を解決し、今後マネーフォワードのすべてのプロダクトを支えるバックエンドサービスを目指して開発・運用を続けていきたいと思います。
おわりに
ここまでお読みいただきありがとうございました！ 最後に、マネーフォワードではこのような課題に一緒に向き合い、解決していけるメンバーを募集しています。 興味を持っていただけた方、ぜひ一度カジュアル面談でお話しましょう！
マネーフォワードでは、エンジニアを募集しています。 ご応募お待ちしています。
【サイトのご案内】 ■マネーフォワード採用サイト ■Wantedly ■京都開発拠点
【プロダクトのご紹介】 ■お金の見える化サービス 『マネーフォワード ME』 iPhone,iPad Android
■ビジネス向けバックオフィス向け業務効率化ソリューション 『マネーフォワード クラウド』
■だれでも貯まって増える お金の体質改善サービス 『マネーフォワード おかねせんせい』
