一休.com がどのように SendGrid と仲良く付き合っているか

1. 一休.com がどのように SendGrid と付き合っているか 2018.5.29 Send With Confidence Tour 仲良く
2. 自己紹介 Tatsuro Shibamura (@shibayan) 一休.com エンジニア Microsoft MVP
3. 一休.com について • 厳選ホテル・レストラン専門の予約サイト
4. 一休.com における SendGrid の利用 • 基本的にトランザクションメール • 新規会員登録など • ホテルやレストランのユーザー向け予約完了 • 施設・店舗向け予約追加 • 今後はマーケティングメールも
5. メールは非常に重要 • 送信に失敗すると何が起こるか • 予約完了のメールが届かないため、予約が取れていないと考える ＿人人人人人人人人人＿ ＞ 重複予約が発生 ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y￣
6. SendGrid の利用前後 • オンプレの SMTP サーバーを自前で管理 • とても高かったらしい • 一休.com の AWS 移行のタイミングで SendGrid に全て移行 • メール配信だけオンプレに残すとかありえない • SMTP から REST API へ移行 • 憎き .NET と ISO-2022-JP の組み合わせ問題も解消
7. メールを送信している仕組み
8. Event Webhook で状態をトラッキング
9. 設計時に考慮した点 • SendGrid の API がエラーを返した場合のリトライ • Elastic Beanstalk + SQS を使うことで自動的に実行させるように • メール配信結果の保存 • DynamoDB と Event Webhook を使い 1 通単位でトラッキング • スケーラビリティと信頼性 • 基本的には Elastic Beanstalk と SQS の信頼性に乗っかる形
10. 学びの多い 2017 年の SendGrid 障害 • メール送信 API のエラーレートが上がる • 送信完了までに遅延が発生する（まだマシな例） • デッドレターキュー入りする（完全に届かない） • 運用を行い半年、ノートラブルで稼働していたので油断 • 原因の特定にかなりの時間を要してしまった • 大規模障害時のリカバリーは手動で行うしかなかった • 送信ログは全て DynamoDB に保存されているのが救いだった
11. 教訓 : 失敗を前提に設計する • Elastic Beanstalk or SendGrid の問題切り分けが行えなかった • → SendGrid API エラー時のレスポンスを詳細にログへ • デッドレターキューからのリカバリ方法が手動 • → 管理画面から一括で未送信メールのリカバリを行えるように改善 • SendGrid 障害時のみに発生するバグもあった • → ワーカーの修正後、リカバリを行えるように管理画面も改善
12. 教訓 : モニタリングを強化する • 障害時にメールの遅延具合や影響範囲を確認出来なかった • → Datadog で Beanstalk Worker のモニタリング強化 • → Datadog に SQS のメトリクスを流し込んでアラート設定
13. 障害を受けて改善 • 10 分以上の配信遅延が発生した場合は Slack にアラート • 遅延が発生した時点で、何かしらの問題が発生していることが分かる • 各事業部・CS チームと連携して対応 • 管理画面から送信できなかったメールを確認できるように • DynamoDB にクエリを投げるだけ、GSI も専用に用意 • 未送信メールは簡単にリカバリ可能に
14. 最近の状況 • 障害が発生しても、検知とリカバリの仕組みを用意済み • 運用ドキュメントを作成して共有 • 運用の分散 • 各事業部から担当者を一人任命、属人化を避ける • SendGrid の障害が発生していないため極めて平和 • 感謝しかない
15. 参考 • 新メール配信基盤への移行 • https://speakerdeck.com/minato128/ikyu-mail-platform • メール配信基盤のモニタリングと障害リカバリーについて • http://user-first.ikyu.co.jp/entry/2017/12/05/000000