ECS 서비스 배포 완벽 가이드

AWS ECS에서 서비스를 생성하고 배포하는 방법을 실무 중심으로 배웁니다. Desired count 설정부터 롤링 업데이트까지, 안정적인 배포 전략을 단계별로 학습합니다.

1. ECS 서비스란?

어느 날 이개발 씨는 드디어 Docker 컨테이너로 만든 애플리케이션을 프로덕션에 배포하게 되었습니다. "이제 이걸 어떻게 운영하지?" 고민하던 중, 팀장님이 말씀하셨습니다.

"ECS 서비스로 관리하면 됩니다."

ECS 서비스는 지정한 수의 태스크가 항상 실행되도록 보장하는 관리 계층입니다. 마치 24시간 가게를 운영하면서 항상 직원 3명이 일하도록 관리하는 매니저와 같습니다.

컨테이너가 중단되면 자동으로 새로운 것을 시작해주고, 로드밸런서와 연결하여 트래픽을 분산시킵니다.

다음 코드를 살펴봅시다.

// AWS CLI로 ECS 서비스 생성하기
aws ecs create-service \
  --cluster my-cluster \
  --service-name my-web-service \
  --task-definition my-app:1 \
  --desired-count 3 \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-12345],securityGroups=[sg-12345],assignPublicIp=ENABLED}" \
  --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:...,containerName=web,containerPort=80"

// 서비스 상태 확인
aws ecs describe-services --cluster my-cluster --services my-web-service

이개발 씨는 지난 3개월 동안 열심히 웹 애플리케이션을 개발했습니다. Docker로 컨테이너화도 완료했고, ECR에 이미지도 올렸습니다.

이제 남은 것은 실제 사용자들이 접속할 수 있도록 배포하는 것입니다. "그냥 EC2에 Docker 실행하면 안 되나요?" 이개발 씨가 물었습니다.

팀장 박클라우드 씨는 웃으며 대답했습니다. "물론 가능하죠.

하지만 컨테이너가 갑자기 죽으면 어떻게 하시겠어요? 새벽 3시에 전화 받고 싶으세요?" ECS 서비스가 필요한 이유가 바로 여기에 있습니다.

ECS 서비스는 단순히 컨테이너를 실행하는 것을 넘어서, 운영 관점에서 필요한 모든 것을 제공합니다. 마치 24시간 편의점을 운영한다고 생각해봅시다.

항상 직원 3명이 근무해야 한다는 규칙이 있다면, 누군가 퇴근하거나 아프면 즉시 대체 인력을 투입해야 합니다. ECS 서비스도 마찬가지입니다.

"항상 컨테이너 3개를 실행하라"고 지시하면, 어떤 이유로든 컨테이너가 중단되면 자동으로 새로운 컨테이너를 시작합니다. 이것을 원하는 상태 유지라고 부릅니다.

서비스가 없던 시절에는 어땠을까요? 개발자가 직접 각 컨테이너를 관리해야 했습니다.

컨테이너가 죽었는지 확인하고, 수동으로 재시작하고, 로드밸런서 설정을 직접 변경해야 했습니다. 밤낮으로 모니터링하며 긴장해야 했죠.

더 큰 문제는 배포할 때였습니다. 무중단 배포를 위해 복잡한 스크립트를 작성하고, 한 번에 하나씩 조심스럽게 컨테이너를 교체해야 했습니다.

바로 이런 운영 부담을 해결하기 위해 ECS 서비스가 등장했습니다. ECS 서비스를 사용하면 선언적 관리가 가능해집니다.

"이렇게 실행하라"가 아니라 "이런 상태를 유지하라"고 선언하는 것입니다. 또한 자동 복구 기능도 얻을 수 있습니다.

무엇보다 로드밸런서 통합이라는 큰 이점이 있습니다. ALB나 NLB와 자동으로 연동되어 트래픽을 분산시킵니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 --service-name으로 서비스 이름을 지정합니다.

이 이름으로 서비스를 관리하게 됩니다. --task-definition은 어떤 컨테이너를 실행할지 정의합니다.

여기서 my-app:1은 태스크 정의의 이름과 버전을 의미합니다. --desired-count 3이 핵심입니다.

항상 3개의 태스크를 실행 상태로 유지하라는 의미입니다. --launch-type FARGATE는 서버리스 방식으로 실행하겠다는 뜻입니다.

EC2 인스턴스 관리 없이 컨테이너만 신경 쓰면 됩니다. --network-configuration에서는 VPC 설정을 지정합니다.

어느 서브넷에서 실행할지, 어떤 보안 그룹을 적용할지 정합니다. 마지막으로 --load-balancers에서 로드밸런서를 연결합니다.

이렇게 하면 서비스가 시작될 때 자동으로 로드밸런서의 타겟 그룹에 등록됩니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 쇼핑몰 API 서버를 운영한다고 가정해봅시다. 평소에는 트래픽이 적지만, 세일 기간에는 폭주합니다.

ECS 서비스를 활용하면 Auto Scaling과 연동하여 트래픽에 따라 컨테이너 수를 자동으로 조절할 수 있습니다. 또한 컨테이너가 비정상 종료되더라도 즉시 새로운 컨테이너가 투입되어 서비스 중단을 방지합니다.

많은 스타트업과 대기업에서 이런 패턴을 적극적으로 사용하고 있습니다. 특히 마이크로서비스 아키텍처에서는 각 서비스를 ECS 서비스로 관리하는 것이 표준처럼 자리 잡았습니다.

하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수 중 하나는 태스크 정의와 서비스를 혼동하는 것입니다.

태스크 정의는 컨테이너의 설계도이고, 서비스는 그 설계도를 기반으로 실제로 실행하고 관리하는 계층입니다. 설계도만 있고 건물을 짓지 않으면 아무 일도 일어나지 않는 것처럼, 태스크 정의만으로는 컨테이너가 실행되지 않습니다.

또 다른 실수는 네트워크 설정을 잘못하는 것입니다. 퍼블릭 서브넷에서 실행하려면 assignPublicIp=ENABLED를 반드시 설정해야 합니다.

그렇지 않으면 컨테이너가 인터넷에 접근할 수 없어 이미지를 다운로드하지 못하고 시작에 실패합니다. 다시 이개발 씨의 이야기로 돌아가 봅시다.

박클라우드 씨의 설명을 들은 이개발 씨는 고개를 끄덕였습니다. "아, 그래서 ECS 서비스라는 게 필요하구나!" ECS 서비스를 제대로 이해하면 안정적이고 확장 가능한 컨테이너 운영이 가능합니다.

여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 서비스 이름은 클러스터 내에서 고유해야 하며, 명확한 네이밍 규칙을 사용하세요

Fargate를 사용하면 서버 관리 부담이 없지만, 비용이 약간 더 높습니다
개발 환경에서는 desired-count를 1로, 프로덕션에서는 최소 2 이상으로 설정하세요

2. 서비스 생성하기

드디어 이개발 씨가 첫 ECS 서비스를 생성하기로 했습니다. AWS 콘솔을 열고 ECS 메뉴로 들어갔지만, 수많은 옵션에 당황했습니다.

"이걸 다 설정해야 해요?" 옆에서 지켜보던 선배 최데브옵스 씨가 말했습니다. "핵심만 알면 5분이면 됩니다."

ECS 서비스를 생성할 때는 클러스터, 태스크 정의, 네트워크, 로드밸런서 네 가지 핵심 요소를 설정합니다. 마치 새 가게를 오픈할 때 위치, 메뉴, 인테리어, 간판을 정하는 것과 같습니다.

순서대로 따라하면 누구나 성공적으로 서비스를 시작할 수 있습니다.

다음 코드를 살펴봅시다.

// Terraform으로 ECS 서비스 생성하기
resource "aws_ecs_service" "app" {
  name            = "my-app-service"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.app.arn
  desired_count   = 2
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = aws_subnet.private[*].id
    security_groups  = [aws_security_group.ecs_tasks.id]
    assign_public_ip = false
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.app.arn
    container_name   = "app"
    container_port   = 8080
  }

  depends_on = [aws_lb_listener.app]
}

이개발 씨는 화면을 보며 고민에 빠졌습니다. ECS 콘솔에는 수십 개의 설정 항목이 있었고, 각각 무엇을 의미하는지 알기 어려웠습니다.

"이거 잘못 설정하면 어떻게 되죠?" 불안한 마음에 물었습니다. 최데브옵스 씨는 웃으며 화이트보드를 들고 왔습니다.

"어렵게 생각할 것 없어요. 핵심만 이해하면 됩니다." ECS 서비스를 생성하는 것은 생각보다 단순합니다.

하지만 처음에는 용어와 개념이 낯설어서 어렵게 느껴집니다. 쉽게 비유하자면, ECS 서비스 생성은 마치 새로운 레스토랑을 오픈하는 것과 같습니다.

먼저 어느 쇼핑몰에 입점할지 결정해야 합니다(클러스터). 그다음 어떤 메뉴를 팔지 정합니다(태스크 정의).

매장 내부 인테리어와 동선을 설계하고(네트워크), 마지막으로 고객이 찾아올 수 있도록 간판을 답니다(로드밸런서). 이 네 가지만 제대로 설정하면 레스토랑이 오픈됩니다.

서비스 생성이 체계화되기 전에는 어땠을까요? 개발자가 직접 EC2 인스턴스에 접속해서 Docker 명령어를 실행해야 했습니다.

컨테이너를 하나씩 수동으로 시작하고, 각각의 IP 주소를 로드밸런서에 등록하고, 헬스체크가 통과할 때까지 기다렸습니다. 실수로 설정을 빠뜨리면 컨테이너는 실행되지만 트래픽이 도달하지 않는 유령 서비스가 되기도 했습니다.

더 큰 문제는 확장할 때였습니다. 컨테이너를 하나 더 추가하려면 모든 과정을 반복해야 했습니다.

팀원 간 설정 방법이 달라서 환경마다 미묘한 차이가 생기기도 했습니다. 바로 이런 혼란을 해결하기 위해 ECS 서비스 생성 프로세스가 표준화되었습니다.

ECS 서비스를 사용하면 일관된 방식으로 서비스를 생성할 수 있습니다. 클릭 몇 번이나 코드 몇 줄이면 완성됩니다.

또한 재현 가능한 인프라를 얻을 수 있습니다. Terraform이나 CloudFormation으로 코드화하면 언제든 똑같은 환경을 만들 수 있습니다.

무엇보다 실수 방지라는 큰 이점이 있습니다. 필수 항목을 빠뜨리면 에러를 보여주기 때문에 설정 누락을 방지할 수 있습니다.

위의 Terraform 코드를 단계별로 살펴보겠습니다. 먼저 name과 cluster를 지정합니다.

어느 클러스터에 어떤 이름의 서비스를 만들 것인지 선언하는 것입니다. 다음으로 task_definition을 설정합니다.

이것이 실제로 실행할 컨테이너의 설계도입니다. desired_count = 2는 항상 2개의 태스크를 실행 상태로 유지하라는 의미입니다.

network_configuration 블록이 중요합니다. subnets에서는 컨테이너가 실행될 서브넷을 지정합니다.

프라이빗 서브넷을 사용하면 보안이 강화됩니다. security_groups는 방화벽 규칙을 정의합니다.

assign_public_ip = false는 프라이빗 서브넷에서 실행하므로 퍼블릭 IP가 필요 없다는 뜻입니다. load_balancer 블록에서 로드밸런서를 연결합니다.

target_group_arn은 어느 타겟 그룹에 등록할지, container_name과 container_port는 컨테이너의 어느 포트로 트래픽을 보낼지 지정합니다. 마지막으로 depends_on은 리스너가 먼저 생성된 후 서비스를 만들라는 의존성 선언입니다.

이것이 없으면 서비스 생성 시 리스너가 없어서 실패할 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

대부분의 기업에서는 AWS 콘솔보다 Infrastructure as Code를 선호합니다. Terraform이나 CloudFormation으로 서비스를 정의해두면, 개발/스테이징/프로덕션 환경을 일관되게 관리할 수 있습니다.

또한 Git으로 버전 관리하여 언제든 이전 상태로 롤백할 수 있습니다. 예를 들어 신규 마이크로서비스를 추가할 때, 기존 서비스의 Terraform 코드를 복사하여 몇 가지 값만 수정하면 됩니다.

