Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
一休.com がどのように SendGrid と仲良く付き合っているか
Search
Tatsuro Shibamura
June 06, 2018
Technology
0
5.1k
一休.com がどのように SendGrid と仲良く付き合っているか
Tatsuro Shibamura
June 06, 2018
Tweet
Share
More Decks by Tatsuro Shibamura
See All by Tatsuro Shibamura
# Azure Cosmos DB パフォーマンス最適化入門 - 設計・開発・運用の実践テクニック
shibayan
0
130
Hack Azure! #5 - Geek of Azure Serverless
shibayan
0
83
.NET Conf 2020 Online - .NET 5 リリース記念パーティートーク
shibayan
0
8.5k
Terraform Provider for Azure に貢献してみた話
shibayan
0
550
Azure Functions と SendGrid の良い関係
shibayan
0
1k
Azure Serverless を活用したリアルタイム Web のすべて
shibayan
1
2.7k
祝 東日本リージョン一般提供! Azure Application Insights 基礎と実践
shibayan
1
40k
なかなか楽にならないSSL/TLS証明書の話
shibayan
2
1.6k
.NET Conf 2018 Tokyo
shibayan
1
3.9k
Other Decks in Technology
See All in Technology
[OpsJAWS Meetup33 AIOps] Amazon Bedrockガードレールで守る安全なAI運用
akiratameto
2
160
困難を「一般解」で解く
fujiwara3
9
3.1k
失敗しないAIエージェント開発:階層的タスク分解の実践
kworkdev
PRO
0
630
StotybookからはじめるVRT -個人開発編-
arrow2nd
1
660
DevinでAI AWSエンジニア製造計画 序章 〜CDKを添えて〜/devin-load-to-aws-engineer
tomoki10
0
280
最近のラズピッピいじり / 20250308-rpijam-13th-birthday
akkiesoft
0
150
サイト信頼性エンジニアリングとAmazon Web Services / SRE and AWS
ymotongpoo
8
2k
Linuxのブートプロセス
sat
PRO
6
110
【Snowflake九州ユーザー会#2】BigQueryとSnowflakeを比較してそれぞれの良し悪しを掴む / BigQuery vs Snowflake: Pros & Cons
civitaspo
5
1.6k
エンジニア採用と 技術広報の実践/acaricsummit2025
nishiuma
1
140
開発組織を進化させる!AWSで実践するチームトポロジー
iwamot
2
650
「頑張る」を「楽しむ」に変換する技術
tomoyakitaura
10
1.9k
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
4 Signs Your Business is Dying
shpigford
183
22k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
Optimizing for Happiness
mojombo
377
70k
Code Reviewing Like a Champion
maltzj
521
39k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.3k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Transcript
一休.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