CI/CD 설계

0. 기존 CD 파이프라인의 한계

V1에서는 GitHub Actions를 통해 이미지를 빌드한 뒤 EC2에 SSH로 접속하여 배포 스크립트를 실행하고, Nginx 기반 Blue/Green 방식으로 배포하였다.

CD의 한계

V1에서는 신규 컨테이너가 Health Check를 통과하면 정상 배포로 판단하고 트래픽을 전환한다.

그러나 Health Check만으로는 특정 API 오류, 서비스 간 연동 실패 등 실제 기능의 정상 동작까지 보장할 수 없다.

또한 배포 이후 문제가 발생할 경우 개발자가 직접 장애를 확인하고 이전 버전으로 롤백해야 하므로 장애 감지와 복구 과정에 수동 개입이 필요하다.

따라서 V2에서는 다음을 목표로 CI/CD 파이프라인을 개선한다.

• Production 배포 전 실제 환경에서 핵심 기능을 검증한다.
• 배포 중 Task가 정상적으로 안정화되는지 검증한다.
• 배포 이후 실제 서비스 지표를 통해 이상 여부를 판단한다.
• 배포 실패 시 이전 정상 Deployment로 자동 롤백한다.

---

1. CD 파이프라인 요약

2. 전체 배포 전략

V2에서는 배포 과정에서 다음과 같은 3단계 검증 구조를 사용한다.

단계	검증 목적	검증 방법	실패 시 처리
Staging Smoke Test	주요 기능이 실제 환경에서 정상 동작하는가	Staging ECS + Staging DB에서 핵심 시나리오 테스트	Production 배포 중단
배포상태 검증	신규 Task가 정상적으로 실행되고 안정화되는가	ECS Deployment Circuit Breaker	Deployment 실패 및 자동 롤백
Production 검증	실제 트래픽에서도 신규 버전이 정상 동작하는가	CloudWatch Alarm	Deployment 실패 및 자동 롤백

각 단계는 서로 다른 문제를 검증한다.

• Staging Smoke Test: 기능 및 서비스 연동 검증
• Circuit Breaker: 배포 및 Task 안정성 검증
• CloudWatch Alarm: 실제 운영 트래픽에서 발생하는 이상 검증

2-1. Staging 환경 구성

Production 배포 전에 실제 ECS 환경에서 핵심 사용자 시나리오를 검증하기 위해 Staging 환경을 구성한다.

Staging 환경은 상시 운영하지 않고 배포 시점에만 활성화한다.

주요 설정

항목	설정
ECS Cluster	Production과 동일 Cluster 사용
ECS Service	Staging 전용 Service
평상시 Desired Count	0
테스트 시 Desired Count	1
DB	Staging 전용 DB (EC2 t3.micro)
ALB Target Group	Staging 전용 Target Group
ALB	기존 ALB 공유
접근 경로	staging.star23.com
실행 주체	GitHub Actions
종료 조건	Smoke Test 성공 또는 실패 후 항상 종료

Staging 환경은 Production과 ECS Cluster 및 ALB를 공유하지만 Target Group, ECS Service, DB를 분리하여 테스트가 Production 환경에 영향을 주지 않도록 한다.

---

3. Production 배포 전략

3-1. Rolling Deployment 주요 설정

설정	초기 설정	목적
Deployment Strategy	Rolling	Task를 점진적으로 신규 버전으로 교체
minimumHealthyPercent	100%	배포 중 기존 서비스 처리 용량 유지
maximumPercent	200%	기존 Task를 유지하면서 신규 Task 우선 실행
Deployment Circuit Breaker	Enable	신규 Deployment 실패 감지
Circuit Breaker Rollback	Enable	실패 시 이전 정상 Deployment 복구

3-2. Deployment Circuit Breaker

Rolling Deployment 과정에서 신규 Task가 정상적으로 실행되지 못하는 경우를 자동으로 감지하기 위해 ECS Deployment Circuit Breaker를 활성화한다.

Circuit Breaker를 통해 신규 Deployment가 정상 상태에 도달하지 못하는 상황을 감지하여 Deployment를 실패 처리한다.

주요 설정

항목	설정
Circuit Breaker	Enable
Rollback	Enable
적용 대상	Production ECS Service
실패 결과	Deployment FAILED
복구 대상	이전 정상 COMPLETED Deployment

