AWS ECS 무중단 CI/CD Pipeline 0. ECS 배포하게 된 배경

기존 배포 방식

기존 배포 방식과 CodeDeploy의 한계

처음에는 단일 EC2 인스턴스에 수동으로 애플리케이션을 배포했습니다. 
매번 터미널을 통해 파일을 옮기고 명령어를 실행하는 반복적인 작업은 시간이 많이 소요되고, 작은 실수로도 서비스 장애가 발생할 수 있는 위험한 방법이었습니다.
이후 AWS CodeDeploy를 도입하여 자동화를 시도했지만, 서버 장애 시 수동으로 재시작해야 했고, 배포 과정에서 예기치 않은 오류들이 빈번히 발생했습니다.
CodeDeploy가 서버 상태를 제대로 감지하지 못해 배포 실패가 발생하면 수동으로 재설정해야 했습니다.
이로 인해 배포 과정은 여전히 불안정하고 스트레스가 많았습니다.

Docker와 ECS로의 전환

이 문제를 해결하기 위해 Docker와 AWS ECS(Elastic Container Service)를 도입하기로 결정했습니다.
Docker를 사용하면 애플리케이션과 그 의존성을 컨테이너에 담아 일관된 환경에서 실행할 수 있었고, 이를 통해 개발 환경과 배포 환경의 차이로 인한 문제를 해결할 수 있었습니다.
하지만 Docker를 처음 접하는 것은 쉽지 않았습니다.
Dockerfile 작성과 이미지 빌드 과정에서 많은 시행착오를 겪었고, ECS 클러스터 설정과 관리에서도 어려움이 많았습니다.
 
특히, 컨테이너 간 네트워킹과 로드 밸런싱 설정에서 여러 문제를 해결해야 했습니다.
여러 차례의 실패를 통해 ECS를 안정적으로 구축, 운영할 수 있게 되었습니다.
CI/CD 파이프라인을 구축하여 자동으로 Docker 이미지를 빌드하고 ECS에 배포할 수 있게 되었으며, Auto Scaling 기능을 활용하여 트래픽 증가에 따라 자동으로 인스턴스를 추가할 수 있었습니다.
 
사실 저는 Docker를 자세히 학습한 적이 없어 매우 부족했습니다.
이를 학습하기 위해 두 가지 강의를 들었습니다.
 
GitAction을 활용한 무중단 CI/CD는 CodeDeploy로 경험해보았지만, Docker는 저에게 너무 생소했습니다.
아래 두 가지 강의로 학습을 진행하였습니다. 처음에는 AWS 강의를 듣다가, Docker에 대한 이해가 부족해 도커 강의를 들은 후 다시 AWS 강의를 학습하였습니다.
 
첫 번째 강의는 "AWS 배포 완벽가이드 - ECS"였습니다.
이 강의에서는 AWS ECS를 사용하여 Docker 컨테이너를 배포하고 관리하는 방법을 배웠습니다. ECS 클러스터를 설정하고, 서비스와 태스크 정의를 작성하며, Auto Scaling과 로드 밸런싱을 설정하는 과정을 상세히 다루었습니다. 이를 통해 ECS의 기본 개념을 알게 되었습니다.

 
두 번째 강의는 "2024 개발자를 위한 쉬운 도커" 강의였습니다.
Dockerfile 작성, 이미지 빌드 및 배포, Docker Compose를 활용한 멀티 컨테이너 환경 설정 등 Docker의 전반적인 개념과 실습을 통해 깊이 있는 이해를 쌓았습니다.
이 과정을 통해 Docker를 사용하는 방법과 장점을 체험할 수 있었고, 이후 AWS ECS와의 연계를 보다 원활하게 할 수 있었습니다.

 
위 두 가지 강의를 학습하며 가장 먼저 든 생각은 어떻게 우리 서비스에 적용할 수 있을까였습니다. 
두 번째로는 백엔드와 배포 환경 사이의 벽이 허물어졌다는 느낌을 받았습니다. 
세 번째로는 학교에서 학습한 운영체제와 Docker의 밀접한 관계를 이해하게 되었습니다. 
네 번째로는 ECS를 학습한 후, 다음 기회가 된다면 비슷한 기술인 Kubernetes도 학습해보고 싶다는 생각이 들었습니다.
 
