SendGridのEvent Webhookをサーバーレスアーキテクチャで構築した話

Transcript

1. SendGridのEvent Webhookを
 サーバーレスアーキテクチャで
 構築した話
 私たちのサーバーレスアーキテクチャはこれだ！Lunch LT
 株式会社JMDC

2. © JMDC Inc. 2
 自己紹介

3. © JMDC Inc. 3
 自己紹介
 株式会社JMDC
 • プロダクト開発部
 • バックエンドエンジニア
 
 野田 実 / Minoru NODA

4. © JMDC Inc. 4
 アジェンダ

5. © JMDC Inc. 5
 アジェンダ
 1. 背景
 2. 初期実装
 Lambda Functionの実装
 3. 問題
 503 SlowDown
 4. 解決
 Kinesis Data Firehoseでバッファリング
 5. まとめ

6. © JMDC Inc. 6
 背景

7. © JMDC Inc. 7
 背景
 システム特徴
 • Ruby on Rails製のローンチ後、7年経過したプロダクト
 • 発行ID数は約540万ID(2023年3月末時点)
 • インフラはAWS
 
 • サービスがスケールした段階で改めて他のメールサービスを見てみると、コストや安定性の面で SendGridが有利になったの で移行することに決定 • メールの送信数・開封数・クリック数を取得していて、施策の効果検証の指標として活用 
 
 SendGridへのメールサービス移行プロジェクト発足 

8. © JMDC Inc. 8
 背景
 アーキテクチャ検討
 • 元々使っていたメールサービスではメールの送信数、 開封数、クリック数をAPIで取得していた • 日次更新 • SendGridでは送信、開封、クリックなどといった イベントごとにEvent Webhookを飛ばすことができる • 大量のリクエストが発生する • Railsで受けるのは現実的でない • SendGridにもAPIはあるがEvent Webhookでデータ蓄積が推奨 • S3に蓄積してAthenaで送信数、開封数、クリック数を 取得するアーキテクチャにする方向で進めていくことに決定 • データストアとしてDynamoDBも検討したが、 Readの頻度が少ない、コストの優位性もないので不採用 
 
 
 SendGridへのメールサービス移行プロジェクト発足 

9. © JMDC Inc. 9
 背景
 アーキテクチャ検討
 • 元々使っていたメールサービスではメールの送信数、 開封数、クリック数をAPIで取得していた • 日次更新
 • SendGridでは送信、開封、クリックなどといった イベントごとにEvent Webhookを飛ばすことができる • 大量のリクエストが発生する • Railsで受けるのは現実的でない • SendGridにもAPIはあるがEvent Webhookでデータ蓄積が推奨 • S3に蓄積してAthenaで送信数、開封数、クリック数を 取得するアーキテクチャにする方向で進めていくことに決定 • データストアとしてDynamoDBも検討したが、 Readの頻度が少ない、コストの優位性もないので不採用 
 
 
 SendGridへメールサービスを移行
 今日はこの部分の話をします

10. © JMDC Inc. 10
 初期実装
 Lambda Functionの実装

11. © JMDC Inc. 11
 Lambda Functionの実装
 • API GatewayはHTTPで作成
 • S3にWebhook用のバケットを作成し、蓄積
 • 一意なファイル名を生成
 
 • API Gatewayのendpointを知ってるユーザーな ら任意の文字列をPOSTしS3へ保存できてしま う • (実際はyear/month/dayでprefixを切る、gzへ 圧縮しているが省略) 
 
 
 
 素朴な実装でまずはやってみる 

12. © JMDC Inc. 12
 Lambda Functionの実装
 • Signed Event WebhookというSendGridの認証の機構を利用
 • Signed Event Webhook Requestsを有効にすると公開鍵が 発行される • Event Webhookに X-Twilio-Email-Event-Webhook-Signature, X-Twilio-Email-Event-Webhook-Timestampヘッダーがつく ようになる • それらと Event Webhookのbodyで認証を行う
 
 • この実装でしばらく運用
 
 
 認証を考えた実装

13. © JMDC Inc. 13
 問題
 503 Slow Down

14. © JMDC Inc. 14
 • S3へ保存するときに503 Slow Downが発生 • 原因: prefix ごとのリクエストが多すぎる • > you can send 3,500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD requests per second per prefix in an S3 bucket. https://repost.aws/knowledge-center/http-5xx-errors-s3 • 送信、開封、クリックごとに POST -> POST 数が莫大 
 
 
 問題発生
 503 Slow Downの発生

15. © JMDC Inc. 15
 解決
 Kinesis Data Firehoseでバッファリング

16. © JMDC Inc. 16
 Kinesis Data Firehoseでのバッファリング
 • 1リクエスト-> 1 S3 postが原因 • バッファリングで解消を図る • Lambdaから直接 S3へpost するのではなく Kinesis Data Firehose でバッファリング • S3へのpost回数を減らす • prefixをyear/month/day/hourへ • アーキテクチャ変更により503 Slow Downは
 発生しなくなった
 • 1年近く運用しているが、安定
 中間層を設け解決

17. © JMDC Inc. 17
 まとめ

18. © JMDC Inc. 18
 まとめ
 • サーバーレスアーキテクチャで大量のリクエストを安定して捌くことができた 
 • 問題が発生してもサーバーレスのサービスを組み合わせることで解消できた 
 • S3でSlow Downが発生することなどチームに知見が溜まった 
 
 • サービスを組み合わせて課題解決、楽しい！ 
 
 サーバーレスを用いることで高スループットなアーキテクチャが実現できた 

19. © JMDC Inc. 19
 We are hiring!
 JMDCでは一緒にプロダクト開発を推進いただける方を積極採用中です！
 今日のお話しを聞いていただき、少しでもご興味をお持ちいただけましたら
 ぜひまずはカジュアルにお話しできればと思います。
 ▲カジュアル面談 エントリーページ