AWS ECS 1-Click Rollback 기능 출시

Devops Engineer로서 장애시 늘상하게 되는 고민

AWS ECS와 Terraform을 주로 다루는 DevOps 엔지니어입니다.

1인 Devops Engineer 형태로 이루어진 회사들이 대부분 그렇습니다만 주말이던 업무중 외부에 나와있던 인프라 관련 장애를 모두 대응해야 합니다.

"서버가 이상해요! 살려주세요!"

라는 문제 발생하면 일단 휴대폰에서 Datadog 켜보고 AWS Console에 ECS Status도 확인해보고 할텐데요.

문제가 보이더라도 즉시 대응하기 쉽진 않습니다. (못해도 5 ~ 10분은 걸리는 듯)

 

그럴때마다 급하면 개발자들이 "저희한테 권한 좀 주세요! 일단 직접 해결해볼게요!" 이런 이야기할때는 좀 무섭습니다. 권한이 더 열리면 더 요구하게 되고 열다보면 나중에 사고가 나도 책임소재가 모호해지는 경우가 있습니다.

 

게다가 저는 Terraform을 입사하는 회사에선 어지간하면 사용하고 있기 때문에 개발자가 Resource를 변경하면 Terraform State가 깨져서 더욱 고민되고 있기도 합니다. Terraform은 저만 쓰고 있거든요.

---

 

1. 개발자에게 권한을 급하다고 막 줘도 될까?

- 주는 거야 가능은 합니다만, 나중에 회수시 어색한 상황이 발생합니다. 보안팀장 또는 별도의 보안 컴플라이언스가 없으면 회수가 어려워서 잠재적인 인프라 위협이 발생할 소지가 있습니다.

 

2. Terraform 상태 깨짐

- 의도치 않은 권한 확장으로 인해 실수로 콘솔에서 제어되었거나 급해서 인프라 담당자와 소통 없이 개발자 단독으로 작업한 경우 Terraform State가 깨져 plan을 돌릴때 깨진 상태가 보이면 정말 많은 생각을 하게 됩니다.... (하...)

 

3. 권한 없이 Rollback 또는 Rollforward를 하려면 Git merge만이 답이다.

- 누군가 코드를 건드려서 해결을 봐야하는 상황이라면, Devops Engineer가 하는 것보단 개발자가 하는 것이 훨씬 안전합니다. 하지만 클라우드에 올라간 이상 오류가 발생했을시 로그 Tracing을 제대로 할 수 없다면 당연히 Devops가 1차적으로 확인하게 되므로 불필요한 시간이 지체됩니다. 긴급시 Devops가 코드를 수정하게 되면 추후 Side Effect 확인을 못하고 긴급 작업하게 되므로 다른 문제가 생길 수 있다는 점은 여전히 큰 문제입니다.

 

4. 어차피 수동으로 하려고 해도 인프라 담당자 아니면 하기 쉽지 않음

1. 이전 태스크 정의가 뭔지 찾기
2. 서비스 업데이트로 이전 버전 지정하기
3. 배포 완료까지 기다리기 (5-15분 걸림)
4. 혹시 다른 기능에 문제 없는지 확인하기

---

클라우드 상의 실제 배포 프로세스

1. Github Push (개발자의 배포)

2. Github Action Trigger

(in Github Action)

3. Docker Build

4. ECR Push

5. Task Def Update

6. ECS Update : Task Def Ver Change (인프라의 배포)

---

AWS ECS 1-Click 롤백 기능 추가

2025년 5월 5일에 AWS에서 1-Click Rollback 기능이 추가되었다고 합니다!

https://aws.amazon.com/ko/about-aws/whats-new/2025/05/amazon-ecs-1-click-rollbacks-service-deployments/

Amazon ECS, 서비스 배포용 원클릭 롤백 도입 - AWS

 

ECS 배포가 잘못되었거나 문제가 생겼을 때 클릭 한 번으로 마지막에 정상이었던 상태로 되돌릴 수 있어요.

AWS Console, CLI, API 모두 사용 가능.

예전: 문제 발견 → 뭐가 문제인지 찾기 → 이전 버전 찾기 → 업데이트 → 기다리기 (10-15분)
지금: 문제 발견 → Stop Deployment 버튼 클릭 → 끝! (2-3분)

 

ECS Rolling Update를 사용하는 것이라면 모두 사용이 가능합니다.

ECS on EC2, ECS on Fargate 모두 지원하고 있습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecs:StopDeployment",
        "ecs:DescribeServices"
      ],
      "Resource": "arn:aws:ecs:*:*:service/*"
    }
  ]
}

 

