🚀

【Rails】Gmailを用いたActionMailerの限界について

2023/04/12に公開

何をしようとしたの?

業務内で、ユーザの一括登録のスクリプトを回した時の話。

「ユーザ登録→メール配信」といった流れのロジックで、
1ユーザ登録するたびに、1メール飛ぶような仕様となっていた。
過去にも100人程度の一括登録をしたことがあり、その際は問題なかった。
なお、メール配信はSidekiqを用いて遅延処理を行なっているものとしている。

今回はその10倍の1400人の一括登録をしてほしいと依頼があった。
いささか心配だったが、いざスクリプト実行!

何が起きたのか?

まずユーザ登録自体に問題なかった。
しかし、ActionJob側でメール配信でキューがいくつか死んでおり、以下のようなエラーが発生した。

Net::SMTPAuthenticationError: 454 4.7.0 Too many login attempts, please try again later.

まあだいたい検討はつく。。。

結局何がダメだったのか。

今回は、スクリプトを回した直後に、メール送信タスク1400件がキューにたまる。
しかしGmail側には以下のように送信数制限があるため、アプリ側でどんどん送信処理を登録すればいいってものでもないらしい。(登録後に送信されるメール以外にも、アプリ内でレポート出力後に送信するメールなどあったため総送信数が制限を超えてしまっていた。)

https://support.google.com/a/answer/166852?hl=ja

どのように回避した?

回避方法としては大きく分けて3つ考えた。

  1. Gmailアカウントを複数作成し、機能ごとにメールアドレス分ける。
  2. メール配信システムを利用する
  3. そもそもメールを利用しない導線を引く

正直、1の案は現実的ではない。アプリの規模がスケールした際に、とんでもない数のGmailアカウントを管理する必要があるからだ。
3については、できるならばそちらを実践するのは悪くないと思われる。しかし、UI/UXを変えることを、1エンジニアの独断ですることもできず、ROIもそこまで高いとは思えず、断念。

結局メール配信システムを使った方が良いと判断。
とはいえ結構これも時間かかりそうだなと思ったのだが、
社内の営業チームが使っていたBlastmailにAP連携機能ないかなと調査したところ
なんとできるではないか!

https://blastmail.jp/api/

ということでAP連携することで問題回避した。

まとめ

もっといい方法ありそうな気もしたりしなかったり。
ただ、ROIを考えると今回は割と最適解を導けたと思う。

Discussion