[AWS] ECS Rolling Update, Blue/Green 배포 방식이란?

01. ECS Codeploy Blue/Green 도입 검토

ECS는 기본적으로 Rolling Update 방식으로 배포를 진행한다. 하지만 AWS에서 제공하는 코드 시리즈를 사용하려면, Rolling Update를 사용하는 것이 아니라 Blue/Green을 배포 유형(Deployment Type)로 지정해줘야 한다. 하여, 이번 시간에는 Rolling Update와 Blue/Green이란 무엇인지? 배포 방식으로는 어떤 부분이 존재하는지 알아본다.

02. ECS는 어떤 배포 방식이 존재할까?

AWS ECS의 배포 방식은 크게 롤링 업데이트(Rolling Update), Blue/Green, 외부(External) 3가지 방식이 존재한다. 우선 Rolling Update에 대해 알아보고 Blue/Green 배포 방식까지만 정리해본다.

• 롤링 배포: V1 → V2로 점진적 교체
• 블루-그린 배포: 2개의 Target Group을 통해 새 환경 구축 후 트래픽만 전환
• 카나리 배포: 일부 사용자만 새 버전 사용
• 전체 배포: 전체를 한 번에 교체

02-1. 롤링 업데이트(Rolling Update)

🚀 롤링 배포(Rolling Deployment)란? 무중단 배포 방식 완벽 정리

태스크를 대체하여 Amazon ECS 서비스 배포 - Amazon Elastic Container Service

롤링 업데이트(Rolling Update)는 S/W 배포 전략 중 하나로, 애플리케이션의 모든 인스턴스를 동시에 업데이트하지 않고, 점진적으로 일정한 단위(인스턴스/파드)를 교체하는 배포 방식이다. ECS에서 롤링 업데이트(Rolling Update) 유형을 지정하면, ECS 서비스 스케쥴러가 현재 실행중인 Task(V1)를 신규 Task(V2)로 대체한다. 또한, 롤링 업데이트 중 ECS Service에서 추가 되거나 제거되는 ECS Task 수는 배포 구성에 의해 제어된다. 여기서 말하는 배포 구성은 minimumHealthyPercent, maximumPercent 옵션 값을 의미한다.

1. ECS 롤링 업데이트 진행 순서

• ECS가 새 버전의 Task 1개(v2)를 먼저 띄운다
• 이 v2 Task의 Health Check가 통과되면, 기존 v1 Task 1개를 종료
• 다음 v2 Task 1개를 띄우고 → 기존 v1 Task 1개를 종료
• 이런 방식으로 기존 v1 → v2를 순차적으로 교체

2. 문제점

롤링 업데이트(Rolling Update)는 새 버전(v2)이 올라오면, 이전 버전(v1)은 실시간으로 사라지기에, 문제가 생겨도 기존 버전을 즉시 복구하는것은 불가능함. 이러한 이슈로 인해 완전한 롤백을 하려면, Blue/Green 방식을 사용해야 한다.

그렇다면 위에서 배포 구성에 따라서, ECS Service에서 추가/제거되는 Task 수가 결정이 된다고 하였는데, 아래 2가지 옵션(minimumHealthyPercent / maximumPercent)에 대해 자세히 살펴보자.

3. 최소 실행 작업 비율(minimumHealthyPercent)

⚠️ 최소 정상 유지 Task 수 = desiredCount x (minimumHealthyPercent / 100)

minimumHealthyPercent 옵션은 배포가 진행되는 동안, 최소 몇 개의 Task가 정상적으로 구동이 되고 있어야 하는지를 정하는 옵션이다. 예를 들어 desiredCount가 5이고, minimumHealthyPercent가 100이면, 항상 최소 5개의 Task가 정상 상태로 있어야 하기 때문에, 새 버전의 Task가 정상 상태로 올라오기 전에는 기존 Task를 먼저 종료할 수 없다. 아래 예시를 살펴보자.

예시

✅ desiredCount: 5개

minimumHealthyPercent: 100%
⇒ 결과 : 5 x (100 / 100) = 5 → 총 5개 Task 반드시 정상 구동 필요

minimumHealthyPercent: 75%
⇒ 결과 : 5 x (75 / 100) = 3.75(내림) → 총 3개의 Task 반드시 정상 구동 필요

minimumHealthyPercent: 50%
⇒ 결과 : 5 x (50 / 100) = 2.5(내림) → 총 2개의 Task 반드시 정상 구동 필요

