첫 번째 전략은 오랫동안 실행되는 작업을 위해 EC2 인스턴스를 프로비저닝하는 것이며 여러분은 거기서 CRON기능을 실행하고 싶을 겁니다. 이 서비스는 훌륭하며 CRON을 아는 사람들은 효율적으로 사용할 수 있습니다.
하지만 문제는 가용성이 높지 않고 확장성도 없다는 것입니다. 만약 EC2 인스턴스가 줄어들면 문제가 생깁니다. 그래서 이것은 훌륭한 전략이 아니며 솔루션 아키텍쳐로서 절대 보증해서는 안되는 것입니다.
두 번째 아키텍쳐는 아마존 EventBridge나 Lambda 같은 것을 사용하는 것인데요.
EventBridge는 Lambda function을 호출하는 규칙을 가질 수 있고 그 Lambda가 순수하게 서버리스이기 때문에 여기서 서버리스 cron작업을 수행할 수 있습니다. 그래서 런타임, 시간을 초과하기 전 시간 등의 측면에서 Lambda function에 의해 제한을 갖게 됩니다
하지만 이 솔루션은 아주 훌륭한 것이고, AWS는 가능한 한 아주 많이 여러분에게 강요할 것입니다.
세 번째 옵션은 일종의 상호작용을 하는 워크플로를 갖는 것으로 AWS내에서 발생하는 이벤트에 의해 호출되는 Lambda Function을 가져옵니다.
물론 EventBridge는 훌륭합니다, 다양한 AWS 서비스내에서 이벤트가 발생하기를 원하다면 말이죠. 하지만 S3는 새로운 객체 생성을 위해 자체 이벤트를 만들어냅니다. 예를 들면 API 게이트웨이 역시 Lambda Function을 호출할 수 있습니다
SQS queue와 SNS queue 역시 데이터 소스가 될 수 있으며 Lambda Function 등을 위한 호출이 될 수 있습니다. 이것은 상호작용을 하는 워크플로인데 인프라스트럭쳐에서 어떤 일이 발생하자 마자 Lambda Function을 실행해서 대응하기 때문입니다
네번째 전략은 오래 실행되는 작업을 위해 AWS Batch를 사용하고, 완전한 독립형 컨테이너를 위해 두번째 전략의 EventBridge를 사용합니다.
EventBridge와 장기 실행 워크로드를 위한 배치에서 시간 기반의 이벤트에 적용하는 규칙덕분에 3시간마다 배치 작업을 호출합니다.
전략 5는 Fargate를 사용하는 것으로 batch보다 좀더 단순하고 기본적인 전략입니다, batch는 배치작업을 실행하는 방법과 같은 측면에서 좀더 많은 기능과 확장성을 갖고 있습니다.
하지만 Fargate를 EventBridge의 대상으로 사용해서 컨테이너를 아주 빠르게 실행할 수도 있습니다.
전략 6는 AWS에서 아주 오랫동안 작업을 실행하고 싶다면, 아마 대부분 빅데이터 작업이 될텐데 그때는 Elastic MapReduce인 EMR을 사용하는 것이 좋습니다, 만약 단계별로 수행할 것이 있거나, 이런 종류의 빅데이터 워크로드를 클러스터링하고 실행해야 한다면 말이죠.
