[SAA] ECS 서비스 및 작업, 로드 밸런싱

ECS Services & Tasks

• Amazon ECS 클러스터가 있고 이들이 EC2 실행 타입일 때 두 개의 컨테이너 인스턴스가 존재
  Amazon ECS 클러스터에 여러 서비스를 가동할 수 있을 때
  
  예1) 여러 테스크를 EC2 인스턴스에 걸쳐 가동하는 서비스 A를 사용자들에게 이를 노출시키고 싶다면
  애플리케이션 로드 밸런서를 생성해서 테스크를 직접 통합시킬 수 있으며
  로드 밸런서의 뒤에는 ECS 테스크에 오는 모든 요청(ECS 서비스의 일부로서 가동되고 있는 요청들)을 포워딩하여
  ECS 클러스터 하나에서 다중 서비스를 가동할 수 있음
  
  예2) 만약 서비스 B라는 또 다른 서비스를 생성해 노출시키고 싶다면
  같거나 새로운 애플리케이션 로드 밸런서를 연결
  
  

  

Load Balancing for EC2 Launch Type

• EC2 실행 타입을 사용하면 로드 밸런서에 연결할 수 있음
• 가장 좋은 방법으로는 컨테이너를 지정된 포트 없이 실행하는 것이므로
  컨테이너를 실행할 때 EC2 인스턴스에 배정된 무작위 포트를 얻어 지정받게 되고
  서로 다른 네 개의 테스크에 서로 다른 두 개의 ECS 컨테이너 인스턴스가 배정되게 됨 
  이 때 로드 밸런서는 어떤 포트와 통신해야하는지 알기 위해 ALB의 동적 포트 포워딩 기능을 사용해
  ECS 테스크에 대한 올바른 포트를 EC2 인스턴스에서 찾을 수 있게 되며
  ALB가 ECS에서 특정 서비스에 한 번 등록되면 테스크를 찾아서 자동으로 올바른 포트를 통해 통신하게 됨
  
  

  

• 이를 통해 같은 컨테이너에서 원하는 만큼 많은 컨테이너 인스턴스를 하나의 EC2 인스턴스에 가동하고,
  하나의 애플리케이션 로드 밸런서를 통해 노출시킬 수 있음
• 이를 위해서는 EC2 인스턴스 보안 그룹에서 ALB 보안 그룹으로부터 오는 포트를 허용해야
  ALB가 인스턴스 상의 다양한 포트 그룹과 통신할 수 있으므로 네트워킹을 위해 보안 규칙을 설정해야 함

Load Balancing for Fargate

• Fargate는 우리가 가동하는 모든 테스크에 대해 ENI를 생성하며, ENI는 고유의 IP를 가지지만 포트는 그대로 동일함
  그러므로 각 테스크의 IP는 다르지만 모두 포트가 같으므로 ALB를 생성하면 서로 다른 IP들과 통신하지만 전부 같은 포트와 통신
  
  

  

• 네트워크 보안에서 이를 가능하게 하려면 보안 그룹으로서의 ENI가 테스크 보드에서 ALB를 반드시 허용해야 함

ECS tasks invoked by Event Bridge

• ECS 테스크를 수동으로 불러올 수 있으며, ECS 콘솔에서 직접 테스크를 시작할 수 있음
• 자동화를 원한다면 Amazon Event Bridge나 CloudWatch 이벤트에 의해 ECS 테스크를 생성 또는 불러올 수 있음
• 리전, VPC, Amazon ECS 클러스터가 있고 간단한 Fargate 클러스터를 가동하게 했을 때
  사용자가 S3 버킷에 오브젝트를 업로드할 때
  그 오브젝트를 처리하기 위해서는 Fargate 테스크를 가동하고 DynamoDB에 메타데이터를 넣어야 하는데
  이를 위해서는 S3 버킷으로부터 오는 Amazon Event Bridge 이벤트를 생성해야 함
  Amazon Event Bridge 이벤트는 대상으로서의 규칙(ECS 테스크를 가동하기 위한 규칙)이 있으며
  이 규칙이 새로운 대상 테스크를 생성해주며, 이 테스크는 올바른 ECS 테스크 역할이 있어야 Amazon S3에 액세스가 가능하고
  객체를 넣은 곳에서 회수할 수 있으며 DynamoDB에 메타데이터를 넣을 수 있음
  이것이 완료되면 테스크는 S3에 액세스가 가능하고 객체를 가져올 수 있으며, 작업이 완료되면 처리 과정 결과를 저장할 수 있음
  즉, ECS 테스크 역할에 의해 정의된 IAM 정책 덕분에 메타데이터를 Amazon DynamoDB 테이블에 저장할 수 있는 것
  
  

  

<ECS 실습>

• ECS 실습
  컨테이너 정의, 테스크 정의, 서비스, 클러스터까지 존재
  이렇게 컨테이너 정의를 구성하고 ECS 서비스를 구성하고 클러스터에서 서비스를 실행하며
  이러한 모든 과정이 백엔드의 EC2 인스턴스 없이 이루어짐
  
  sample-app은 httpd 이미지 버전 2.4를 실행하므로 이 앱으로 컨테이너를 시작
  
  테스크 정의를 FARGATE 모드로 실행하게 되며
  이는 서버리스 ECS 클러스터이므로 백엔드에서 ECS 클러스터로 실행되는 EC2는 없게 되므로 이렇게 컨테이너 정의 구성
  
  그리고 다음을 누르면 서비스 정의가 실행되며 필요하면 더 많은 테스크를 추가할 수도 있음
  또한 새로운 보안 그룹을 자동으로 생성하게 설정할 수 있으며
  애플리케이션에 액세스하는 애플리케이션 로드 밸런서의 사용 여부를 선택할 수 있음
  만약 애플리케이션 로드 밸런서가 없다면 포트 80으로 인스턴스를 직접 액세스할 수도 있음
  반면 애플리케이션 로드 밸런서를 사용하면 서비스의 일부로써 실행되는 ECS 테스크 모두와 연결됨
  이번 실습에서는 간단하게 None으로 진행
  
  클러스터의 이름은 Fargate 모드를 사용하므로 demo-stephane-fargate로 설정
  
  마지막으로 요약을 통해 새로운 테스트 정의의 생성을 볼 수 있으며 이 후 ECS를 생성
  Fargate 애플리케이션은 httpd 이미지를 실행하고 서비스의 테스크는 하나이며 새로운 클러스터와 VPC 서브넷을 생성
  
  생성된 ECS를 살펴보면 ECS 클러스터와 테스크 정의, 서비스, 로그 그룹, CloudFormation 스택,
  VPC, 서브넷1, 서브넷2, 보안 그룹까지 생성된 것을 볼 수 있음
  

모두 생성 완료

• 생성된 ECS 확인
  Services로 이동하면 서비스가 실행 중인 것을 볼 수 있으면 Task 탭을 보면 테스크 하나가 대기 중임을 볼 수 있음
  대기 상태란 지금 생성되어 Fargate에서 실행 가능한 것이므로 새로고침하면 애플리케이션이 작동하므로 실행 상태로 변경됨
  
  테스크를 클릭하면 Fargate로 실행 중이며 Fargate 컨테이너에 ENI가 연결되어 사설 IP와 공용 IP를 제공해줌을 알 수 있음
  공용 IP를 사용하여 탭을 열어 포트 80으로 이동하면 Amazon ECS Sample App이 성공적으로 작동하고 있으며
  ECS의 컨테이너에서 실행되고 있음을 볼 수 있음