옵션에 따른 값은 위와 같다. 상황에 맞춰 사용하면 된다.

4. 최대 실행 작업 비율(maximumPercent)

🔥 최대 실행 가능 Task 수 = desiredCount × (maximumPercent / 100)

maximumPercent 옵션은 배포가 진행되는 동안, 동시에 실행할 수 있는 최대 Task 수의 비율을 제한하는 설정이다. 이 비율은 desiredCount를 기준으로 계산되며, 이 값이 클수록 더 많은 새(new) Task를 한 꺼번에 띄울 수 있어, 배포 속도가 빨라지고, 작을수록 점직적인 배포가 이루어져 리소스 소비를 줄일 수 있다. 아래 예시를 살펴보자.

예시

✅ desiredCount: 5개

maximumPercent: 200%
⇒ 결과 : 5 x (200 / 100) = 10 → 총 10개의 Task 동시 실행 가능

maximumPercent: 150%
⇒ 결과 : 5 x (150 / 100) = 7.5(내림) → 총 7개 Task 동시 실행 가능

maximumPercent: 100%
⇒ 결과 : 5 x (100 / 100) = 1 → 총 5개 Task 동시 실행 가능

 

보통은 200%로 잡는게 배포를 한 방에, 그리고 빠르게 진행할 수 있는 방법인 것 같다.

추가로, 롤링 업데이트와 관련 상태 검사 유예 기간이라는 옵션도 알고 있어야 한다.
내용은 아래와 같다.

5. 상태 검사 유예 기간(HealthCheck Grace Period)

“ECS Task를 죽일까 말까?” 를 판단하는 옵션이며, 트래픽은 ALB에서 Task를 정상으로 판단하면 들어오기 시작한다.

상태 검사 유예 기간(HealthCheck Grace Period)은 새 Task가 시작된 뒤, 일정 시간 동안 상태 검사 실패가 있어도 ECS가 Task를 종료하지 않고 기다려주는 시간이다. 이 기간 동안 ALB(Target Group)에서 Task가 unhealthy로 보일 수 있지만, ECS는 이를 무시하고 Task를 RUNNING 상태로 유지한다.

How Elastic Load Balancing works - Elastic Load Balancing

또한, 정말 중요하다 생각하는 부분인데, 실제 ALB → TG → ECS로 트래픽이 유입되는 시점은 ALB에 연동되어 있는 Target Group에서 Health Checking Green이 된 상태에만, 트래픽을 전달하기 시작한다고 한다. (테스트는 안해봤음) 그렇기에 위에서 말한 상태 검사 유예 기간이 트래픽이 들어오는 것을 기다리는 시간으로 착각하면 안되고, 단지 ECS Task를 죽일지 말지를 결정하는 옵션 정도로 이해해야 할것이다.

02-2. Code Deploy를 Blue/Green 배포 방식

ECS CICD Automation - 9. ECS Linear, Canary Deployment Intro

Blue/Green 배포는 기존에 트래픽을 받고 있던 애플리케이션(Blue)과 동일한 환경(Green)을 별도로 구동한 뒤, 새 버전을 Green에 배포해 테스트 및 검증을 거친 후, 이상이 없을 경우 트래픽을 Green으로 전환하는 무중단 배포 방식이다.

 

Blue/Green 방식과 Rolling Update의 차이는, Rolling Update는 CodeDeploy 같은 별도의 CD 도구 없이도 사용 가능하지만, 배포 중 기존 버전(v1)과 새 버전(v2)이 공존하는 구조이며, 인프라 비용 측면에서는 상대적으로 유리하다. 반면, Blue/Green 배포는 환경 구성에 따라 비용은 증가할 수 있으나, 사용자에게 두 버전(v1/v2)이 동시에 노출되지 않으며, 문제가 생기면 빠르게 이전 버전(Blue)으로 롤백할 수 있는 장점이 있다.

Blue/Green의 배포 구성은 아래와 같이 3가지(AllAtOnce, Canary, Linear)가 존재한다. 배포 구성에 대해 알아보자.

1. CodeDeploy ECS Blue/Green 배포 구성

CodeDeployDefault.ECSAllAtOnce

• 설명 : 전체 트래픽을 한 번에 기존(Blue) 환경에서, 새 환경(Green)로 전환하는 방식
• 특징
  • 전환 속도 : 가장 빠름 (즉시 전체 전화)
  • 공존 여부 : 없음 (시용자 트래픽 한 시점에 전부 전환)
  • 위험도 : 문제 발생 시, 시스템 전반에 영향을 미칠 수 있음
  • 사용 예시 : 내부 시스템, QA 환경, 영향도 적은 서비스 변경 시

