I'm currently using AWS EventBridge Scheduler to run 44 schedules per minute that all point to a single AWS Lambda function. Under normal conditions, AWS handles the execution seamlessly, and I usually see around 7 to 9 concurrent invocations at peak times, but all 44 triggers happen within one minute. However, due to some organizational restrictions, I'm required to transition this setup to EKS where a containerized microservice will take over the same tasks.
I have a couple of questions regarding this migration:
1. What's the best way to connect the EventBridge Scheduler to the microservice running on EKS? Should I expose the service through a LoadBalancer or API Gateway, or is there a way to directly invoke it using a private endpoint?
2. How can I ensure that all 44 invocations hit the microservice within one minute, similar to the way it functions with Lambda? I'm particularly concerned about fault tolerance, like pod restarts or scaling events, and whether I should set up multiple replicas of the service for load balancing.
Additionally, I'm keen on hearing about any architecture patterns, retry handling techniques, or rate limiting strategies that could ensure my service performs efficiently under heavy load, like it does with Lambda. I haven't started on a proof of concept yet; I'm just trying to clarify the best approach to take.
4 Answers
It’s crucial to know what events are triggering your current Lambda; that might inform how you migrate. If you're using Kubernetes, you could set up a cron job to manage the tasks without relying on external triggers. Understanding what each event does is key, especially if your current setup involves multiple configurations that require precise execution.
Using EventBridge to trigger AWS Batch could be a viable alternative. It allows for running multiple parallel jobs, which could boost the performance and handle higher parallelism for your requests.
You could set up EventBridge to trigger an API Gateway, which then invokes your EKS service. Alternatively, you might consider using SQS to queue the requests, allowing your EKS service to poll the messages, although keep in mind this could introduce some asynchronous processing delays.
But won't using SQS lead to some delays in processing due to its asynchronous nature?
Consider what triggers your EventBridge and what payloads you send to Lambda. Instead of going through EventBridge, you might be able to set up a pod in EKS that directly calls the relevant microservice based on those events.
I have 44 schedules to work with because they involve various configurations leading to many API calls. I really need to ensure that they're all scheduled to meet my requirements.