사례8건

8건 중 7~8번째

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

   Amazon Web Services2024

   증상

   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 셀로 가는 요청은 정상이었다.

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

   촉발

   2024-07-30 PDT 오전 9:09 에 내부 Kinesis 셀 하나의 가용 영역 한 곳에서 정기 배포가 시작됐다. 이 셀에는 처리량이 아주 낮은 샤드가 아주 많았다. 배포가 호스트를 서비스에서 뺐다가 다시 넣자 셀 관리 시스템이 잘못 동작했다.

   원인

   소프트웨어 결함

   구성 요소

   메시지 브로커서버리스 함수 플랫폼오브젝트 스토리지

   기여 요인

   스테이징 불일치자동화 증폭

   조치

   • PDT 오후 4:25 에 덜 급한 내부 워크로드의 유입 스트림을 줄여 부하를 덜어 내는 변경을 배포했다. 셀 관리 시스템이 처리할 데이터가 줄어 오후 5:39 에 오류율과 지연이 나아지기 시작했다.
   • 보안 연결을 만드는 하위 시스템에 용량을 더해 셀 관리 시스템의 상태를 되살렸다. 오후 5:55 에 셀 관리 시스템이 Kinesis 요청 처리에 쓰는 보안 연결을 제대로 맺었다.
   • 오후 6:32 에 연결 프로비저닝을 더 나아지게 하려고 용량을 더 늘렸고, 오류율이 더 내려갔다.

   후속 조치

   • 장애 중에 한 변경을 US-EAST-1 에 그대로 남긴다. 데이터 플레인 연결을 만드는 용량을 늘리고, 부하를 덜어 내는 도구를 운영에 넣고, 연결 한도를 바꾼 것이 여기에 든다.
   • 새 Kinesis Data Streams 아키텍처의 셀이 있는 다른 모든 AWS 리전에도 같은 변경을 이미 적용했다.
   • 이번 장애를 일으킨 워크로드를 더 잘 다루도록 셀 관리 시스템을 더 고친다.

   사례 보기
2. IL-0382 Newark 와 Atlanta 의 Linode Object Storage 가 느려지고 모든 클라이언트에 503 - Slow Down 으로 응답했다

   Linode2022

   증상

   10월 19일과 20일 Newark 와 Atlanta 데이터 센터의 Linode Object Storage 에서 성능과 가용성이 떨어졌다. 고객은 “503 - Slow Down” HTTP 응답 코드로 나타나는 속도 제한을 더 많이 받았다.

   오류율 상승메모리 압박

   촉발

   10월 19일과 20일 Newark 와 Atlanta 의 Object Storage 클러스터로 요청 수와 처리량이 모두 아주 높은 트래픽이 들어왔다.

   원인

   용량 한계

   구성 요소

   오브젝트 스토리지

   기여 요인

   미패치 알려진 버그과도한 영향 범위

   조치

   • Object Storage 클러스터 경계의 속도 제한을 고쳐 공개한 한도인 버킷당 초당 750 요청을 정확히 지키게 했다. 이전에는 클라이언트가 이 값보다 훨씬 많은 I/O 를 할 수 있었다.
   • 일부 내부 Object Storage 인프라에서 메모리를 지나치게 쓰게 하던 Ceph 버그를 해결하고, 하드웨어나 네트워크 고장 뒤 클러스터 복구 같은 스토리지 압박 상황에서 메모리가 폭주하지 않게 설정 값을 조정했다.
   • 자원 경합을 겪던 내부 Object Storage 구성 요소를 덜 붐비고 더 안정적이며 성능이 더 높은 인프라로 옮겼다.
   • 내부 Object Storage 구성 요소와 백엔드 클러스터의 성능 설정 값 몇 개를 조정해 고객을 너무 일찍 속도 제한하지 않게 했다.

   후속 조치

   • 처리량 제한을 더 세밀하게 만든다.
   • 부하를 더 효율적으로 나누도록 내부 Object Storage 인프라를 키운다.
   • 내부 Object Storage 인프라의 하드웨어 성능을 더 높일 방법을 찾는다.
   • 클러스터에 부하가 한곳에 몰리지 않도록 부하 분산 알고리즘을 다듬는다.

   교훈

   백엔드 속도 제한은 한번 걸리면 공개한 한도를 넘지 않은 클라이언트까지 모든 클라이언트에 영향을 준다. Linode 는 버킷당 프런트엔드 속도 제한이 뜻한 대로 동작한다면 클라이언트를 가리지 않는 이런 백엔드 제한은 아예 걸리지 않아야 한다고 봤고, 그래서 백엔드 설정 값을 바꿨다.

   사례 보기

원인별6