Incident Library

IL-0535 Amazon Web Services · 2024-07-30awsdatabaseobservability

US-EAST-1 에서 AWS 내부용 Kinesis Data Streams 셀 하나가 느려져 CloudWatch Logs 와 이를 쓰는 여러 서비스의 지연과 오류가 늘었다

여러 AWS 서비스는 여러 출처의 대량 데이터를 받아 처리하고 저장하려고 Kinesis Data Streams 를 쓴다. 예를 들어 CloudWatch Logs 는 로그 스트림을 저장하기 전에 Kinesis Data Streams 에 버퍼링한다. Kinesis Data Streams 는 리전마다 AWS 서비스만 쓰는 셀과 고객이 쓰는 셀을 따로 둔다. AWS 는 지난 몇 년 동안 Kinesis 셀을 새 아키텍처로 옮겨 왔다. 새 아키텍처에는 셀 관리 시스템이 있어서, 셀 안의 모든 호스트 상태를 지켜보며 정상 호스트에 샤드 처리를 나눠 준다. AWS 는 장애 전 몇 달 동안 US-EAST-1 의 내부 전용 셀도 문제없이 새 아키텍처로 옮겼다. 그런데 그중 한 셀에는 처리량이 아주 낮은 샤드를 아주 많이 가진 내부 워크로드가 있었고, 셀 관리 시스템은 이런 워크로드에서 잘못 동작했다.

2024-07-30 PDT 오전 9:09 에 이 셀의 가용 영역 하나에서 정기 배포가 시작됐다. 배포는 호스트를 하나씩 서비스에서 빼고, 배포하고, 헬스 체크를 돌리고, 다시 넣는 과정이다. 그동안 셀 관리 시스템이 빠지는 호스트의 일을 다른 호스트로 옮긴다. 셀 관리 시스템은 처리량과 I/O 를 기준으로 일을 나누기 때문에 처리량이 낮은 샤드를 고르게 나누지 못했다. 그 결과 호스트 몇 대가 이런 샤드를 아주 많이 받았다. 각 호스트는 처리하는 샤드마다 정보를 담은 상태 메시지를 셀 관리 시스템에 주기적으로 보낸다. 샤드를 많이 받은 호스트들의 상태 메시지는 아주 커져 제때 전달되고 처리되지 못했다. 이 때문에 다른 호스트의 상태 메시지 처리도 늦어졌다. 셀 관리 시스템은 상태 메시지를 제때 받지 못한 정상 호스트를 비정상으로 잘못 판단하고 그 샤드를 다른 호스트로 다시 나누기 시작했다. 샤드 재분배가 급증하자 Kinesis 데이터 플레인 통신에 쓰는 보안 연결을 만드는 다른 구성 요소에 과부하가 걸렸다. 오후 2:45 부터 이 셀로 가는 요청의 지연과 오류율이 올랐다.

엔지니어링 팀은 곧바로 셀을 조사했다. 팀은 오후 4:25 에 덜 급한 내부 워크로드의 유입 스트림을 줄여 부하를 덜어 내는 변경을 배포했고, 오후 5:39 에 오류율과 지연이 나아지기 시작했다. 보안 연결을 만드는 하위 시스템에 용량을 더하자 오후 5:55 에 셀 관리 시스템이 보안 연결을 제대로 맺었다. 오후 6:04 에는 대부분의 요청이 성공했다. 오후 6:32 에 용량을 더 늘렸고, 오후 7:21 에 거의 모든 요청이 정상으로 처리됐다. 셀이 회복한 오후 9:37 에 영향을 받은 서비스가 정상으로 돌아왔다. 밀린 CloudWatch 로그는 7월 31일 오전 5:50 에, 밀린 S3 이벤트는 8월 1일 오전 2:38 에 처리가 끝났다.

