ECS 적용기 : EC2 와 Fargate (Serverless) 선택과 적용할 아키텍처

 

문제

• 서버 관리가 힘듬
• SQLD 끝나고 ECS 학습 후 적용해보기

ECS

Amazon Elastic Container Service

• 한 마디로 애플리케이션을 “컨테이너화” 하여 설치, 운영, 관리를 도와주는 서비스.
  • 로드밸런싱, 오토스케일링 외에도 네트워킹, 모니터링, 디버깅 등 편리한 관리 가능
• 서버를 “도커 이미지”로 말아서 AWS 에 레지스트리 주소를 알려주면
  • AWS 가 해당 이미지를 이용해 컨테이너를 실행시켜 직접 컨테이너(애플리케이션)를 올립니다.

ECS 옵션

ECS 를 사용할 때는 2가지 옵션 중 하나를 선택해야 합니다.

• EC2
  • ECS 를 실행하기 전 EC2 인스턴스 선택 (기존 인스턴스 사용 가능하나, 복잡한 설정 필요)
  • 일반적으로 ECS 용 클러스터를 등록할 때 ECS 용으로 구성된 EC2 인스턴스를 등록하는 것이 일반적
• Fargate (Serverless)
  • 별다른 설정 없이 곧바로 컨테이너 실행 가능
  • 참고로 서버리스는 서버가 없는 것이 아니라 우리가 서버를 직접 관리하지 않아도 된다는 의미(AWS 에서 직접 관리해줌)

그럼 어떤 옵션을 선택하는 것이 좋을까?

가격

EC2

 

• t2.medium 기준으로 조회
• 온디맨드 인스턴스 시간당 요금 0.0576
• 데이터 전송 요금 → 송신량에 따라 다름

Fargate

• 시간당 vCPU 당 사용 요금 0.04656
• 시간당 GB 사용 요금 0.00511
• 프리티어 X

단순 가격만 비교해보았을 땐 EC2 요금이 더 저렴해보이지만 fargate 는 CPU 0.25 개와 0.5GB 의 메모리부터 사용하며 늘려갈 수 있음. → 해당 애플리케이션이 사용한 만큼의 리소스 요금만 청구됨 → 컨테이너 밀도와 활용도가 완벽

 

	t2.medium	fargate (최소 용량)
CPU	2	0.25
메모리	4GB	0.5GB
시간당 비용	0.0464	0.00142
하루 비용(24h)	1.1136	0.3407
한 달(약 730h)	33.872	10.36

• 참고로 fargate 는 애플리케이션 “갯수”당 용량임을 참고

성능

EC2

• CPU, 메모리, 네트워킹 옵션 등 인스턴스 옵션 자유롭게 세부 선택 가능
• 최신 하드웨어 출시 → EC2 업그레이드로 바로 적용 가능함

Fargate

• CPU, 메모리만 선택 가능 → 하드웨어 세대 등 세부 정보 선택 불가
  • 왜냐하면 Fargate 는 서버리스로, 우리가 서버를 관리하는 것이 아니라 AWS 가 관리해줌
  • 우리는 선택할 수 없고 AWS 가 관리해주는 대로 사용하면 됨

관리 간접 비용

EC2

 

• 인프라 최신 패치 등등 직접 관리 필요
• 인스턴스 유형 등 직접 설정 필요

Fargate

 

• 서버리스, 직접 관리 X

수요 변동성

EC2

• 지속적인 부하가 있는 경우 적합
• 예상되는 꾸준한 트래픽이 있는 경우 → 트래픽에 맞춰 EC2 를 만들고 그 안에서 동작하도록 구성

Fargate

• 오토스케일링 기능 O
• 작업 부하가 작고 가끔씩 버스트가 발생한다면 (낮에는 트래픽이 있고 밤에는 적다면)
  • 밤에는 컨테이너 하나로 축소하고 낮엔 트래픽에 맞춰 자동 확장
• 이 외에도 스팟 옵션(지속 사용X 사용하다가 끊길 수 있는 가능성O) 사용하면 가격도 저렴(정가에서 최대 70% 할인) → 테스트 서버 등에 적합

