Incident Library

IL-0536 Amazon Web Services · 2014-06-13awsdatabase

US East 의 Amazon SimpleDB 가 두 시간 동안 거의 모든 API 호출에 실패했다

SimpleDB 는 고객 데이터를 여러 데이터센터에 복제하는 분산 데이터 저장소다. 스토리지 노드는 사용자 데이터를 저장한다. 고객의 Domain 은 하나마다 스토리지 노드 묶음에 복제된다. 메타데이터 노드는 각 Domain 이 어느 스토리지 노드에 있는지 같은 메타데이터를 저장한다. SimpleDB 는 어떤 Domain 을 어느 노드 묶음이 맡을지 내부 락 서비스로 정한다. 이 락 서비스도 여러 데이터센터에 복제돼 있다. 각 노드는 주기적으로 락 서비스와 핸드셰이크해 자기가 맡은 데이터나 메타데이터를 여전히 맡고 있는지 확인한다.

6월 13일 한 데이터센터에서 서버에 전원이 끊겨 스토리지 노드 여러 대가 한꺼번에 내려갔다. SimpleDB 는 여러 노드가 동시에 실패해도 버티도록 만들어졌지만, 이번 실패 방식에서는 락 서비스가 실패한 스토리지 노드를 복제 그룹에서 빠르게 등록 해제하느라 락 서비스의 부하가 갑자기 크게 늘었다. 그 때문에 정상 노드와 락 서비스 사이의 핸드셰이크가 느려졌고, 노드들은 정해진 핸드셰이크 타임아웃 안에 핸드셰이크를 끝내지 못했다. 재시도와 타임아웃이 몇 번 되풀이되자 스토리지 노드와 메타데이터 노드가 스스로 운영 클러스터에서 빠졌고, API 요청이 500 오류를 받았다. 스토리지 노드는 메타데이터 노드의 승인을 받아야 클러스터에 다시 들어갈 수 있다. 오래된 데이터를 가진 노드가 실수로 들어오지 않게 하려는 규칙이다. 그런데 메타데이터 노드도 같은 핸드셰이크 타임아웃 때문에 내려가 있어서 승인을 해 줄 수 없었다.

문제를 찾은 뒤 엔지니어들은 핸드셰이크 타임아웃 값을 손으로 늘리고 메타데이터 노드 일부를 재시작해 스토리지 노드를 승인하게 했다. 스토리지 노드가 클러스터에 다시 들어가면서 PDT 오후 11:16 에 CreateDomain 과 DeleteDomain 을 뺀 모든 API 가 정상으로 돌아왔다. 나머지 메타데이터 노드가 안전하게 회복하도록 메타데이터 노드가 처리하는 CreateDomain 과 DeleteDomain 호출은 오전 1:30 까지 스로틀링했다.

심각도
–
영향 범위
All SimpleDB API calls except a fraction of eventually consistent reads for two hours, then elevated errors for CreateDomain and DeleteDomain for a little over two more hours
영향 사용자
SimpleDB customers
지역
US East
감지까지
–
복구까지
4h 14m

증상

US East 리전의 SimpleDB 가 PDT 오후 9:16 부터 11:16 까지 거의 모든 API 호출에 실패했다. 최종 일관성 읽기 호출 일부만 성공했다. API 요청은 서버 쪽 오류인 http response code 500 을 받았다.

오후 11:16 에 다른 API 는 정상으로 돌아왔지만, CreateDomain 과 DeleteDomain API 호출은 오전 1:30 까지 오류율이 높았다.

노드 쪽에서는 정상 SimpleDB 노드와 내부 락 서비스 사이의 핸드셰이크 지연이 늘었다. 노드들은 정해진 "handshake timeout" 안에 핸드셰이크를 끝내지 못했다. 재시도와 타임아웃이 몇 번 되풀이된 뒤 스토리지 노드와 메타데이터 노드가 스스로 운영 클러스터에서 빠졌다.

증상 서비스 중단오류율 상승

원인

원인 소프트웨어 결함

구성 요소 데이터베이스코디네이션 키-값 저장소데이터센터 전력·냉각
기여 요인 자동화 증폭
촉발
한 데이터센터에서 서버에 전원이 끊겨 SimpleDB 스토리지 노드 여러 대가 한꺼번에 내려갔다.

감지

–

조치

후속 조치

교훈

핸드셰이크 타임아웃 값을 낮게 잡은 것은 복제본 실패를 빨리 알아채기 위해서였지만, 지나고 보니 너무 낮았다. 핸드셰이크 타임아웃을 여러 번 겪은 노드가 곧바로 클러스터에서 빠지는 동작이 장애의 범위를 넓혔고 API 오류로 이어졌다. 노드는 기다렸다가 더 긴 타임아웃으로 핸드셰이크를 다시 시도했어야 했다.

출처

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스, 코디네이션 키-값 저장소, 데이터센터 전력·냉각. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

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