클러스터, 네트워크, 보안 그룹 등의 공통 설정은 재사용하고, 서비스별 고유 설정만 변경하는 것입니다. 이렇게 하면 팀 전체가 동일한 패턴을 따르게 되어 운영이 훨씬 수월해집니다.

하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수 중 하나는 보안 그룹을 잘못 설정하는 것입니다.

컨테이너의 보안 그룹은 로드밸런서의 보안 그룹으로부터 트래픽을 허용해야 합니다. 만약 잘못 설정하면 서비스는 정상 실행되지만 헬스체크가 실패하여 unhealthy 상태로 남게 됩니다.

또 다른 실수는 서브넷 선택입니다. 퍼블릭 서브넷에서 실행하면서 assign_public_ip = false로 설정하면 컨테이너가 인터넷에 접근할 수 없습니다.

반대로 프라이빗 서브넷에서 assign_public_ip = true로 설정해도 퍼블릭 IP는 할당되지 않습니다. 서브넷 타입과 IP 할당 옵션을 정확히 이해해야 합니다.

다시 이개발 씨의 이야기로 돌아가 봅시다. 최데브옵스 씨의 설명을 들은 이개발 씨는 자신감이 생겼습니다.

"생각보다 간단하네요!" ECS 서비스 생성을 제대로 이해하면 몇 분 만에 새로운 서비스를 배포할 수 있습니다. 여러분도 오늘 배운 내용을 실제로 시도해 보세요.

실전 팁

💡 - 처음에는 AWS 콘솔로 생성해보고, 이해한 후 Terraform으로 전환하세요

보안 그룹은 최소 권한 원칙을 따르되, 헬스체크 포트는 반드시 열어야 합니다
프라이빗 서브넷 사용 시 NAT Gateway 설정을 확인하세요

3. Desired count 설정

서비스를 생성한 이개발 씨는 desired count를 몇으로 설정해야 할지 고민에 빠졌습니다. "1개면 충분할까요, 아니면 10개로 해야 할까요?" 옆에서 듣던 박클라우드 씨가 말했습니다.

"무조건 많다고 좋은 건 아닙니다. 상황에 맞게 설정해야죠."

Desired count는 서비스가 항상 유지해야 할 태스크의 개수입니다. 마치 식당에서 최소 몇 명의 직원이 근무해야 하는지 정하는 것과 같습니다.

너무 적으면 장애 시 서비스가 중단되고, 너무 많으면 비용이 낭비됩니다. 적절한 균형을 찾는 것이 중요합니다.

다음 코드를 살펴봅시다.

// AWS CLI로 desired count 업데이트
aws ecs update-service \
  --cluster my-cluster \
  --service my-app-service \
  --desired-count 3

// Auto Scaling으로 동적 조정
resource "aws_appautoscaling_target" "ecs" {
  max_capacity       = 10
  min_capacity       = 2
  resource_id        = "service/${aws_ecs_cluster.main.name}/${aws_ecs_service.app.name}"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace  = "ecs"
}

// CPU 기반 스케일링 정책
resource "aws_appautoscaling_policy" "cpu" {
  name               = "cpu-autoscaling"
  policy_type        = "TargetTrackingScaling"
  resource_id        = aws_appautoscaling_target.ecs.resource_id
  scalable_dimension = aws_appautoscaling_target.ecs.scalable_dimension
  service_namespace  = aws_appautoscaling_target.ecs.service_namespace

  target_tracking_scaling_policy_configuration {
    target_value       = 70.0
    predefined_metric_specification {
      predefined_metric_type = "ECSServiceAverageCPUUtilization"
    }
  }
}

이개발 씨는 진지한 표정으로 물었습니다. "개발 환경이니까 1개로 해도 되겠죠?" 박클라우드 씨는 고개를 저었습니다.

"1개만 실행하면 배포할 때 서비스가 중단됩니다. 최소 2개는 유지해야 무중단 배포가 가능해요." Desired count 설정은 단순해 보이지만, 서비스의 가용성과 비용에 직접적인 영향을 미치는 중요한 결정입니다.

쉽게 비유하자면, desired count는 마치 24시간 편의점의 근무 인원과 같습니다. 낮 시간대에는 손님이 많으니 직원 3명이 필요하지만, 새벽 시간에는 1명만 있어도 충분합니다.

하지만 최소 1명은 항상 있어야 가게가 운영됩니다. 만약 유일한 직원이 화장실에 가면 그 순간 가게는 무인 상태가 됩니다.

따라서 최소 2명은 있어야 안전합니다. ECS도 마찬가지입니다.

Desired count 1로 설정하면 평소에는 문제없지만, 그 하나의 태스크가 재시작되는 순간 서비스가 중단됩니다. 배포할 때나 컨테이너에 문제가 생겼을 때 다운타임이 발생하는 것입니다.

Desired count를 고정값으로만 사용하던 시절에는 어땠을까요? 트래픽이 많아질 것을 대비해서 항상 넉넉하게 설정해야 했습니다.

새벽에 사용자가 거의 없어도 10개의 컨테이너가 계속 실행되었습니다. 반대로 너무 적게 설정하면 갑작스러운 트래픽 증가에 대응할 수 없었습니다.

담당자가 수동으로 모니터링하다가 CPU 사용률이 높아지면 급하게 desired count를 올리는 식이었습니다. 밤에 알람이 울려서 깨어나 desired count를 조정하는 일도 흔했습니다.

사람이 직접 개입해야 하므로 대응이 느렸고, 휴일이나 심야에는 대응 자체가 어려웠습니다. 바로 이런 운영 부담을 해결하기 위해 Auto Scaling이 등장했습니다.

Auto Scaling을 사용하면 자동 확장이 가능해집니다. CPU 사용률이나 메모리 사용률을 모니터링하다가 임계값을 넘으면 자동으로 desired count를 증가시킵니다.

또한 자동 축소도 지원합니다. 트래픽이 줄어들면 불필요한 태스크를 종료하여 비용을 절감합니다.

무엇보다 무중단 운영이라는 큰 이점이 있습니다. 사람의 개입 없이 시스템이 알아서 조절하므로 새벽에도 안심할 수 있습니다.

위의 코드를 단계별로 살펴보겠습니다. 먼저 간단한 방법은 AWS CLI로 직접 desired count를 변경하는 것입니다.

--desired-count 3으로 설정하면 즉시 3개의 태스크를 유지하도록 변경됩니다. 하지만 이것은 수동 방식입니다.

더 나은 방법은 Auto Scaling을 설정하는 것입니다. aws_appautoscaling_target 리소스에서 최소값과 최대값을 정의합니다.

min_capacity = 2는 아무리 트래픽이 적어도 최소 2개는 유지하라는 의미입니다. max_capacity = 10은 최대 10개까지 확장할 수 있다는 뜻입니다.

aws_appautoscaling_policy에서 스케일링 정책을 정의합니다. target_value = 70.0은 CPU 사용률을 70% 수준으로 유지하라는 목표입니다.

만약 평균 CPU가 70%를 넘으면 태스크를 추가하고, 70%보다 낮으면 태스크를 줄입니다. 이렇게 하면 항상 적정 수준의 리소스를 유지할 수 있습니다.

실제 현업에서는 어떻게 활용할까요? 대부분의 프로덕션 환경에서는 고정 desired count와 Auto Scaling을 혼합하여 사용합니다.

예를 들어 쇼핑몰 API 서버라면 평소에 최소 3개의 태스크를 유지하고, 트래픽이 증가하면 최대 20개까지 확장되도록 설정합니다. 블랙프라이데이 같은 대규모 이벤트를 앞두고는 미리 desired count를 높여두기도 합니다.

평소에는 Auto Scaling에 맡기지만, 확실히 트래픽이 폭증할 것을 알고 있다면 사전에 스케일 아웃하는 것이 안전합니다. 스케일링에는 시간이 걸리므로, 급격한 트래픽 증가에는 대응이 늦을 수 있기 때문입니다.

또한 여러 지표를 조합하여 스케일링하기도 합니다. CPU뿐만 아니라 메모리, 요청 수, 응답 시간 등을 함께 고려하여 더 정교하게 조절하는 것입니다.

하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수 중 하나는 min_capacity를 1로 설정하는 것입니다.

최소 1개만 유지하면 배포 중에 다운타임이 발생합니다. 무중단 배포를 위해서는 최소 2개 이상을 유지해야 합니다.

또 다른 실수는 스케일링 임계값을 너무 낮게 설정하는 것입니다. CPU 30%에 스케일 아웃하도록 설정하면, 조금만 부하가 생겨도 계속 확장됩니다.

비용이 불필요하게 증가할 수 있습니다. 일반적으로 70-80% 정도가 적정합니다.

스케일 다운 속도도 중요합니다. 너무 빠르게 줄이면 트래픽이 다시 증가했을 때 대응이 느립니다.

스케일 업은 빠르게, 스케일 다운은 천천히 하는 것이 원칙입니다. 다시 이개발 씨의 이야기로 돌아가 봅시다.

박클라우드 씨의 설명을 들은 이개발 씨는 이해했습니다. "개발 환경은 2개, 프로덕션은 Auto Scaling으로 가야겠네요!" Desired count를 제대로 설정하면 가용성과 비용 효율을 모두 잡을 수 있습니다.

여러분도 오늘 배운 내용을 자신의 환경에 맞게 조정해 보세요.

실전 팁

💡 - 프로덕션 환경에서는 최소 2개 이상의 태스크를 유지하세요

CPU 70-80%를 목표로 Auto Scaling을 설정하는 것이 일반적입니다
스케일 다운은 천천히, 스케일 업은 빠르게 설정하세요

4. 배포 구성

이제 실제 배포를 준비하는 단계입니다. 이개발 씨는 새로운 버전의 코드를 배포하려고 하는데, 어떻게 해야 사용자에게 영향을 주지 않을지 고민입니다.

"배포하는 동안 서비스가 중단되면 안 되는데요." 최데브옵스 씨가 웃으며 말했습니다. "그래서 배포 구성이 중요합니다."

배포 구성은 새 버전을 어떻게 배포할지 정의하는 전략입니다. 마치 식당에서 주방장을 교체할 때, 모든 주방장을 한 번에 바꿀지 한 명씩 바꿀지 정하는 것과 같습니다.

ECS에서는 롤링 업데이트, 블루/그린 배포, 카나리 배포 등 다양한 방식을 제공합니다.

다음 코드를 살펴봅시다.

// Rolling Update 배포 구성
resource "aws_ecs_service" "app" {
  name            = "my-app-service"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.app.arn
  desired_count   = 4

  deployment_configuration {
    maximum_percent         = 200  // 최대 8개까지 동시 실행 가능
    minimum_healthy_percent = 50   // 최소 2개는 항상 실행 유지
  }

  deployment_circuit_breaker {
    enable   = true
    rollback = true  // 배포 실패 시 자동 롤백
  }

  // Blue/Green 배포 설정 (CodeDeploy 사용 시)
  deployment_controller {
    type = "CODE_DEPLOY"
  }
}

// 태스크 정의 업데이트로 배포 트리거
aws ecs update-service \
  --cluster my-cluster \
  --service my-app-service \
  --task-definition my-app:2 \
  --force-new-deployment

이개발 씨는 긴장된 표정으로 물었습니다. "그냥 태스크 정의를 업데이트하면 자동으로 배포되는 거 아닌가요?" 최데브옵스 씨는 고개를 끄덕였습니다.

"맞아요. 하지만 어떻게 배포될지는 배포 구성에 달려 있습니다." 배포는 운영 중인 서비스에서 가장 위험한 작업 중 하나입니다.

새로운 코드에 버그가 있을 수 있고, 설정이 잘못되었을 수도 있습니다. 배포 방식에 따라 사용자 경험과 서비스 안정성이 크게 달라집니다.

쉽게 비유하자면, 배포는 마치 고속도로에서 차선을 변경하는 것과 같습니다. 한 번에 모든 차를 새 차선으로 옮기면 혼란이 발생합니다.

하지만 천천히 한 대씩 옮기면 교통 흐름이 유지됩니다. ECS의 배포 구성은 바로 이런 "차선 변경 전략"을 정의하는 것입니다.

배포 구성이 없던 시절에는 어땠을까요? 모든 컨테이너를 한 번에 종료하고 새로운 버전을 시작했습니다.

이것을 "재생성 배포"라고 부릅니다. 간단하지만 치명적인 단점이 있었습니다.

구 버전 컨테이너를 종료하는 순간부터 신 버전 컨테이너가 준비될 때까지 서비스가 완전히 중단되는 것입니다. 새벽 시간에만 배포하거나, 점검 공지를 띄우고 배포해야 했습니다.

