EC2를 컨테이너 인스턴스로 사용하는 ECS를 구축해보자!

ECS 이해하기

Amazon Elastic Container Service(Amazon ECS)는 컨테이너 애플리케이션을 쉽게 배포, 관리 및 확대할 수 있도록 도와주는 완전 관리형 컨테이너 오케스트레이션 서비스입니다.

개념 이해하기

• 컨테이너

  • 애플리케이션 코드 + 라이브러리 + 종속성 등 각종 애플리케이션의 구동에 필요한 모든 환경을 함께 패키징하고, 독립적으로 격리된 환경에서 실행하는 소프트웨어 실행 단위를 말한다.
  • 애플리케이션 실행에 있어 일관된 환경을 제공한다.

• 마이크로서비스 아키텍처

  • 과거 전통적인 방식에서는 하나의 거대한 아키텍처인 모놀리식 아키텍처를 사용했다.
  • 모놀리식 아키텍처를 쪼개서 모듈화, 캡슐화한 것이 바로 마이크로서비스 아키텍처이다.

• Docker

  • 어플리케이션 프로세스를 독립적으로 실행시킬 수 있는 리눅스 컨테이너 환경이다.
  • DockerFile로 컨테이너에 설치해야 하는 패키지, 설정 등을 기록한다.
  • DockerFile을 바탕으로 Docker image를 생성한다.
  • Docker image를 run해 Docker Container를 실행하며, 이 컨테이너는 하나의 애플리케이션으로 작동한다.

AWS ECS는 완전 관리형 컨테이너 오케스트레이션 서비스로, 도커 컨테이너들을 자동으로 배포, 관리, 확장, 모니터링하는 서비스이다. ECS를 사용해 마이크로서비스 아키텍처를 구현 가능하다.

ECS 구조

ECS는 다음과 같이 구성되어 있다.

• ECS Cluster
• Container Instance
  • Task가 실행되는 인스턴스
  • EC2, Fargate로 2가지 유형이 존재한다.
• Service
  • Task를 관리하는 논리적인 요소
  • Task 배포, 생명주기 등을 관리한다.
  • Task Definition를 통해 Task를 실행한다. Task Definition에는 Task가 사용할 CPU, Memory, Docker image 등의 여러 설정이 작성되어 있다.
• Task
• Contanier

ECS Cluster > Container Instance > Service > Task > Contanier와 같은 구조이다. 직접 생성해보면 이해가 금방 간다!

ECS 배포 전략

무중단 배포

어떤 서비스를 버전 1(v1)에서 버전 2(v2)로 전환하는 상황이라면, v1 종료 → v2 실행 → v2 운영 시작으로 배포 과정이 진행된다. v1를 종료하고 v2를 실행해 운영을 시작하는 시간 사이에는 다운타임이 존재한다. 이 다운타임 동안 유저는 해당 서비스를 이용할 수 없다.
이러한 다운타임이 없는 배포를 무중단 배포라고 한다. 무중단 배포에는 롤링, Blue/Green, 카나리 방식이 존재하며 ECS 무중단 배포 방식을 사용하며, 롤링, Blue/Green 배포 방식을 제공한다.

롤링 배포 방식

점진적으로 구버전에서 신버전으로 옮기는 방식을 말한다.
서버 수의 제약이 있는 경우 유용하지만, 구버전 + 신버전이 동시에 서비스되어 호환성 문제가 발생할 수 있다.

Blue/Green 배포 방식

현재 운영 환경인 Blue 서버, 신규 배포 환경인 Green 서버가 동시에 나란히 구성된다. 로드 밸런서가 트래픽을 Blue에서 Green으로 전환하고, 배포 성공 시 Blue 서버를 제거한다.
롤링 배포와 달리 Blue에서 Green으로 한 번에 전환해 호환성 문제는 없지만, 운영에 필요한 서버의 2배를 확보해야 해 비용이 증가할 수 있다.

ECS 구축하기

ECS에 사용할 VPC, ALB가 사전에 구축되어 있어야 한다.

IAM 역할 생성하기

총 3가지 역할을 생성한다.

• Container Instance 역할
  • AmazonEC2ContainerServiceforEC2Role 정책 포함
  • 사용 사례에서 EC2 Role for Elastic Container Service를 선택하면 위 정책이 자동으로 포함된다.
    
    
    
• Task 역할
  • 해당 태스크에게 필요한 적절한 정책을 포함한다.
• Task Execute 역할
  • AmazonECSTaskExecutionRolePolicy 정책 포함
  • 수동으로 정책을 포함한다.
    
    
    

Auto Scaling 시작 템플릿 설정

• AMI 설정

  • ECS Optimized AMI를 사용한다.
  • ECS Optimized AMI의 최신 버전은 해당 링크에서 확인 가능하다.
    
    
    

• IAM 인스턴스 프로파일 설정

  • IAM 인스턴스 프로파일에 위에서 생성한 Container Instance 역할을 추가한다.
    
    
    

• 보안 그룹 설정

  • EC2 컨테이너 인스턴스의 보안 그룹에서 8080포트를 열어야 한다. 아래의 인바운드 규칙을 추가한다.
  • 유형: 사용자 지정 TCP / 포트 범위: 8080 / 소스 유형: 사용자 지정 / 소스: ALB 보안그룹
    
    

