{"id":"IL-0535","org":"Amazon Web Services","date":"2024-07-30","docs":[],"title":{"en":"An internal Kinesis Data Streams cell in US-EAST-1 degraded, raising errors in CloudWatch Logs, S3 events and Lambda","ko":"US-EAST-1 에서 AWS 내부용 Kinesis Data Streams 셀 하나가 느려져 CloudWatch Logs 와 이를 쓰는 여러 서비스의 지연과 오류가 늘었다"},"domain":["aws","database","observability"],"impact":{"scope":"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","users":"unknown","region":"Northern Virginia (US-EAST-1)"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://aws.amazon.com/message/073024/","kind":"official-status","archived":"https://web.archive.org/web/20261106145613/https://aws.amazon.com/message/073024/"}],"summary":{"en":"Many AWS services buffer data through Amazon Kinesis Data Streams; CloudWatch Logs, for example, buffers incoming log streams in it before writing them to its own storage. Kinesis Data Streams is split into cells, each made of independent subsystems spread over several Availability Zones, and every region has cells used only by AWS services and separate cells for customers. Over the previous couple of years AWS had been moving cells to a new architecture with a cell management system that monitors host health and spreads Kinesis shards across healthy hosts. The system had been tested extensively and had run in many cells for months, and internal cells in US-EAST-1 had been upgraded without issue. One of these internal cells had a workload unlike the others: a very large number of very low-throughput shards.\n\nAt 9:09 AM PDT on July 30th, 2024 a routine deployment began in one Availability Zone of that cell. The deployment takes each host out of service, deploys, runs health checks and brings it back, and the cell management system moves work off each host being removed. It balances work by throughput and other I/O dimensions, so it did not spread the many low-throughput shards across all healthy hosts, and a few hosts received a very large number of them. The status messages these hosts send to the cell management system list every shard the host processes, so the messages became very large, could not be sent and processed in time, and delayed the status messages of other hosts. The cell management system then wrongly marked healthy hosts as unhealthy and moved their shards elsewhere. The spike of shard redistribution overloaded another component that provisions secure connections to the Kinesis data plane subsystems, and from 2:45 PM PDT requests to the cell had elevated latency and errors. Other Kinesis cells in US-EAST-1 and other regions were unaffected.\n\nAt 4:25 PM PDT engineers deployed a change that shed load by reducing incoming stream volume from less time-sensitive internal workloads, and error rates and latency began to improve at 5:39 PM PDT. Engineers added capacity to the subsystem that provisions secure connections; by 5:55 PM PDT the cell could establish secure connections again, most requests succeeded at 6:04 PM PDT, more capacity was added at 6:32 PM PDT, and by 7:21 PM PDT the vast majority of requests were processed normally. The cell recovered fully at 9:37 PM PDT, and the dependent services worked through their backlogs until July 31st and August 1st.","ko":"여러 AWS 서비스는 여러 출처의 대량 데이터를 받아 처리하고 저장하려고 Kinesis Data Streams 를 쓴다. 예를 들어 CloudWatch Logs 는 로그 스트림을 저장하기 전에 Kinesis Data Streams 에 버퍼링한다. Kinesis Data Streams 는 리전마다 AWS 서비스만 쓰는 셀과 고객이 쓰는 셀을 따로 둔다. AWS 는 지난 몇 년 동안 Kinesis 셀을 새 아키텍처로 옮겨 왔다. 새 아키텍처에는 셀 관리 시스템이 있어서, 셀 안의 모든 호스트 상태를 지켜보며 정상 호스트에 샤드 처리를 나눠 준다. AWS 는 장애 전 몇 달 동안 US-EAST-1 의 내부 전용 셀도 문제없이 새 아키텍처로 옮겼다. 그런데 그중 한 셀에는 처리량이 아주 낮은 샤드를 아주 많이 가진 내부 워크로드가 있었고, 셀 관리 시스템은 이런 워크로드에서 잘못 동작했다.\n\n2024-07-30 PDT 오전 9:09 에 이 셀의 가용 영역 하나에서 정기 배포가 시작됐다. 배포는 호스트를 하나씩 서비스에서 빼고, 배포하고, 헬스 체크를 돌리고, 다시 넣는 과정이다. 그동안 셀 관리 시스템이 빠지는 호스트의 일을 다른 호스트로 옮긴다. 셀 관리 시스템은 처리량과 I/O 를 기준으로 일을 나누기 때문에 처리량이 낮은 샤드를 고르게 나누지 못했다. 그 결과 호스트 몇 대가 이런 샤드를 아주 많이 받았다. 각 호스트는 처리하는 샤드마다 정보를 담은 상태 메시지를 셀 관리 시스템에 주기적으로 보낸다. 샤드를 많이 받은 호스트들의 상태 메시지는 아주 커져 제때 전달되고 처리되지 못했다. 이 때문에 다른 호스트의 상태 메시지 처리도 늦어졌다. 셀 관리 시스템은 상태 메시지를 제때 받지 못한 정상 호스트를 비정상으로 잘못 판단하고 그 샤드를 다른 호스트로 다시 나누기 시작했다. 샤드 재분배가 급증하자 Kinesis 데이터 플레인 통신에 쓰는 보안 연결을 만드는 다른 구성 요소에 과부하가 걸렸다. 오후 2:45 부터 이 셀로 가는 요청의 지연과 오류율이 올랐다.\n\n엔지니어링 팀은 곧바로 셀을 조사했다. 팀은 오후 4:25 에 덜 급한 내부 워크로드의 유입 스트림을 줄여 부하를 덜어 내는 변경을 배포했고, 오후 5:39 에 오류율과 지연이 나아지기 시작했다. 보안 연결을 만드는 하위 시스템에 용량을 더하자 오후 5:55 에 셀 관리 시스템이 보안 연결을 제대로 맺었다. 오후 6:04 에는 대부분의 요청이 성공했다. 오후 6:32 에 용량을 더 늘렸고, 오후 7:21 에 거의 모든 요청이 정상으로 처리됐다. 셀이 회복한 오후 9:37 에 영향을 받은 서비스가 정상으로 돌아왔다. 밀린 CloudWatch 로그는 7월 31일 오전 5:50 에, 밀린 S3 이벤트는 8월 1일 오전 2:38 에 처리가 끝났다."},"trigger":{"en":"At 9:09 AM PDT on July 30th a routine deployment started in one Availability Zone of the Kinesis cell, and taking hosts in and out of service during the deployment set off the failure.","ko":"2024-07-30 PDT 오전 9:09 에 내부 Kinesis 셀 하나의 가용 영역 한 곳에서 정기 배포가 시작됐다. 이 셀에는 처리량이 아주 낮은 샤드가 아주 많았다. 배포가 호스트를 서비스에서 뺐다가 다시 넣자 셀 관리 시스템이 잘못 동작했다."},"severity":"unknown","symptoms":["high-latency","high-error-rate","monitoring-down","readiness-probe-failures"],"timeline":{"detected_after":null,"resolved_after":"6h 52m"},"date_kind":"incident","detection":null,"components":["message-broker","serverless-functions","object-storage"],"root_cause":"software-bug","remediation":[{"text":{"en":"Deployed a change that shed load by reducing incoming stream volume from less time-sensitive internal workloads","ko":"PDT 오후 4:25 에 덜 급한 내부 워크로드의 유입 스트림을 줄여 부하를 덜어 내는 변경을 배포했다. 셀 관리 시스템이 처리할 데이터가 줄어 오후 5:39 에 오류율과 지연이 나아지기 시작했다."}},{"text":{"en":"Added capacity to the subsystem that provisions secure connections for Kinesis requests","ko":"보안 연결을 만드는 하위 시스템에 용량을 더해 셀 관리 시스템의 상태를 되살렸다. 오후 5:55 에 셀 관리 시스템이 Kinesis 요청 처리에 쓰는 보안 연결을 제대로 맺었다."}},{"text":{"en":"Added more capacity at 6:32 PM PDT to further improve connection provisioning","ko":"오후 6:32 에 연결 프로비저닝을 더 나아지게 하려고 용량을 더 늘렸고, 오류율이 더 내려갔다."}}],"action_items":[{"text":{"en":"Keep the added connection provisioning capacity, load-shedding tooling and changed connection limits in place in US-EAST-1","ko":"장애 중에 한 변경을 US-EAST-1 에 그대로 남긴다. 데이터 플레인 연결을 만드는 용량을 늘리고, 부하를 덜어 내는 도구를 운영에 넣고, 연결 한도를 바꾼 것이 여기에 든다."}},{"text":{"en":"Apply the same changes in every other region that has cells with the new Kinesis Data Streams architecture","ko":"새 Kinesis Data Streams 아키텍처의 셀이 있는 다른 모든 AWS 리전에도 같은 변경을 이미 적용했다."}},{"text":{"en":"Update the cell management system to better manage the workload that triggered the issue","ko":"이번 장애를 일으킨 워크로드를 더 잘 다루도록 셀 관리 시스템을 더 고친다."}}],"contributing":["staging-not-representative","automation-amplified"],"recurrence_of":null,"symptoms_text":{"en":"From 2:45 PM PDT on July 30th, 2024, several AWS services in the Northern Virginia (US-EAST-1) Region had higher latency and error rates: CloudWatch Logs, Amazon Data Firehose, the event framework that publishes Amazon S3 events, Amazon ECS, AWS Lambda, Amazon Redshift and AWS Glue. All of them used one internal cell of Amazon Kinesis Data Streams, whose requests had started to see elevated latency and errors.\n\nEach service showed it differently. Amazon Data Firehose had more failures on PutRecord and PutRecordBatch calls and was slower to deliver and to create or delete delivery streams, without losing data. S3 event delivery was delayed until 7:21 PM PDT. ECS tasks that used the awslogs log driver in its default blocking mode were blocked when logs could not be sent to CloudWatch Logs and then could not answer health checks. Lambda function executions were missing their CloudWatch Logs, so customers could not tell whether their functions ran successfully, and functions that called CloudWatch Logs or Firehose directly had more errors or latency. API Gateway logging failed. Redshift connections through Query Editor v2 and JDBC, ODBC or Python drivers failed intermittently, and MWAA and Glue had slow and failing API calls.\n\nRecovery was gradual. Error rates first improved at 5:39 PM PDT, most requests to the cell succeeded by 7:21 PM PDT and the cell was normal at 9:37 PM PDT. Backlogs took much longer: CloudWatch Logs processed the newest log streams first and finished the older backlog at 5:50 AM PDT on July 31st, when logs, metrics filtered from log events and CloudWatch alarms on delayed metrics were normal again, and the backlog of S3 events finished at 2:38 AM PDT on August 1st.","ko":"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 셀로 가는 요청은 정상이었다.\n\nCloudWatch Logs 는 로그 스트림을 Kinesis Data Streams 에 버퍼링하기 때문에 로그 수집이 늦어졌다. 복구 뒤 CloudWatch Logs 는 실시간 관측을 위해 가장 최근 로그 스트림부터 처리했고, 몇 시간 동안 쌓인 옛 로그는 나란히 처리했다. 로그 처리는 7월 31일 PDT 오전 5:50 에 끝났고, 이때 로그, 로그 이벤트에서 걸러 낸 지표, 늦게 들어온 지표에 건 CloudWatch 경보가 정상으로 돌아왔다.\n\nS3 이벤트 전달은 오후 2:45 부터 7:21 까지 늦어졌고, 밀린 S3 이벤트는 8월 1일 PDT 오전 2:38 에 처리가 끝났다. Amazon Data Firehose 는 PutRecord 와 PutRecordBatch API 호출의 실패가 늘었다. 스트림 전달과 전달 스트림의 생성, 삭제도 느려졌다. 데이터 손실은 없었다.\n\nawslogs 로그 드라이버를 기본값인 blocking 모드로 쓰는 ECS 태스크는 로그를 CloudWatch Logs 로 보내지 못하자 멈춰서 헬스 체크에 응답하지 못했다. non-blocking 모드로 설정한 고객의 애플리케이션은 정상으로 돌았다.\n\nLambda 함수 실행 로그가 CloudWatch Logs 에 남지 않았다. 함수 안에서 CloudWatch Logs 나 Data Firehose API 를 직접 호출하는 고객은 함수 오류나 지연이 늘었다. 오류는 로깅 호출이 끝나기를 기다리는 함수에서 났다. 고객은 장애 중에 함수가 모두 성공했는지 확인할 수 없었다. API Gateway 는 로그 전달이 실패했고 로깅 설정의 오류가 늘었다. API Gateway 를 거친 Lambda 호출 일부도 오류를 냈다.\n\nECS Fargate 태스크 실패와 CloudWatch Logs 오류가 다른 서비스로도 번졌다. Amazon Redshift 고객은 Query Editor v2 나 JDBC, ODBC, Python 드라이버로 클러스터에 연결할 때 간헐적으로 문제를 겪었다. Redshift 클러스터의 CloudWatch 지표를 볼 때도 오류가 늘었다. Amazon MWAA 와 AWS Glue 는 리소스 생성과 변경, 지표 기록에서 지연과 API 실패가 늘었다."},"updated_at":"2026-11-14T12:34:17.807515Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0535","org_slug":"amazon-web-services"}