AWS EC2 AMI 교체 중 CodeDeploy 오토스케일링 충돌 장애 경험담

[embed]Migrating from an Amazon Linux 2 to an Amazon Linux 2023 Amazon ECS-optimized AMI Learn how to migrate your Amazon ECS workloads from Amazon Linux 2 to Amazon Linux 2023 Amazon ECS-optimized AMIs.docs.aws.amazon.co

Amazon Linux 이후 Amazon ECS는 2026년 6월 30일에 Amazon Linux 2 Amazon ECS 최적화 AMI에 대한 표준 지원을 종료합니다.

AWS 로부터 위 메시지를 전달 받았다. 보안을 위해 AMI 를 바꾸는 작업을 진행해야만 했다.

AWS 환경에서 EC2 인스턴스의 AMI 교체 작업을 진행하던 중, 팀원의 CodeDeploy 배포 작업이 겹치면서 오토스케일링 그룹과 타겟 그룹에 비정상적인 인스턴스가 생성되는 장애가 발생했다.

미리 AMI 를 만들어둔 상태였고 많은 서버를 혼자서 못하기 때문에 팀원들과 나눠서 진행했다.

1. 장애 발생 과정

1.1 초기 작업 진행

EC2 인스턴스 12대의 AMI를 교체하기 위해 시작 템플릿을 신규 버전으로 수정했다. 이후 오토스케일링그룹(ASG)의 인스턴스 수를 12대에서 13대로 늘려, 신규 EC2에 새로운 AMI가 정상 적용되고 트래픽이 문제없이 전달되는 것을 확인했다.

1.2 비정상적인 인스턴스 증가

기존 EC2를 하나씩 종료(Terminate)하며 교체되는 과정을 수동으로 확인하던 중, 갑자기 EC2 인스턴스가 24대로 급증하는 현상이 발생했다.

1.3 원인 파악

팀원이 CodeDeploy를 통해 배포 작업을 진행한 것이 원인이었다. 인프라 작업 중임을 팀원들에게 미리 알리지 않은 것이 문제의 발단이었다. 열심히 원인을 찾고 있었다. 다행히 서비스가 멈추는 장애는 아니었다. 그리고 알 수 없는 원인으로 오토스케일링 그룹이 하나 더 생성되었다.

2. 장애 상태 분석

2.1 타겟 그룹 불일치

총 24대의 EC2 인스턴스 중 19대만이 타겟 그룹에 포함되어 있었고, 나머지 5대는 연결되지 않은 유령 상태로 남아있었다. 시간이 지나면 AWS가 자동으로 상태를 동기화할 것으로 기대하고 대기했으나, 상태는 계속 유지되었다.

2.2 오토스케일링그룹과 CodeDeploy 연결 상태 확인

새롭게 생성된 오토스케일링 그룹은 CodeDeploy와 연결되어 있지 않았다. 신규 오토스케일링 그룹의 인스턴스 수를 12에서 8, 4로 점진적으로 줄이자 타겟 그룹의 인스턴스 수도 10대로 감소했다. 최소 12대 이상이 유지되어야 하는 상황에서 원본 오토스케일링 그룹의 12대 중 8대만 타겟 그룹에 포함된 비정상적인 상태임을 확인했다.

3. 해결 과정

3.1 리드와의 논의 및 조치

문제 해결을 위해 먼저 리드와 논의 했고 다음 절차대로 조치를 취했다.

1. 신규 오토스케일링 그룹의 인스턴스 수를 0으로 설정하여 제거한다.
2. 타겟 그룹에서 누락된 EC2 인스턴스들을 강제로 추가한다.
3. CodeDeploy를 통해 새롭게 배포를 진행한다.

3.2 정상화 확인

조치 완료 후 로그와 CloudWatch를 통해 CPU 사용량 및 트래픽 지표를 모니터링했으며, 모두 정상 범위에서 동작하는 것을 확인했다.

4. 깨달음

4.1 커뮤니케이션의 중요성

인프라 작업 시에는 반드시 팀원들에게 미리 일정을 공유하고, 실제 작업을 시작하는 시점에도 한 번 더 알려야 한다. 평소에는 잘 지켜지던 공유 프로세스를 한 번 누락했을 때 바로 문제가 발생했다.

4.2 인프라 지식의 필요성

AWS의 오토스케일링과 CodeDeploy가 맞물려 동작하는 원리에 대한 깊은 이해가 부족했다. 장애 상황에서 신속하고 정확하게 대응하기 위해 인프라에 대한 깊이 있는 학습이 필요하다.