ECS - EC2 간단 배포하기 [3] - ci/cd 설계

프로젝트에서 자주 사용하는 CI/CD 파이프라인

기존에 AWS 프리티어를 사용해서 자주하는 CI/CD 파이프라인은 아래 그림과 같다.

• 깃헙 액션을 통해서 jar 파일을 빌드하고, 해당 파일을 이미지로 만든다.
• 이미지를 도커 허브에 올린다.
• SSH 를 통해 EC2에 접속하여 도커 허브에 있는 이미지를 Pull 받는다
• EC2 인스턴스에서 해당 이미지를 실행한다.

 

ECS를 활용한 CI/CD 파이프라인

ECS(Elastic Container Service)를 활용한 CI/CD 파이프라인은 아래 그림과 같다 기존의 도커허브의 역할을 ECR이 해주고, EC2에서 직접 접속하여 서버를 실행하던 걸, ECS가 대신해주는 방식만 달라졌다. 아래와 같은 방식으로 실행해도, 프리티어 영역 내기 때문에 과금이 될 요소는 전혀 없다.

• 깃헙 액션을 통해서 jar파일을 빌드하고, 해당 파일을 이미지로 만든다.
• 이미지를 Amazon ECR에 올린다.
• Task Definition을 수정하고, ECS에 배포를 요청한다.
• ECS는 Task Definition을 보고, EC2에 해당 이미지를 실행한다.

 

ECS를 사용하면서 얻게되는 장점

🙋‍♂️CI/CD가 수행되는 단계자체는 크게 달라지지 않는다. 그렇다면 기존 파이프라인에서 ECS를 사용하는 파이프라인으로 변경하면서 얻게되는 장점은 무엇일까?

• 자동화 수준 향상
  • 빌드(이미지 생성) → ECR 등록 → ECS 배포까지 파이프라인이 자동화되므로, 수동으로 EC2에 SSH 접속해 이미지를 Pull 받거나 컨테이너를 실행할 필요가 없다.
  • GitHub Actions에서 SSH 비밀키 등 직접 접속 정보를 관리하지 않아도 되므로, GitHub Secrets 관리 부담이 줄어든다.
• 오케스트레이션 기능
  • ECS는 컨테이너의 롤링 업데이트, 서비스 확장(스케일 아웃/인), 태스크 할당 등 오케스트레이션 기능을 기본 제공하므로, 수작업 없이도 확장성과 유연성을 확보할 수 있다.
• 자동 복구(셀프 힐링) 능력
  • 컨테이너가 예기치 않게 종료되면 ECS가 이를 감지해 자동으로 재시작한다. 별도의 모니터링/알림 시스템이 없어도 장애에 대한 대응력이 높아진다.
• AWS 서비스와 긴밀한 통합
  • ECR을 통한 이미지 관리, IAM 연동 등을 통해 AWS 생태계와 자연스럽게 통합되어 보안 및 접근 권한 관리가 편하다.
  • CloudWatch, EventBridge 등 다른 AWS 서비스와도 쉽게 연계하여 모니터링/로그 수집을 확대할 수 있다.

 

 

다음편부터는 첫번째 그림과 같이 ci/cd가 실행되고 있던 프로젝트를 실제 웹 상에 배포하고, 두번째 그림처럼 ECS를 활용하여 ci/cd를 수행할 수 있도록 해보겠다.