これは何

どのように技術選定してますか。よく聞かれます。SREチーム鈴木心之介です。しかし説明が難しい。難しいですが説明の助けになってほしく思い、技術選定を文書化した DesignDoc から1枚を公開してみました。

DesignDoc とは、ある程度の大きさや複雑さがあり一言で説明の難しい技術選定について、文書化したものです。これを通じて、技術選定をどのように行うか組織内に広めようとする試みです。2021年1月頃から始めています。

題材は、メール配信の冗長化をRailsで実現した

tech.andpad.co.jp

を、インフラ視点から技術選定した DesignDoc です。このメール配信SaaSの選定は2019年末頃に実施したもので、DesignDoc の取り組みを始めていなかった頃でした。時が経ち、ソースコードやSaaSの構成からは意図を読むことが難しく「なんじゃこれ」って質問を頂くことが幾度かあり、 2021年3月頃に当時の技術選定を社内向けにDesignDoc の形式で文書化したものです。

↓ ここから DesignDoc です。

プロダクトオーナー・問い合わせ先

SREチーム鈴木心之介

本稿では「将来このような選定で進めるぞ」ではなく「過去にこのような選定を行った」というのを記述します。

Goal

長期的に安定して、ANDPADシステムからANDPADユーザーに、電子メールによる連絡、通知を実現します。ユーザーがメール受信できないものについて、説明できるようにします。

Target

ANDPAD本体のメール配信機能を経由するメールすべて
- ANDPAD受発注など、ANDPAD本体のメール配信機能に便乗しているものも含む
ANDPADのシステムからメールを受け取るANDPADのユーザー
ANDPADのシステムからメールを受け取るANDPADのユーザーをサポートするANDPAD運営メンバー
ANDPAD本体のエンジニア

What

Amazon SES をやめて、他のメール配信SaaSに移行することで、安定したメール配信を実現します。

Profit

Background に挙げた、以下についての直接的な利点があります。

Amazon SES チームから苦情レート高いの是正しないと止めるぞ通告を受けた
- メール配信SaaS自体が、バウンスや苦情に関するハンドリングをしてくれる
- Amazon SES チームに提示されたxxx万通のレビュー期間が終了する前に、移行できる
ANDPAD本体からCSチーム宛にメールが届かない事象が急激に悪化した
- CSチームのメーリングリストを、バウンスや苦情のホワイトリストに登録できる。
  - 誰かがカッとなってバウンスや苦情をしても、ホワイトリストにあれば強制的に送信してくれる

加えて以下の利点があります。

ANDPADからのメールを受信できなかった方々に対して、これまでより精度の高い案内できる可能性がある
- メール配信SaaSに備え付けのログビューワで、メール配信SaaSから宛先メールサーバー間のログを参照できる
  - これまではAmazon SESからのSNSからの通知のハンドリングに問題があり、情報がなんも残ってなく、何も調査できなかった
固定IPを使っている限りは、Amazon SESのように「3週間後に止めるぞ」などと言い出してこない
- 固定IPのレビュテーション維持は我々の責務なので

今回は Detailed Design のとおり Mailgun を主系としましたが、Amazon SES 以外のメール配信SaaSは、だいたいどれでも上記の機能を備えています。

Not Goal

ANDPAD本体以外は対象外とした
- 移行を実施した当時は、メール配信を行っているのはANDPAD本体だけだった

Background

Amazon SES チームから苦情レート高いの是正しないと止めるぞ通告を受けた

くそいそがしい年の瀬 2019/11/27 に、Amazon SESチームから、苦情レート高いの是正しないと止めるぞ通告を受けました。対応したことある方は血の気が引くやつです。

Amazon SES Complaint Review Period for AWS Account xxxxxxxxxxxx

雑に要約すると「今から以降のxxx万通に対する苦情の比率を眺めて、Amazon SESチームの次の動きを決めるからな!!」という通告です。xxx万通を、当時の1日のメール配信量で割ると、3週間くらいでした。(たしかそんな)