만약 배포가 실패하면 긴 다운타임이 발생했고, 사용자들은 오류 페이지만 보게 되었습니다. 롤백하려면 다시 처음부터 배포 과정을 반복해야 했습니다.

더 큰 문제는 배포 실패를 감지하는 메커니즘이 없었다는 것입니다. 새 버전에 심각한 버그가 있어도 일단 배포되면 그대로 서비스되었습니다.

사용자 신고를 받고 나서야 문제를 알게 되는 경우도 많았습니다. 바로 이런 위험을 줄이기 위해 정교한 배포 구성이 개발되었습니다.

ECS의 배포 구성을 사용하면 무중단 배포가 가능해집니다. 구 버전과 신 버전이 잠시 공존하면서 점진적으로 전환됩니다.

또한 자동 헬스체크로 새 버전이 정상인지 확인합니다. 만약 헬스체크에 실패하면 배포를 중단하고 구 버전을 유지합니다.

무엇보다 자동 롤백이라는 안전장치가 있습니다. Circuit breaker를 활성화하면 배포 실패 시 자동으로 이전 버전으로 되돌아갑니다.

위의 코드를 자세히 살펴보겠습니다. deployment_configuration 블록이 핵심입니다.

maximum_percent = 200은 배포 중에 desired count의 200%까지 태스크를 실행할 수 있다는 의미입니다. 예를 들어 desired count가 4라면 최대 8개까지 동시에 실행될 수 있습니다.

이렇게 하면 구 버전 4개가 실행 중인 상태에서 신 버전 4개를 모두 시작하고, 신 버전이 healthy 상태가 되면 구 버전을 종료합니다. minimum_healthy_percent = 50은 배포 중에도 최소 50%의 태스크는 healthy 상태를 유지해야 한다는 뜻입니다.

Desired count가 4라면 최소 2개는 항상 실행되어야 합니다. 이 설정이 무중단 배포를 보장합니다.

deployment_circuit_breaker는 배포 안전장치입니다. enable = true로 활성화하면 배포가 반복적으로 실패할 때 자동으로 감지합니다.

rollback = true로 설정하면 실패 시 자동으로 이전 버전으로 롤백합니다. 이것이 없으면 배포가 계속 실패하는데도 시도를 반복하여 시간을 낭비합니다.

태스크 정의를 업데이트하면 자동으로 배포가 트리거됩니다. --task-definition my-app:2로 새 버전을 지정하면, 설정된 배포 구성에 따라 롤링 업데이트가 시작됩니다.

--force-new-deployment 플래그는 태스크 정의가 바뀌지 않아도 강제로 배포하라는 의미입니다. 컨테이너 이미지는 바뀌었지만 태스크 정의는 같은 경우에 유용합니다.

실제 현업에서는 어떻게 활용할까요? 대부분의 기업에서는 롤링 업데이트를 기본으로 사용합니다.

빠르고 간단하며 대부분의 경우에 충분합니다. 하지만 중요한 서비스나 대규모 변경 시에는 블루/그린 배포를 선호합니다.

블루/그린 배포는 구 버전(블루)과 신 버전(그린)을 완전히 분리된 환경에서 실행하고, 로드밸런서를 전환하는 방식입니다. 롤백이 즉각적이고 안전합니다.

금융권이나 의료 시스템처럼 안정성이 극도로 중요한 곳에서는 카나리 배포를 사용하기도 합니다. 전체 트래픽의 5%만 새 버전으로 보내고, 문제가 없으면 점진적으로 비율을 높여가는 방식입니다.

만약 에러율이 증가하면 즉시 중단하고 조사합니다. CI/CD 파이프라인과 통합하면 더욱 강력해집니다.

GitHub Actions나 Jenkins에서 테스트가 통과하면 자동으로 새 태스크 정의를 생성하고 배포하는 식입니다. CloudWatch 알람과 연동하여 배포 후 에러율이나 응답 시간을 모니터링하고, 임계값을 넘으면 자동으로 롤백하는 고급 전략도 가능합니다.

하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수 중 하나는 maximum_percent를 너무 낮게 설정하는 것입니다.

예를 들어 100%로 설정하면 추가 태스크를 실행할 수 없습니다. 이 경우 구 버전을 종료해야만 신 버전을 시작할 수 있어서 배포가 매우 느려집니다.

반대로 minimum_healthy_percent를 너무 높게 설정하는 것도 문제입니다. 100%로 설정하면 모든 태스크가 healthy 상태를 유지해야 하므로, 배포 중에 일시적으로 용량이 부족할 수 있습니다.

특히 클러스터 리소스가 제한적일 때 배포가 멈출 수 있습니다. Circuit breaker를 활성화하지 않는 것도 위험합니다.

배포가 실패해도 계속 시도하면서 시간만 낭비하고, 결국 수동으로 개입해야 합니다. 항상 circuit breaker를 활성화하고 자동 롤백을 설정하세요.

다시 이개발 씨의 이야기로 돌아가 봅시다. 최데브옵스 씨의 설명을 들은 이개발 씨는 안심했습니다.

"이제 배포가 두렵지 않네요!" 배포 구성을 제대로 설정하면 안전하고 빠른 배포가 가능합니다. 여러분도 오늘 배운 내용을 자신의 서비스에 적용해 보세요.

실전 팁

💡 - maximum_percent는 200%, minimum_healthy_percent는 50%로 시작하는 것이 안전합니다

반드시 circuit breaker와 자동 롤백을 활성화하세요
블루/그린 배포는 중요한 변경이나 대규모 서비스에 적합합니다

5. 서비스 업데이트

배포 구성까지 완료한 이개발 씨는 실제로 서비스를 업데이트할 차례입니다. "코드를 수정했으니 이제 배포하면 되는 거죠?" 그렇게 말하며 배포 버튼을 누르려던 순간, 최데브옵스 씨가 손을 잡았습니다.

"잠깐만요. 서비스 업데이트는 단순히 배포 버튼만 누르는 게 아닙니다."

서비스 업데이트는 새로운 태스크 정의로 서비스를 갱신하는 과정입니다. 마치 레스토랑의 메뉴판을 새 버전으로 교체하는 것과 같습니다.

이미지 태그 변경, 환경변수 수정, 리소스 할당 조정 등 다양한 이유로 서비스를 업데이트하게 됩니다.

다음 코드를 살펴봅시다.

// 1. 새 태스크 정의 생성
{
  "family": "my-app",
  "containerDefinitions": [
    {
      "name": "app",
      "image": "123456789.dkr.ecr.us-east-1.amazonaws.com/my-app:v2.0.0",
      "memory": 512,
      "cpu": 256,
      "essential": true,
      "environment": [
        {"name": "NODE_ENV", "value": "production"},
        {"name": "API_VERSION", "value": "v2"}
      ],
      "portMappings": [
        {"containerPort": 8080, "protocol": "tcp"}
      ]
    }
  ]
}

// 2. 태스크 정의 등록
aws ecs register-task-definition --cli-input-json file://task-definition.json

// 3. 서비스 업데이트 (새 태스크 정의 적용)
aws ecs update-service \
  --cluster my-cluster \
  --service my-app-service \
  --task-definition my-app:2

// 4. 배포 상태 모니터링
aws ecs describe-services \
  --cluster my-cluster \
  --services my-app-service \
  --query 'services[0].deployments'

이개발 씨는 당황했습니다. "배포 버튼만 누르면 안 되나요?" 최데브옵스 씨는 화면을 가리키며 설명했습니다.

"ECS는 태스크 정의라는 개념을 사용합니다. 서비스를 업데이트하려면 먼저 새로운 태스크 정의를 만들어야 해요." 서비스 업데이트는 생각보다 많은 단계를 거칩니다.

하지만 각 단계를 이해하면 배포 과정을 정확히 제어할 수 있습니다. 쉽게 비유하자면, 서비스 업데이트는 마치 건축 설계도를 개정하는 것과 같습니다.

먼저 새로운 설계도를 그립니다(태스크 정의 작성). 그다음 건축 허가를 받습니다(태스크 정의 등록).

마지막으로 실제 건물을 개정된 설계도대로 리모델링합니다(서비스 업데이트). 설계도 없이는 건물을 바꿀 수 없는 것처럼, 태스크 정의 없이는 서비스를 업데이트할 수 없습니다.

서비스 업데이트가 체계화되기 전에는 어땠을까요? 개발자가 직접 각 서버에 접속해서 수동으로 컨테이너를 재시작했습니다.

"지금부터 서버 1번 배포합니다", "서버 2번 배포 시작" 이런 식으로 하나씩 처리했습니다. 설정 파일을 직접 편집하고, Docker 명령어를 실행하고, 로그를 지켜보면서 문제가 없는지 확인했습니다.

배포 중에 문제가 생기면 긴급하게 중단하고 이전 버전으로 롤백해야 했습니다. 하지만 어느 서버까지 배포했는지, 어떤 버전이 실행 중인지 추적하기 어려웠습니다.

여러 사람이 동시에 배포하면 충돌이 발생하기도 했습니다. 더 큰 문제는 일관성이었습니다.

서버마다 미묘하게 다른 설정이나 버전으로 실행되는 경우가 많았습니다. "이상하다, 로컬에서는 되는데..." 하는 말이 자주 들렸습니다.

바로 이런 혼란을 해결하기 위해 태스크 정의 기반 업데이트가 등장했습니다. ECS의 서비스 업데이트를 사용하면 버전 관리가 명확해집니다.

모든 태스크 정의는 버전 번호를 가지므로 언제든 특정 버전으로 돌아갈 수 있습니다. 또한 선언적 관리가 가능합니다.

원하는 상태를 선언하면 ECS가 알아서 그 상태로 만들어줍니다. 무엇보다 추적 가능성이라는 큰 이점이 있습니다.

누가 언제 어떤 변경을 했는지 모두 기록됩니다. 위의 과정을 단계별로 살펴보겠습니다.

첫 번째 단계는 새로운 태스크 정의를 작성하는 것입니다. JSON 형식으로 컨테이너 이미지, 리소스, 환경변수 등을 정의합니다.

여기서는 이미지를 v2.0.0 태그로 변경하고, API_VERSION 환경변수를 추가했습니다. 메모리나 CPU 할당도 필요에 따라 조정할 수 있습니다.

두 번째 단계는 태스크 정의를 ECS에 등록하는 것입니다. register-task-definition 명령으로 JSON 파일을 제출하면 새로운 버전이 생성됩니다.

예를 들어 이전이 my-app:1이었다면 이제 my-app:2가 만들어집니다. 세 번째 단계가 실제 서비스 업데이트입니다.

update-service 명령으로 서비스가 새 태스크 정의를 사용하도록 지시합니다. 이 순간 롤링 업데이트가 시작됩니다.

구 버전 태스크를 하나씩 종료하고 신 버전 태스크를 시작하는 것입니다. 네 번째 단계는 배포 상태를 모니터링하는 것입니다.

describe-services 명령으로 현재 어떤 배포가 진행 중인지, 몇 개의 태스크가 실행 중인지 확인할 수 있습니다. 배포가 완료될 때까지 지켜보면서 문제가 없는지 확인합니다.

실제 현업에서는 어떻게 활용할까요? 대부분의 팀에서는 서비스 업데이트를 자동화합니다.

CI/CD 파이프라인에서 코드가 푸시되면 자동으로 Docker 이미지를 빌드하고, ECR에 업로드하고, 새 태스크 정의를 생성하고, 서비스를 업데이트합니다. 이 모든 과정이 몇 분 안에 자동으로 진행됩니다.

예를 들어 GitHub Actions 워크플로우를 만들면 이렇습니다. 마스터 브랜치에 머지되면 테스트를 실행하고, Docker 이미지를 빌드하고, Git commit SHA를 이미지 태그로 사용하여 ECR에 푸시합니다.

그다음 태스크 정의 JSON 파일의 이미지 태그를 새로운 SHA로 교체하고, AWS CLI로 태스크 정의를 등록하고 서비스를 업데이트합니다. Terraform을 사용하면 더 편리합니다.

태스크 정의를 Terraform 코드로 관리하고, 이미지 태그만 변수로 받아서 변경합니다. terraform apply를 실행하면 자동으로 새 태스크 정의가 등록되고 서비스가 업데이트됩니다.

