テーマ

初Adventです！

最近､メール送信時のトラブルを分析していたのですが､ActionMailerの実装についての情報がなかなか見つからず困りました｡

この機会に、ActionMailerの実装を掘り下げ、「メールを送信したら内容がSlackに届く」というSlackMailerのサンプルに挑戦したいと思います。

なぞのおじさん

あらためてrailsを支えるコンポーネント軍団を眺めてみると､それはそれはツヨそうなメンバーが揃っています。

ActionPackやActiveRecordといったフレームワークを動かす最重要幹部たち､ActiveSupportという有能な参謀。さらにはActionCableやActiveStorageのような期待の大型新人もいます｡

よく見るとわれらがActionMailerも｢地味な窓際おじさん｣といった風情で鎮座しておられますね｡

いまひとつ注目されないこの古株おじさんを､愛と尊敬を持って観察してみましょう。

動きを観察する

このActionMailerおじさん､実はかなりミステリアスな技を持っています｡

さっそく適当にSampleMailerクラスを作ってみましょう｡

# app/mailers/sample_mailer

class SampleMailer < ActionMailer::Base

  def hello(user) # emailを持つUserモデルを用意しておく
    @user = user
    mail(from: 'xxx@example.com' ,to: user.email, subject: "Hello")
  end
end

ここにあるように､ActionMailer::Baseを継承したSampleMailerクラスに#helloメソッドを書くだけ｡簡単ですね｡

対応するビューもつくっておきます｡

# app/views/sample_mailer/hello.text.erb

<%= "Hello #{@user.nickname}" %>
This is a test mail.

すると、簡単にメールを作成できます。

pry(main)> user = User.first # 適当なUserオブジェクトを入れておく
pry(main)> mail = SampleMailer.hello(user)
[INFO ]   Rendering sample_mailer/hello.text.erb
[INFO ]   Rendered sample_mailer/hello.text.erb (1.8ms)
=> #<Mail::Message:70193536029860, Multipart: false, Headers: <From: xxxxx@example.com>, <To: yyyyy@example.com>, <Subject: Hello>, <Mime-Version: 1.0>, <Content-Type: text/plain>>

まあ、ここまでは普通です・・よね。

いやいや。

メソッド違い？

先ほどSampleMailerクラスに定義したのはインスタンスメソッドでした｡

しかしSampleMailer.helloで呼ばれるのは､SampleMailerのクラスメソッドのはずです｡

おかしいと思いませんか？

試しに､似たような使い方をするコントローラーを見てみましょうか｡

pry(main)> UsersController.instance_methods(false) # UsersController#showを定義
=> [:show]