不可解だったのは、メール配信量が増えるような何か新機能を出していたわけでもなく、新規ANDPADクライアントもそれまでどおりに増えており、にもかかわらず苦情レートがグッと上がっていました。このことから、Amazon SES内部実装で何か変化があり、バウンスや苦情と判断する基準が厳しくなったのだと推測しました。そして今後それが緩くなる可能性はなく、むしろAmazon SES側の気分で厳しくなることが推測できました。

「ままAWSさん落ちついてくださいよ誠実に対応いたしてますんで」的なメールを打ち返したものの、3週間で劇的に改善できる気配はなく、3週間というのも送信量によっては前倒しになる可能性もありました。

ANDPAD本体からCSチーム宛にメールが届かない事象が急激に悪化した

ANDPAD本体からユーザーに送信しているメールのうち、お問合せページからのメールについては、ユーザー宛てに送信し、加えてCSチームのメーリングリストにも送信しています。2019年11月28日に、CSチームが1通もメールを受けとれない事象を観測したことで異変に気付き、CSから開発本部に依頼され、調査したところから発覚しました。

当時CSチームは、届いたメールを起点にお問合せの対処をしていたそうで、メールが受け取れないのが、問合せの対応漏れに直結するため、死活問題でした。

Overview

変更前

f:id:sasasin_net:20211026141020p:plain — 変更前の構成

ウェブアプリの動くフロント、非同期処理のバック、定期実行処理のバッチが、Amazon SES を経由して、ANDPADユーザーにメールを送ります。Amazon SES がバウンスまたは苦情を観測した際は、SNSとSQS経由し、フロントに連絡してくれます。

変更後

f:id:sasasin_net:20211026140926p:plain — 変更後の構成

Amazon SES, SNS, SQS を廃します。

Mailgun と SendGrid 経由でメールを送ります。Mailgun と SendGrid の使い分けは、

Mailgun を主系として送信する
Mailgun が弾いたメールは SendGrid 経由で送信する
- Mailgun が弾くとは、以下の事象を指す
  - Mailgun の仕様で、メールアドレス形式がRFC準拠していない場合
  - Mailgun のAPIに投げたとき、理由はとにかく弾かれた場合

バウンスと苦情のハンドリングは、Mailgun と SendGrid に任せます。

Detailed Design

ANDPAD本体での実装

Mailgun および SendGrid を含むプルリクを参照

※ これをアプリケーションコードで実装したのが tech.andpad.co.jp です。

Mailgun のアカウント運用

本番用、開発用にそれぞれMailgunアカウントを開設します。

本番用は、以下指針に則り権限付与します。

ユーザー管理業務を実施するメンバーに、Admin権限
領収書などの財務証跡を収集するメンバーに、Billing権限
ユーザー問合せを受けてログ調査などをするメンバーに、Support権限

開発用は、以下指針に則り権限付与します。

ユーザー管理業務を実施するメンバーに、Admin権限
領収書などの財務証跡を収集するメンバーに、Billing権限
エンジニアに、 Developer 権限

Mailgun で権限ごとにできること/できないことは、公式文書を参照。

User Manual — Mailgun API documentation
https://documentation.mailgun.com/en/latest/user_manual.html#managing-user-roles

SendGrid のアカウント運用

送信メール数が極めて微量であることから、 Essentials プランにてアカウントを開設します。

価格 | SendGrid
https://sendgrid.kke.co.jp/plan/

Essentials プランでは、管理者ユーザー1名と、追加で権限を絞った1名のみを使えます。これを受けて以下のとおりとしました。

SendGrid にログインできる人数自体を絞る。
- ユーザー管理業務を実施するメンバー
- ユーザー問合せを受けてログ調査などをするメンバー
- 領収書などの財務証跡を収集するメンバー

パスワードはBitwardenで管理しており、DMで共有されるという前時代的なことはやっておりません。そこはまた別途違うDesignDocがあり、テックブログが公開されるでしょう。

過去に検討された事案

Amazon SES を使い続ける。バウンス & 苦情を正しくハンドリングする

初手として検討したのは当然ですがコレ。引越し大変ですからね。