강의가 매우 길었지만, 1주일을 갈아넣어 완강한 후 제 서비스에 적용시키기 위해 계획을 세우기 시작했습니다.강의가 매우 길었습니다. 1주일을 갈아넣어 완강한 후 나의 서비스에 적용시키기 위해 판을 짜보았습니.

강의와 프로젝트의 서비스 차이

AWS 강의와 저의 서비스는 크게 3가지 정도 차이가 있었습니다.
1. AWS 강의는 node js를 사용한 간단 api이지만 우리의 서비스는 Spring Boot를 활용한 복잡한 서비스입니다.
2. 강의 내에서는 클러스터 속 서비스를 node service와 redis service로 두었지만, 우리의 서비스는 프론트와 백엔드가 필요합니다.
3. 강의에서는 rest api 응답을 화면에 뿌려줬지만, 우리는 프론트가 화면을 뿌리고, 백엔드가 api로 응답하는 구조입니다.
 
위 차이를 적용하여 아래의 서비스로 배포에 성공하였습니다.

프로젝트 전체 아키텍처

 

설계한 아키텍처

설계한 아키텍처는 아래와 같습니다.
 
1. 자동화된 워크플로우 설정:
    - git action은 develop 브랜치의 커밋을 감지하면 자동으로 Java 설치, 체크아웃, application.yml 파일 생성 작업을 수행합니다.
    - Java 빌드 후, AWS ECS와 ECR 접근을 위한 자격 증명 권한을 생성합니다.
    - Docker를 통해 빌드된 이미지는 AWS ECR로 푸시되고, ECS 태스크 정의가 새로운 이미지로 업데이트되어 배포됩니다.
 
2. 아키텍처 구조:
    - 클러스터 내의 컨테이너 서비스는 private 보안 그룹으로 구성되어 외부의 모든 요청을 차단합니다.
    - 클러스터와 로드밸런서의 보안그룹은 동일하게 설정하여 로드밸런서가 클러스터에 접근할 수 있게 합니다.
    - 백엔드 서비스와 프론트 서비스는 같은 VPC 내에 있으므로 통신이 가능하며, 로드밸런서 또한 같은 보안 그룹을 가집니다.
 
3. 로드밸런서 설정:
    - 로드밸런서는 3개의 보안그룹을 가지며, 클러스터와 동일한 보안그룹, 모든 HTTP 요청을 받는 보안 그룹, 모든 HTTPS 요청을 받는 보안그룹을 포함합니다.
    - 로드밸런서의 리스너는 HTTP 요청을 HTTPS로 리다이렉트하여 보안을 강화합니다.
    - 로드밸런서의 리스너는 호스트의 이름이 api일 경우 백엔드 서비스로 이동시키고, 그 외에는 프론트로 이동시킵니다.
 
4. 트래픽 관리:
    - 인터넷 게이트웨이를 통해 라우터로 진입하면, 리스너가 호스트 이름에 따라 요청을 백엔드 또는 프론트엔드 대상 그룹으로 전달합니다. 
    - 100shot.net 사이트 앞에 호스트가 api이면 요청은 백엔드로 전달됩니다.
 
5. 서비스 구성:
    - 클러스터 내 서비스는 백엔드와 프론트엔드 컨테이너 서비스로 구성되어 있습니다.
    - 로드밸런서는 부하 분산을 위해 백엔드 태스크를 3개, 프론트엔드 태스크를 2개로 구성합니다.
 
6. 무중단 CI/CD 파이프라인:
    - 새로운 버전을 배포할 때 무중단 CI/CD 파이프라인을 구축하여 서비스의 안정성과 유연성을 높입니다.
 
강의를 듣고 우리 서비스에 적용하기 위해 2주일을 갈아넣었고, 결국 ECS 배포에 성공하였으며, 안정적인 무중단 CI/CD 파이프라인을 구축했습니다.
다음에 기회가 된다면 배포하는 과정을 작성해보겠습니다.