pry(main)> UsersController.show # エラー
NoMethodError: undefined method `show' for UsersController:Class

当然エラーですw
なぜメールだけはクラスメソッドで呼ぶ（呼べる）のでしょう？

さらにもうひとつ

helloメソッドはActionMailer::MessageDeliveryインスタンスを産み落とします｡

pry(main)> mail.class
=> ActionMailer::MessageDelivery

これはおそらく､先程書いたメソッドの最後にある#mailメソッドが､テンプレートhello.text.erbをベースに作成したメールオブジェクトを作り出しているものと思われます｡

試しに､｢まったく何もしないメソッド｣を定義してみましょうか｡

class SampleMailer < ActionMailer::Base
  def nop
  end
end

呼び出してみます｡

pry(main)> empty_mail = SampleMailer.nop
pry(main)> empty_mail.class
=> ActionMailer::MessageDelivery

あれ･･･さっきと同じクラスのオブジェクトだ｡
中で何もしてないのになぜ返ってくるの？

ちなみに､あえてインスタンスメソッドとして#nopを呼んでみると

pry(main)> empty_mail2 = SampleMailer.new.nop
pry(main)> empty_mail2
=> nil

期待通りにnilが帰ります｡

ねえ､おじさん！？
私のメールに何をしてるの？

ActionMailerマジック

おじさんの真の姿は黒魔術に守られていて､pryの力を持ってしてもなかなか正体が見えてきません｡

というわけで、ソースコードから解読していきましょう｡

まずSampleMailerのベースクラスであるActionMailer::Baseの実装を見てみます｡
我々が叩いたのはクラスメソッドのはず､ですよね｡

module ActionMailer

  class Base < AbstractController::Base

    # モジュールのインクルード､クラス変数の宣言など

    class << self

      # snip

      def method_missing(method_name, *args)
        if action_methods.include?(method_name.to_s)
          MessageDelivery.new(self, method_name, *args)
        else
          super
        end
      end

      def respond_to_missing?(method, include_all = false)
        action_methods.include?(method.to_s) || super
      end
     end

   # snip

おまえかーーー!!

いきなりダークそうなやつが潜んでいました｡

見ての通り､メソッド名method_nameが､action_methods内に定義されていれば､ActionMailer::MessageDeliveryをnewして返しています｡¹

継承元AbstractController::Baseに定義されているaction_methodsは､SampleMailerに生えているpublicなインスタンスメソッドをまとめてSetに入れて戻してくれます｡ ² ³

つまり今回のケースだと､ないはずのクラスメソッドを呼び出した時に､"nop"､"hello"という文字列のいずれかと一致していたら､ActionMailer::MessageDeliveryインスタンスが戻ってくるという仕組みです。

pry(main)> SampleMailer.action_methods
=> #<Set: {"nop", "hello"}>

MessageDelivery.new(self, method_name, *args)の引数部分については（例えばSampleMailer.helloが呼ばれたとすると）、こんな感じになるはずです。

  # self        ...  SampleMailer
  # method_name ...  :hello
  # *args       ...  user (Userインスタンス)

さらなるミステリー

これで｢クラスメソッドを叩いたらインスタンスメソッドが呼ばれる｣｢何も書いていなくてもActionMailer::MessageDeliveryオブジェクトが返ってくる｣という理由が理解できました｡

しかし､なんでそんなややこしいことをしているのか？

それでは、この後の動きを詳しく追いかけてみましょう｡
先ほどの処理の最後の方で、ActionMailer::MessageDelivery.newをしていましたよね。

module ActionMailer
  class MessageDelivery < Delegator
    def initialize(mailer_class, action, *args) #:nodoc:
      @mailer_class, @action, @args = mailer_class, action, args
      @processed_mailer = nil
      @mail_message = nil
    end
    # snip

なんと､ただ渡された中身をインスタンス変数に持たせるだけです｡

処理はここまで｡

・・・

・・・・？

いやいやいやいやちょっと待って

pry(main)> mail = SampleMailer.hello(user)
[INFO ]   Rendering sample_mailer/hello.text.erb
[INFO ]   Rendered sample_mailer/hello.text.erb (1.8ms)

ログ上にはテンプレートをレンダリングしたというが形跡がしっかり残っていましたよね？

おじさん・・・まだ裏で何かやってますね。

おじさんの闇の衣

実はここで一度行き詰まっていたのですが､ヒントはDelegatorにありました｡

  class MessageDelivery < Delegator # おじさんがまとってる闇の衣

    # snip

    def __getobj__ #:nodoc:
      @mail_message ||= processed_mailer.message
    end

Delegatorとはその名の通り､rubyで委譲を行うために用意された方法の一つ｡

ちょくちょく見かけるfowardableとは違い､委譲先を動的に設定できるというすごい裏技です｡

上の例では __get_obj__が委譲先を指定している部分にあたります｡これのおかげでActionMailer::MessageDeliveryがnewされたタイミングで､自身の持たないメソッドは､processed_mailer.messageで表されるオブジェクトに委譲する、という設定がされます。

この__getobj__が初期化のタイミングで走るため、processed_mailer.messageが評価される ことになります｡

(newした後に続きがあった！！)

module ActionMailer
  class MessageDelivery < Delegator

    # snip

    private
      def processed_mailer
        @processed_mailer ||= @mailer_class.new.tap do |mailer|
          mailer.process @action, *@args
        end
      end

      # snip

先ほどの例で言うと､SampleMailerをnewした上で､そのインスタンスに対してprocess(user)を叩きます。

ここで親クラスActionMailer::Baseの#initializeと#processが順次よばれます。

    def initialize
      super()
      @_mail_was_called = false
      @_message = Mail.new
    end

    def process(method_name, *args)
      payload = {
        mailer: self.class.name,
        action: method_name,
        args: args
      }

      ActiveSupport::Notifications.instrument("process.action_mailer", payload) do
        super
        @_message = NullMail.new unless @_mail_was_called
      end
    end

newの方は単純で､Mail::Messageインスタンス⁴を作成して@_messageという内部変数⁵に持たせます｡このMailとは､rubyのメールライブラリで､これが配信作業を支えています。

つまりActionMailerおじさんは直接送信をさばいているわけではなく､実務をMailに丸投げしています。

一方processはsuperのところで、AbstractControllerに定義された#processを呼び出し､それは最終的に#process_actionに渡されます｡

module AbstractController
  class Base
     #snip

     private

     def process_action(method_name, *args)
        send_action(method_name, *args)
     end

     alias send_action send

要はsendです｡レシーバselfはSampleMailerでしたね。

ということは、ここで初めて､インスタンスメソッドSampleMailer#hello(user)が実行されたことになります!!

ついに･･ついに見つけたどー＼(^o^)／

メールはどこでレンダーされているのか

処理の流れがつかめてめでたしめでたし････

しかし、まだテンプレートapp/views/sample_mailer/hello.text.erbはいったいどこでレンダーされているのか､という疑問が解決していません｡

結論から言うと、最初にMailerのアクション内に書いていたmailメソッドが､ここで初めて活躍するのです｡(直前でSampleMailer#helloがsendされたので､そのままよばれますね)

実装は､ActionMailer::Base#mailの中にあります｡

    def mail(headers = {}, &block)
      return message if @_mail_was_called && headers.blank? && !block
      # （中略）　headerの中身を作成

      wrap_delivery_behavior!(headers[:delivery_method], headers[:delivery_method_options])

      assign_headers_to_message(message, headers)
      # （中略）　メッセージを取り出す（レンダリングはココ！！）
      @_mail_was_called = true
      # （中略）　multipartメールの組み立てなど
      message
    end

・・・ついに、ついに発見しました！

ここで先ほど作成したMail::Messageインスタンスに様々な要素を突っ込むことで、メールを作成しています｡⁶

メール送信はどうなっているのか

さて、ここでもう一つ。

このメソッドはメールをレンダーするだけではなく、wrap_delivery_behavior!というメソッドによって、メールに配送手段を与えます｡

Production環境以外をletter openerにしたり、ステージング用のメーラーを設定することがありますが、この仕組みによって最終的な配送手段を切り替えることができています。

ActionMailer::DeliveryMethodsというConcernモジュールをみてみると・・

module ActionMailer
  module DeliveryMethods
    extend ActiveSupport::Concern

    included do
      # snip

      def wrap_delivery_behavior(mail, method = nil, options = nil)
        method ||= delivery_method
        mail.delivery_handler = self

        case method
        # snip

        when Symbol # ここで配信メソッドを与えている
          if klass = delivery_methods[method]
            mail.delivery_method(klass, (send(:"#{method}_settings") || {}).merge(options || {}))

        # snip
        end

        mail.perform_deliveries    = perform_deliveries
        mail.raise_delivery_errors = raise_delivery_errors
      end
    end

    def wrap_delivery_behavior!(*args) # このまま上のクラスメソッドを呼び出す
      self.class.wrap_delivery_behavior(message, *args)
    end
  end

どうやら前半のcase文で行われていることが核心のようです。

つまり、実際に配信を担当する機能を持ったクラスを取り出してMail#delivery_methodに渡す。（ActionMailerのデフォルトではMail::SMTPクラスが渡されています。）この時、オプション類も一緒に渡します。

Mail::Messageの実装を追いかけると、

module Mail
  class Message
    def delivery_method(method = nil, settings = {})
      unless method
        @delivery_method
      else
        @delivery_method = Configuration.instance.lookup_delivery_method(method).new(settings)
      end
    end

ここでConfiguration.instance.lookup_delivery_methodというシングルトンメソッドは、デフォルト設定された配信手段以外は、与えられたクラスをそのまま戻します。

つまりMail::Messageオブジェクトは、渡されたクラスを（一緒に渡されたオプションを使って）初期化し、作成されたオブジェクトを@develiry_methodに格納します。

なお、この配送設定を行うにはいくつか方法がありますが⁷、一般的にはconfig/environment/以下の設定ファイル内で

  config.action_mailer.delivery_method = :hogemail # このシンボルに対応するクラスがnewされる
  config.action_mailer.hogemail_settings = { # newする際に渡されるオプション
    domain:  'oreore.jp'
    something: :something
  }

のように行っているのがそれにあたります⁸

そう、いつも何気なく設定していたアレは、ここのためにあったのですね。

実際の配信

さて、最終的な配信ですが、これは先ほどnewされた、配信手段を提供するオブジェクト@delivery_methodが持っている#deliver!というメソッドが呼ばれます。

逆に言えば、#deliver!というインスタンスメソッドを持つクラスであれば、どんなものでも配信を請け負うことが可能なんですね。⁹

ついでに言うと、このdeliverの前後にはinterceptorやobserverといったコールバックを設定することが可能です。これを利用して例えば、ステージング環境からのメールを特定の宛先に変更してしまう、なんていう使い方もできるのですね。

ともあれ、ようやくメール配信という仕事の全容が見えました。

まとめ

かなり話が複雑なので、ここまでの流れをまとめてみたいと思います。

1. クラスメソッドSampleMailer.hello(user)が叩かれた時

ActionMailer::BaseがActionMailer::Deliveryインスタンスを作成して返す
ActionMailer::DeliveryインスタンスはSampleMailerインスタンスを作成し、SampleMailer#process(:hello, user)を実行
ActionMailer::Deliveryインスタンスは、SampleMailerが内部で作成するMail::Messageを委譲先に設定

2. SampleMailer#process(:hello, user)で起こること

SampleMailer#hello(user)が実行される。mailメソッドが使われている場合、ActionMailer::Base#mailが呼ばれる。
mailメソッドは、ActionMailer::Baseが持つ様々なメソッドを利用する。
まず適切なテンプレートを探してレンダーし、その内容を、引数にもたせた値やconfigと一緒に、Mail::Messageオブジェクトに設定。
つぎにMail::Messageに対して、実際の配信を担うdelivery agentクラスを設定する。このクラスはすぐにnewされ、実際の配信時に#deliver!メソッドが叩かれる。

3. メール送信を行う

ActionMailer#deliver_now(later)は、Mail::Messageの#deliverメソッドを呼ぶ
Mail::Messageは、(２)で設定されたdelivery agentオブジェクトに対して、#deliver!メソッドを実行する。delivery agentにMail::Messageオブジェクトが渡される。
agentがMail::Messageオブジェクトを実際に発送する

とまあこんな感じでしょうか。

それにしてもややこしい😮

ActionMailerは自分で配送作業しているわけではなく、要件ごとに発注先を組み合わせて、複雑な配送業務をそつなく回すデキるおじさんだったのですね。

遊んでみる

ここまでわかったmailerの仕組みをつかえば、たとえばメールの内容を送信する代わりにslackに流すお手製エージェントが作れそうです。

というわけで、本番環境ではない場合に限り、全ての送信メールを横取りして、代わりにslackの指定チャネルに送信してくれる機能のデモをつくってみした。

仮に「会員登録の際にお知らせメールを自動配信する雑アプリ」をつくって、その中で動かしています。

メールオブジェクトから内容を抜き出してスラックの指定チャネルに投げる、というSlackMailerエージェントを作成。
次に#mailメソッドをApplicationMailerクラスでいったん上書きします。そこで条件に応じた適切なdelivery_methodオプションをヘッダーに指定した上で、superします。（以降は本来の動作になる）
ApplicationMailerを継承する全てのMailerでこの機能が使えます。もちろんActionMailer::Baseから直接継承したMailerをつくると、普通通りメールを出すことも可能。

デモ機能はこちらに置きました。

記事が長くなってしまったので、またニーズがあれば解説記事など書いてみたいと思います。

環境

環境は以下の通りです。

ruby 2.3.1
rails 5.1.4
railsリポジトリは２０１７/１２月時点（一部を抜粋、コメントなど割愛しています）

エンジニア歴１年に満たない初心者の読み解きなので、おかしな点があればビシバシとご指摘いただければありがたいです！

あとがき

やろうと思ったきっかけ

Webサービス開発現場で､ユーザーにメールを配信するため､mailgunというAPIベースのメールサービスを利用しています｡

ラッパーとして最近アップデート状況がよくなっているmailgun-ruby（公式gem）を試用していたところ､テキストメールがコケるという謎の現象に見舞われました｡¹⁰

しかたなく修正PRをたてたのですが¹¹､状況を再現するテストケースを立てる際に「そもそもメール送信がどういう実装になっているのかがわからなすぎてテストがかけない」という困った状況になったことをきっかけに調べ始めました。

マニアックな知識ですが、どこかの誰かの役に立てば幸いです^^

定義されていなければ通常通りに継承チェーンを上がっていき､NoMethodErrorに行き着く ↩
正確には､レシーバSampleMailerの継承チェーン中でもっとも末端側の｢abstractクラスであるActionMailer::Baseをのぞいた子孫側 にある全クラス｣に定義されているpublicなインスタンスメソッドの名前の集合｡つまり､このSampleMailerがHogeMailer < ActionMailer::Baseを継承している場合は､「HogeMailerのpublicインスタンスメソッドも含めた集合」が戻る｡ ↩
AbstractControllerがどういう存在か､そもそもabstractという概念は何を意図したものなのか､というところがまた面白かったのですが､話がそれるのでこちらを参照｡ ↩
一見Mailインスタンスに見えるが、Mail.newは最終的に[Mail::Message.newを呼ぶため]、Mail::Messageインスタンスが戻る。（https://github.com/mikel/mail/blob/61f0f01deaaae4bddb40932179bb5e18ce518f76/lib/mail/mail.rb#L50） ↩
実態はattr_internalなので､アクセサ名はmessage､変数名は@_messageという形になっている｡ ↩
mailメソッドを全く使わない#nopのようなメソッドだと､当然レンダーはされないのですが､代わりにNullMailインスタンスが@_massageに入ります｡ここで、#mailが呼ばれたかどうかを判定しているのが@_mail_was_calledフラグにあたるようです。 ↩
mailメソッドに、delivery_methodオプションを持たせることでmethodを指定することも可能。つまり動的に配信メーラーを切り替えることもできるようになっています。 ↩
この場合、シンボル:hogemailに対応する配信用のクラスを設定する必要があるが、そのためにActionMailer::Base.add_develiry_methodが利用できる。 ↩
例えば有名なletter_openerは自身が持つ#develer!メソッドの中で送信メールオブジェクトを受け取って表示しています。 ↩
テキストメール(またはhtmlメール）を､おかしな方法でmultipart化してしまっていることが判明｡ ↩
修正が取り入れられたので、次のバージョン1.1.9で直る予定 ↩

ActionMailerは何をしているのか

テーマ