심각도
–
영향 범위
One internal Kinesis Data Streams cell, and through it CloudWatch Logs, Amazon Data Firehose, S3 event delivery, Amazon ECS, AWS Lambda, API Gateway logging, Amazon Redshift, Amazon MWAA and AWS Glue
영향 사용자
–
지역
Northern Virginia (US-EAST-1)
감지까지
–
복구까지
6h 52m

증상

2024-07-30 PDT 오후 2:45 부터 US-EAST-1 리전의 여러 AWS 서비스에서 지연과 오류율이 올랐다. CloudWatch Logs, Amazon Data Firehose, Amazon S3 이벤트를 게시하는 이벤트 프레임워크, Amazon ECS, AWS Lambda, Amazon Redshift, AWS Glue 가 영향을 받았다. 같은 리전의 다른 Kinesis Data Streams 셀로 가는 요청은 정상이었다.

CloudWatch Logs 는 로그 스트림을 Kinesis Data Streams 에 버퍼링하기 때문에 로그 수집이 늦어졌다. 복구 뒤 CloudWatch Logs 는 실시간 관측을 위해 가장 최근 로그 스트림부터 처리했고, 몇 시간 동안 쌓인 옛 로그는 나란히 처리했다. 로그 처리는 7월 31일 PDT 오전 5:50 에 끝났고, 이때 로그, 로그 이벤트에서 걸러 낸 지표, 늦게 들어온 지표에 건 CloudWatch 경보가 정상으로 돌아왔다.

S3 이벤트 전달은 오후 2:45 부터 7:21 까지 늦어졌고, 밀린 S3 이벤트는 8월 1일 PDT 오전 2:38 에 처리가 끝났다. Amazon Data Firehose 는 PutRecord 와 PutRecordBatch API 호출의 실패가 늘었다. 스트림 전달과 전달 스트림의 생성, 삭제도 느려졌다. 데이터 손실은 없었다.

awslogs 로그 드라이버를 기본값인 blocking 모드로 쓰는 ECS 태스크는 로그를 CloudWatch Logs 로 보내지 못하자 멈춰서 헬스 체크에 응답하지 못했다. non-blocking 모드로 설정한 고객의 애플리케이션은 정상으로 돌았다.

Lambda 함수 실행 로그가 CloudWatch Logs 에 남지 않았다. 함수 안에서 CloudWatch Logs 나 Data Firehose API 를 직접 호출하는 고객은 함수 오류나 지연이 늘었다. 오류는 로깅 호출이 끝나기를 기다리는 함수에서 났다. 고객은 장애 중에 함수가 모두 성공했는지 확인할 수 없었다. API Gateway 는 로그 전달이 실패했고 로깅 설정의 오류가 늘었다. API Gateway 를 거친 Lambda 호출 일부도 오류를 냈다.

ECS Fargate 태스크 실패와 CloudWatch Logs 오류가 다른 서비스로도 번졌다. Amazon Redshift 고객은 Query Editor v2 나 JDBC, ODBC, Python 드라이버로 클러스터에 연결할 때 간헐적으로 문제를 겪었다. Redshift 클러스터의 CloudWatch 지표를 볼 때도 오류가 늘었다. Amazon MWAA 와 AWS Glue 는 리소스 생성과 변경, 지표 기록에서 지연과 API 실패가 늘었다.

증상 지연 시간 증가오류율 상승모니터링 중단프로브 실패

원인

원인 소프트웨어 결함

구성 요소 메시지 브로커서버리스 함수 플랫폼오브젝트 스토리지
기여 요인 스테이징 불일치자동화 증폭
촉발
2024-07-30 PDT 오전 9:09 에 내부 Kinesis 셀 하나의 가용 영역 한 곳에서 정기 배포가 시작됐다. 이 셀에는 처리량이 아주 낮은 샤드가 아주 많았다. 배포가 호스트를 서비스에서 뺐다가 다시 넣자 셀 관리 시스템이 잘못 동작했다.

감지

–

조치

후속 조치

교훈

–

출처

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 메시지 브로커, 서버리스 함수 플랫폼, 오브젝트 스토리지. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

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