Amazon SES は、

メールの送信やってくれる
メール配信に関する統計をCloudWatchで見えるようにしてくれる
メールを宛先メールサーバーに投げた結果を、SNS/SQSに投げ込んでくれる
バウンスレート、苦情レートがAmazon SESチームの定めたレートを越えると容赦なく停止してくる

ものです。厄介なことに、

メールを宛先メールサーバーに投げた結果を、SNS/SQSに投げ込んでくれる
バウンスレート、苦情レートがAmazon SESチームの定めたレートを越えると容赦なく停止してくる

この間の部分に「SNS/SQSから受け取って、バウンスや苦情だったら、次からAmazon SESに投げつけない」機構を、ANDPAD側に実装する必要があったのですが、そういったものは、少なくともAmazon SESチームを納得させられるような品質ではありませんでした。

Amazon SESはバウンスや苦情のレートを厳しく取締っているようで、2019年11月下旬の事象は、一過性のものではなく、今後も突如として基準が変化し、その都度ANDPADのメール配信機構が振り回されることが、強く思い浮かびました。

これらを勘案し、3週間できちんとしたバウンス処理の仕組みを構築するのは極めて困難だし、Amazon SES を使い続けるのも厳しいと判断しました。

Amazon SES やめて EC2内に Postfix を立てる

Amazon SES をやめて、自前で Postfix を立てて送信する案です。ANDPAD本体では、「フロント」「バック」「バッチ」の他に「メール」が増えるイメージです。「技術的には可能です」というやつで、ElasticIPなど確保して、自分でウォームアップして、1台で足りないなら複数台にスケールアウトなどなど頑張ろうという話ですね。これのために何人のSREが必要ですかと。あまり深く考えるまでもなく却下しました。

Amazon SES から Mailgun 以外のメール配信SaaSに引っ越す

メールといえばSendGridじゃないすか最大手ですし。実際SendGridを主系とすることも選択肢として検討しました。

しかしANDPADの送信量で、まともな金額で送信しようとすると、PRO以上のプランで契約する必要があります。PROプランは固定IPが必須で、共有IPを利用できません。固定IPは数週間以上かけてウォームアップが必要です。Amazon SESからはxxx万通でレビューするからなという通告を受けており、長くて3週間程度しか時間がありません。目先の引っ越し先として適してないと判断しました。

一方でMailgunは、どのプランでも固定IPの利用は必須ではなく(強く推奨はされる)、共有IPを利用できます。加えてしんのすけが過去にMailgunを本番環境で利用した経験があって、短期間でセットアップできる勘所があったのも、決め手のひとつです。

主系を SendGrid に乗り換える

2021年時点では Amazon SES から引っ越して長く、Mailgunから追い出される気配もない。SendGridを主系にしてもいいのではないか、という質問を受けることがあります。いくつかの理由で、今後も Mailgun を主系として利用しようと考えています。

いまMailgunでは固定IPに乗り換えて、ちょいちょい届かねえぞって連絡を受けることはあるものの、全体としては安定して送信できている。という所感です。

現状からSendGridに全面移行できますが、うーん、これ頑張るほど困ってないよなあ、という。

SendGridで契約プランを変更して、固定IPをウォームアップする必要がある
たとえば、大丈夫そうな何十社とかドメイン単位とかで、Mailgun経由せず、SendGridで送るような仕組みを整備して、ウォームアップする必要がある

Mailgun と SendGrid を今の形で使っていることで、障害に強くなっているのは大きなメリットです。

Mailgunが死んでも、SendGridに全部送信させることができる
SendGridが死んでも、Sidekiqがプールしてくれるので、1日くらいは大丈夫

Mailgun で固定IPが十分に温まっていることから、一部の「海外のIPからのメールは弾いてます」のようなANDPADユーザーに、MailgunのこのIPアドレスだけホワイトリストに入れて受けとってくださいとお願いしていたりします。このようなコミュニケーションを行った全ANDPADユーザーに、SendGridに全面移行するのでIPアドレス変わります的なお願いを再度やる必要があります。なかなか厳しい。