{"id":"IL-0282","org":"Amazon Web Services","date":"2015-09-20","docs":[],"title":{"en":"DynamoDB in US-East reached about 55% request errors as storage servers overloaded its metadata service","ko":"US-East 리전의 DynamoDB 스토리지 서버들이 멤버십 정보를 받지 못해 스스로 요청 처리에서 빠지면서 고객 요청의 약 55% 가 실패했다"},"domain":["database","aws"],"impact":{"scope":"The error rate of DynamoDB customer requests in US-East rose far beyond normal by 2:37am PDT and settled at about 55% until error rates came down at 7:10am PDT; Amazon SQS, EC2 Auto Scaling, CloudWatch and AWS Console login were also affected, and some customers saw high error rates and stuck tables into Monday","users":"DynamoDB customers in US-East and customers of AWS services that depend on DynamoDB","region":"US-East"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"A low overall error rate can hide disproportionately high error rates for a few customers, and AWS should have posted to the dashboard sooner. A call that does not need to succeed, like the DynamoDB-dependent API call in Console login, should fail quickly instead of blocking on a very long timeout. Splitting the metadata service into many instances, each serving part of the fleet, is meant to contain the impact of software, capacity or infrastructure failures.","ko":"AWS 는 멤버십 크기처럼 성능에 영향을 주는 값을 자세히 보지 않아 메타데이터 서비스에 필요한 용량을 미리 잡지 못했다. 전체 오류율이 낮아도 일부 고객에게는 오류가 몰릴 수 있다. AWS 는 이를 늦게 알아채 월요일에 상태 대시보드 게시가 늦었다. 콘솔 로그인은 성공하지 않아도 되는 API 호출에 아주 긴 타임아웃이 걸려 수십 초씩 막혔다. 이런 호출은 빨리 실패하고 로그인을 이어 가게 했어야 했다."},"related":[],"sources":[{"url":"https://aws.amazon.com/message/5467D2/","kind":"official-status","archived":"https://web.archive.org/web/20261030034754/https://aws.amazon.com/message/5467D2/"}],"summary":{"en":"DynamoDB splits each table into partitions and spreads them over many storage servers for low latency and durability. The group of partitions assigned to one storage server is its membership, which DynamoDB's internal metadata service manages; the metadata service is replicated and runs across several datacenters. Storage servers ask the metadata service for their membership periodically, after a network disruption and at startup, and if no answer comes within a set time they retry and temporarily stop accepting requests. In the months before the event, customers had rapidly adopted Global Secondary Indexes (GSIs), which let a table be read by alternate keys and have their own partitions on the storage servers. Several GSIs on a table with many partitions could quickly double or triple its share of the membership lists. Rapid adoption by customers with very large tables raised the size of some membership lists significantly, and the processing time of some membership requests came close to the storage servers' time limit. AWS did not monitor membership size closely enough and had not given the metadata service enough capacity for these heavier requests.\n\nAt 2:19am PDT a brief network disruption sent many storage servers to the metadata service at once. Simultaneous requests for large memberships slowed processing past the limit, the affected storage servers became unavailable and retried, and the slowed metadata service then failed renewals for healthy servers too. By 2:37am the customer error rate had risen far beyond any level of the previous 3 years, and it settled at about 55%. The load blocked the administrative requests needed to add capacity, so at 5:06am AWS paused requests to the metadata service. With the retries gone, the metadata service could take administrative requests, significant capacity was added, requests were turned back on and storage servers returned to the customer request path. At 7:10am PDT error rates were low enough for most customers and dependent AWS services to resume. Amazon SQS, which refreshes cached queue information from a DynamoDB table, had significantly elevated errors after DynamoDB finished disabling traffic at 5:45am, and recovered at 7:10am with no queue data lost. EC2 Auto Scaling, which keeps its groups and launch configurations in DynamoDB, had increased API faults from 2:15am to 7:10am and then worked through a backlog of launch and termination activities until 10:52am. CloudWatch, which adds Auto Scaling group membership from a DynamoDB table to incoming EC2 metrics, had intermittent EC2 metrics from 2:35am to 5:45am and elevated PutMetricData errors from about 5:51am to 7:10am, and fully recovered at 7:29am. AWS Console logins from 5:45am to 7:10am were much slower because an API call that relied on DynamoDB, and did not need to succeed for login, had a very long timeout; a shorter timeout was already in testing but not yet rolled out.\n\nAfter the main recovery a low error rate of 0.15%-0.25% remained. AWS did not see early enough that it fell disproportionately on a small number of customers, and posted to the dashboard later than it should have on Monday. The cause was a metadata partition that was still not taking its full share of traffic, and the team restored it on Monday.","ko":"DynamoDB 테이블은 파티션으로 나뉘어 여러 스토리지 서버에 흩어져 있다. 어떤 파티션들을 어느 서버가 맡는지 정한 배정을 멤버십이라 하고, 내부 메타데이터 서비스가 이를 관리한다. 스토리지 서버는 주기적으로, 그리고 네트워크 장애 뒤나 시작할 때 메타데이터 서비스에 자기 멤버십을 묻고, 정해진 시간 안에 받지 못하면 재시도하면서 잠시 요청 처리에서 빠진다. 지난 몇 달 동안 고객들은 Global Secondary Indexes, 줄여서 GSI 를 빠르게 도입했다. GSI 는 테이블 데이터를 다른 키로 찾게 해 주는 기능이고, GSI 마다 파티션을 따로 가진다. 그래서 큰 테이블을 가진 고객들이 GSI 를 만들자 일부 서버의 멤버십 목록이 크게 늘었고, 메타데이터 서비스의 처리 시간이 서버가 기다리는 한도에 가까워졌다. AWS 에는 멤버십 크기를 볼 만큼 자세한 모니터링이 없었고, 메타데이터 서비스에 이 무거운 요청을 감당할 용량도 마련해 두지 않았다.\n\n2015년 9월 20일 일요일 2:19am PDT 에 짧은 네트워크 장애가 스토리지 서버 일부에 영향을 줬다. 이 서버들이 한꺼번에 멤버십을 요청하자 큰 멤버십 요청의 처리가 더 느려져 한도를 넘었다. 서버들은 갱신에 실패해 요청 처리에서 빠진 채 재시도를 이어 갔다. 부하가 걸린 메타데이터 서비스는 장애와 관계없는 서버들의 정기 갱신에도 늦게 답했고, 이 서버들도 다수가 빠졌다. 2:37am PDT 에는 고객 요청 오류율이 지난 3년 동안 없던 수준을 훨씬 넘었고, 약 55% 에서 머물렀다. SQS, EC2 Auto Scaling, CloudWatch, AWS Console 로그인처럼 DynamoDB 내부 테이블에 기대는 서비스들도 오류와 지연을 겪었다.\n\n처음에는 메타데이터 서비스의 부하가 너무 높아 관리 요청이 통하지 않았고, 그래서 용량을 늘릴 수 없었다. 여러 번 실패한 뒤 5:06am PDT 에 메타데이터 서비스로 가는 요청을 멈춰 재시도를 줄였고, 관리 요청이 다시 통하자 용량을 크게 늘렸다. 그 뒤 요청을 다시 열고 스토리지 서버를 고객 요청 경로에 되돌렸다. 7:10am PDT 에는 대부분의 고객과 AWS 서비스가 정상 운영을 이어 갈 만큼 오류율이 내려갔다. Auto Scaling 은 쌓인 작업을 10:52am PDT 까지 처리했고 CloudWatch 는 7:29am PDT 에 완전히 회복했다. 남은 0.15%~0.25% 의 오류는 받아야 할 트래픽을 받지 못하던 메타데이터 파티션 하나 때문이었고, 팀은 월요일에 이 파티션을 전체 트래픽으로 되돌려 마무리했다."},"trigger":{"en":"At 2:19am PDT a brief network disruption affected a portion of DynamoDB's storage servers, and they all requested their membership data from the metadata service at the same time.","ko":"2:19am PDT 의 짧은 네트워크 장애가 DynamoDB 스토리지 서버 일부에 영향을 줬고, 이 서버들이 한꺼번에 메타데이터 서비스에 멤버십 정보를 요청했다."},"severity":"unknown","symptoms":["high-error-rate","database-overloaded"],"timeline":{"detected_after":null,"resolved_after":"4h 51m"},"date_kind":"incident","detection":{"en":"For the errors that remained after the main recovery, a growing number of customer support cases on Monday about tables stuck in the updating or deleting stage and higher than normal error rates showed that the low overall error rate was hitting some customers hard.","ko":"주 문제를 해결한 뒤 남은 낮은 오류율은 월요일에 고객들이 테이블이 updating 이나 deleting 단계에 멈췄다거나 오류율이 높다는 지원 케이스를 열면서 드러났다."},"components":["database"],"root_cause":"capacity","remediation":[{"text":{"en":"Paused requests to the metadata service, which cut the retries and relieved its load","ko":"용량 추가가 여러 번 실패한 뒤 5:06am PDT 에 메타데이터 서비스로 가는 요청을 멈췄다. 재시도가 줄어 메타데이터 서비스의 부하가 크게 덜어졌다."}},{"text":{"en":"Added significant capacity to the metadata service once it could answer administrative requests","ko":"메타데이터 서비스가 관리 요청에 다시 응답하자 용량을 크게 늘렸다."}},{"text":{"en":"Turned requests to the metadata service back on and returned storage servers to the customer request path","ko":"메타데이터 서비스로 가는 요청을 다시 열고 스토리지 서버를 고객 요청 경로에 되돌렸다. 7:10am PDT 에 대부분의 고객과 AWS 서비스가 정상 운영을 이어 갈 만큼 오류율이 내려갔다."}},{"text":{"en":"Restored a metadata partition that was still not taking its full traffic, ending the remaining errors on Monday","ko":"받아야 할 만큼 트래픽을 받지 못하던 메타데이터 파티션 하나를 전체 트래픽으로 되돌려 남은 오류를 월요일에 정리했다."}}],"action_items":[{"text":{"en":"Significantly increased the capacity of the metadata service, which AWS had already done by the time of the summary","ko":"메타데이터 서비스의 용량을 이미 크게 늘렸다."}},{"text":{"en":"Add stricter monitoring on performance dimensions such as membership size, to plan capacity ahead","ko":"멤버십 크기 같은 성능 지표를 더 엄격하게 모니터링해 상태를 파악하고 알맞은 용량을 미리 계획한다."}},{"text":{"en":"Reduce the rate at which storage nodes request membership data","ko":"스토리지 노드가 멤버십 정보를 요청하는 빈도를 줄인다."}},{"text":{"en":"Lengthen the time allowed to process membership queries","ko":"메타데이터 서비스가 요청을 처리하는 데 쓸 수 있는 시간을 늘린다."}},{"text":{"en":"Segment DynamoDB into many metadata service instances, each serving only part of the storage server fleet","ko":"DynamoDB 서비스를 나눠 메타데이터 서비스 인스턴스를 여럿 두고, 각 인스턴스가 스토리지 서버의 일부만 맡게 한다."}},{"text":{"en":"Change SQS metadata caching so send and receive keep working without long access to the metadata table","ko":"SQS 의 메타데이터 캐싱을 고쳐 메타데이터 테이블에 오래 접근하지 못해도 메시지 보내기와 받기가 계속되게 한다."}},{"text":{"en":"Partition work across the Auto Scaling servers to process a backlog of scaling jobs in parallel","ko":"Auto Scaling 서버들에 작업을 나누는 방식을 바꿔 쌓인 스케일링 작업을 더 병렬로 처리한다."}},{"text":{"en":"Prune older scaling activities that have been superseded","ko":"더 새로운 작업으로 대체된 오래된 스케일링 작업을 걸러 내는 장치를 넣는다."}},{"text":{"en":"Increase the capacity available to process scaling activities","ko":"스케일링 작업을 처리하는 용량을 늘린다."}},{"text":{"en":"Change CloudWatch caching of DynamoDB group membership data to refresh only the smallest set of metrics","ko":"CloudWatch 가 DynamoDB 의 그룹 멤버십 데이터를 캐싱하는 방식을 바꿔, 갱신이 필요한 지표를 가능한 한 적게 줄인다."}},{"text":{"en":"Deliver CloudWatch metrics faster through write-through caching","ko":"write-through 캐싱으로 지표를 더 빨리 전달하는 기능을 개발한다. 이 캐시는 지표를 저장하기 전에 바로 보여 준다."}},{"text":{"en":"Roll out the shorter timeout on the DynamoDB-dependent API call in Console login","ko":"타임아웃을 줄인 콘솔 로그인 코드를 며칠 안에 배포한다. 이 코드는 이미 테스트 과정에 들어가 있다."}}],"contributing":["no-capacity-planning","monitoring-blind-spot","retry-storm","circular-dependency","blast-radius-too-wide"],"recurrence_of":null,"symptoms_text":{"en":"Early on Sunday 20 September 2015, the error rate of customer requests to Amazon DynamoDB in the US-East Region rose far beyond any level of the previous 3 years by 2:37am PDT and settled at about 55%. Some other AWS services in the region that depend on DynamoDB were affected as well.\n\nInside DynamoDB, the storage servers that hold the partitions of customer tables could not get their membership, the list of partitions assigned to them, from DynamoDB's internal metadata service within the time they allow for it. A storage server that cannot renew its membership in time takes itself out of the request path and retries. After a brief network disruption at 2:19am PDT, many storage servers asked for their membership at the same moment, the answers for the largest membership lists ran past the time limit, and those servers stopped taking requests.\n\nThe overloaded metadata service then also answered too slowly for storage servers that the network disruption had not touched and that were checking in on their normal schedule, so many of them became unavailable as well. Unavailable servers kept retrying and held the load high, and servers that had renewed successfully failed their next renewal and dropped out again. Downstream, Amazon SQS returned significantly elevated errors, EC2 Auto Scaling returned API faults and then lagged in launching and terminating instances until 10:52am PDT, CloudWatch had delayed and missing EC2 metrics and elevated errors on PutMetricData calls, and logins to the AWS Console became much slower.\n\nEngineers first tried to add capacity to the metadata service, but the administrative requests needed for that failed under the same load, and several attempts did not work. After the main recovery, an error rate of 0.15%-0.25% remained. It looked too low to post on the service dashboard, but on Monday more customers opened support cases about tables stuck in the updating or deleting stage and higher than normal error rates, because that low overall rate fell heavily on a small number of customers.","ko":"2:19am PDT 에 짧은 네트워크 장애가 있은 뒤 DynamoDB 고객 요청의 오류율이 치솟았다. 2:37am PDT 에는 오류율이 지난 3년 동안 겪은 어떤 수준보다 훨씬 높아졌고, 약 55% 에서 머물렀다.\n\n스토리지 서버들이 정해진 시간 안에 메타데이터 서비스에서 멤버십 정보를 받지 못해 요청을 받지 않는 상태로 빠졌다. 멤버십은 어떤 파티션들을 어느 서버가 맡는지 정한 배정이다. 빠진 서버들은 멤버십 요청을 계속 재시도했고, 메타데이터 서비스는 높은 부하에서 벗어나지 못했다.\n\n부하가 걸린 메타데이터 서비스는 처음 네트워크 장애와 관계없던 스토리지 서버들의 정기 확인에도 느리게 응답했다. 이 서버들도 다수가 요청 처리에서 빠졌고, 멤버십 갱신에 한 번 성공한 정상 서버도 다음 갱신에 실패해 다시 사용 불가 상태로 돌아갔다.\n\nDynamoDB 에 기대는 다른 서비스도 오류를 냈다. Amazon SQS 는 처음에 오류와 지연이 조금 늘었다가 5:45am PDT 에 DynamoDB 가 트래픽을 막은 뒤 큐 정보 캐시를 갱신하지 못해 오류율이 크게 올랐다. EC2 Auto Scaling 은 2:15am 부터 7:10am PDT 까지 API 오류가 크게 늘었고, 그 뒤 10:52am PDT 까지 새 인스턴스를 넣거나 비정상 인스턴스를 종료하는 일이 크게 늦어졌다.\n\nCloudWatch 는 2:35am PDT 부터 EC2 지표가 늦거나 빠졌고, 5:51am 무렵부터 7:10am PDT 까지 PutMetricData 호출의 오류율이 크게 올라 모든 AWS 서비스 지표와 사용자 지정 지표에 영향을 줬다. AWS Console 은 5:45am 부터 7:10am PDT 까지 로그인이 수십 초씩 걸렸다.\n\n주 문제를 해결한 뒤에도 오류율이 0.15%~0.25% 사이에 남았다. 월요일에 테이블이 updating 이나 deleting 단계에 멈췄다거나 오류율이 평소보다 높다는 고객 지원 케이스가 늘었다. 전체 오류율은 낮았지만 일부 고객은 유독 높은 오류율을 겪고 있었다."},"updated_at":"2026-11-14T12:33:53.681461Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0282","org_slug":"amazon-web-services"}