EC2 가 적합한 곳

• 작업 부하가 많고 지속적인 트래픽이 있는 곳에서 가격을 최적화하려는 경우
• 유지하고 최적화하는 것이 기업(개발자)의 책임이긴 하지만..
  • 조건만 잘 설정한다면 더 저렴한 비용으로 실행 가능

AWS Fargate 적합한 곳

• 관리 인프라가 부족한 스타트업
• 애플리케이션의 트래픽이 예상이 안 되는 경우

ECS 아키텍처

1. (애플리케이션) 도커 이미지
2. ECR (Amazon Elastic Container Registry) 에 이미지 푸쉬 (Docker 허브 등 기타 레지스트리 사용 가능)
3. 작업 결정 → Task, Web Service, DB Service, 컨테이너 용량 등 정하기
4. ECS Cluster 생성 → 작업이 실행되는 인스턴스
5. 서비스(로드밸런서) 연결

적용 방법 : EC2 사용 기준

VPC 설정

• 가용 영역 2군데 이상 (ALB 사용할 땐 가용영역이 2군데 이상이어야 함)
• Pub / Priv 서브넷 외 NAT 설정 등 복잡한 네트워크 설정 필요
  
  • ALB 때문에 최소 서브넷 4개 필요(pub 두개 + priv 두개)

ALB (Application Load Balancer) 생성

• 서브넷 → 퍼블릿 서브넷
• 보안그룹
  • 인바운드 : HTTP 80 트래픽 모두 허용
  • 아운바운드 : 모든 트래픽 허용

Cluster 설정

ASG (Auto Scaling Group)

 

• 최소 1개로 해놓으면 클러스터 생성 시 EC2 인스턴스 한 개가 생성 됨.

VPC

• Private 서브넷 안에 둔다.
• EC2 는 오직 ALB 를 통해서만 통신

단, EC2 가 priavte 서브넷 안에 있어 엔드포인트 설정을 해야지만 ssh 접속 가능

보안 그룹

• 아웃바운드 : 모든 트래픽 허용
• 인바운드 : HTTP 80 트래픽 허용 (외부에서 80포트로 오는 트래픽)

적용 방법 : Fargate 사용 기준

클러스터

• 인프라 관련 설정 아무것도 필요 없음.

태스크 (작업)

• 네트워크는 강제로 awsvpc 모드를 사용하게 됨.
  • 모든 작업이 privateIP 를 가지게 됨
  • 내부가 10.0.1.231:8080 (priavteIP)
  • 외부

 

• 호스트 포트 설정 부분이 없는 것을 확인 가능
  • awsvpc 에서 알아서 나중에 설정할 호스트 포트와 ↔ 컨테이너 포트를 매핑해줌.

 

• 용량 공급자 선택 가능
  • FARGATE_SPOT : 스팟 인스턴스로, 지속적인 사용이 어려울 수 있어서 가격이 싼 인스턴스 → 테스트 서버 등에 유용

아키텍처

 

기존에 사용하던 Github Actions 를 적절히 이용하고 ECR 과 ECS 를 사용하고자 한다.

Build

1. 로컬에서 특정 브랜치에 코드를 푸쉬.
   1. 여기에서는 “canary” 에 푸쉬했다고 가정.
2. github Actions 워크플로우에서 Trigger (on push branch canary) 가 생겨
   1. 아티팩트를 빌드하고
   2. 빌드한 아티팩트로 도커 이미지를 만들어 ECR 에 푸쉬.

Deploy

1. ECR 에서 레지스트리에 이미지 버전 업데이트가 이루어졌다면, ECR 과 연결된 ECS 에 이미지 변경을 트리거를 잡아 새로운 배포 진행 가능.
   1. 필요하다면 이미지 업데이트를 하더라도 자동 배포가 되지 않도록, 수동으로 배포를 진행할 수도 있다.
2. 만약 ECS 서비스 설정에서 이미지가 새 버전으로 업데이트 될 때마다 새로운 작업을 추가하게 설정했다면, 이미지가 업데이트 된다면 기존에 설정했던 작업 설정대로 새로운 컨테이너가 올라감.