✅ CodeDeployDefault.ECSLinear10PercentEvery1Minutes

• 설명 : 전체 트래픽을 10%씩 1분마다 Green 환경으로 점직적으로 이동시키는 방식
• 특징
  • 전환 속도 : 느림 (총 10분 소요)
  • 공존 여부 : 있음 (전환 중 Blue와 Green이 동시에 트래픽 처리)
  • 위험도 : 낮음 (문제 발생 시 빠르게 중단 가능)
  • 사용 예시 : 민감한 프로덕션 환경, 사용자 수가 많은 서비스

CodeDeployDefault.ECSLinear10PercentEvery3Minutes

• 설명 : 전체 트래픽을 10%씩 3분마다 Green 환경으로 점진적으로 이동시키는 방식
• 특징
  • 전환 속도 : 매우 느림 (총 30분 소요)
  • 공존 여부 : 있음 (전환 중 Blue와 Green이 동시에 트래픽 처리)
  • 위험도 : 매우 낮음 (문제 발생 시 빠르게 중단 가능)
  • 사용 예시 : 대규모 서비스 환경

✅ CodeDeployDefault.ECSCanary10percent5Minutes

• 설명 : 초기 트래픽 10%를 Green 환경에 먼저 전환하고, 5분 뒤 나머지 90%를 한 번에 전환하는 방식
• 특징
  • 전환 속도 : 중간 (총 5분 대기 후 전환)
  • 공존 여부 : 있음 (초기 5분간 일부 트래픽만 Green로 이동)
  • 위험도 : 낮음 (초기 사용자 기반 판단 가능)
  • 사용 예시 : 기능 업데이트 시 조기 반응 체크용

CodeDeployDefault.ECSCanary10percent15Minutes

• 설명 : 초기 트래픽 10%를 Green 환경에 먼저 전환하고, 15분 뒤 나머지 90%를 한 번에 전환하는 방식
• 특징
  • 전환 속도 : 느림 (총 15분 대기)
  • 공존 여부 : 있음
  • 위험도 : 매우 낮음
  • 사용 예시 : 고위험 서비스, 금융/결제 시스템 외부 고객 대상 배포

그렇다면 Canary, Linear 배포란 무엇인지 한 번더 살펴보자.

1. Canary(카나리아 배포)

카나리아(Canary) 배포는 Blue/Green 배포 전략의 일종으로, 처음에는 10% 트래픽만 Version2로보내서 성능 및 안정성을 테스트한다. 후에, 문제가 없으면 나머지 트래픽도 Version2로 전환해 위험을 최소화 하는 방식이다. 배포 실패시에는 자동 롤백 기능이 제공된다. 하지만, 특정 HTTP 오류(503, 504, 400, 499)를 감지하여 롤백을 수행하려면 Cloudwatch 경보를 설정해야 한다.

🚨 Cloudwatch 설정 절차

1. Cloudwatch 경보 생성 : 모니터링할 지표(HTTPCode_Target_5xx_Count) 경보 생성
2. CodeDeploy 배포 그룹 구성 : 배포 그룹에 생성한 경보를 연결하고, 경보 활성화 시 자동 롤백 되도록 설정
3. 배포 구성 적용 : 배포 시 해당 배포 그룹을 사용하여 배포 진행

2. Linear(선형 배포)

선형(Linear) 배포도 마찬가지로 Blue/Green 배초 전략 중 하나로, 동일한 비율의 트래픽(예: 10 %)를 고정된 간격(예: 1분 - 3분)마다 새 버전으로 반복 전환하여, 모든 트래픽이 전환될 때까지 지속하는 배포 방식이다.

03. ECS Blue/Green 관련 용어 정리

CodeDeploy Blue/Green 배포를 진행하는 경우, 대부분 CodeCommit + CodeBuild + CodeDeploy + CodePipeline을 통해 CI/CD 파이프라인을 구성한다. 이 때, 필요한 대표적인 파일은 appspec.yaml, buildspec.yaml, taskdef.json, imagedefinitions.json이 존재하고, 추가적인 CodeDeploy의 설정이 존재한다. 관련하여 위에서 말한 순서대로 알아보자. 우선 appspec.yaml 파일이다.

1. appspec.yaml

