この記事は一休.comアドベントカレンダー2017の5日目です。

宿泊事業部 Platformチーム*1の id:minato128 です。今年一休ではクラウド移行に伴い、メール配信の仕組みを大きく変えました。詳しくは一休✕bitFlyer C#をつかったサービス開発の裏側でお話したスライドがこちらにありますので、興味のある方はご覧ください。

新メール配信基盤への移行 /ikyu-mail-platform // Speaker Deck

さて、宿泊予約やレストラン予約のサービスを提供している一休では、メールをユーザーに届けることはとても大切です。特に予約完了メールが届かなかった場合、（メール以外の確認方法もあるとはいえ）予約が取れたことに気づかず、最悪ユーザーが２重に予約をしてしまう可能性もあります。*2 そこでメールを届けるために、どのようにメール配信基盤のモニタリングや障害が起きたときのリカバリーを行っているかを紹介したいと思います。

f:id:minato128:20171204145554p:plain

前提として

現在このようにメール配信を行っています。また、日次のトランザクションメールは 13~15万通ほどです。

各アプリケーションから Cloud Queue (SQS) に Message (JSON) を Enqueue する
Worker (Elastic Beanstalk) で Message を処理して SendGrid Web API で送信する
- 成功したら Message をメールログ(DynamoDB) に保存する
- n 回エラーになったら Dead Letter Queue (以下 DLQ とします) に入るように設定
SendGrid Event Webhook を AWS Lambda で受けてメールログに送信ステータスを反映する

f:id:minato128:20171201172336p:plain

モニタリング

このようなアラートを設定しています。大抵の場合、Datadog のアラートで何かが起きていることがわかり、Logentries のエラーログで原因がわかります。

Datadog
- Worker の状態異常アラート
- Queue の Message 遅延アラート
- DLQ の存在アラート
Logentries
- Worker のアプリケーションエラーアラート

f:id:minato128:20171201172621p:plain

f:id:minato128:20171201172611p:plain

障害リカバリー

SendGrid だけでなくアプリのバグや AWS など障害によってメールが送れなかったとき、復旧時にメールを再送してあげる必要があるので、このような仕組みを用意しています。

Worker で Message が処理できず、DLQ に入ってしまったとき

これはそもそも SendGrid まで届いていないケースで、DLQ から送信用の Queue へ Message を移せるようにしています。Message の移動だけなのでわざわざ用意するほどでもないう気もしますが、障害はいつ起こるかわからないし誰が対応するかもわからないので簡単にできるようにしておいたほうがいいでしょう。

メール DLQ 管理画面

f:id:minato128:20171201172637p:plain