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

自己紹介 Tatsuro Shibamura (@shibayan) 一休.com エンジニア Microsoft MVP 

一休.com について • 厳選ホテル・レストラン専門の予約サイト 

一休.com における SendGrid の利用 • 基本的にトランザクションメール • 新規会員登録など • ホテルやレストランのユーザー向け予約完了 • 施設・店舗向け予約追加 • 今後はマーケティングメールも 

メールは非常に重要 • 送信に失敗すると何が起こるか • 予約完了のメールが届かないため、予約が取れていないと考える ＿人人人人人人人人人＿ ＞ 重複予約が発生 ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y￣ 

SendGrid の利用前後 • オンプレの SMTP サーバーを自前で管理 • とても高かったらしい • 一休.com の AWS 移行のタイミングで SendGrid に全て移行 • メール配信だけオンプレに残すとかありえない • SMTP から REST API へ移行 • 憎き .NET と ISO-2022-JP の組み合わせ問題も解消 

メールを送信している仕組み 

Event Webhook で状態をトラッキング 

設計時に考慮した点 • SendGrid の API がエラーを返した場合のリトライ • Elastic Beanstalk + SQS を使うことで自動的に実行させるように • メール配信結果の保存 • DynamoDB と Event Webhook を使い 1 通単位でトラッキング • スケーラビリティと信頼性 • 基本的には Elastic Beanstalk と SQS の信頼性に乗っかる形 

学びの多い 2017 年の SendGrid 障害 • メール送信 API のエラーレートが上がる • 送信完了までに遅延が発生する（まだマシな例） • デッドレターキュー入りする（完全に届かない） • 運用を行い半年、ノートラブルで稼働していたので油断 • 原因の特定にかなりの時間を要してしまった • 大規模障害時のリカバリーは手動で行うしかなかった • 送信ログは全て DynamoDB に保存されているのが救いだった 

教訓 : 失敗を前提に設計する • Elastic Beanstalk or SendGrid の問題切り分けが行えなかった • → SendGrid API エラー時のレスポンスを詳細にログへ • デッドレターキューからのリカバリ方法が手動 • → 管理画面から一括で未送信メールのリカバリを行えるように改善 • SendGrid 障害時のみに発生するバグもあった • → ワーカーの修正後、リカバリを行えるように管理画面も改善 

教訓 : モニタリングを強化する • 障害時にメールの遅延具合や影響範囲を確認出来なかった • → Datadog で Beanstalk Worker のモニタリング強化 • → Datadog に SQS のメトリクスを流し込んでアラート設定 

障害を受けて改善 • 10 分以上の配信遅延が発生した場合は Slack にアラート • 遅延が発生した時点で、何かしらの問題が発生していることが分かる • 各事業部・CS チームと連携して対応 • 管理画面から送信できなかったメールを確認できるように • DynamoDB にクエリを投げるだけ、GSI も専用に用意 • 未送信メールは簡単にリカバリ可能に 

最近の状況 • 障害が発生しても、検知とリカバリの仕組みを用意済み • 運用ドキュメントを作成して共有 • 運用の分散 • 各事業部から担当者を一人任命、属人化を避ける • SendGrid の障害が発生していないため極めて平和 • 感謝しかない 

参考 • 新メール配信基盤への移行 • https://speakerdeck.com/minato128/ikyu-mail-platform • メール配信基盤のモニタリングと障害リカバリーについて • http://user-first.ikyu.co.jp/entry/2017/12/05/000000