CodeDeploy를 통해 어떤 서비스를 배포할것인지? 그리고 로드밸런서 트래픽을 어느 컨테이너로 연결할지?

# AppSpec 파일 버전 (현재는 무조건 version: 1 사용)
version: 1

# 배포 리소스 목록 (여기서는 ECS 서비스 하나)
Resources:
  - TargetService:
      Type: AWS::ECS::Service # 배포 대상이 ECS 서비스임을 명시
      Properties:
        TaskDefinition: "<TASK_DEFINITION_NAME>" # 새로 배포할 Task Definition 이름 (CodePipeline에서 자동 치환됨)
        LoadBalancerInfo:
          ContainerName: "<CONTAINER_NAME>" # ALB와 연결된 ECS Task 내 컨테이너 이름
          ContainerPort: 8000 # ALB가 라우팅할 컨테이너 포트 (Targate Group 포트와 동일해야 함)
        PlatformVersion: "1.4.0" # ECS 버전 기재
        NetworkConfiguration:
          AwsvpcConfiguration:
            Subnets: ["subnet-xxxxxxxx", "subnet-xxxxxxxx", "subnet-xxxxxxxx"] # ECS private subnets
            SecurityGroups: ["sg-xxxxxxxx"] # ECS Task container api security group
            AssignPublicIp: "DISABLED" # ECS Task public ip status
#        CapacityProviderStrategy:
#        - Base: 1
#          CapacityProvider: "FARGATE_SPOT"
#          Weight: 1
#        - Base: 0
#          CapacityProvider: "FARGATE"
#          Weight: 1
#Hooks:
#  - BeforeInstall: "LambdaFunctionToValidateBeforeInstall"
#  - AfterInstall: "LambdaFunctionToValidateAfterInstall"
#  - AfterAllowTestTraffic: "LambdaFunctionToValidateAfterTestTrafficStarts"
#  - BeforeAllowTraffic: "LambdaFunctionToValidateBeforeAllowingProductionTraffic"
#  - AfterAllowTraffic: "LambdaFunctionToValidateAfterAllowingProductionTraffic"

appspec.yaml 파일은 기본적으로 프로젝트의 루트 경로에 위치하면 된다. 첫 번째로 appspec.yaml 파일은 CodeDeploy를 통해 배포를 진행 할 떄, CodeDeploy가 어떤 서비스를 배포해야 하는지 명시하는 파일이다. 예를 들면 ECS Blue/Green을 사용하는 경우 어떤 Task Definition을 배포할지 명시해주는 옵션이 존재한다. 두 번째로는, 로드밸런서 연결 정보를 명시하는데 어떤 컨테이너 포트에 ALB 트래픽을 연결할지 지정한다. 세 번째로는 배포 라이프사이클 훅을 정의하는 란이 존재한다. 해당 란의 CodeDeploy에 의해 배포가 완료되면 Hook 이벤트를 통해 다른 서비스를 호출해야 하는 경우 사용한다.

2. buildspec.yaml

CodeBuild를 사용하는 경우, 빌드 스크립트을 작성해야 하는 경우 사용되는 파일

version: 0.2 # BuildSpec 파일 버전

phases:
  install:
    runtime-versions:
      java: corretto11
    commands:
      - echo Installing dependencies...
      - ./gradlew clean build

  pre_build:
    commands:
      - echo Preparing for build...
      - mkdir -p deploy

  build:
    commands:
      - echo Building application...
      - cp build/libs/myapp.jar deploy/

  post_build:
    commands:
      - echo Build completed. Preparing for deployment...
      - aws s3 cp appspec.yml s3://my-bucket/deploy/appspec.yml
      - aws s3 cp deploy/myapp.jar s3://my-bucket/deploy/myapp.jar

artifacts:
  files:
    - appspec.yml
    - deploy/myapp.jar

마찬가지로, buildspec.yaml 파일 역시 프로젝트 루트(root) 경로에 위치하면 된다. 해당 파일은 AWS CodeBuild가 빌드 작업을 수행할 때 필요한 파일이다. 주로, 필요한 패키지를 설치하고, ECR에 이미지를 업로드하는 등의 빌드 작업을 수행한다. 또한, imagedefinitions.json 파일과 appspec.yaml 파일을 생성하여 CodeDeploy로 넘기는 작업도 수행할 수 있다.

3. taskdef.json

ECS에 새로운 Task 등록 → CodeDeploy에서는 해당 Task기반 배포 진행

