はじめに
こんにちは、こんばんは。マネーフォワードでCTO室マイクロサービス推進部に所属している木吉です。 マネーフォワードではマイクロサービス化のために様々な活動を行っています。 私の部署でもプロダクトから技術要素に特化した機能をサービスとして切り離し、複数のプロダクトから共通機能として使ってもらうための開発を行っています。
今回はその中でもメール送信APIを提供するサービス(以下メール送信API)に関する活動について紹介します。
メール送信API
技術スタック
言語: Go インフラ: AWS(RDS,SNS,SQS)/Kubernetes(EKS)
サービスについて
ここで今回のメール送信APIについて説明します 機能としては非常にシンプルなもので、APIリクエストとしてプロダクトから送信したいメールの情報を受け取り送信します。
もともとプロトタイプとして作ったサービスであるため、当時は利用も少なく1日に数百件発生する程度でした。しかし、
ニーズが高まったこと、品質面での補強が必須
日々マネーフォワードでも多種多様なプロダクト開発を行われています。その中で、1日で数百万件オーダーで発生するメール送信をこのメール送信APIで対応したいという要望が生まれ、 「想像するだけでもこのままじゃ絶対ムリ」となった結果、性能改善施策とともに性能指標を定めるための活動を計画しました。 当時の運用状況で分かっている性能からざっくり1万倍のキャパシティを保証する必要がありました(笑)
背景
メール送信API自体は、もともと有志メンバーの余剰リソースを使うことで開発・運用がされていましたが、ニーズが高まってきたこと、品質面での補強が必須であることを理由に、それらを引き継ぐ形で私のチームで受け入れることになりました。
当時の課題としては以下のようなものがありました
- 専任メンバーがいない。みんな別の主務を持っている(泣
- 最低限動くレベルでリリースし最小限のリソースで維持運用を行っていたため、品質面での不安が残る
- 性能面での指標がない
- 開発を進めることで精一杯のため、リファクタリングなどの改善を行う余裕がない。プロトタイプ実装がかなり残っており、機能追加に時間がかかってしまう
- モニタリング面での品質が十分でない
そして、そもそもこれらすべてを解消するためリソースがないという問題でした(笑)
課題への取り組み
結論から言うとシンプルに計画立ててこれらをひとつひとつ解決していくという方法を取りました。
アーキテクチャ変更
メール送信APIはメール送信リクエストを受け付けるプロセス(producer)とメール送信プロセス(consumer)に分かれており、非同期でのメール送信を実現しています。 大きなボトルネックとなっていた、DBへのアクセス集中を軽減するため、間にSQSをいれてメッセージドリブンな仕組みに変更しました。これによりDBポーリングによるアクセスをなくし、負荷を減らすことができました。
直接SQSへメッセージを送信せず、間にSNSを挟むことで、さらなるプロセス間の抽象化を実現しています。実際に条件付けして投入するSQSキューを分けることで、さまざまな条件に応じた優先度によってメール送信を行うことをできるようにしています
性能テスト
もともと指標とできる値がなかったため、改めて性能テストを計画して実施することとしました。実際には以下のようなプロセスになります。
- 計画を立てる
- 負荷量
- ミドルウェアのスペック
- プロセスに割り当てるリソース(メモリ・CPU)
- シナリオの作成
- 環境整備(他システム依存箇所をモックなど)
- 性能テスト実施
- 負荷を処理できるかどうか
- 高負荷になった際にスケールするかどうか
- 結果集計
- 妥当かどうか検討し、NGであればチューニングしなおして再度性能テスト計画にもどる
負荷ツールとしてk6 (ここでは紹介だけしておきます)を利用し大量のリクエストを送信することで高負荷状態を再現することでテストを行いました。
結果的に最低限保証したい性能のさらに倍までは保証できることがわかり、安心してプロダクトにも使ってほしいと言えるようになりました。
パフォーマンス可視化
Datadog APMを導入して、どういった処理にどれくらいの時間を使っているのかを可視化できるようにしました。ボトルネックの発見にもつながるため、性能テスト前に仕組みをいれておくととても便利です。 これは個人的に一番やってよかったと思っているものです。Dadadog Logsと関連付けることでさらに強力になります。
サービス開発・運用のチーム化
サービスに関して詳しいメンバーが少ないことが当初の課題の一つでもありました。 以下のような取り組みを地道に続けることで、メンバーが自発的に開発・運用を進められるようになってきました。
- 勉強会を開催する
- 定形・運用作業をルール化し、ドキュメントにする
- タスク分割し新たなメンバーにアサインしてフォローにまわる
課題の変化
活動が続くにつれて課題の質も変化したと感じており、当初は
- 開発リソースが足りない
- 必要な機能が十分でない
- いつ止まるかわからない・止まってもすぐにメンテできるかわからない
そもそもリソースが不十分であることへの対応であったところから
- 性能面でもっと向上させたい(10倍、100倍量の送信をできるようにしたい)
- より多くのプロダクトからのメールを送信するために、機能を充実させたい
- アラートに対応できるためのルールを明確にし、メンバーの負荷を分散させたい
このように、よりプロダクトとしての質を求めていくような形にシフトしてきています。
おわりに
ここまで紹介してきた内容で、まずは当初の目的を達成することができました。また個人的には、ほぼチームが存在しなかったところから、サービスの品質を保証できるような体制ができてきたことを嬉しく思っています。
「アーキテクチャ変更」と途中で書きましたが、システム構成をガラッと変更して性能改善!のような内容でなくてがっかりされた方すみません(しかしながらこういった地道な活動や、前段階としてそもそも体制を整えることが大切であると、プロジェクトを通して実感しました)
今後はさらに多量のメールへの対応、対応プロダクトを増やし、マネーフォワードのあらゆるメール送信を担う基盤としてプロダクトの成長に貢献させていきたいと思っています。
将来的なビジネス拡大に応じてスケールするサービスにするためには性能面含め課題がたくさんあります。 マネーフォワードでは、こういった課題に一緒に立ち向かってくださる仲間を募集しています!興味を持っていただけたらぜひカジュアル面談でお話しましょう!
マネーフォワードでは、エンジニアを募集しています。 ご応募お待ちしています。
【会社情報】 ■Wantedly ■株式会社マネーフォワード ■福岡開発拠点 ■関西開発拠点(大阪/京都)
【SNS】 ■マネーフォワード公式note ■Twitter - 【公式】マネーフォワード ■Twitter - Money Forward Developers ■connpass - マネーフォワード ■YouTube - Money Forward Developers