Incident Library

IL-0282 Amazon Web Services · 2015-09-20databaseaws

US-East 리전의 DynamoDB 스토리지 서버들이 멤버십 정보를 받지 못해 스스로 요청 처리에서 빠지면서 고객 요청의 약 55% 가 실패했다

DynamoDB 테이블은 파티션으로 나뉘어 여러 스토리지 서버에 흩어져 있다. 어떤 파티션들을 어느 서버가 맡는지 정한 배정을 멤버십이라 하고, 내부 메타데이터 서비스가 이를 관리한다. 스토리지 서버는 주기적으로, 그리고 네트워크 장애 뒤나 시작할 때 메타데이터 서비스에 자기 멤버십을 묻고, 정해진 시간 안에 받지 못하면 재시도하면서 잠시 요청 처리에서 빠진다. 지난 몇 달 동안 고객들은 Global Secondary Indexes, 줄여서 GSI 를 빠르게 도입했다. GSI 는 테이블 데이터를 다른 키로 찾게 해 주는 기능이고, GSI 마다 파티션을 따로 가진다. 그래서 큰 테이블을 가진 고객들이 GSI 를 만들자 일부 서버의 멤버십 목록이 크게 늘었고, 메타데이터 서비스의 처리 시간이 서버가 기다리는 한도에 가까워졌다. AWS 에는 멤버십 크기를 볼 만큼 자세한 모니터링이 없었고, 메타데이터 서비스에 이 무거운 요청을 감당할 용량도 마련해 두지 않았다.

2015년 9월 20일 일요일 2:19am PDT 에 짧은 네트워크 장애가 스토리지 서버 일부에 영향을 줬다. 이 서버들이 한꺼번에 멤버십을 요청하자 큰 멤버십 요청의 처리가 더 느려져 한도를 넘었다. 서버들은 갱신에 실패해 요청 처리에서 빠진 채 재시도를 이어 갔다. 부하가 걸린 메타데이터 서비스는 장애와 관계없는 서버들의 정기 갱신에도 늦게 답했고, 이 서버들도 다수가 빠졌다. 2:37am PDT 에는 고객 요청 오류율이 지난 3년 동안 없던 수준을 훨씬 넘었고, 약 55% 에서 머물렀다. SQS, EC2 Auto Scaling, CloudWatch, AWS Console 로그인처럼 DynamoDB 내부 테이블에 기대는 서비스들도 오류와 지연을 겪었다.

처음에는 메타데이터 서비스의 부하가 너무 높아 관리 요청이 통하지 않았고, 그래서 용량을 늘릴 수 없었다. 여러 번 실패한 뒤 5:06am PDT 에 메타데이터 서비스로 가는 요청을 멈춰 재시도를 줄였고, 관리 요청이 다시 통하자 용량을 크게 늘렸다. 그 뒤 요청을 다시 열고 스토리지 서버를 고객 요청 경로에 되돌렸다. 7:10am PDT 에는 대부분의 고객과 AWS 서비스가 정상 운영을 이어 갈 만큼 오류율이 내려갔다. Auto Scaling 은 쌓인 작업을 10:52am PDT 까지 처리했고 CloudWatch 는 7:29am PDT 에 완전히 회복했다. 남은 0.15%~0.25% 의 오류는 받아야 할 트래픽을 받지 못하던 메타데이터 파티션 하나 때문이었고, 팀은 월요일에 이 파티션을 전체 트래픽으로 되돌려 마무리했다.

심각도
–
영향 범위
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
영향 사용자
DynamoDB customers in US-East and customers of AWS services that depend on DynamoDB
지역
US-East
감지까지
–
복구까지
4h 51m

증상

2:19am PDT 에 짧은 네트워크 장애가 있은 뒤 DynamoDB 고객 요청의 오류율이 치솟았다. 2:37am PDT 에는 오류율이 지난 3년 동안 겪은 어떤 수준보다 훨씬 높아졌고, 약 55% 에서 머물렀다.

스토리지 서버들이 정해진 시간 안에 메타데이터 서비스에서 멤버십 정보를 받지 못해 요청을 받지 않는 상태로 빠졌다. 멤버십은 어떤 파티션들을 어느 서버가 맡는지 정한 배정이다. 빠진 서버들은 멤버십 요청을 계속 재시도했고, 메타데이터 서비스는 높은 부하에서 벗어나지 못했다.

부하가 걸린 메타데이터 서비스는 처음 네트워크 장애와 관계없던 스토리지 서버들의 정기 확인에도 느리게 응답했다. 이 서버들도 다수가 요청 처리에서 빠졌고, 멤버십 갱신에 한 번 성공한 정상 서버도 다음 갱신에 실패해 다시 사용 불가 상태로 돌아갔다.

DynamoDB 에 기대는 다른 서비스도 오류를 냈다. Amazon SQS 는 처음에 오류와 지연이 조금 늘었다가 5:45am PDT 에 DynamoDB 가 트래픽을 막은 뒤 큐 정보 캐시를 갱신하지 못해 오류율이 크게 올랐다. EC2 Auto Scaling 은 2:15am 부터 7:10am PDT 까지 API 오류가 크게 늘었고, 그 뒤 10:52am PDT 까지 새 인스턴스를 넣거나 비정상 인스턴스를 종료하는 일이 크게 늦어졌다.

CloudWatch 는 2:35am PDT 부터 EC2 지표가 늦거나 빠졌고, 5:51am 무렵부터 7:10am PDT 까지 PutMetricData 호출의 오류율이 크게 올라 모든 AWS 서비스 지표와 사용자 지정 지표에 영향을 줬다. AWS Console 은 5:45am 부터 7:10am PDT 까지 로그인이 수십 초씩 걸렸다.

주 문제를 해결한 뒤에도 오류율이 0.15%~0.25% 사이에 남았다. 월요일에 테이블이 updating 이나 deleting 단계에 멈췄다거나 오류율이 평소보다 높다는 고객 지원 케이스가 늘었다. 전체 오류율은 낮았지만 일부 고객은 유독 높은 오류율을 겪고 있었다.

증상 오류율 상승데이터베이스 과부하

원인

원인 용량 한계

구성 요소 데이터베이스
기여 요인 용량 계획 부재모니터링 사각지대재시도 폭주순환 의존과도한 영향 범위
촉발
2:19am PDT 의 짧은 네트워크 장애가 DynamoDB 스토리지 서버 일부에 영향을 줬고, 이 서버들이 한꺼번에 메타데이터 서비스에 멤버십 정보를 요청했다.

감지

주 문제를 해결한 뒤 남은 낮은 오류율은 월요일에 고객들이 테이블이 updating 이나 deleting 단계에 멈췄다거나 오류율이 높다는 지원 케이스를 열면서 드러났다.

조치

후속 조치

교훈

AWS 는 멤버십 크기처럼 성능에 영향을 주는 값을 자세히 보지 않아 메타데이터 서비스에 필요한 용량을 미리 잡지 못했다. 전체 오류율이 낮아도 일부 고객에게는 오류가 몰릴 수 있다. AWS 는 이를 늦게 알아채 월요일에 상태 대시보드 게시가 늦었다. 콘솔 로그인은 성공하지 않아도 되는 API 호출에 아주 긴 타임아웃이 걸려 수십 초씩 막혔다. 이런 호출은 빨리 실패하고 로그인을 이어 가게 했어야 했다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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