이 권한만 있으면 사용할 수 있기 때문에 개발자들에게 최소 권한으로 서비스 배포를 중지시킬 수 있습니다.

 

근데 이런 경우는 사용을 못한다고 합니다.

- CodeDeploy로 Blue/Green 배포를 하는 경우

- 다른 배포 도구를 쓰는 경우 : Github Action, Bitbucket Pipeline 등 Custom Action으로 처리할 수 있을거 같긴 합니다.
- 처음 배포할 경우 : 롤백할 버전이 없음

---

Use Case

Case 1. 버그성 있는 코드가 긴급 배포되었을때

- 회사에서 테스트할 시간이 부족하지만 어쩔수 없이 배포 나가는 경우가 종종 있습니다. 하지만 사용자들은 로그인이 안된다고 합니다. 근데 Health Check는 또 된다고 하네요. Web Http로 curl로 쏴봐도 또 된답니다.

# service 확인
aws ecs describe-services --cluster my-cluster --services my-service

# task 문제 확인
aws ecs list-task-definitions --family-prefix my-app --status ACTIVE

# 버전 찾아서 rollback
aws ecs update-service --cluster my-cluster --service my-service --task-definition my-app:42

CLI로 했을땐 이랬을 거고 Console에선 버전 찾아서 ecs service에서 task version을 1칸 내리고 재 배포했을텐데요.

이젠 이런식으로 가능하다고 하네요.

aws ecs stop-deployment --cluster my-cluster --service my-service

 

Case 2. 메모리 부족 (OOM)

- 새로 배포한 버전에서 생각보다 메모리를 엄청나게 사용하고 있습니다. dev에도 stage에도 모두 문제가 없었지만 prod에서만 나온다고 해요. java라면 힙메모리를 너무 크게 잡았을 수도 있고, 의도치 않게 dev, stage 빌드에서 사용하지 않은 라이브러리가 hot fix로 운영에 심겨서 나갔을 수도 있습니다. 그럴땐 개발의 문제인지 인프라 문제인지 확인이 쉽지 않지요. 미리 논의가 되었어야 되겠지만, 무한 로딩은 ECR Pull을 위한 인터넷 비용등의 문제까지 추가적으로 발생할 수 있는 심각한 사항입니다. 이때 롤백을 하면 빠르게 조치할 수 있습니다. 하지만, 언제나 메모리를 더 쓰고 할 거 같으면 어지간하면 인프라 담당자와 상의하는 것이 좋겠죠?

 

Case 3. 초긴급 상황

- 코드 배포를 했지만 즉시 조치가 불가능한 경우가 있을수 있습니다. 만일 긴급한 상황이었다면 당연히 코드 담당자들이나 인프라 담당자들, 테스트 인원이 대기하고 있겠지만, 원격으로 배포되었거나 즉시 협업이 불가능하여 원인 파악이 어려운 경우엔 코드를 건드리지 않고 이 방법으로 문제 없던 버전으로 다시 돌아갈 수도 있겠습니다.

---

수정하는 방법

Console

1. 일단 한번 만들어봅니다.

임의의 서비스 생성

정상 이미지용 파일과 오류 이미지용 파일 생성

org가 원본이고 오류난걸로 다시 빌드 달립니다.

빌드 스크립트

오류 이미지 연결하는 Task Definition 업데이트

Definition도 새로 만들었습니다.

ECS Service에 Task Definition 업데이트

배포 진행중

임의로 제가 죽이도록 올린거지만, 실제라면 좀 무섭네요.

롤백 버튼을 누르면?

롤백 실패

기본 회로 차단기 임계값이 있다면 몇번 실패를 감지하고 자동으로 롤백 처리가 됩니다. 하지만 설정 되어 있지 않으면 무한 배포 시도를 합니다.

CLI

 

Command가 헷갈리시면

aws ecs stop-service-deployment help

이렇게 해보시면 됩니다.

 

참고문헌

https://aws.amazon.com/ko/about-aws/whats-new/2025/05/amazon-ecs-1-click-rollbacks-service-deployments/

Amazon ECS, 서비스 배포용 원클릭 롤백 도입 - AWS

docs

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-ecs.html

Deploy Amazon ECS services by replacing tasks - Amazon Elastic Container Service

---

사용해본 느낌

보통은 별일이 없으면 회로 차단기 모드를 가동하고 사용하는 것이 대부분입니다만,

안 켜고 쓰는 경우엔 정말 무한 실행이 되어 버릴 수 있어서 배포도 막히고 정말 난감한 경우가 발생할 수 있습니다.

이럴때는 유용하리라 생각합니다.