Incident Library

IL-0224 Amazon Web Services · 2012-12-24awsnetworking

유지보수 작업이 운영 ELB 상태 데이터 일부를 지워 US-East 리전의 Elastic Load Balancer 일부가 오류를 내고 나머지는 확장하거나 바꿀 수 없게 됐다.

ELB 상태 데이터는 ELB 제어 평면이 리전의 로드 밸런서 설정을 관리하는 데 쓰는 데이터이고, 로드 밸런서마다 트래픽을 보낼 백엔드 호스트 목록도 여기에 있다. 2012-12-24 PST 오후 12시 24분에 운영 환경 접근 권한을 가진 소수의 개발자 가운데 한 명이 유지보수 프로세스를 실수로 운영 ELB 상태 데이터를 대상으로 실행해 데이터 일부를 논리적으로 지웠다. AWS 는 운영 데이터를 모든 접근을 막는 정책으로 보호하지만, ELB 는 아직 자동화가 끝나지 않은 운영 절차를 돌리도록 소수 개발자에게 추가 접근을 허용했다. 이 접근은 접근마다 승인을 받는 방식이 아니라 상시 권한으로 잘못 설정돼 있었다.

삭제 직후 제어 평면의 API 지연과 오류율이 올랐다. 팀은 몇 시간 동안 일부만 실패하는 API 오류를 쫓았다. 그사이 제어 평면이 설정을 바꾼 로드 밸런서는 필요한 상태 데이터가 없어 잘못 설정됐고, 성능 저하와 오류를 냈다. 이 로드 밸런서들을 파고들어 사라진 상태 데이터가 원인임을 확인한 뒤, 팀은 오후 5시 2분에 확장과 축소를 포함한 제어 평면 워크플로 여러 개를 껐다. 정점에서 돌고 있는 로드 밸런서의 6.8% 가 영향을 받았고, 나머지는 정상으로 돌았지만 확장하거나 바꿀 수 없었다.

팀은 월요일 밤에 일부 로드 밸런서를 손으로 복구하고, 상태 데이터를 사고 직전 시점으로 되돌린 뒤 그 뒤의 변경을 합치는 방식으로 복구를 시도했다. 처음 쓴 복원 방법은 몇 시간이 걸리고도 쓸 수 있는 스냅샷을 만들지 못해 복구가 늦어졌다. 다른 방법으로 12월 25일 오전 2시 45분에 삭제 직전 시점의 스냅샷을 복원했고, 오전 5시 40분에 그 뒤의 변경을 합치고 검증을 마쳤다. 이어 워크플로와 API 를 천천히 다시 켜 오전 8시 15분에 대부분을 되살렸고, 오전 10시 30분에 영향받은 로드 밸런서가 거의 모두 정상으로 돌아왔다. 팀은 서비스를 더 지켜본 뒤 오후 12시 5분에 정상 운영을 알렸다.

심각도
–
영향 범위
Applications using Amazon ELB in the US-East Region: up to 6.8% of running load balancers degraded with errors, and the rest could not scale or be modified
영향 사용자
–
지역
US-East
감지까지
–
복구까지
22h 6m

증상

2012-12-24 PST 오후 12시 24분부터 US-East 리전의 ELB 제어 평면에서 로드 밸런서를 관리하는 API 호출의 지연과 오류율이 올랐다. 이때는 돌고 있는 로드 밸런서의 요청 처리에 영향이 없었다.

기술팀은 이후 몇 시간 동안 API 오류를 쫓았지만 많은 API 가 성공하고 일부만 실패해 원인을 짚지 못했다. 고객은 새 로드 밸런서를 만들고 관리할 수 있었지만 기존 로드 밸런서는 관리할 수 없었다.

시간이 지나자 일부 고객의 돌고 있는 로드 밸런서에서 성능 문제가 나타났다. 이 문제는 제어 평면이 설정을 바꾼 로드 밸런서에서만 일어났다. 사용자가 설정을 바꿨거나 로드 밸런서가 확장 또는 축소된 경우였다. 제어 평면에 필요한 상태 데이터가 없어 이 로드 밸런서들이 잘못 설정됐고, 이를 쓰는 고객 애플리케이션에 성능 저하와 오류가 났다. 팀은 성능이 떨어진 로드 밸런서를 깊이 파고든 뒤에야 ELB 상태 데이터가 사라진 것이 원인임을 찾았다.

정점에서는 돌고 있는 ELB 로드 밸런서의 6.8% 가 영향을 받았다. 나머지 로드 밸런서는 제대로 동작했지만 확장할 수도, 고객이 설정을 바꿀 수도 없었다.

증상 컨트롤 플레인 지연오류율 상승지연 시간 증가

원인

원인 운영 실수

구성 요소 클라우드 로드 밸런서
기여 요인 파괴적 변경 보호 장치 부재미검증 백업자동화 증폭
촉발
운영 환경에 접근할 수 있는 아주 적은 수의 개발자 가운데 한 명이 유지보수 프로세스를 실수로 운영 ELB 상태 데이터를 대상으로 실행해 데이터 일부를 논리적으로 지웠다. 그 개발자는 그때 실수를 알아채지 못했다.

감지

데이터가 지워진 뒤 ELB 제어 평면에서 로드 밸런서를 관리하는 API 호출의 지연과 오류율이 올랐고, 기술팀은 이 API 오류부터 살폈다. 사라진 상태 데이터는 팀이 성능이 떨어진 로드 밸런서를 깊이 파고든 뒤에야 찾았다. 데이터를 지운 개발자는 그때 실수를 알아채지 못했다.

조치

후속 조치

교훈

–

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 클라우드 로드 밸런서. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.