- 최신
- 최다 투표
- 가장 많은 댓글
The "cloud native" way of doing this is to use a queue.
It's not detailed in the question but my guess here is that there is a single submission to the application which is intended to cause a single email email notification. But the submission is (probably) stored in a database somewhere and when all of the instances run their cron jobs they all pick up the job out of the database and all send emails.
Instead: Have the submission of the job create a message in SQS and have the email notification system retrieve it from SQS. Even if there are multiple instances running the notification code only one of them will ever receive the SQS message - that's how the service is designed.
Hello,
Brettskis SQS Solution is probably the correct and more robust solution at scale. However, it could be a bit lite over-engineer for such an easy task.
Just create an endpoint in your service for "notifications" (the same function that your cron job triggered), then have a cron job in cloud watch event bridge trigger it using SNS, or go via a private lambda if it's a private endpoint. T
This way, only one request will be sent even if you have multiple EC2s, and it's easy to test and trigger add hoc "notifications". And you won't have to spend money on SQS pooling (keep in mind that SQS pooling blooks one thread in your machine).
Hope this helps!
//Carl
관련 콘텐츠
AWS 공식업데이트됨 일 년 전
Given that SQS is free for the first million requests per month if this is a small-scale application then costs isn't going to be an issue. I run this exact solution for a personal website because it is inexpensive and it's really easy to engineer. Many AWS services are there to solve problems small and large. And SQS polling only blocks for the long polling period specified by the caller.