これ結論から言ってしまえばメール送信をAmazon SESはいけてないけど、SendGridやMailGunも何があるかたまったものじゃないので、送信手段を分散させておこう…ってことにほかならないのではないか？と思った次第↓
Amazon SESとかいうのがあるならそれにするか…て感じにすると何やらめんどうだったので、SendGridとMailGunのいずれか2択で選択することに相成ったことがあったが、この事例「バウンスしすぎて Amazon SES から追放された俺たちは Mailgun と SendGrid に国を作ることにした – ANDPAD Tech Blog」を見る限り直感的な判断は間違っていなかったんだなぁという気がしている。
以下はメモ書き。
※すべてはアマゾン様のお気の召すままに処遇されるらしい。まあ、アマゾン様が言う事なら絶対です！という切り抜け方もあるのかもしれないけれど、ブラックボックスだからそれでいい…というのは「違う」よなあ。自分が事業者で技術者に依頼する側で「アマゾン様が言っている」とか言われたら「じゃあ他の神様なり自前の手段をとってくださいよ」と言いたくなるだろうから…クライアント次第じゃなくて原因究明とか運用責任的な部分をきちんと深く考えていかないといけない。なんだかんだ言ってメールはWebサービスにとってまだまだ「命の綱」で非常に重要なユーザとシステムをつなぐためのもの。
※CSがメールを一切受信できないとかシステムの信用に関わる問題
※SRE…擁護として初めて知った。サイト信頼性エンジニアリング と言うらしい。人間としての役割だとサイト信頼性エンジニア…「SRE とは」SLOとかSLIとかいろいろありすぎて謎すぎ。
※SREはDevOpsに対比される考え方らしい。
※SREとしての役割はGoogle社は開発作業に対して50%以下に抑えられることが推奨されているらしい。
コメント