{"id":"IL-0337","org":"Amazon Web Services","date":"2011-04-21","docs":[],"title":{"en":"EBS volumes in one US East Availability Zone got stuck after a network change cut EBS nodes off from their replicas","ko":"US East 리전 한 가용 영역에서 네트워크 변경으로 EBS 노드가 복제본과 끊겨 EBS 볼륨이 멈췄다"},"domain":["aws","networking"],"impact":{"scope":"EBS volumes in one Availability Zone (about 13% stuck, 0.07% not restorable in a consistent state) and the EC2 instances using them; EBS APIs and launches of EBS-backed EC2 instances across the Region; RDS single-AZ instances in the zone (peak 45% stuck) and 2.5% of multi-AZ instances in the Region that did not fail over","users":"unknown","region":"US East Region, one Availability Zone"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"AWS writes that with more spare capacity the cluster would have absorbed the re-mirroring requests without a storm, and that it now understands how much capacity large recovery events need. The event also showed that the EBS control plane let a failure in one Availability Zone affect the others, so more work is needed to make zones behave as if completely independent. AWS adds that some customers had critical components in a single zone, and that multi-AZ deployments need to become easier to design and run.","ko":"AWS 는 이 사고를 촉발한 것은 네트워크 설정 변경이었지만, 앞으로의 일은 비슷한 실패가 나도 EBS 가 견디게 만드는 데 둔다고 했다. 여유 용량이 더 있었다면 망가진 클러스터가 재미러링 요청을 빨리 흡수해 폭주를 피했을 것이라고 봤다. 가용 영역들을 완전히 독립된 것처럼 만들려면 더 투자해야 한다는 것을 이 사고로 배웠다고 했다. 장애 중에 고객이 영향받은 자원을 다른 정상 가용 영역에서 바꾸기 어려웠던 일이 다시 일어나지 않게 하는 것을 최우선으로 꼽았다. 여러 가용 영역에 걸친 배포를 쉽게 설계하고 운영하도록 고객을 돕는 일도 더 잘해야 한다고 했다. 여러 종류의 볼륨 복구에 쓴 방식을 자동화해 두었다면 복구 시간을 크게 줄였을 것이라고 했다. 장애 중 고객 소통은 더 자주, 더 많은 정보를 담아야 한다고 봤다."},"related":[],"sources":[{"url":"https://aws.amazon.com/message/65648/","kind":"official-status","archived":null}],"summary":{"en":"An EBS cluster runs inside one Availability Zone and is made of EBS nodes that keep replicas of volume data. Each node uses an aggressive peer-to-peer failover: when it loses contact with a node it replicates to, it assumes that node failed and searches the cluster for space to create a new replica (re-mirroring), and access to the volume is blocked until a new primary replica is chosen. The nodes are linked by a high-bandwidth primary network and a lower-capacity replication network. A regional EBS control plane accepts API requests and acts as the authority when nodes elect primary replicas. At 12:47 AM PDT on 21 April 2011, an incorrect traffic shift during a capacity upgrade moved primary network traffic onto the replication network, so a part of one cluster had neither network working and many nodes were isolated. When the shift was rolled back, a large number of nodes began re-mirroring at the same moment, used up the cluster's free capacity and kept searching for space in a loop. This \"re-mirroring storm\" left about 13% of the zone's volumes stuck. Nodes did not back off aggressively enough when they found no space, and a rarely hit race condition made nodes crash when they closed many replication requests at once, which created more volumes needing re-mirroring.\n\nThe degraded cluster also hurt the whole Region. Long time-outs on create volume calls filled the EBS control plane's regional thread pool, so it failed API requests for other zones until a change at 2:40 AM PDT disabled new Create Volume requests in the affected zone, after which other EBS APIs recovered by 2:50 AM PDT. By 5:30 AM PDT, the growing number of negotiations with the control plane browned it out again, and from 8:20 AM PDT the team cut all communication between the degraded cluster and the control plane, which brought the other zones back to normal but left no EBS API access in the affected zone. At 11:30 AM PDT the team stopped servers in the degraded cluster from futilely contacting other servers for space without breaking other node-to-node traffic; the cluster stopped degrading, with 13% of volumes stuck. A control plane change at the same time ended the elevated errors on new EBS-backed instance launches in other zones by noon. By 12:04 PM PDT the outage was contained to the one zone.\n\nRecovery then meant adding storage capacity so stuck volumes could find room. EBS does not reuse a failed node until all its replicas are re-mirrored, so the team had to move spare servers physically from across the US East Region into the cluster, and the changes that had cut node-to-node communication to stabilise the cluster made it hard to bring the new servers in. From about 02:00 AM PDT on 22 April new capacity worked through the backlog, and by 12:30 PM PDT all but about 2.2% of the zone's volumes were restored. To reopen control plane access without overwhelming it, the team built a separate EBS control plane partitioned to the affected zone and finer-grained throttles; the backlog was processed from 11:30 AM PDT on 23 April, and API access in the zone was restored at 6:15 PM PDT. The remaining 2.2% were restored from S3 snapshots taken early in the event, leaving 1.04% by 12:30 PM PDT on 24 April, and the team then ran forensics on the volumes on failed machines that had no snapshot and began restoring them at 3:00 PM PDT; 0.07% could not be restored in a consistent state. For RDS, 2.5% of multi-AZ instances in the Region did not fail over because the fast sequence of the network partition and stuck I/O on the primary hit a previously unseen bug that left the primary isolated, so automatic failover was not safe without risking data loss.","ko":"EBS 클러스터는 가용 영역 하나 안에서 돌고, 클러스터의 EBS 노드들이 볼륨 데이터의 복제본을 나눠 저장한다. 노드들은 대역폭이 큰 주 네트워크와 용량이 작은 보조 복제 네트워크로 서로 이어진다. 노드는 복제 상대와 연결이 끊기면 상대가 죽었다고 보고 빈 공간이 있는 새 노드를 찾아 데이터를 다시 복제하는데, AWS 는 이를 재미러링이라고 부른다. 2011년 4월 21일 오전 12시 47분 PDT, 주 네트워크 용량 증설 중 트래픽 전환을 잘못 해 트래픽이 보조 네트워크로 몰렸다. 클러스터 일부의 노드는 두 네트워크를 다 잃고 서로 완전히 고립됐다. 잘못된 전환을 되돌려 연결이 돌아오자 많은 노드가 한꺼번에 재미러링할 공간을 찾았다. 클러스터의 여유 용량은 금세 바닥났고, 노드들은 빈 공간을 계속 찾는 루프에 갇혔다. 공간을 찾지 못한 노드는 충분히 백오프하지 않고 계속 다시 찾았다. EBS 노드에는 많은 복제 요청을 한꺼번에 닫을 때 노드를 죽이는 경쟁 조건 버그가 있었다. 평소에는 아주 드물게 나타나던 이 버그가 이때는 자주 터져 stuck 볼륨이 더 늘었다.\n\n망가진 클러스터는 리전마다 한 벌씩 있는 EBS 컨트롤 플레인까지 끌어내렸다. create volume API 의 긴 타임아웃 때문에 쌓인 호출이 스레드를 다 써서 다른 가용 영역의 API 도 실패했다. 오전 2시 40분에 영향받은 가용 영역의 새 Create Volume 요청을 막자 2시 50분에 API 가 회복했다. 5시 30분쯤에는 복제본 협상 호출이 불어나 리전 전체의 API 가 다시 나빠졌고, 팀은 8시 20분부터 망가진 클러스터와 컨트롤 플레인 사이의 통신을 끊었다. 11시 30분에 노드들이 빈 공간도 없는 다른 서버에 헛되이 연락하지 못하게 바꾸자 클러스터는 더 나빠지지 않았다. 낮 12시 04분에는 장애가 그 가용 영역 안에 갇혔다.\n\n남은 약 13% 의 stuck 볼륨을 살리려면 저장 용량이 더 있어야 했다. 실패한 노드는 데이터를 다 살릴 때까지 다시 쓰지 않았으므로, US East 리전 곳곳의 여유 서버를 물리적으로 옮겨 설치해야 했다. 노드 사이 통신을 줄여 둔 탓에 새 용량을 클러스터에 붙이는 데도 시간이 걸렸다. 4월 22일 오전 2시쯤 새 용량이 들어가기 시작해 낮 12시 30분까지 약 2.2% 를 뺀 볼륨이 복구됐다. 4월 23일에는 그 가용 영역 전용으로 떼어 둔 EBS 컨트롤 플레인과 더 세밀한 스로틀로 밀린 상태 변경을 처리했다. 오후 6시 15분에 그 가용 영역의 EBS API 접근이 돌아왔다. 남은 2.2% 는 장애 초반에 떠 둔 S3 스냅샷으로 복구해, 4월 24일 낮 12시 30분에는 1.04% 만 남았다. 끝내 0.07% 는 일관된 상태로 복구하지 못했다. RDS 에서는 그 가용 영역 single-AZ 인스턴스의 0.4% 가 EBS 볼륨을 되살리지 못했고, multi-AZ 인스턴스 2.5% 는 그전까지 만난 적 없는 버그 때문에 자동 장애 전환을 하지 못해 사람이 개입해야 했다."},"trigger":{"en":"During a routine network change to upgrade the capacity of the primary EBS network in one Availability Zone, traffic was to be shifted off one of the redundant routers. The shift was executed incorrectly and sent the traffic onto the lower-capacity replication network instead of the other primary router, which could not carry it.","ko":"US East 리전의 한 가용 영역에서 주 EBS 네트워크의 용량을 올리는 작업 중, 이중화된 라우터 하나에서 트래픽을 빼는 단계를 잘못 실행했다. 트래픽은 주 네트워크의 다른 라우터가 아니라 용량이 작은 보조 EBS 네트워크로 갔다."},"severity":"unknown","symptoms":["storage-disconnected","network-unreachable","control-plane-slow","high-error-rate","failover-failed","data-loss"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":null,"components":["block-storage","database"],"root_cause":"human-operation","remediation":[{"text":{"en":"Rolled back the incorrect traffic shift, which restored network connectivity","ko":"잘못된 트래픽 전환을 되돌려 네트워크 연결을 살렸다. 연결이 돌아오자 노드들이 한꺼번에 재미러링할 공간을 찾기 시작했다."}},{"text":{"en":"Disabled all new Create Volume requests in the affected Availability Zone at 2:40 AM PDT","ko":"4월 21일 오전 2시 40분 PDT, 영향받은 가용 영역의 새 Create Volume 요청을 모두 막는 변경을 배포했다. 2시 50분에 다른 EBS API 의 지연과 오류율이 회복했다."}},{"text":{"en":"Disabled all communication between the degraded EBS cluster and the EBS control plane from 8:20 AM PDT","ko":"오전 8시 20분부터 망가진 EBS 클러스터와 EBS 컨트롤 플레인 사이의 통신을 모두 끊었다. 그 가용 영역의 EBS API 는 전부 막혔지만 리전의 나머지 EBS API 는 정상으로 돌아왔다."}},{"text":{"en":"Stopped EBS servers in the degraded cluster from futilely contacting other servers for free space","ko":"오전 11시 30분, 클러스터 노드 사이에 꼭 필요한 통신은 그대로 두고, 망가진 클러스터의 EBS 서버가 빈 공간도 없는 다른 서버에 헛되이 연락하지 못하게 막았다. 이 변경 뒤 클러스터는 더 나빠지지 않았다."}},{"text":{"en":"Changed the EBS control plane so new EBS-backed instance launches stopped failing","ko":"오전 11시 30분, EBS 컨트롤 플레인을 바꿔 다른 가용 영역에서 EBS 기반 EC2 인스턴스를 새로 띄울 때의 오류와 지연을 없앴다. 정오에 거의 정상으로 돌아왔다."}},{"text":{"en":"Moved spare server capacity physically from across the US East Region into the degraded cluster","ko":"실패한 노드는 다시 쓰지 않고, US East 리전 곳곳의 여유 서버를 물리적으로 옮겨 망가진 EBS 클러스터에 설치했다."}},{"text":{"en":"Adjusted the negotiation throttles so the new servers could join without flooding the old ones","ko":"새로 들인 서버와는 협상이 일어나되 기존 서버에 처리하지 못할 요청이 다시 몰리지 않도록 협상 스로틀을 조심스럽게 바꿨다."}},{"text":{"en":"Built a separate EBS control plane partitioned to the affected zone and finer-grained throttles, then processed the backlog","ko":"리전의 다른 가용 영역에 영향이 가지 않도록 영향받은 가용 영역에만 쓰는 EBS 컨트롤 플레인을 따로 세우고 더 세밀한 스로틀을 만든 뒤, 밀린 상태 변경을 처리했다."}},{"text":{"en":"Restored the remaining volumes from S3 snapshots taken early in the event","ko":"장애 초반에 데이터 손실에 대비해 남은 2.2% 의 볼륨을 S3 백업에 스냅샷으로 떠 두었다. 그 스냅샷에서 볼륨을 복구하는 코드를 만들고 시험한 뒤 밤새 묶음으로 처리했다."}},{"text":{"en":"Restored volumes on failed machines that had no snapshot after forensic work","ko":"기계 고장을 겪어 스냅샷도 뜨지 못한 나머지 볼륨을 포렌식으로 조사했고, 4월 24일 오후 3시부터 복구했다."}},{"text":{"en":"Intervened by hand on the RDS multi-AZ instances that did not fail over automatically","ko":"자동 장애 전환을 하지 못하고 고립된 RDS multi-AZ 인스턴스의 primary 복제본은 데이터 손실 위험 때문에 사람이 직접 개입해 처리했다."}}],"action_items":[{"text":{"en":"Audit the change process and add automation to prevent the traffic shift mistake","ko":"변경 절차를 감사하고 자동화를 늘려 이번 같은 실수가 다시 나지 않게 한다."}},{"text":{"en":"Change capacity planning and alarming to keep the extra safety capacity needed for large recovery events","ko":"큰 장애 복구에 필요한 안전 여유 용량을 늘 갖도록 용량 계획과 알람을 바꾼다. 용량 여유분은 이미 크게 늘렸고, 필요한 새 용량은 몇 주 안에 갖춘다."}},{"text":{"en":"Change the retry logic in EBS nodes to back off harder and reconnect to previous replicas instead of searching for new nodes","ko":"EBS 서버 노드의 재시도 로직을 바꿔, 큰 중단이 나면 더 적극적으로 백오프하고 새 노드를 헛되이 찾기보다 이전 복제본과 연결을 되살리는 데 집중하게 한다."}},{"text":{"en":"Test and deploy the fix for the race condition that crashed EBS nodes","ko":"EBS 노드를 죽인 경쟁 조건의 원인을 찾았고, 고친 코드를 시험해 몇 주 안에 클러스터에 배포한다."}},{"text":{"en":"Fix the RDS bug that kept multi-AZ instances from failing over automatically","ko":"RDS multi-AZ 인스턴스가 자동 장애 전환을 하지 못하게 만든 버그를 고치고 있다."}},{"text":{"en":"Improve the EBS control plane timeout logic to prevent thread exhaustion when one zone's cluster is slow","ko":"한 가용 영역의 클러스터가 요청을 너무 오래 처리할 때 스레드가 고갈되지 않도록 타임아웃 로직을 바로 고친다."}},{"text":{"en":"Make the EBS control plane aware of Availability Zones so it sheds load when over capacity","ko":"EBS 컨트롤 플레인이 가용 영역을 더 잘 구분하고, 용량을 넘었을 때 부하를 골라서 덜어 내게 한다."}},{"text":{"en":"Move more EBS control plane functions into per-cluster services that run in the same zone as the cluster","ko":"EBS 컨트롤 플레인의 기능을 더 많이 떼어 내, 지원하는 EBS 클러스터와 같은 가용 영역에서 도는 클러스터별 서비스로 옮긴다."}},{"text":{"en":"Offer multiple Availability Zones to Amazon VPC customers","ko":"로드맵을 조정해 지금은 가용 영역 하나만 쓸 수 있는 VPC 고객이 되도록 빨리 여러 가용 영역을 쓰게 한다."}},{"text":{"en":"Provide better tools for building multi-AZ applications that survive the loss of a zone","ko":"가용 영역 하나를 통째로 잃어도 애플리케이션 가용성이 유지되는 multi-AZ 애플리케이션을 만들 수 있도록 더 나은 도구를 고객에게 준다."}},{"text":{"en":"Host free webinars and publish whitepapers on fault-tolerant architecture","ko":"클라우드 설계 모범 사례를 다루는 무료 웨비나를 5월 2일 월요일부터 열고, 모범 사례 백서와 함께 AWS 웹사이트의 새 Architecture Center 에 둔다."}},{"text":{"en":"Build the fine-grained control and throttling used in recovery into the EBS nodes and automate the recovery models","ko":"팀이 클러스터를 복구할 때 쓴 세밀한 제어와 스로틀을 EBS 노드 안에 바로 넣고, 여러 종류의 볼륨 복구에 쓴 방식을 자동화한다."}},{"text":{"en":"Look at changes that keep volumes working while a cluster is degraded, including the ability to take a snapshot of a stuck volume","ko":"클러스터가 나빠진 동안에도 볼륨 기능을 지키는 방법을 찾고, stuck 볼륨의 스냅샷을 뜨는 기능을 넣는 것을 검토한다."}},{"text":{"en":"Send more frequent and detailed customer updates and staff developer support more widely during events","ko":"장애 도중부터 늘린 업데이트 빈도를 앞으로도 같은 수준으로 이어 간다. 또 이런 장애 때 개발자 지원 팀 인력을 더 넓게 배치하고, 짐작은 피하면서 이르고 쓸모 있는 정보를 내도록 조직하는 방법을 준비하고 있다."}},{"text":{"en":"Develop tools that show through the APIs whether instances are impaired","ko":"고객이 API 로 자기 인스턴스가 손상됐는지 볼 수 있는 도구를 만들고 있다."}}],"contributing":["automation-amplified","retry-storm","no-spare-capacity","blast-radius-too-wide","alert-noise"],"recurrence_of":null,"symptoms_text":{"en":"From 12:47 AM PDT on 21 April 2011, a subset of Amazon EBS volumes in one Availability Zone of the US East Region could no longer serve reads or writes, and EC2 instances that tried to use them got stuck as well. AWS called these \"stuck\" volumes. EBS API calls across the whole US East Region also returned high error rates and latencies during two periods on the first day.\n\nThe EBS nodes in the affected cluster had lost both of the networks they use to talk to each other: the high-bandwidth primary network and the lower-capacity replication network, which is meant only as a backup. Many nodes were completely isolated from the rest of the cluster and lost contact with the nodes holding their replicas. When connectivity came back, the nodes all looked for free space to create new replicas at once, and about 13% of the volumes in the Availability Zone ended up stuck. Because data on a volume is blocked while a new primary replica is chosen, an instance doing I/O on such a volume simply hung.\n\nThe trouble spread beyond the one zone through the regional EBS control plane. The cluster could not answer \"create volume\" requests, and because that API had a long time-out, slow calls piled up until the control plane's regional thread pool was full and it failed requests for other Availability Zones too. From 5:30 AM PDT the volume of negotiations with the control plane about which replica is primary, increased by retries and by nodes crashing on a race condition, browned out the control plane again. Launches of new EBS-backed EC2 instances in other zones had elevated error rates for about 11 hours, until noon PDT; AWS's alarming was not fine-grained enough for the one control plane API involved, so those launch errors were hidden behind the general errors from the degraded cluster. Some customers also reported stuck volumes in other zones; AWS measured a peak of less than 0.07% there, caused by slower normal re-mirroring while the control plane was degraded.\n\nAmazon RDS depends on EBS, so RDS databases in the zone were affected too. At the peak 45% of single-AZ database instances in the affected zone had stuck I/O, a larger share than for EBS volumes because each database uses several volumes. Of multi-AZ database instances in the US East Region, 2.5% did not fail over automatically and needed manual intervention. In the end 0.07% of the volumes in the affected zone could not be restored in a consistent state, and 0.4% of single-AZ database instances there had a volume that could not be recovered.","ko":"2011년 4월 21일 오전 12시 47분 PDT, US East 리전의 한 가용 영역에서 EBS 볼륨 일부가 읽기와 쓰기를 처리하지 못하게 됐고, 그 볼륨을 쓰던 EC2 인스턴스도 읽거나 쓰려다 함께 멈췄다. 리전 전체에서 EBS API 의 오류율과 지연도 높아졌다.\n\nAWS 는 이 상태의 볼륨을 \"stuck\" 볼륨이라고 불렀다. 재미러링은 노드가 복제 상대를 잃은 뒤 새 노드를 찾아 데이터를 다시 복제하는 일이다. 재미러링 중인 볼륨은 새 primary 복제본이 정해질 때까지 접근이 막히기 때문에, 그 볼륨에 I/O 를 하던 EC2 인스턴스에서는 볼륨이 멈춘 것으로 보였다. 영향받은 가용 영역 볼륨의 약 13% 가 이 상태가 됐다.\n\n클러스터의 여유 용량이 바닥나자 클러스터는 \"create volume\" API 요청을 처리하지 못했다. 이 API 의 타임아웃이 길어 느린 호출이 쌓였고, EBS 컨트롤 플레인이 리전 전체에서 함께 쓰는 스레드 풀이 바닥나 다른 가용 영역의 API 요청까지 실패했다. 첫 번째 API 장애는 오전 12시 50분부터 2시 40분까지 이어졌다.\n\n오전 5시 30분쯤 리전 전체에서 EBS API 의 오류율과 지연이 다시 올랐다. EBS 노드가 계속 죽으면서, 어떤 복제본을 primary 로 삼을지 EBS 컨트롤 플레인과 협상하는 호출이 재시도와 새 요청으로 불어났다. 그 부하에 눌린 컨트롤 플레인은 제대로 응답하지 못했다.\n\n영향받지 않은 가용 영역에서도 EBS 기반 EC2 인스턴스를 새로 띄우면 장애 시작부터 정오 PDT 까지 약 11시간 동안 오류율과 지연이 크게 높았다. 새 인스턴스를 볼륨에 붙일 때만 쓰는 EBS 컨트롤 플레인 API 하나가 원인이었다. 처음에는 알람이 이 API 를 따로 구분할 만큼 세밀하지 않아, 인스턴스 실행 오류가 망가진 클러스터에서 나온 일반 오류에 가려졌다.\n\nRDS 는 데이터베이스와 로그를 EBS 에 저장하기 때문에 영향받은 가용 영역의 RDS 데이터베이스 일부에 접속할 수 없었다. 그 가용 영역의 single-AZ 인스턴스 가운데 45% 가 한때 I/O 가 멈춘 상태였고, 리전의 multi-AZ 인스턴스 중 2.5% 는 I/O 가 멈춘 뒤에도 보조 복제본으로 자동 장애 전환을 하지 않았다.\n\n목요일에 일부 고객은 영향받은 가용 영역이 아닌 곳에서도 stuck 볼륨이 생겼다고 알렸다. 다른 가용 영역의 stuck 볼륨 비율은 가장 높을 때도 0.07% 미만이었다. 이 볼륨들은 EBS 컨트롤 플레인의 지연과 오류 때문에 평소 늘 일어나는 재미러링의 복구가 늦어져 생겼다. 컨트롤 플레인이 나빠진 동안 고객은 다른 정상 가용 영역에서 볼륨이나 EBS 로 부팅하는 EC2 인스턴스를 새로 만들어 바꾸기 어려웠다."},"updated_at":"2026-11-14T12:33:59.244550Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0337","org_slug":"amazon-web-services"}