[AWS] AWS's containers - ECS 솔루션 아키텍트

Amazon ECS를 사용할 때, 접할 수 있는 몇가지 솔루션 아키텍처에 대해 알아보자.

 

ECS tasks invoked by Event Bridge

• 첫 번째는 EventBridge에 의해 호출된 ECS 태스크이다.
• 예를 들어, Amazon ECS 클러스터가 있고, 그걸 AWS Fargate가 지원하고 있다. S3 버킷이 있고, 사용자들은 객체들을 우리 S3 버킷에 업로드할 것이다. 이 S3 버킷은 예를 들어 Amazon EventBridge와 통합되어서 모든 이벤트를 전송할 수있다. 그리고 Amazon EventBridge는 항상 ECS 태스크를 실행하기 위한 규칙을 갖고 있을 수 있다. 
• 이제 ECS 태스크가 생성될 것이고, 그것에 관련된 ECS 태스크 역할이 있을 것이다. 태스크 자체로부터 직접 객체를 받고 그걸 처리하고 그 결과는 Amazon DynamoDB로 전송할 수 있다. 그렇게 되는 건 우리가 그에 관련된 ECS 태스크 역할을 갖고 있기 때문이다.
• 그래서 위의 예시에서 Docker Container, Amazon EventBridge, Fargate 모드의 ECS 그리고 Amazon S3 및 Amazon DynamoDB와 대화하기 위한 ECS 태스크 역할을 사용해서 우리의 S3 버킷에서 이미지나 객체를 처리할 수 있는 서버리스 아키텍처를 만든 셈이다.

 

ECS tasks invoked by Event Bridge Schedule

• Fargate와 Amazon EventBridge가 지원하는 Amazon ECS 클러스터가 있다.
• 1시간마다 트리거되는 규칙을 스케줄링하고, 이 규칙은 우리를 대신해 Fargate에서 ECS 태스크를 실행할 것이다.
    - 즉, 1시간마다 우리의 Fargate 클러스터 안에서 새로운 태스크가 생성된다는 의미이다.
• 태스크는 우리가 원하는 무엇이든 할 수 있다.
    - 예를 들어, S3에 액세스 할 수 있는 ECS 태스크 역할을 만들 수 있다.
    - 태스크 Docker Container, 프로그램은 Amazon S3에서 어떤 파일들에 대한 배치 프로세싱을 1시간마다 수행할 수 있다.
• 모든 아키텍처는 완전히 서버리스이다.

 

ECS - SQS Queue Example

• 2개의 ECS 태스크가 있는 서비스가 있을 수 있다.
• 메시지가 SQS Queue로 전송되고, 서비스 자체가 SQS Queue로부터 메시지를 가져와서 그것들을 처리하게 된다.
• 이 서비스 외에도 ECS 서비스 오토 스케일링을 활성화 할 수 있다.
• 그러면 예를 들어 SQS Queue에 더 많은 메시지가 있으면 오토 스케일링 덕분에 우리의 ECS 서비스에 더 많은 태스크를 갖게 될 것이다.

 

ECS - Intercept Stopped Tasks using EventBridge

• EventBridge를 사용하여 실제로 우리의 ECS 클러스터 안에서 이벤트를 가로채는 형태의 통합도 있다.
• 예를 들어, 태스크가 나가는 것에 대응하려한다고 해보자.
• 그런 경우에 우리의 ECS 클러스터에서 나가거나 시작되는 모든 태스크는 EventBridge에서 이벤트로서 트리거 될 수 있다.
• 예를 들어, STOPPED나 stoppedReason에 대해서 ECS 태스크 상태가 변하는 것이다. 그러면 거기서부터 예를 들어 우리는 SNS 토픽으로 경보하거나 관리자에게 이메일을 전송할 수 있다.
    - 즉, EventBridge는 최소한 우리의 ECS 클러스터에 있는 컨테이너들의 라이프사이클을 이해할 수 있게 해주는 것이다.