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

Transcript

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