이를 통해 신규 Task가 정상적으로 배포되지 못하는 경우 ECS가 이전 정상 Deployment로 자동 복구한다.

3-3. Production 배포 이후 검증

Task가 정상적으로 실행되고 Health Check를 통과했다고 해서 실제 서비스의 모든 기능이 정상임을 보장할 수는 없다.

따라서 Production에 실제 트래픽이 유입된 이후 CloudWatch Alarm을 이용하여 서비스 상태를 추가로 검증한다.

3-3-1. 초기 모니터링 지표

지표	목적	기준
ALB Target 5XX	신규 Application 오류 탐지	SLO 선정 후 결정
Target Response Time	응답 성능 저하 탐지	SLO 선정 후 결정

3-3-2. CloudWatch Alarm과 자동 롤백

Production ECS Deployment에 CloudWatch Alarm을 연결한다.

신규 버전 배포 과정에서 지정된 CloudWatch Alarm이 ALARM 상태가 되면 해당 Deployment를 실패로 판단하고 자동 롤백한다.

주요 설정

항목	설정
Deployment Alarm	Enable
Rollback	Enable
Primary Metric	ALB Target 5XX
Latency Metric	Target Response Time
Bake Time	초기값 검증 필요
Alarm 발생 시	Deployment FAILED
Rollback 대상	Last COMPLETED Deployment`

전체 흐름은 다음과 같다.

Rolling Deployment 완료 
→ 실제 트래픽 처리 
→ CloudWatch Alarm 관찰 
→ 정상 시 COMPLETED / 이상 시 FAILED 
→ 이상 시 Automatic Rollback

실제 서비스 지표를 관찰함으로써 Health Check만으로 배포 성공 여부를 결정했던 V1의 한계를 보완한다.

---

4. 최종 배포 성공 기준

V1에서는 Health Check 통과 여부만으로 배포 성공을 판단하였다.

V2에서는 배포 성공을 다음 세 단계로 확장한다.

1. Staging Smoke Test 통과
   • 실제 배포 환경과 유사한 환경에서 핵심 기능이 정상적으로 동작한다.
2. Production Deployment Steady State 도달
   • 신규 Task가 정상적으로 실행되고 ECS Deployment가 Steady State에 도달한다.
3. Production 지표 정상
   • 실제 사용자 트래픽을 처리하는 동안 지정된 CloudWatch Alarm이 발생하지 않는다.

세 조건을 모두 만족한 경우에만 Production Deployment를 최종 성공으로 판단한다.

이를 통해 V1의 단순 Health Check 기반 배포 검증과 수동 롤백 구조를 개선하고, 배포 전 기능 검증부터 배포 후 운영 지표 검증 및 자동 복구까지 포함하는 CD 파이프라인을 구성한다.

---

5. 개선점 총 정리

구분	V1	V2	개선점
배포 방식	Nginx 기반 Blue/Green	ECS Rolling Deployment	ECS Service 기반의 점진적 Task 교체
배포 중 가용성	일정 시간 Blue/Green 환경 유지	minimumHealthyPercent로 최소 Healthy Task 유지	Rolling 중 서비스 처리 용량 유지
배포 자원 제어	Blue/Green 컨테이너 직접 관리	maximumPercent로 최대 Task 수 제어	배포 중 추가 자원 사용량 제어
배포 안정성 판단	Health Check	Stag 환경 Smoke Test, Steady State	신규 Task의 기동 및 배포 안정화 실패 자동 감지
배포 후 검증	별도 검증 없음	CloudWatch Alarm으로 5XX, Response Time 관찰	실제 사용자 트래픽 기반 이상 탐지
배포 성공 기준	Health Check 통과	Steady State 도달 + 일정 시간 동안 Alarm 미발생	단순 기동 여부에서 실제 서비스 상태까지 검증 범위 확대
장애 감지	개발자가 직접 확인	Circuit Breaker + CloudWatch Alarm	배포 과정의 장애 자동 감지
Rollback 실행	EC2 접속 후 수동 복구	Automatic Rollback	장애 발생 시 이전 정상 Deployment로 자동 복구
Rollback 대상	개발자가 이전 이미지/컨테이너 버전 확인	Last COMPLETED Deployment	복구 과정 자동화
운영 관리	SSH 및 배포 스크립트 중심	ECS Service 중심	관리 지점 감소