인프라 변경 이력이 Git에 남으므로 언제든 이전 상태로 돌아갈 수 있습니다. 배포 전후로 Slack이나 이메일로 알림을 보내는 것도 좋은 습관입니다.

팀원들이 배포 상황을 실시간으로 파악할 수 있고, 문제가 생기면 즉시 대응할 수 있습니다. 하지만 주의할 점도 있습니다.

초보자들이 흔히 하는 실수 중 하나는 이미지 태그를 latest로 사용하는 것입니다. latest 태그는 항상 최신 이미지를 가리키므로, 동일한 태스크 정의로도 다른 이미지가 실행될 수 있습니다.

이렇게 되면 어떤 버전이 실행 중인지 알 수 없어 디버깅이 어렵습니다. 항상 명확한 버전 태그(v1.0.0, commit-sha 등)를 사용하세요.

또 다른 실수는 배포 후 확인하지 않는 것입니다. 서비스 업데이트 명령을 실행하면 즉시 반환되지만, 실제 배포는 백그라운드에서 진행됩니다.

반드시 배포 상태를 모니터링하고, 새 태스크가 healthy 상태인지 확인해야 합니다. CloudWatch 로그를 보면서 에러가 없는지도 체크하세요.

환경변수를 변경할 때도 주의가 필요합니다. 민감한 정보(API 키, 비밀번호)는 태스크 정의에 직접 넣지 말고 Secrets Manager나 Parameter Store를 사용하세요.

태스크 정의는 평문으로 저장되므로 보안에 취약합니다. 다시 이개발 씨의 이야기로 돌아가 봅시다.

최데브옵스 씨의 안내에 따라 차근차근 진행한 이개발 씨는 첫 배포에 성공했습니다. "생각보다 간단하네요!" 서비스 업데이트를 제대로 이해하면 자신 있게 배포할 수 있습니다.

여러분도 오늘 배운 내용을 실제 배포에 적용해 보세요.

실전 팁

💡 - 이미지 태그는 latest 대신 명확한 버전이나 commit SHA를 사용하세요

배포 후 반드시 CloudWatch 로그와 메트릭을 확인하세요
민감한 정보는 Secrets Manager를 사용하여 관리하세요

6. 롤링 업데이트

첫 배포를 성공한 이개발 씨는 배포 과정을 지켜보며 신기해했습니다. "어?

서비스가 중단되지 않고 계속 동작하네요?" 최데브옵스 씨가 웃으며 설명했습니다. "바로 롤링 업데이트 덕분입니다.

하나씩 차근차근 교체하는 거죠."

롤링 업데이트는 구 버전 태스크를 점진적으로 종료하면서 신 버전 태스크를 시작하는 무중단 배포 방식입니다. 마치 달리는 기차의 객차를 하나씩 교체하는 것과 같습니다.

기차는 멈추지 않고 계속 달리면서 객차만 바뀌는 것입니다.

다음 코드를 살펴봅시다.

// 롤링 업데이트 프로세스 시뮬레이션
// 초기 상태: 4개의 구버전 태스크 실행 중 (desired=4)
// [v1, v1, v1, v1]

// 1단계: 신버전 태스크 2개 시작 (maximum_percent=200 → 최대 8개)
// [v1, v1, v1, v1, v2, v2]

// 2단계: 신버전 태스크가 healthy 되면 구버전 2개 종료
// [v1, v1, v2, v2]

// 3단계: 추가로 신버전 2개 시작
// [v1, v1, v2, v2, v2, v2]

// 4단계: 신버전 healthy 확인 후 남은 구버전 종료
// [v2, v2, v2, v2]

// ECS 이벤트로 롤링 업데이트 추적
aws ecs describe-services \
  --cluster my-cluster \
  --services my-app-service \
  --query 'services[0].events[0:10]'

// 배포 진행 상황 확인
watch -n 5 'aws ecs describe-services \
  --cluster my-cluster \
  --services my-app-service \
  --query "services[0].deployments[*].[id,status,runningCount,desiredCount]" \
  --output table'

이개발 씨는 모니터링 화면을 보며 감탄했습니다. 구버전 태스크가 하나씩 사라지고 신버전 태스크가 생겨나는 모습이 마치 세포 분열을 보는 것 같았습니다.

"이게 어떻게 가능한 거예요?" 롤링 업데이트는 현대 클라우드 배포의 핵심 기술입니다. 무중단 배포를 가능하게 만드는 마법 같은 메커니즘입니다.

쉽게 비유하자면, 롤링 업데이트는 마치 24시간 운영하는 편의점의 직원 교대와 같습니다. 밤 11시에 야간 근무자가 출근하면, 저녁 근무자는 바로 퇴근하지 않습니다.

두 사람이 잠시 함께 일하면서 인수인계를 합니다. 야간 근무자가 익숙해지고 문제없이 업무를 처리하는 것을 확인한 후에야 저녁 근무자가 퇴근합니다.

이렇게 하면 고객은 직원이 바뀌는지도 모르고 서비스를 계속 이용할 수 있습니다. ECS의 롤링 업데이트도 정확히 같은 원리입니다.

신버전 태스크가 시작되고 healthy 상태가 되는 것을 확인한 후에 구버전 태스크를 종료합니다. 서비스는 단 한 순간도 멈추지 않습니다.

롤링 업데이트가 없던 시절에는 어땠을까요? "재생성 배포"라는 방식을 사용했습니다.

모든 구버전 컨테이너를 한 번에 종료하고, 신버전 컨테이너를 시작합니다. 간단하지만 치명적인 문제가 있었습니다.

종료와 시작 사이에 수십 초에서 수 분의 다운타임이 발생하는 것입니다. 사용자들은 갑자기 "503 Service Unavailable" 에러를 보게 됩니다.

새벽 3시에 배포하더라도 해외 사용자나 야간 근무자들에게는 영향이 갑니다. 더 큰 문제는 배포가 실패했을 때였습니다.

신버전 컨테이너가 시작되지 않으면 서비스는 완전히 중단된 상태로 남습니다. 급하게 롤백을 시도해도 다시 구버전을 시작하는 시간이 필요합니다.

또 다른 방식인 "블루/그린 배포"도 있었지만, 리소스가 두 배로 필요하다는 단점이 있었습니다. 구버전 환경을 그대로 유지하면서 완전히 새로운 환경을 만들어야 하니까요.

작은 스타트업에는 비용 부담이 컸습니다. 바로 이런 문제들을 해결하기 위해 롤링 업데이트가 표준이 되었습니다.

롤링 업데이트를 사용하면 무중단 배포가 가능합니다. 사용자는 배포가 진행 중인지조차 알지 못합니다.

또한 점진적 검증이 가능합니다. 신버전이 정상 작동하는지 단계적으로 확인하면서 진행합니다.

무엇보다 리소스 효율성이라는 장점이 있습니다. 블루/그린처럼 두 배의 리소스가 필요하지 않고, 일시적으로만 약간의 추가 리소스를 사용합니다.

위의 단계를 자세히 살펴보겠습니다. 초기 상태에서는 desired count가 4이므로 4개의 v1 태스크가 실행 중입니다.

모든 태스크가 healthy 상태이고 트래픽을 정상적으로 처리하고 있습니다. 1단계에서 서비스 업데이트가 트리거되면 ECS는 신버전 태스크를 시작합니다.

maximum_percent=200이므로 최대 8개까지 태스크를 실행할 수 있습니다. 따라서 구버전 4개는 그대로 두고 신버전 2개를 추가로 시작합니다.

이 순간 총 6개의 태스크가 실행 중입니다. 2단계에서 신버전 태스크가 헬스체크를 통과하여 healthy 상태가 되면, ECS는 구버전 태스크 2개를 종료합니다.

minimum_healthy_percent=50이므로 최소 2개는 항상 유지해야 합니다. 현재 신버전 2개가 healthy이고 구버전 2개도 실행 중이므로 총 4개가 유지되어 조건을 만족합니다.

3단계에서 다시 신버전 2개를 추가로 시작합니다. 이제 구버전 2개, 신버전 4개가 실행 중입니다.

추가된 신버전 태스크들이 healthy 상태가 되기를 기다립니다. 4단계에서 모든 신버전 태스크가 healthy가 되면 남은 구버전 2개를 종료합니다.

최종적으로 신버전 4개만 남게 되고 배포가 완료됩니다. 이 전체 과정은 수 분 내에 자동으로 진행됩니다.

개발자는 단지 update-service 명령 하나만 실행하면 됩니다. 실제 현업에서는 어떻게 활용할까요?

대부분의 웹 서비스에서 롤링 업데이트는 기본 배포 방식입니다. 하루에도 수십 번 배포하는 팀도 있는데, 매번 무중단으로 진행됩니다.

사용자는 전혀 눈치채지 못합니다. 롤링 업데이트 속도를 조절할 수도 있습니다.

maximum_percent를 낮추면 천천히 교체되고, 높이면 빠르게 교체됩니다. 중요한 서비스는 천천히, 테스트 환경은 빠르게 설정하는 식입니다.

CloudWatch를 활용하면 배포 중 메트릭을 실시간으로 모니터링할 수 있습니다. 에러율이 증가하거나 응답 시간이 길어지면 즉시 알람을 받습니다.

이상 징후가 감지되면 수동으로 롤백하거나, circuit breaker가 자동으로 중단시킵니다. 대규모 서비스에서는 카나리 배포와 결합하기도 합니다.

먼저 1개의 신버전 태스크만 시작하고 전체 트래픽의 10%만 보냅니다. 문제가 없으면 롤링 업데이트를 계속 진행하는 방식입니다.

이렇게 하면 더욱 안전합니다. 하지만 주의할 점도 있습니다.

초보자들이 흔히 하는 실수 중 하나는 헬스체크를 제대로 설정하지 않는 것입니다. 헬스체크가 없거나 잘못 설정되어 있으면, 신버전 태스크가 실제로는 에러를 내고 있어도 healthy로 판단됩니다.

그러면 구버전이 종료되고 문제 있는 신버전만 남게 되어 서비스 장애가 발생합니다. 헬스체크 경로는 단순히 200 OK를 반환하는 것만으로는 부족합니다.

데이터베이스 연결, 외부 API 접근 등 핵심 기능이 정상 작동하는지 확인해야 합니다. /health 엔드포인트에서 의존성을 모두 체크하는 것이 좋은 패턴입니다.

또 다른 실수는 컨테이너 시작 시간을 고려하지 않는 것입니다. Node.js 애플리케이션이 시작하는 데 30초가 걸린다면, 헬스체크 시작 대기 시간을 충분히 설정해야 합니다.

그렇지 않으면 아직 준비되지 않은 컨테이너가 unhealthy로 판정되어 계속 재시작됩니다. 배포 중에는 구버전과 신버전이 동시에 실행됩니다.

따라서 데이터베이스 스키마 변경 시 주의가 필요합니다. 신버전이 요구하는 새 컬럼을 추가할 때, 구버전이 여전히 동작할 수 있도록 호환성을 유지해야 합니다.

먼저 컬럼을 추가하고, 배포 후에 구 컬럼을 삭제하는 2단계 접근이 안전합니다. 다시 이개발 씨의 이야기로 돌아가 봅시다.

롤링 업데이트의 원리를 이해한 이개발 씨는 감탄했습니다. "이제 언제든 자신 있게 배포할 수 있겠어요!" 롤링 업데이트를 제대로 이해하고 활용하면 하루에도 여러 번 안전하게 배포할 수 있습니다.

여러분도 오늘 배운 내용을 실전에 적용해 보세요.

실전 팁

💡 - 헬스체크는 핵심 기능의 정상 동작을 확인하도록 구현하세요

컨테이너 시작 시간을 고려하여 헬스체크 유예 시간을 설정하세요
배포 중 구버전과 신버전이 공존하므로 데이터 스키마 변경 시 호환성을 유지하세요

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#ECS#Docker#Container#Deploy

ECS 서비스 배포 완벽 가이드

