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

by Minoru Noda

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

© 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で認証を行う    • この実装でしばらく運用      認証を考えた実装 

Slide 13

Slide 13 text

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Slide 16

Slide 16 text

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