민혁이의 IT스토리

[AWS] - ECS 구조 완벽 정리: 클러스터, 서비스, 태스크 본문

AWS

[AWS] - ECS 구조 완벽 정리: 클러스터, 서비스, 태스크

FE_Minhyuk 2026. 1. 9. 19:50

도커(Docker)를 썼는데 왜 또 ECS가 필요해?


 

지난 포스팅에서 우리는 "내 프로그램을 컨테이너 박스(Docker)에 담아서 트럭(EC2)에 싣는 법"을 배웠습니다. 그런데 서비스가 대박이 나서 트럭이 100대로 늘어났다고 상상해 보세요.

  • 문제 1: 트럭 5대가 갑자기 고장 나면?
    -> 내가 직접 새벽에 일어나서 새 트럭을 불러야 합니다.

  • 문제 2: 트럭 1대에 짐이 너무 많이 실리면?
    -> 다른 빈 트럭을 찾아서 짐을 옮겨야 하는데, 어디가 비었는지 일일이 확인해야 합니다.

  • 문제 3: 프로그램을 업데이트하려면?
    -> 트럭 100대를 하나하나 세워서 짐을 갈아끼워야 합니다.

이 모든 '노가다'를 대신해 주는 자동화 시스템. 그게 바로 AWS ECS입니다.

한 줄 요약: ECS는 수많은 도커 컨테이너의 탄생(배포), 죽음(복구), 번식(스케일링)을 책임지는 관리 시스템입니다. (전문 용어로는 오케스트레이션이라고 합니다.)

 

 

 


ECS의 3대장 용어 정리 (아파트 단지에 비유하기)


ECS를 처음 접할 때 가장 헷갈리는 것이 클러스터, 서비스, 태스크입니다. 이 용어들은 아파트 단지를 생각하면 쉽습니다.

1. 클러스터 (Cluster) = 아파트 단지 (울타리)

가장 큰 단위입니다. 컨테이너들이 뛰어놀 논리적인 공간 입니다.

  • "여기서부터 저기까지가 우리 '배달 앱'이 돌아가는 구역이야!"라고 울타리를 치는 것과 같습니다.

2. 태스크 정의 (Task Definition) = 입주 설계도 (계약서)

실제 컨테이너를 실행하기 전, 어떤 스펙으로 지을지 적어둔 문서입니다.

  • "이 집에는 안방(CPU)은 얼마만 하게, 거실(RAM)은 몇 평으로 하고, 도커 이미지는 nodejs:18 버전을 쓸 거야"라고 정의합니다.

3. 태스크 (Task) = 실제 입주한 세대 (실행 중인 컨테이너)

설계도(Task Definition)를 보고 실제로 딱 만들어진 컨테이너 1개를 말합니다.

  • 우리가 만든 서버 프로그램이 실제로 살아서 숨 쉬고 있는 본체입니다.

4. 서비스 (Service) = 경비실 / 관리 사무소

가장 중요한 역할을 합니다. "항상 이 단지에는 5세대가 살고 있어야 해!"라고 규칙을 정하고 감시합니다.

  • 만약 태스크 1개가 에러로 죽었다? -> 서비스(경비실)가 즉시 발견하고 시체를 치운 뒤, 새로운 태스크를 1초 만에 입주시킵니다. (Auto Healing)

 


ECS의 두 가지 운영 방식 (Launch Types)


그럼 이 아파트(서버)는 누가 관리하나요?"에 따라 두 가지 모드로 나뉩니다.

1. EC2 모드 (직접 관리)

  • 방식: 내가 EC2 컴퓨터들을 직접 빌리고, 그 위에 ECS를 올리는 방식.
  • 장점: 컴퓨터 세팅을 내 마음대로 아주 디테일하게 할 수 있음. 저렴함.
  • 단점: OS 업데이트, 보안 패치 등 서버 관리를 내가 직접 해야 함. (귀찮음)
  • 비유: 자가 주택. 인테리어는 내 맘대로지만, 보일러 고장 나면 내가 고쳐야 함.

2. Fargate 모드 (서버리스)

  • 방식: EC2가 안 보입니다. AWS가 알아서 어딘가에 있는 서버에 컨테이너만 쏙 띄워줍니다.
  • 장점: 서버 관리 0%. 나는 오직 내 코드(컨테이너)에만 집중하면 됨.
  • 단점: EC2 모드보다 약간 비쌀 수 있음.
  • 비유: 호텔. 청소, 수리 다 호텔이 해줌. 나는 그냥 가서 잠만 자면 됨.

초보자나 소규모 프로젝트라면 정신 건강을 위해 Fargate를 강력 추천합니다.

 

 


왜 ECS를 써야 할까? (핵심 기능)


1. 자동 치유 (Self-Healing) 서버가 죽어도 개발자가 깰 필요가 없습니다. ECS가 "어? 개수가 모자라네?" 하고 즉시 새 컨테이너를 띄웁니다.

2. 무중단 배포 (Rolling Update) 업데이트할 때 서버를 끄지 않아도 됩니다.

"새 버전 컨테이너 하나 띄우고 → 잘 돌아가면 → 구 버전 하나 끄고" 이 과정을 반복해서 사용자는 에러 없이 자연스럽게 새 버전을 쓰게 됩니다.

3. 오토 스케일링 (Auto Scaling) 사용자가 몰리면 자동으로 컨테이너 개수를 늘리고(Scale-out), 밤에 사용자가 없으면 줄여서(Scale-in) 비용을 아껴줍니다.

 

 


결론:


개발자는 코드에만 집중할 수 있다.

 

 

과거에는 개발자가 서버실에 들어가서 선 꼽고, 리눅스 깔고, 밤새 서버 지키고 있어야 했습니다. (EC2만 쓰던 시절)

하지만 ECS가 등장하면서 우리는 "어떤 컨테이너를 몇 개 띄울지"만 정해주면 됩니다. 배치는 누가 하냐고요? 서버가 죽으면 누가 살리냐고요? 그건 우리의 똑똑한 비서 ECS가 다 알아서 할 겁니다.

다음 편에서는 실제로 AWS 콘솔에서 "Fargate를 이용해 서버 관리 없이 웹사이트 띄우기" 실습을 진행해 보겠습니다.

'AWS' 카테고리의 다른 글

[AWS] - EC2 개념 정리  (1) 2026.01.08