• 사용자 데이터 설정

  • 사용자 데이터에 아래의 코드를 넣는다.
  • 이는 ECS 클러스터 이름을 설정하는 코드로, 설정하지 않는 경우 default 클러스터가 생성되고 EC2가 default 클러스터의 컨테이너 인스턴스로 적용된다.

    #!/bin/bash
    CLUSTER_NAME=[ecs 클러스터 이름]
    echo "ECS_CLUSTER=$CLUSTER_NAME" | tee /etc/ecs/ecs.config

    
    

ECS 클러스터 생성

• EC2 인스턴스를 사용해 ECS 클러스터를 생성한다.

  • 위에서 설정한 ASG를 사용한다.
    
    
    

• 클러스터 생성 후 등록된 컨테이너 인스턴스 수를 확인해 ASG의 인스턴스가 제대로 등록되었는지 파악한다.
  
  
  

ECS 태스크 정의 생성

• 시작 유형은 EC2 인스턴스를 선택한다.
  
  
  

• 네트워크 모드를 설정한다. host, bridge, awsvpc로 총 3가지 유형이 있다.

  • host
    • 개별 태스크의 네트워크를 EC2 컨테이너 인스턴스의 ENI에 매핑한다.
    • 하나의 EC2 컨테이너 인스턴스에 여러 태스크가 존재할 수 있으나 태스크 간 포트 충돌이 발생할 수 있다.
    • 사용하는 것을 권장하지 않는다. 롤링 배포 사용 시 반드시 포트 충돌이 발생해 배포에 실패한다.
  • bridge
    • 가상 네트워크 브릿지를 생성해 모든 태스크를 연결한다.
    • 하나의 EC2 컨테이너 인스턴스에 여러 태스크가 존재한다.
    • 동적 포트 할당이 필요하며, ALB 설정이 까다로워 권장하지 않는다.
  • awsvpc
    • 태스크마다 하나씩 ENI를 할당한다.
    • 하나의 EC2 컨테이너 인스턴스에 여러 태스크가 존재한다.
    • AWS에서 사용을 권장한다.

• 네트워크 모드는awsvpc를 선택한다.

  • host 모드는 롤링 배포시 충돌 발생으로 인해 권장하지 않는다.
  • bridge 모드를 사용하는 경우, 동적 포트 할당으로 인해 ALB 설정을 반드시 수정해야 한다. 설정이 번거로워 권장하지 않는다.
  • awsvpc를 사용하는 경우, 대상 그룹 유형을 인스턴스가 아닌 IP로 생성하자.
    
    
    

• 태스크 크기는 EC2 컨테이너 인스턴스를 고려해 설정한다.

  • t2.micro를 컨테이너로 사용하는 경우, 1vCPU, 메모리 1GB를 갖는다. 태스크 크기는 이것보다 더 작게 할당해야 한다.
  • 롤링 배포를 사용하는 경우, 하나의 인스턴스 내에 태스크가 2개 이상 실행될 수 있어 이를 고려해 CPU, 메모리를 할당해야 한다.
    
    
    

• 태스크 역할을 설정한다.

  • 위에서 생성한 태스크 역할, 태스크 실행 역할을 설정한다.
    
    
    

• 컨테이너를 추가한다.

  • 적절한 컨테이너 이름, ECR 이미지 URL을 설정한다.
    
  • 포트 매핑을 추가한다. 컨테이너 포트는 스프링부트 서버 포트인 8080으로 하고, 프로토콜은 HTTP로 설정한다.
    
  • 로깅 옵션에서 로그 수집을 키는 것을 권장한다.
    
  • 로깅 옵션을 켰다면, /ecs/[태스크 정의명]으로 CloudWatch 로그 그룹을 생성한다.
    
    
    

ECS 서비스 생성

• 컴퓨팅 옵션은 시작 유형, 시작 유형은 EC2를 선택한다.
  
  
  

• 배포 구성을 설정한다.

  • 애플리케이션 유형은 서비스로 한다. 스프링부트 웹 서버를 배포할 예정이기 때문이다.
  • 패밀리는 위에서 생성한 태스크 정의를 설정한다.
  • 서비스 유형은 복제본으로 설정한다.
  • 원하는 태스크 수를 적절하게 선택한다.
  • 가용 영역 리밸런싱은 켠다. 이를 끄는 경우, 하나의 AZ에 인스턴스가 몰려 불균형이 발생할 수 있다.
    
    
    

• 배포 옵션을 설정한다.

  • 배포 유형은 롤링 업데이트를 선택한다.
  • 최소 실행 작업 비율을 100%으로 하면 위에서 설정한 원하는 태스크 수만큼 태스크가 유지된다.
  • 최대 실행 작업 비율을 200%로 하면 위에서 설정한 원하는 태스크 수의 2배만큼 태스크가 유지된다. 하나의 인스턴스에 태스크가 2개 실행되어 자원 부족이 발생할 수 있다.
  • 배포 회로 차단기를 사용하고, 배포 실패 시 롤백을 사용한다. 배포 실패 시 자동 롤백되어 편리하다.
    
    
    

• awsvpc 모드를 사용하는 경우, 적절한 네트워킹 구성이 필요하다.

  • 적절한 VPC, 버스넷, 보안그룹을 선택한다.
    
    
    

• 로드 밸런싱을 사용한다.

  • 적절한 로드 밸런서 유형, 컨테이너, 로드 밸런서를 선택한다.
    
    
    

  • 기존에 생성한 리스너, 대상그룹을 사용한다.
    

• 서비스를 생성하면 바로 태스크 정의를 바탕으로 배포가 바로 시작된다.