{
   "executionRoleArn":"arn:aws:iam::account_ID:role/ecsTaskExecutionRole",
   "containerDefinitions":[
      {
         "name":"sample-website",
         "image":"<IMAGE1_NAME>",
         "essential":true,
         "portMappings":[
            {
               "hostPort":80,
               "protocol":"tcp",
               "containerPort":80
            }
         ]
      }
   ],
   "requiresCompatibilities":[
      "FARGATE"
   ],
   "networkMode":"awsvpc",
   "cpu":"256",
   "memory":"512",
   "family":"ecs-demo"
}

taskdef.json 파일은 ECS에 새로운 Task Defintion을 등록하기 위한 설정 파일로, 일반적으로는 AWS CodeBuild에 의해 생성이 된다. AWS CodeBuild의 postbuild에서 aws s3 cp를 통해 S3에 버킷에 업로드가 되면, CodeDeploy는 배포 시점에 S3의 파일을 읽어 새로운 Task Definition을 등록하고, appspec.yaml 내 TaskDefinition 항목을 해당 ARN으로 자동 치환하여 배포를 수행한다.

4. imagedefinitions.json

[
  {
    "name": "컨테이너 이름"
    "imageUri": "이미지URL:latest"
  }
]

taskdef.json은 ECS Task Definition 전체를 새로 생성/정의해야 할 때 사용한다. 반면 imagedefinitions.json은 기존 Task Definition 구조는 유지하고 컨테이너 이미지 URI(태그명)만 교체할 때 사용한다. 두 파일은 함께 사용하지 않으며, 배포 목적에 따라 하나만 선택해 사용해야 한다. 아래 2가지 흐름을 살펴보면 이해가 될 것으로 보인다.

taskdef.json 사용 흐름

[CodeCommit or GitHub]
       ↓
[CodePipeline]
       ↓
[CodeBuild]
   └─ buildspec.yml
       └─ taskdef.json 생성
       └─ appspec.yaml 생성
       └─ S3 업로드
       ↓
[CodeDeploy]
   └─ S3에서 taskdef.json, appspec.yaml 읽음
   └─ ECS에 새 TaskDefinition 등록
   └─ appspec.yaml 내 TaskDefinition ARN 자동 치환
   └─ ECS 배포

imagedefinitions.json 사용 흐름

[CodeCommit or GitHub]
       ↓
[CodePipeline]
       ↓
[CodeBuild]
   └─ buildspec.yml
       └─ imagedefinitions.json 생성
       └─ CodePipeline한테 아티팩트로 전달
       ↓
[CodePipeline - Deploy 단계]
   └─ imagedefinitions.json 읽음
   └─ 기존 TaskDefinition 복사
   └─ 이미지 URI(Tag명)만 교체하여 새 TaskDefinition 생성
   └─ ECS 배포

5. CodeDeploy 콘솔 “애플리케이션(Application)” 탭(Tab)

[CodeDeploy 애플리케이션]
    └── [배포 그룹 (Deployment Group)]
          └── [ECS 서비스 또는 EC2, Lambda 등]

CodeDeploy의 애플리케이션(Application)은 어떤 AWS 서비스(ECS, EC2, Lambda)를 통해 배포를 진행할지 지정하는 최상위 배포 단위다. 또한, 배포 그룹은 CodeDeploy 애플리케이션(Application)을 통해, 어떤 클러스터, 로드밸런서, 대상 그룹, 배포 전략 등을 지정하는 단위를 의미한다. 마지막으로 배포 생성은 위에서 설정한 배포 그룹을 기반으로, 실제 배포가 한 번 실행되는 것을 의미한다. 배포 생성을 진행할 때, S3나 appspec.yaml을 지정하여 배포를 진행할 수 있다.

지금까지 ECS Rolling Update, Blue/Green 배포 방식에 대해 정리해보았다. 이상으로 포스팅을 마친다.

99. 참고 자료

AppSpec 파일 예 - AWS CodeDeploy

CodeDeploy에서 배포 구성 작업 - AWS CodeDeploy

[CodePipeline] ECR을 소스로 해서 CodeDeploy로 ECS 배포하기

AWS ECS + Fargate 를 이용해 애플리케이션 배포하기

AWS CodePipeline 으로 AWS ECS(Fargate) 배포하기 (with S3, CodeBuild, CodeDeploy)

AWS codedeploy 를 사용하여 ECS blue/green 배포하기

ECS CICD Automation - 9. ECS Linear, Canary Deployment Intro