こんにちは、VASILYバックエンドエンジニアの塩崎です。 社会人2年目にも突入し、優秀な後輩たちに抜かされないかと日々ひやひやしています。
さて、今回は1ヶ月程前に完了した、メールサーバーのSendGrid移行について紹介したいと思います。
移行のきっかけ
そもそも、なぜVASILYでメール配信の自社管理をやめてクラウドサービスであるSendGridに移行する必要がでたのでしょうか？ 以前から使用していたpostfixサーバーではなぜダメだったのでしょうか？ それは、大量のメールマガジンを遅延なく配信する必要が生じたからです。
昨年の11月頃からiQONでは、ユーザーさん一人一人にオススメのアイテムを送る、リコメンドメルマガを開始しました。
それにあたり、数万人のユーザーさんに対してそれぞれ内容の少しずつ異なるメールを送る必要が出ました。
このような処理を自社管理のpostfixサーバーで行うことは非常に面倒臭い非現実的であったため、面倒な処理を肩代わりしてくれるクラウドサービスを利用することにしました。
SendGridに決めた理由
メール配信のクラウドサービスを決めるにあたって、SendGrid以外にもAmazon SES、Mandrill、MailChimpなどのサービスも比較しました。 それらと比較してSendGridが優れているポイントを紹介します。
ただメールを送るだけのサービスではない
SendGridはメールを送るだけのサービスではありません。メール配信に関わる機能一式を提供してくれます。 これが、ただメールを送るだけのサービスであるAmazon SESとの大きな違いです。
個人間で送り合うメールならいざ知らず、メールマガジンのような大量のメールを一斉配信することは想像している以上に困難です。 少しでも怪しいメールを送ると携帯キャリアなどのメール受信業者のブラックリストに入ってしまいます。 そのような扱いを受けないようにするためにSPFやDKIMを適切に設定する必要があります。 SendGridはこれらの認証機能を簡単に使用することができたので導入が非常に楽でした。
また、ユーザーさんのメールボックスに届いた後にユーザーさんがどのような行動をするのかも非常に重要です。
メールを開封するのかどうか、メール中のリンクをクリックするのかどうか、これらの指標はメールマーケティングを行うためには最も重要な指標です。
しかし、これらの機能を自社で作り上げるのは非常にメンドイそこそこの人月が必要です。
そのような機能をデフォルトで提供してくれて、しかも綺麗なダッシュボードにまとめてくれるのも嬉しいポイントです。
WEB APIが豊富
SendGridが提供している、ほとんどの機能をWEB APIから使うことができます。 SMTPという旧世紀のプロトコルを使うことなく、近代的な方法でメールの送信を行うことができます。
さらに送信をするためのWebAPIだけでなく、何かイベントが起こった時に特定のエントリーポイントを叩いてくれる機能もあります。 メールの到着、開封、クリックなどのイベントが起こったタイミング毎に指定したエントリーポイントを叩いてくれます。 VASILYではこの機能を利用して、メール配信のログをBigQueryに保存し、それをBIツールであるTableauで可視化しています。 このあたりについては記事の後ろのあたりで、より詳しく紹介します。
日本代理店がある
SendGridの日本代理店として構造計画研究所さんがあり、いざというときに日本語のサポートがあるのが安心でした。 また、構造計画研究所さんではSendGridの初心者向けセミナーや、個別相談説明会、メールマーケティングに関するブログなどの活動を精力的に行っており、ただ本国に取り継ぐだけでなく、メール配信のプロがきちんと日本にもいるという実感が持てました。
注) 色々とSendGrid万歳な紹介をしていますが、弊社はSendGridの回し者ではありません。 使い方によっては他のメール配信サービスを使ったほうがいい場合もあります。 例えば、対エンジニア向けのアラートメールなどは、アプリケーションサーバーに同居しているsendmailで送信を行っています。
移行するためにしたこと
アドレスリストのクリーニング
移行の本来の目的はメルマガ配信の効率化であったため、保持しているメールアドレスリストが大量配信に耐えられるものかどうかを考える必要があります。 諸所の事情により、当時のアドレスリストはダブルオプトインが確認できているかが不明だったために、バウンス率が非常に高くなってしまう恐れがありました。 そのため、SendGridに移行を行う前にアドレスリストのクリーニングを行いました。
幸いにも、シングルオプトインは当時のログから確認できたため、配信対象のユーザーに対してメルマガを試しに送信してみて、開封ログを取ることにしました。
この時はまだSendGridへの移行をしていなかったので、開封トラッキングの仕組み・開封をしてくれたユーザーさんのダブルオプトイン確認フラグを立てる仕組みを自力で作りました。車輪の再発明をしている感じしかなく、面倒くさかったです。
数回メルマガを送っても開封してくれないユーザーさんについては、潔く諦めました。
エンゲージメントの低いユーザーさんに送ってもコストの方が嵩むということに加え、ハニーポットに引っかかるのを防止する効果も期待できます。
また、バウンス率の高いメールを一気に送ることによるレピュテーションの急激な低下を防ぐために、メールを「ゆっくり」送るように、スケジューラーを設定しました。 メールアドレスリストを、主要メール受信業社数社分のリストに分け、それぞれのリストに対して一定のペースで送るようなプログラムを自力で作りました。めんどうくさかったです。
さらに、「レピュテーションは資産である」ということを常に念頭に置き、レピュテーションやブラックリストを確認する外部サービスの結果を毎朝確認し続けました。 レピュテーションを確認できるサービスについてはこちらの構造計画研究所さんのBlogが詳しくまとまっていたので参考にしました。 送信レピュテーションを確認する5つの方法
この辺りの作業については、先日のSendGrid Night #4でもLTを行いました。
メールアドレスの文字コード
SendGrid移行前はmail-iso-2022-jpを利用して、ISO-2022-JP(俗に言うJISコード)でメールの配信を行っていました。 ですが、その設定のままで送信を行うとメールの文字化けが発生してしまったため、このgemを取り除き、UTF8でメールの送信を行うようにしました。
ActionMailerの設定の修正
以下の記事を参考にして、ActionMailerが指し示すサーバーを自社管理のpostfixサーバーから、SendGridのSMTPサーバーに変更しました。 https://sendgrid.kke.co.jp/docs/Integrate/Frameworks/rubyonrails.html#Configure-ActionMailer-to-Use-SendGrid
移行結果
以上の作業を行った結果、1ヶ月程度前にメールサーバーのSendGrid移行が完全に完了しました。 作業が面倒くさそうな書き方をしていますが、ただ置き換えるだけであればActionMailerの設定を書き換えるだけですので非常にシンプルです。 ダブルオプトイン確認フラグの復旧が面倒だっただけです。
VASILYでは社内KPIをBigQueryで集計、BIツールであるTableauで可視化を行っているので、メルマガの配信結果もそれらを利用して作ってみました。 以下に示すような仕組みでSendGridのEventWebHookから飛んでくるデータを可視化しています。
その結果、このようなダッシュボードをエンジニアだけでなく、ビジネス職の人とも共有し、効果的に施策を考えることができています。
ここは改善してほしいなSendGrid
さて、ここまでSendGridを褒めちぎってきましたが、一部使いづらいと思うこともあったので紹介します。 直してくれないかなぁ・・・
予約配信した時に時刻がズレる → 解決しました
SendGridには予約配信機能があり、送信リクエストをしたタイミングと、実際に送信が行われるタイミングをずらすことができます。 メルマガではこの機能を利用し大量のメールを遅延なく配信しています。 しかし、ユーザーさんの手元に届いた時のメールのタイムスタンプが、届いたタイミングではなく送信予約をしたタイミングになってしまいます。
例えば、以下のメールはAM 11:00頃に配信予約をし、PM 9:00にユーザーさんの手元に届いたメールです。 メール中のタイムスタンプが配信予約のリクエストを投げた時刻になってしまっています。
この問題は先日のSendGrid Night #4でSr. Product Support EngineerのScott Kawai氏に質問したところによると、配信予約時にSMTPヘッダーのDateフィールドをPM 9:00に設定すれば良いということを教えていただきました。ありがとうございます。
再送するタイミング
SendGridはsoft bounceしたメールを最大で72時間再送しようと試みてくれます。 一方でパスワードリセットや、領収書などのトランザクションメールはどんな時間に届いても価値があるかと思います。
しかし、メルマガのようなマーケティングメールが深夜に届いたらユーザーさんはどのように思うでしょうか？ 深夜3時に届いたメーケティングメールで目が覚めてしまうなんて、酷い目覚めではないのかと思います。 そのため、メールによっては日中のみに再送をするような設定ができたらいいなと思います。
まとめ
SendGridを実際に使ってみて、SendGridはメールを届ける「だけ」のサービスではないということがわかりました。 メールを届けるのはもちろんのこと、その他メールに関わる色々な面倒臭い処理をまとめて引き受けてくれるサービスであるということがわかりました。
メールをただしくユーザーさんのメールボックスに届けるのが予想外に難しいことを考えると、ほとんどの場合これらの面倒くさい処理をSendGridに任せた方が得策なのではないでしょうか。
終わりに
VASILYではモダンなインフラに興味のある仲間を募集しています。 興味のある方は是非こちらからご応募ください。
