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

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

73c174b34dafaea64f2824eb008a6559?s=128

Tatsuro Shibamura

June 06, 2018
Tweet

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