【一休 × bitFlyer】C#を使ったサービス開発の裏側 に参加しました！
SendGridエバンジェリストの中井(@nakansuke)です。
先日【一休 × bitFlyer】C#を使ったサービス開発の裏側というイベントに参加しました。宿泊、レストラン予約サービスを展開している一休さんと、ビットコイン、ブロックチェーンで有名なbitFlyerさんがなぜ一緒に？と思われるかもしれませんが、この2社に共通しているのがC#を使用してサービス開発をしているという点です。
今回が2回目の開催だそうですが、なんと一休さんのセッション内容がSendGridに移行した話ということで、これは行かねば！と参加して最前列で聴いてきました。
このようにSendGridへの移行の経緯を非常に細かくまとめていただいていますので内容はスライドを見ていただくとして、特に良いなと思った点をご紹介します。
現状や課題を整理し移行計画を立てた
そんなの当たり前じゃないかと思われるかもしれませんが、SendGridはSMTPリレーサーバとしても利用できるので、SMTPサーバへの接続情報を変えて問題なくてそのままGoということはよくあります。サーバが故障した際の緊急事態であればそれでもよいかもしれませんが、基本的に長く使うことになるものなので、移行のタイミングで潰せる問題は潰し、課題は解決しておくことをおすすめします。送信通数が多い場合や、増加が見込まれる場合は尚更です。
以下の2つは多くのお客様で該当すると思うので、ぜひ参考にしてください。
ログ確認機能を用意
サポートにメールが届いていないと問い合わせがあると、インフラ担当がサポート担当から依頼を受けてログを見て何が起きているか確認する、というケースは多いかと思います。しかしエラーメッセージやステータスコードはMTAによって異なることも多く、それを読み解くためにもノウハウが必要になります。
SendGridのEvent Webhookを使用すれば、届けたのか、バウンスしたのか、再送中なのかといった情報を蓄積可能なので、インフラ担当にお願いしなくてもサポートだけで調査できるようになります。
そもそもメール自体必要なのかどうかの見直し
今ではエラーはSlackに通知するといったことが当たり前になりましたが、一昔前は全てメール通知でした。移行元のシステムが古ければあらゆる通知がメールで飛んで来ると思います。そもそもそれをメールで送る必要があるのか、移行前に見直しをするとよいでしょう。
送信通数によって料金が決まるので無駄なコストの削減にもつながります。
移行は少しずつ様子を見ながら行なった
一休さんでは、送信量の少ないサービスから移行を始め、送信量が多いサービスも徐々に移行するという形をとられました。もちろん新しいプログラムにバグがあったり、問題発生時のリカバリが容易だというメリットもありますが、少しずつ移行することで自然とIPウォームアップの効果が得られるのがメリットとして大きいです。
SendGridはこちらで紹介しているスケジュールで進めることを推奨しています。こんなに少量からはじめるのか！？と思われる方も多いと思われますが、いきなり数百通送ってブロックされてしまった、というケースはままあります。スライド内でも紹介されていますがOffice 365宛の送信はトラブルになることが多いので要注意です。
資料の補足
1点資料の補足です。「docomo / au のバウンス率が高い」というスライドで、「5回までバウンスリストから削除する仕組みを追加」とありますが、これはdocomoとauの場合、
- ドメイン指定拒否などを設定している宛先に送信
- ハードバウンスが発生してサプレッションリストに自動追加
- 受信者が拒否設定を解除して再送リクエスト
- サプレッションリストに掲載されているから自動的に破棄(Drop)されてしまう
- 受信者のリクエストに基づいてサプレッションリストから削除（←これが面倒）
という事態になりやすいための対処です。アドレスに誤りがあるのか、フィルタリングされているのかが送信側から判定できないためのやむを得ない対処ですので、同様の対処をする場合、これらのドメインに限って実施するようお気をつけください。（本来ハードバウンスが発生した宛先に対しては再送すべきではありません）
※各キャリアの挙動については変更の可能性もありますので自身でご確認の上対処をお願いします。携帯キャリアの迷惑メール対策についてはこちらをご確認ください。
さいごに
ありがたいことに、SendGridも弊社もべた褒めしていただきました。圧倒的感謝！！
引き続きお客様に満足いただけるよう取り組んでまいりますので、今後共よろしくお願いいたします。
Happy Sending!!