# ECS 서비스 배포 완벽 가이드 AWS ECS에서 서비스를 생성하고 배포하는 방법을 실무 중심으로 배웁니다. Desired count 설정부터 롤링 업데이트까지, 안정적인 배포 전략을 단계별로 학습합니다. --- ## 목차 1. [ECS 서비스란?](#ecs-서비스란?) 2. [서비스 생성하기](#서비스-생성하기) 3. [Desired count 설정](#desired-count-설정) 4. [배포 구성](#배포-구성) 5. [서비스 업데이트](#서비스-업데이트) 6. [롤링 업데이트](#롤링-업데이트) --- ## 1. ECS 서비스란? 어느 날 이개발 씨는 드디어 Docker 컨테이너로 만든 애플리케이션을 프로덕션에 배포하게 되었습니다. "이제 이걸 어떻게 운영하지?" 고민하던 중, 팀장님이 말씀하셨습니다. "ECS 서비스로 관리하면 됩니다." **ECS 서비스**는 지정한 수의 태스크가 항상 실행되도록 보장하는 관리 계층입니다. 마치 24시간 가게를 운영하면서 항상 직원 3명이 일하도록 관리하는 매니저와 같습니다. 컨테이너가 중단되면 자동으로 새로운 것을 시작해주고, 로드밸런서와 연결하여 트래픽을 분산시킵니다. 다음 코드를 살펴봅시다. ```javascript // AWS CLI로 ECS 서비스 생성하기 aws ecs create-service \ --cluster my-cluster \ --service-name my-web-service \ --task-definition my-app:1 \ --desired-count 3 \ --launch-type FARGATE \ --network-configuration "awsvpcConfiguration={subnets=[subnet-12345],securityGroups=[sg-12345],assignPublicIp=ENABLED}" \ --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:...,containerName=web,containerPort=80" // 서비스 상태 확인 aws ecs describe-services --cluster my-cluster --services my-web-service ``` 이개발 씨는 지난 3개월 동안 열심히 웹 애플리케이션을 개발했습니다. Docker로 컨테이너화도 완료했고, ECR에 이미지도 올렸습니다. 이제 남은 것은 실제 사용자들이 접속할 수 있도록 배포하는 것입니다. "그냥 EC2에 Docker 실행하면 안 되나요?" 이개발 씨가 물었습니다. 팀장 박클라우드 씨는 웃으며 대답했습니다. "물론 가능하죠. 하지만 컨테이너가 갑자기 죽으면 어떻게 하시겠어요? 새벽 3시에 전화 받고 싶으세요?" ECS 서비스가 필요한 이유가 바로 여기에 있습니다. **ECS 서비스**는 단순히 컨테이너를 실행하는 것을 넘어서, 운영 관점에서 필요한 모든 것을 제공합니다. 마치 24시간 편의점을 운영한다고 생각해봅시다. 항상 직원 3명이 근무해야 한다는 규칙이 있다면, 누군가 퇴근하거나 아프면 즉시 대체 인력을 투입해야 합니다. ECS 서비스도 마찬가지입니다. "항상 컨테이너 3개를 실행하라"고 지시하면, 어떤 이유로든 컨테이너가 중단되면 자동으로 새로운 컨테이너를 시작합니다. 이것을 **원하는 상태 유지**라고 부릅니다. 서비스가 없던 시절에는 어땠을까요? 개발자가 직접 각 컨테이너를 관리해야 했습니다. 컨테이너가 죽었는지 확인하고, 수동으로 재시작하고, 로드밸런서 설정을 직접 변경해야 했습니다. 밤낮으로 모니터링하며 긴장해야 했죠. 더 큰 문제는 배포할 때였습니다. 무중단 배포를 위해 복잡한 스크립트를 작성하고, 한 번에 하나씩 조심스럽게 컨테이너를 교체해야 했습니다. 바로 이런 운영 부담을 해결하기 위해 ECS 서비스가 등장했습니다. ECS 서비스를 사용하면 **선언적 관리**가 가능해집니다. "이렇게 실행하라"가 아니라 "이런 상태를 유지하라"고 선언하는 것입니다. 또한 **자동 복구** 기능도 얻을 수 있습니다. 무엇보다 **로드밸런서 통합**이라는 큰 이점이 있습니다. ALB나 NLB와 자동으로 연동되어 트래픽을 분산시킵니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 `--service-name`으로 서비스 이름을 지정합니다. 이 이름으로 서비스를 관리하게 됩니다. `--task-definition`은 어떤 컨테이너를 실행할지 정의합니다. 여기서 `my-app:1`은 태스크 정의의 이름과 버전을 의미합니다. `--desired-count 3`이 핵심입니다. 항상 3개의 태스크를 실행 상태로 유지하라는 의미입니다. `--launch-type FARGATE`는 서버리스 방식으로 실행하겠다는 뜻입니다. EC2 인스턴스 관리 없이 컨테이너만 신경 쓰면 됩니다. `--network-configuration`에서는 VPC 설정을 지정합니다. 어느 서브넷에서 실행할지, 어떤 보안 그룹을 적용할지 정합니다. 마지막으로 `--load-balancers`에서 로드밸런서를 연결합니다. 이렇게 하면 서비스가 시작될 때 자동으로 로드밸런서의 타겟 그룹에 등록됩니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 쇼핑몰 API 서버를 운영한다고 가정해봅시다. 평소에는 트래픽이 적지만, 세일 기간에는 폭주합니다. ECS 서비스를 활용하면 Auto Scaling과 연동하여 트래픽에 따라 컨테이너 수를 자동으로 조절할 수 있습니다. 또한 컨테이너가 비정상 종료되더라도 즉시 새로운 컨테이너가 투입되어 서비스 중단을 방지합니다. 많은 스타트업과 대기업에서 이런 패턴을 적극적으로 사용하고 있습니다. 특히 마이크로서비스 아키텍처에서는 각 서비스를 ECS 서비스로 관리하는 것이 표준처럼 자리 잡았습니다. 하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수 중 하나는 태스크 정의와 서비스를 혼동하는 것입니다. **태스크 정의**는 컨테이너의 설계도이고, **서비스**는 그 설계도를 기반으로 실제로 실행하고 관리하는 계층입니다. 설계도만 있고 건물을 짓지 않으면 아무 일도 일어나지 않는 것처럼, 태스크 정의만으로는 컨테이너가 실행되지 않습니다. 또 다른 실수는 네트워크 설정을 잘못하는 것입니다. 퍼블릭 서브넷에서 실행하려면 `assignPublicIp=ENABLED`를 반드시 설정해야 합니다. 그렇지 않으면 컨테이너가 인터넷에 접근할 수 없어 이미지를 다운로드하지 못하고 시작에 실패합니다. 다시 이개발 씨의 이야기로 돌아가 봅시다. 박클라우드 씨의 설명을 들은 이개발 씨는 고개를 끄덕였습니다. "아, 그래서 ECS 서비스라는 게 필요하구나!" ECS 서비스를 제대로 이해하면 안정적이고 확장 가능한 컨테이너 운영이 가능합니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - 서비스 이름은 클러스터 내에서 고유해야 하며, 명확한 네이밍 규칙을 사용하세요 - Fargate를 사용하면 서버 관리 부담이 없지만, 비용이 약간 더 높습니다 - 개발 환경에서는 desired-count를 1로, 프로덕션에서는 최소 2 이상으로 설정하세요 --- ## 2. 서비스 생성하기 드디어 이개발 씨가 첫 ECS 서비스를 생성하기로 했습니다. AWS 콘솔을 열고 ECS 메뉴로 들어갔지만, 수많은 옵션에 당황했습니다. "이걸 다 설정해야 해요?" 옆에서 지켜보던 선배 최데브옵스 씨가 말했습니다. "핵심만 알면 5분이면 됩니다." ECS 서비스를 생성할 때는 **클러스터, 태스크 정의, 네트워크, 로드밸런서** 네 가지 핵심 요소를 설정합니다. 마치 새 가게를 오픈할 때 위치, 메뉴, 인테리어, 간판을 정하는 것과 같습니다. 순서대로 따라하면 누구나 성공적으로 서비스를 시작할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // Terraform으로 ECS 서비스 생성하기 resource "aws_ecs_service" "app" { name = "my-app-service" cluster = aws_ecs_cluster.main.id task_definition = aws_ecs_task_definition.app.arn desired_count = 2 launch_type = "FARGATE" network_configuration { subnets = aws_subnet.private[*].id security_groups = [aws_security_group.ecs_tasks.id] assign_public_ip = false } load_balancer { target_group_arn = aws_lb_target_group.app.arn container_name = "app" container_port = 8080 } depends_on = [aws_lb_listener.app] } ``` 이개발 씨는 화면을 보며 고민에 빠졌습니다. ECS 콘솔에는 수십 개의 설정 항목이 있었고, 각각 무엇을 의미하는지 알기 어려웠습니다. "이거 잘못 설정하면 어떻게 되죠?" 불안한 마음에 물었습니다. 최데브옵스 씨는 웃으며 화이트보드를 들고 왔습니다. "어렵게 생각할 것 없어요. 핵심만 이해하면 됩니다." ECS 서비스를 생성하는 것은 생각보다 단순합니다. 하지만 처음에는 용어와 개념이 낯설어서 어렵게 느껴집니다. 쉽게 비유하자면, ECS 서비스 생성은 마치 새로운 레스토랑을 오픈하는 것과 같습니다. 먼저 어느 쇼핑몰에 입점할지 결정해야 합니다(클러스터). 그다음 어떤 메뉴를 팔지 정합니다(태스크 정의). 매장 내부 인테리어와 동선을 설계하고(네트워크), 마지막으로 고객이 찾아올 수 있도록 간판을 답니다(로드밸런서). 이 네 가지만 제대로 설정하면 레스토랑이 오픈됩니다. 서비스 생성이 체계화되기 전에는 어땠을까요? 개발자가 직접 EC2 인스턴스에 접속해서 Docker 명령어를 실행해야 했습니다. 컨테이너를 하나씩 수동으로 시작하고, 각각의 IP 주소를 로드밸런서에 등록하고, 헬스체크가 통과할 때까지 기다렸습니다. 실수로 설정을 빠뜨리면 컨테이너는 실행되지만 트래픽이 도달하지 않는 유령 서비스가 되기도 했습니다. 더 큰 문제는 확장할 때였습니다. 컨테이너를 하나 더 추가하려면 모든 과정을 반복해야 했습니다. 팀원 간 설정 방법이 달라서 환경마다 미묘한 차이가 생기기도 했습니다. 바로 이런 혼란을 해결하기 위해 ECS 서비스 생성 프로세스가 표준화되었습니다. ECS 서비스를 사용하면 **일관된 방식**으로 서비스를 생성할 수 있습니다. 클릭 몇 번이나 코드 몇 줄이면 완성됩니다. 또한 **재현 가능한 인프라**를 얻을 수 있습니다. Terraform이나 CloudFormation으로 코드화하면 언제든 똑같은 환경을 만들 수 있습니다. 무엇보다 **실수 방지**라는 큰 이점이 있습니다. 필수 항목을 빠뜨리면 에러를 보여주기 때문에 설정 누락을 방지할 수 있습니다. 위의 Terraform 코드를 단계별로 살펴보겠습니다. 먼저 `name`과 `cluster`를 지정합니다. 어느 클러스터에 어떤 이름의 서비스를 만들 것인지 선언하는 것입니다. 다음으로 `task_definition`을 설정합니다. 이것이 실제로 실행할 컨테이너의 설계도입니다. `desired_count = 2`는 항상 2개의 태스크를 실행 상태로 유지하라는 의미입니다. `network_configuration` 블록이 중요합니다. `subnets`에서는 컨테이너가 실행될 서브넷을 지정합니다. 프라이빗 서브넷을 사용하면 보안이 강화됩니다. `security_groups`는 방화벽 규칙을 정의합니다. `assign_public_ip = false`는 프라이빗 서브넷에서 실행하므로 퍼블릭 IP가 필요 없다는 뜻입니다. `load_balancer` 블록에서 로드밸런서를 연결합니다. `target_group_arn`은 어느 타겟 그룹에 등록할지, `container_name`과 `container_port`는 컨테이너의 어느 포트로 트래픽을 보낼지 지정합니다. 마지막으로 `depends_on`은 리스너가 먼저 생성된 후 서비스를 만들라는 의존성 선언입니다. 이것이 없으면 서비스 생성 시 리스너가 없어서 실패할 수 있습니다. 실제 현업에서는 어떻게 활용할까요? 대부분의 기업에서는 AWS 콘솔보다 Infrastructure as Code를 선호합니다. Terraform이나 CloudFormation으로 서비스를 정의해두면, 개발/스테이징/프로덕션 환경을 일관되게 관리할 수 있습니다. 또한 Git으로 버전 관리하여 언제든 이전 상태로 롤백할 수 있습니다. 예를 들어 신규 마이크로서비스를 추가할 때, 기존 서비스의 Terraform 코드를 복사하여 몇 가지 값만 수정하면 됩니다. 클러스터, 네트워크, 보안 그룹 등의 공통 설정은 재사용하고, 서비스별 고유 설정만 변경하는 것입니다. 이렇게 하면 팀 전체가 동일한 패턴을 따르게 되어 운영이 훨씬 수월해집니다. 하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수 중 하나는 보안 그룹을 잘못 설정하는 것입니다. 컨테이너의 보안 그룹은 로드밸런서의 보안 그룹으로부터 트래픽을 허용해야 합니다. 만약 잘못 설정하면 서비스는 정상 실행되지만 헬스체크가 실패하여 unhealthy 상태로 남게 됩니다. 또 다른 실수는 서브넷 선택입니다. 퍼블릭 서브넷에서 실행하면서 `assign_public_ip = false`로 설정하면 컨테이너가 인터넷에 접근할 수 없습니다. 반대로 프라이빗 서브넷에서 `assign_public_ip = true`로 설정해도 퍼블릭 IP는 할당되지 않습니다. 서브넷 타입과 IP 할당 옵션을 정확히 이해해야 합니다. 다시 이개발 씨의 이야기로 돌아가 봅시다. 최데브옵스 씨의 설명을 들은 이개발 씨는 자신감이 생겼습니다. "생각보다 간단하네요!" ECS 서비스 생성을 제대로 이해하면 몇 분 만에 새로운 서비스를 배포할 수 있습니다. 여러분도 오늘 배운 내용을 실제로 시도해 보세요. **실전 팁** 💡 - 처음에는 AWS 콘솔로 생성해보고, 이해한 후 Terraform으로 전환하세요 - 보안 그룹은 최소 권한 원칙을 따르되, 헬스체크 포트는 반드시 열어야 합니다 - 프라이빗 서브넷 사용 시 NAT Gateway 설정을 확인하세요 --- ## 3. Desired count 설정 서비스를 생성한 이개발 씨는 desired count를 몇으로 설정해야 할지 고민에 빠졌습니다. "1개면 충분할까요, 아니면 10개로 해야 할까요?" 옆에서 듣던 박클라우드 씨가 말했습니다. "무조건 많다고 좋은 건 아닙니다. 상황에 맞게 설정해야죠." **Desired count**는 서비스가 항상 유지해야 할 태스크의 개수입니다. 마치 식당에서 최소 몇 명의 직원이 근무해야 하는지 정하는 것과 같습니다. 너무 적으면 장애 시 서비스가 중단되고, 너무 많으면 비용이 낭비됩니다. 적절한 균형을 찾는 것이 중요합니다. 다음 코드를 살펴봅시다. ```javascript // AWS CLI로 desired count 업데이트 aws ecs update-service \ --cluster my-cluster \ --service my-app-service \ --desired-count 3 // Auto Scaling으로 동적 조정 resource "aws_appautoscaling_target" "ecs" { max_capacity = 10 min_capacity = 2 resource_id = "service/${aws_ecs_cluster.main.name}/${aws_ecs_service.app.name}" scalable_dimension = "ecs:service:DesiredCount" service_namespace = "ecs" } // CPU 기반 스케일링 정책 resource "aws_appautoscaling_policy" "cpu" { name = "cpu-autoscaling" policy_type = "TargetTrackingScaling" resource_id = aws_appautoscaling_target.ecs.resource_id scalable_dimension = aws_appautoscaling_target.ecs.scalable_dimension service_namespace = aws_appautoscaling_target.ecs.service_namespace target_tracking_scaling_policy_configuration { target_value = 70.0 predefined_metric_specification { predefined_metric_type = "ECSServiceAverageCPUUtilization" } } } ``` 이개발 씨는 진지한 표정으로 물었습니다. "개발 환경이니까 1개로 해도 되겠죠?" 박클라우드 씨는 고개를 저었습니다. "1개만 실행하면 배포할 때 서비스가 중단됩니다. 최소 2개는 유지해야 무중단 배포가 가능해요." Desired count 설정은 단순해 보이지만, 서비스의 가용성과 비용에 직접적인 영향을 미치는 중요한 결정입니다. 쉽게 비유하자면, desired count는 마치 24시간 편의점의 근무 인원과 같습니다. 낮 시간대에는 손님이 많으니 직원 3명이 필요하지만, 새벽 시간에는 1명만 있어도 충분합니다. 하지만 최소 1명은 항상 있어야 가게가 운영됩니다. 만약 유일한 직원이 화장실에 가면 그 순간 가게는 무인 상태가 됩니다. 따라서 최소 2명은 있어야 안전합니다. ECS도 마찬가지입니다. Desired count 1로 설정하면 평소에는 문제없지만, 그 하나의 태스크가 재시작되는 순간 서비스가 중단됩니다. 배포할 때나 컨테이너에 문제가 생겼을 때 다운타임이 발생하는 것입니다. Desired count를 고정값으로만 사용하던 시절에는 어땠을까요? 트래픽이 많아질 것을 대비해서 항상 넉넉하게 설정해야 했습니다. 새벽에 사용자가 거의 없어도 10개의 컨테이너가 계속 실행되었습니다. 반대로 너무 적게 설정하면 갑작스러운 트래픽 증가에 대응할 수 없었습니다. 담당자가 수동으로 모니터링하다가 CPU 사용률이 높아지면 급하게 desired count를 올리는 식이었습니다. 밤에 알람이 울려서 깨어나 desired count를 조정하는 일도 흔했습니다. 사람이 직접 개입해야 하므로 대응이 느렸고, 휴일이나 심야에는 대응 자체가 어려웠습니다. 바로 이런 운영 부담을 해결하기 위해 Auto Scaling이 등장했습니다. Auto Scaling을 사용하면 **자동 확장**이 가능해집니다. CPU 사용률이나 메모리 사용률을 모니터링하다가 임계값을 넘으면 자동으로 desired count를 증가시킵니다. 또한 **자동 축소**도 지원합니다. 트래픽이 줄어들면 불필요한 태스크를 종료하여 비용을 절감합니다. 무엇보다 **무중단 운영**이라는 큰 이점이 있습니다. 사람의 개입 없이 시스템이 알아서 조절하므로 새벽에도 안심할 수 있습니다. 위의 코드를 단계별로 살펴보겠습니다. 먼저 간단한 방법은 AWS CLI로 직접 desired count를 변경하는 것입니다. `--desired-count 3`으로 설정하면 즉시 3개의 태스크를 유지하도록 변경됩니다. 하지만 이것은 수동 방식입니다. 더 나은 방법은 Auto Scaling을 설정하는 것입니다. `aws_appautoscaling_target` 리소스에서 최소값과 최대값을 정의합니다. `min_capacity = 2`는 아무리 트래픽이 적어도 최소 2개는 유지하라는 의미입니다. `max_capacity = 10`은 최대 10개까지 확장할 수 있다는 뜻입니다. `aws_appautoscaling_policy`에서 스케일링 정책을 정의합니다. `target_value = 70.0`은 CPU 사용률을 70% 수준으로 유지하라는 목표입니다. 만약 평균 CPU가 70%를 넘으면 태스크를 추가하고, 70%보다 낮으면 태스크를 줄입니다. 이렇게 하면 항상 적정 수준의 리소스를 유지할 수 있습니다. 실제 현업에서는 어떻게 활용할까요? 대부분의 프로덕션 환경에서는 고정 desired count와 Auto Scaling을 혼합하여 사용합니다. 예를 들어 쇼핑몰 API 서버라면 평소에 최소 3개의 태스크를 유지하고, 트래픽이 증가하면 최대 20개까지 확장되도록 설정합니다. 블랙프라이데이 같은 대규모 이벤트를 앞두고는 미리 desired count를 높여두기도 합니다. 평소에는 Auto Scaling에 맡기지만, 확실히 트래픽이 폭증할 것을 알고 있다면 사전에 스케일 아웃하는 것이 안전합니다. 스케일링에는 시간이 걸리므로, 급격한 트래픽 증가에는 대응이 늦을 수 있기 때문입니다. 또한 여러 지표를 조합하여 스케일링하기도 합니다. CPU뿐만 아니라 메모리, 요청 수, 응답 시간 등을 함께 고려하여 더 정교하게 조절하는 것입니다. 하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수 중 하나는 min_capacity를 1로 설정하는 것입니다. 최소 1개만 유지하면 배포 중에 다운타임이 발생합니다. 무중단 배포를 위해서는 최소 2개 이상을 유지해야 합니다. 또 다른 실수는 스케일링 임계값을 너무 낮게 설정하는 것입니다. CPU 30%에 스케일 아웃하도록 설정하면, 조금만 부하가 생겨도 계속 확장됩니다. 비용이 불필요하게 증가할 수 있습니다. 일반적으로 70-80% 정도가 적정합니다. 스케일 다운 속도도 중요합니다. 너무 빠르게 줄이면 트래픽이 다시 증가했을 때 대응이 느립니다. 스케일 업은 빠르게, 스케일 다운은 천천히 하는 것이 원칙입니다. 다시 이개발 씨의 이야기로 돌아가 봅시다. 박클라우드 씨의 설명을 들은 이개발 씨는 이해했습니다. "개발 환경은 2개, 프로덕션은 Auto Scaling으로 가야겠네요!" Desired count를 제대로 설정하면 가용성과 비용 효율을 모두 잡을 수 있습니다. 여러분도 오늘 배운 내용을 자신의 환경에 맞게 조정해 보세요. **실전 팁** 💡 - 프로덕션 환경에서는 최소 2개 이상의 태스크를 유지하세요 - CPU 70-80%를 목표로 Auto Scaling을 설정하는 것이 일반적입니다 - 스케일 다운은 천천히, 스케일 업은 빠르게 설정하세요 --- ## 4. 배포 구성 이제 실제 배포를 준비하는 단계입니다. 이개발 씨는 새로운 버전의 코드를 배포하려고 하는데, 어떻게 해야 사용자에게 영향을 주지 않을지 고민입니다. "배포하는 동안 서비스가 중단되면 안 되는데요." 최데브옵스 씨가 웃으며 말했습니다. "그래서 배포 구성이 중요합니다." **배포 구성**은 새 버전을 어떻게 배포할지 정의하는 전략입니다. 마치 식당에서 주방장을 교체할 때, 모든 주방장을 한 번에 바꿀지 한 명씩 바꿀지 정하는 것과 같습니다. ECS에서는 롤링 업데이트, 블루/그린 배포, 카나리 배포 등 다양한 방식을 제공합니다. 다음 코드를 살펴봅시다. ```javascript // Rolling Update 배포 구성 resource "aws_ecs_service" "app" { name = "my-app-service" cluster = aws_ecs_cluster.main.id task_definition = aws_ecs_task_definition.app.arn desired_count = 4 deployment_configuration { maximum_percent = 200 // 최대 8개까지 동시 실행 가능 minimum_healthy_percent = 50 // 최소 2개는 항상 실행 유지 } deployment_circuit_breaker { enable = true rollback = true // 배포 실패 시 자동 롤백 } // Blue/Green 배포 설정 (CodeDeploy 사용 시) deployment_controller { type = "CODE_DEPLOY" } } // 태스크 정의 업데이트로 배포 트리거 aws ecs update-service \ --cluster my-cluster \ --service my-app-service \ --task-definition my-app:2 \ --force-new-deployment ``` 이개발 씨는 긴장된 표정으로 물었습니다. "그냥 태스크 정의를 업데이트하면 자동으로 배포되는 거 아닌가요?" 최데브옵스 씨는 고개를 끄덕였습니다. "맞아요. 하지만 어떻게 배포될지는 배포 구성에 달려 있습니다." 배포는 운영 중인 서비스에서 가장 위험한 작업 중 하나입니다. 새로운 코드에 버그가 있을 수 있고, 설정이 잘못되었을 수도 있습니다. 배포 방식에 따라 사용자 경험과 서비스 안정성이 크게 달라집니다. 쉽게 비유하자면, 배포는 마치 고속도로에서 차선을 변경하는 것과 같습니다. 한 번에 모든 차를 새 차선으로 옮기면 혼란이 발생합니다. 하지만 천천히 한 대씩 옮기면 교통 흐름이 유지됩니다. ECS의 배포 구성은 바로 이런 "차선 변경 전략"을 정의하는 것입니다. 배포 구성이 없던 시절에는 어땠을까요? 모든 컨테이너를 한 번에 종료하고 새로운 버전을 시작했습니다. 이것을 "재생성 배포"라고 부릅니다. 간단하지만 치명적인 단점이 있었습니다. 구 버전 컨테이너를 종료하는 순간부터 신 버전 컨테이너가 준비될 때까지 서비스가 완전히 중단되는 것입니다. 새벽 시간에만 배포하거나, 점검 공지를 띄우고 배포해야 했습니다. 만약 배포가 실패하면 긴 다운타임이 발생했고, 사용자들은 오류 페이지만 보게 되었습니다. 롤백하려면 다시 처음부터 배포 과정을 반복해야 했습니다. 더 큰 문제는 배포 실패를 감지하는 메커니즘이 없었다는 것입니다. 새 버전에 심각한 버그가 있어도 일단 배포되면 그대로 서비스되었습니다. 사용자 신고를 받고 나서야 문제를 알게 되는 경우도 많았습니다. 바로 이런 위험을 줄이기 위해 정교한 배포 구성이 개발되었습니다. ECS의 배포 구성을 사용하면 **무중단 배포**가 가능해집니다. 구 버전과 신 버전이 잠시 공존하면서 점진적으로 전환됩니다. 또한 **자동 헬스체크**로 새 버전이 정상인지 확인합니다. 만약 헬스체크에 실패하면 배포를 중단하고 구 버전을 유지합니다. 무엇보다 **자동 롤백**이라는 안전장치가 있습니다. Circuit breaker를 활성화하면 배포 실패 시 자동으로 이전 버전으로 되돌아갑니다. 위의 코드를 자세히 살펴보겠습니다. `deployment_configuration` 블록이 핵심입니다. `maximum_percent = 200`은 배포 중에 desired count의 200%까지 태스크를 실행할 수 있다는 의미입니다. 예를 들어 desired count가 4라면 최대 8개까지 동시에 실행될 수 있습니다. 이렇게 하면 구 버전 4개가 실행 중인 상태에서 신 버전 4개를 모두 시작하고, 신 버전이 healthy 상태가 되면 구 버전을 종료합니다. `minimum_healthy_percent = 50`은 배포 중에도 최소 50%의 태스크는 healthy 상태를 유지해야 한다는 뜻입니다. Desired count가 4라면 최소 2개는 항상 실행되어야 합니다. 이 설정이 무중단 배포를 보장합니다. `deployment_circuit_breaker`는 배포 안전장치입니다. `enable = true`로 활성화하면 배포가 반복적으로 실패할 때 자동으로 감지합니다. `rollback = true`로 설정하면 실패 시 자동으로 이전 버전으로 롤백합니다. 이것이 없으면 배포가 계속 실패하는데도 시도를 반복하여 시간을 낭비합니다. 태스크 정의를 업데이트하면 자동으로 배포가 트리거됩니다. `--task-definition my-app:2`로 새 버전을 지정하면, 설정된 배포 구성에 따라 롤링 업데이트가 시작됩니다. `--force-new-deployment` 플래그는 태스크 정의가 바뀌지 않아도 강제로 배포하라는 의미입니다. 컨테이너 이미지는 바뀌었지만 태스크 정의는 같은 경우에 유용합니다. 실제 현업에서는 어떻게 활용할까요? 대부분의 기업에서는 롤링 업데이트를 기본으로 사용합니다. 빠르고 간단하며 대부분의 경우에 충분합니다. 하지만 중요한 서비스나 대규모 변경 시에는 블루/그린 배포를 선호합니다. 블루/그린 배포는 구 버전(블루)과 신 버전(그린)을 완전히 분리된 환경에서 실행하고, 로드밸런서를 전환하는 방식입니다. 롤백이 즉각적이고 안전합니다. 금융권이나 의료 시스템처럼 안정성이 극도로 중요한 곳에서는 카나리 배포를 사용하기도 합니다. 전체 트래픽의 5%만 새 버전으로 보내고, 문제가 없으면 점진적으로 비율을 높여가는 방식입니다. 만약 에러율이 증가하면 즉시 중단하고 조사합니다. CI/CD 파이프라인과 통합하면 더욱 강력해집니다. GitHub Actions나 Jenkins에서 테스트가 통과하면 자동으로 새 태스크 정의를 생성하고 배포하는 식입니다. CloudWatch 알람과 연동하여 배포 후 에러율이나 응답 시간을 모니터링하고, 임계값을 넘으면 자동으로 롤백하는 고급 전략도 가능합니다. 하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수 중 하나는 maximum_percent를 너무 낮게 설정하는 것입니다. 예를 들어 100%로 설정하면 추가 태스크를 실행할 수 없습니다. 이 경우 구 버전을 종료해야만 신 버전을 시작할 수 있어서 배포가 매우 느려집니다. 반대로 minimum_healthy_percent를 너무 높게 설정하는 것도 문제입니다. 100%로 설정하면 모든 태스크가 healthy 상태를 유지해야 하므로, 배포 중에 일시적으로 용량이 부족할 수 있습니다. 특히 클러스터 리소스가 제한적일 때 배포가 멈출 수 있습니다. Circuit breaker를 활성화하지 않는 것도 위험합니다. 배포가 실패해도 계속 시도하면서 시간만 낭비하고, 결국 수동으로 개입해야 합니다. 항상 circuit breaker를 활성화하고 자동 롤백을 설정하세요. 다시 이개발 씨의 이야기로 돌아가 봅시다. 최데브옵스 씨의 설명을 들은 이개발 씨는 안심했습니다. "이제 배포가 두렵지 않네요!" 배포 구성을 제대로 설정하면 안전하고 빠른 배포가 가능합니다. 여러분도 오늘 배운 내용을 자신의 서비스에 적용해 보세요. **실전 팁** 💡 - maximum_percent는 200%, minimum_healthy_percent는 50%로 시작하는 것이 안전합니다 - 반드시 circuit breaker와 자동 롤백을 활성화하세요 - 블루/그린 배포는 중요한 변경이나 대규모 서비스에 적합합니다 --- ## 5. 서비스 업데이트 배포 구성까지 완료한 이개발 씨는 실제로 서비스를 업데이트할 차례입니다. "코드를 수정했으니 이제 배포하면 되는 거죠?" 그렇게 말하며 배포 버튼을 누르려던 순간, 최데브옵스 씨가 손을 잡았습니다. "잠깐만요. 서비스 업데이트는 단순히 배포 버튼만 누르는 게 아닙니다." **서비스 업데이트**는 새로운 태스크 정의로 서비스를 갱신하는 과정입니다. 마치 레스토랑의 메뉴판을 새 버전으로 교체하는 것과 같습니다. 이미지 태그 변경, 환경변수 수정, 리소스 할당 조정 등 다양한 이유로 서비스를 업데이트하게 됩니다. 다음 코드를 살펴봅시다. ```javascript // 1. 새 태스크 정의 생성 { "family": "my-app", "containerDefinitions": [ { "name": "app", "image": "123456789.dkr.ecr.us-east-1.amazonaws.com/my-app:v2.0.0", "memory": 512, "cpu": 256, "essential": true, "environment": [ {"name": "NODE_ENV", "value": "production"}, {"name": "API_VERSION", "value": "v2"} ], "portMappings": [ {"containerPort": 8080, "protocol": "tcp"} ] } ] } // 2. 태스크 정의 등록 aws ecs register-task-definition --cli-input-json file://task-definition.json // 3. 서비스 업데이트 (새 태스크 정의 적용) aws ecs update-service \ --cluster my-cluster \ --service my-app-service \ --task-definition my-app:2 // 4. 배포 상태 모니터링 aws ecs describe-services \ --cluster my-cluster \ --services my-app-service \ --query 'services[0].deployments' ``` 이개발 씨는 당황했습니다. "배포 버튼만 누르면 안 되나요?" 최데브옵스 씨는 화면을 가리키며 설명했습니다. "ECS는 태스크 정의라는 개념을 사용합니다. 서비스를 업데이트하려면 먼저 새로운 태스크 정의를 만들어야 해요." 서비스 업데이트는 생각보다 많은 단계를 거칩니다. 하지만 각 단계를 이해하면 배포 과정을 정확히 제어할 수 있습니다. 쉽게 비유하자면, 서비스 업데이트는 마치 건축 설계도를 개정하는 것과 같습니다. 먼저 새로운 설계도를 그립니다(태스크 정의 작성). 그다음 건축 허가를 받습니다(태스크 정의 등록). 마지막으로 실제 건물을 개정된 설계도대로 리모델링합니다(서비스 업데이트). 설계도 없이는 건물을 바꿀 수 없는 것처럼, 태스크 정의 없이는 서비스를 업데이트할 수 없습니다. 서비스 업데이트가 체계화되기 전에는 어땠을까요? 개발자가 직접 각 서버에 접속해서 수동으로 컨테이너를 재시작했습니다. "지금부터 서버 1번 배포합니다", "서버 2번 배포 시작" 이런 식으로 하나씩 처리했습니다. 설정 파일을 직접 편집하고, Docker 명령어를 실행하고, 로그를 지켜보면서 문제가 없는지 확인했습니다. 배포 중에 문제가 생기면 긴급하게 중단하고 이전 버전으로 롤백해야 했습니다. 하지만 어느 서버까지 배포했는지, 어떤 버전이 실행 중인지 추적하기 어려웠습니다. 여러 사람이 동시에 배포하면 충돌이 발생하기도 했습니다. 더 큰 문제는 일관성이었습니다. 서버마다 미묘하게 다른 설정이나 버전으로 실행되는 경우가 많았습니다. "이상하다, 로컬에서는 되는데..." 하는 말이 자주 들렸습니다. 바로 이런 혼란을 해결하기 위해 태스크 정의 기반 업데이트가 등장했습니다. ECS의 서비스 업데이트를 사용하면 **버전 관리**가 명확해집니다. 모든 태스크 정의는 버전 번호를 가지므로 언제든 특정 버전으로 돌아갈 수 있습니다. 또한 **선언적 관리**가 가능합니다. 원하는 상태를 선언하면 ECS가 알아서 그 상태로 만들어줍니다. 무엇보다 **추적 가능성**이라는 큰 이점이 있습니다. 누가 언제 어떤 변경을 했는지 모두 기록됩니다. 위의 과정을 단계별로 살펴보겠습니다. 첫 번째 단계는 새로운 태스크 정의를 작성하는 것입니다. JSON 형식으로 컨테이너 이미지, 리소스, 환경변수 등을 정의합니다. 여기서는 이미지를 `v2.0.0` 태그로 변경하고, `API_VERSION` 환경변수를 추가했습니다. 메모리나 CPU 할당도 필요에 따라 조정할 수 있습니다. 두 번째 단계는 태스크 정의를 ECS에 등록하는 것입니다. `register-task-definition` 명령으로 JSON 파일을 제출하면 새로운 버전이 생성됩니다. 예를 들어 이전이 `my-app:1`이었다면 이제 `my-app:2`가 만들어집니다. 세 번째 단계가 실제 서비스 업데이트입니다. `update-service` 명령으로 서비스가 새 태스크 정의를 사용하도록 지시합니다. 이 순간 롤링 업데이트가 시작됩니다. 구 버전 태스크를 하나씩 종료하고 신 버전 태스크를 시작하는 것입니다. 네 번째 단계는 배포 상태를 모니터링하는 것입니다. `describe-services` 명령으로 현재 어떤 배포가 진행 중인지, 몇 개의 태스크가 실행 중인지 확인할 수 있습니다. 배포가 완료될 때까지 지켜보면서 문제가 없는지 확인합니다. 실제 현업에서는 어떻게 활용할까요? 대부분의 팀에서는 서비스 업데이트를 자동화합니다. CI/CD 파이프라인에서 코드가 푸시되면 자동으로 Docker 이미지를 빌드하고, ECR에 업로드하고, 새 태스크 정의를 생성하고, 서비스를 업데이트합니다. 이 모든 과정이 몇 분 안에 자동으로 진행됩니다. 예를 들어 GitHub Actions 워크플로우를 만들면 이렇습니다. 마스터 브랜치에 머지되면 테스트를 실행하고, Docker 이미지를 빌드하고, Git commit SHA를 이미지 태그로 사용하여 ECR에 푸시합니다. 그다음 태스크 정의 JSON 파일의 이미지 태그를 새로운 SHA로 교체하고, AWS CLI로 태스크 정의를 등록하고 서비스를 업데이트합니다. Terraform을 사용하면 더 편리합니다. 태스크 정의를 Terraform 코드로 관리하고, 이미지 태그만 변수로 받아서 변경합니다. `terraform apply`를 실행하면 자동으로 새 태스크 정의가 등록되고 서비스가 업데이트됩니다. 인프라 변경 이력이 Git에 남으므로 언제든 이전 상태로 돌아갈 수 있습니다. 배포 전후로 Slack이나 이메일로 알림을 보내는 것도 좋은 습관입니다. 팀원들이 배포 상황을 실시간으로 파악할 수 있고, 문제가 생기면 즉시 대응할 수 있습니다. 하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수 중 하나는 이미지 태그를 `latest`로 사용하는 것입니다. `latest` 태그는 항상 최신 이미지를 가리키므로, 동일한 태스크 정의로도 다른 이미지가 실행될 수 있습니다. 이렇게 되면 어떤 버전이 실행 중인지 알 수 없어 디버깅이 어렵습니다. 항상 명확한 버전 태그(v1.0.0, commit-sha 등)를 사용하세요. 또 다른 실수는 배포 후 확인하지 않는 것입니다. 서비스 업데이트 명령을 실행하면 즉시 반환되지만, 실제 배포는 백그라운드에서 진행됩니다. 반드시 배포 상태를 모니터링하고, 새 태스크가 healthy 상태인지 확인해야 합니다. CloudWatch 로그를 보면서 에러가 없는지도 체크하세요. 환경변수를 변경할 때도 주의가 필요합니다. 민감한 정보(API 키, 비밀번호)는 태스크 정의에 직접 넣지 말고 Secrets Manager나 Parameter Store를 사용하세요. 태스크 정의는 평문으로 저장되므로 보안에 취약합니다. 다시 이개발 씨의 이야기로 돌아가 봅시다. 최데브옵스 씨의 안내에 따라 차근차근 진행한 이개발 씨는 첫 배포에 성공했습니다. "생각보다 간단하네요!" 서비스 업데이트를 제대로 이해하면 자신 있게 배포할 수 있습니다. 여러분도 오늘 배운 내용을 실제 배포에 적용해 보세요. **실전 팁** 💡 - 이미지 태그는 `latest` 대신 명확한 버전이나 commit SHA를 사용하세요 - 배포 후 반드시 CloudWatch 로그와 메트릭을 확인하세요 - 민감한 정보는 Secrets Manager를 사용하여 관리하세요 --- ## 6. 롤링 업데이트 첫 배포를 성공한 이개발 씨는 배포 과정을 지켜보며 신기해했습니다. "어? 서비스가 중단되지 않고 계속 동작하네요?" 최데브옵스 씨가 웃으며 설명했습니다. "바로 롤링 업데이트 덕분입니다. 하나씩 차근차근 교체하는 거죠." **롤링 업데이트**는 구 버전 태스크를 점진적으로 종료하면서 신 버전 태스크를 시작하는 무중단 배포 방식입니다. 마치 달리는 기차의 객차를 하나씩 교체하는 것과 같습니다. 기차는 멈추지 않고 계속 달리면서 객차만 바뀌는 것입니다. 다음 코드를 살펴봅시다. ```javascript // 롤링 업데이트 프로세스 시뮬레이션 // 초기 상태: 4개의 구버전 태스크 실행 중 (desired=4) // [v1, v1, v1, v1] // 1단계: 신버전 태스크 2개 시작 (maximum_percent=200 → 최대 8개) // [v1, v1, v1, v1, v2, v2] // 2단계: 신버전 태스크가 healthy 되면 구버전 2개 종료 // [v1, v1, v2, v2] // 3단계: 추가로 신버전 2개 시작 // [v1, v1, v2, v2, v2, v2] // 4단계: 신버전 healthy 확인 후 남은 구버전 종료 // [v2, v2, v2, v2] // ECS 이벤트로 롤링 업데이트 추적 aws ecs describe-services \ --cluster my-cluster \ --services my-app-service \ --query 'services[0].events[0:10]' // 배포 진행 상황 확인 watch -n 5 'aws ecs describe-services \ --cluster my-cluster \ --services my-app-service \ --query "services[0].deployments[*].[id,status,runningCount,desiredCount]" \ --output table' ``` 이개발 씨는 모니터링 화면을 보며 감탄했습니다. 구버전 태스크가 하나씩 사라지고 신버전 태스크가 생겨나는 모습이 마치 세포 분열을 보는 것 같았습니다. "이게 어떻게 가능한 거예요?" 롤링 업데이트는 현대 클라우드 배포의 핵심 기술입니다. 무중단 배포를 가능하게 만드는 마법 같은 메커니즘입니다. 쉽게 비유하자면, 롤링 업데이트는 마치 24시간 운영하는 편의점의 직원 교대와 같습니다. 밤 11시에 야간 근무자가 출근하면, 저녁 근무자는 바로 퇴근하지 않습니다. 두 사람이 잠시 함께 일하면서 인수인계를 합니다. 야간 근무자가 익숙해지고 문제없이 업무를 처리하는 것을 확인한 후에야 저녁 근무자가 퇴근합니다. 이렇게 하면 고객은 직원이 바뀌는지도 모르고 서비스를 계속 이용할 수 있습니다. ECS의 롤링 업데이트도 정확히 같은 원리입니다. 신버전 태스크가 시작되고 healthy 상태가 되는 것을 확인한 후에 구버전 태스크를 종료합니다. 서비스는 단 한 순간도 멈추지 않습니다. 롤링 업데이트가 없던 시절에는 어땠을까요? "재생성 배포"라는 방식을 사용했습니다. 모든 구버전 컨테이너를 한 번에 종료하고, 신버전 컨테이너를 시작합니다. 간단하지만 치명적인 문제가 있었습니다. 종료와 시작 사이에 수십 초에서 수 분의 다운타임이 발생하는 것입니다. 사용자들은 갑자기 "503 Service Unavailable" 에러를 보게 됩니다. 새벽 3시에 배포하더라도 해외 사용자나 야간 근무자들에게는 영향이 갑니다. 더 큰 문제는 배포가 실패했을 때였습니다. 신버전 컨테이너가 시작되지 않으면 서비스는 완전히 중단된 상태로 남습니다. 급하게 롤백을 시도해도 다시 구버전을 시작하는 시간이 필요합니다. 또 다른 방식인 "블루/그린 배포"도 있었지만, 리소스가 두 배로 필요하다는 단점이 있었습니다. 구버전 환경을 그대로 유지하면서 완전히 새로운 환경을 만들어야 하니까요. 작은 스타트업에는 비용 부담이 컸습니다. 바로 이런 문제들을 해결하기 위해 롤링 업데이트가 표준이 되었습니다. 롤링 업데이트를 사용하면 **무중단 배포**가 가능합니다. 사용자는 배포가 진행 중인지조차 알지 못합니다. 또한 **점진적 검증**이 가능합니다. 신버전이 정상 작동하는지 단계적으로 확인하면서 진행합니다. 무엇보다 **리소스 효율성**이라는 장점이 있습니다. 블루/그린처럼 두 배의 리소스가 필요하지 않고, 일시적으로만 약간의 추가 리소스를 사용합니다. 위의 단계를 자세히 살펴보겠습니다. 초기 상태에서는 desired count가 4이므로 4개의 v1 태스크가 실행 중입니다. 모든 태스크가 healthy 상태이고 트래픽을 정상적으로 처리하고 있습니다. 1단계에서 서비스 업데이트가 트리거되면 ECS는 신버전 태스크를 시작합니다. `maximum_percent=200`이므로 최대 8개까지 태스크를 실행할 수 있습니다. 따라서 구버전 4개는 그대로 두고 신버전 2개를 추가로 시작합니다. 이 순간 총 6개의 태스크가 실행 중입니다. 2단계에서 신버전 태스크가 헬스체크를 통과하여 healthy 상태가 되면, ECS는 구버전 태스크 2개를 종료합니다. `minimum_healthy_percent=50`이므로 최소 2개는 항상 유지해야 합니다. 현재 신버전 2개가 healthy이고 구버전 2개도 실행 중이므로 총 4개가 유지되어 조건을 만족합니다. 3단계에서 다시 신버전 2개를 추가로 시작합니다. 이제 구버전 2개, 신버전 4개가 실행 중입니다. 추가된 신버전 태스크들이 healthy 상태가 되기를 기다립니다. 4단계에서 모든 신버전 태스크가 healthy가 되면 남은 구버전 2개를 종료합니다. 최종적으로 신버전 4개만 남게 되고 배포가 완료됩니다. 이 전체 과정은 수 분 내에 자동으로 진행됩니다. 개발자는 단지 `update-service` 명령 하나만 실행하면 됩니다. 실제 현업에서는 어떻게 활용할까요? 대부분의 웹 서비스에서 롤링 업데이트는 기본 배포 방식입니다. 하루에도 수십 번 배포하는 팀도 있는데, 매번 무중단으로 진행됩니다. 사용자는 전혀 눈치채지 못합니다. 롤링 업데이트 속도를 조절할 수도 있습니다. `maximum_percent`를 낮추면 천천히 교체되고, 높이면 빠르게 교체됩니다. 중요한 서비스는 천천히, 테스트 환경은 빠르게 설정하는 식입니다. CloudWatch를 활용하면 배포 중 메트릭을 실시간으로 모니터링할 수 있습니다. 에러율이 증가하거나 응답 시간이 길어지면 즉시 알람을 받습니다. 이상 징후가 감지되면 수동으로 롤백하거나, circuit breaker가 자동으로 중단시킵니다. 대규모 서비스에서는 카나리 배포와 결합하기도 합니다. 먼저 1개의 신버전 태스크만 시작하고 전체 트래픽의 10%만 보냅니다. 문제가 없으면 롤링 업데이트를 계속 진행하는 방식입니다. 이렇게 하면 더욱 안전합니다. 하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수 중 하나는 헬스체크를 제대로 설정하지 않는 것입니다. 헬스체크가 없거나 잘못 설정되어 있으면, 신버전 태스크가 실제로는 에러를 내고 있어도 healthy로 판단됩니다. 그러면 구버전이 종료되고 문제 있는 신버전만 남게 되어 서비스 장애가 발생합니다. 헬스체크 경로는 단순히 200 OK를 반환하는 것만으로는 부족합니다. 데이터베이스 연결, 외부 API 접근 등 핵심 기능이 정상 작동하는지 확인해야 합니다. `/health` 엔드포인트에서 의존성을 모두 체크하는 것이 좋은 패턴입니다. 또 다른 실수는 컨테이너 시작 시간을 고려하지 않는 것입니다. Node.js 애플리케이션이 시작하는 데 30초가 걸린다면, 헬스체크 시작 대기 시간을 충분히 설정해야 합니다. 그렇지 않으면 아직 준비되지 않은 컨테이너가 unhealthy로 판정되어 계속 재시작됩니다. 배포 중에는 구버전과 신버전이 동시에 실행됩니다. 따라서 데이터베이스 스키마 변경 시 주의가 필요합니다. 신버전이 요구하는 새 컬럼을 추가할 때, 구버전이 여전히 동작할 수 있도록 호환성을 유지해야 합니다. 먼저 컬럼을 추가하고, 배포 후에 구 컬럼을 삭제하는 2단계 접근이 안전합니다. 다시 이개발 씨의 이야기로 돌아가 봅시다. 롤링 업데이트의 원리를 이해한 이개발 씨는 감탄했습니다. "이제 언제든 자신 있게 배포할 수 있겠어요!" 롤링 업데이트를 제대로 이해하고 활용하면 하루에도 여러 번 안전하게 배포할 수 있습니다. 여러분도 오늘 배운 내용을 실전에 적용해 보세요. **실전 팁** 💡 - 헬스체크는 핵심 기능의 정상 동작을 확인하도록 구현하세요 - 컨테이너 시작 시간을 고려하여 헬스체크 유예 시간을 설정하세요 - 배포 중 구버전과 신버전이 공존하므로 데이터 스키마 변경 시 호환성을 유지하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: JavaScript

태그: AWS, ECS, Docker, Container, Deploy

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

ECS 서비스 배포 완벽 가이드

목차

1. ECS 서비스란?

2. 서비스 생성하기

3. Desired count 설정

4. 배포 구성

5. 서비스 업데이트

6. 롤링 업데이트

댓글 (0)

함께 보면 좋은 카드 뉴스

서비스 메시 완벽 가이드

쿠버네티스 아키텍처 완벽 가이드

EFK 스택 로깅 완벽 가이드

Grafana 대시보드 완벽 가이드

분산 추적 완벽 가이드