사례2건

2건 중 1~2번째

1. IL-0384 US-EAST-1 의 Amazon Kinesis Data Streams 에서 레코드 읽기와 쓰기가 하루 대부분 실패했다

   Amazon Web Services2020

   증상

   2020년 11월 25일 5:15 AM PST 에 Kinesis 레코드를 넣고 가져오는 호출의 오류 알람이 울리기 시작했다. Kinesis 를 쓰는 CloudWatch, CloudWatch Events, EventBridge 도 같은 시각부터 오류와 지연을 보였다.

   오류율 상승지연 시간 증가모니터링 중단

   촉발

   2:44 AM PST 부터 3:47 AM PST 까지 Kinesis 프런트엔드 서버군에 비교적 작은 용량을 더했다. AWS 는 이것이 촉발 요인이었지만 근본 원인은 아니었다고 밝혔다.

   원인

   용량 한계

   구성 요소

   메시지 브로커서버리스 함수 플랫폼텔레메트리 에이전트

   기여 요인

   한계 미인지과도한 영향 범위순환 의존

   감지

   5:15 AM PST 에 Kinesis 레코드를 넣고 가져오는 호출의 오류 알람이 울리기 시작했고, 팀이 로그를 보기 시작했다.

   조치

   • 조심하려고 다른 오류를 조사하면서 새로 더한 프런트엔드 용량을 빼기 시작했다.
   • 재시작을 빠르게 하려고, 프런트엔드 서버가 시작할 때 이웃 프런트엔드 서버 대신 정본 메타데이터 저장소에서 바로 데이터를 받도록 설정을 넣기 시작했다.
   • 10:07 AM PST 부터 프런트엔드 서버를 다시 올리며 시간당 수백 대씩 천천히 트래픽을 더했다.
   • Cognito 팀은 장애 초기에 용량을 더해 Kinesis 호출을 버퍼링할 여유를 늘렸다.
   • 10:15 AM PST 에 Cognito 의 Kinesis 의존을 줄이는 변경을 배포하기 시작했고, 오류율이 내려가기 시작했다.
   • 10:36 AM PST 에 엔지니어들이 Lambda 함수 호출 호스트의 메모리 경합을 줄이는 조치를 해서 호출 오류가 풀렸다.
   • 의존이 적은 예비 도구로 Service Health Dashboard 에 게시하고, Personal Health Dashboard 로 영향받은 고객에게 직접 알리고, Service Health Dashboard 에 전역 배너 요약을 올려 고객에게 상황을 알렸다.

   후속 조치

   • CPU 와 메모리가 더 큰 서버로 옮겨 서버 수를 줄이고, 서버마다 서버군 안에서 통신하는 데 필요한 스레드 수를 줄인다.
   • 서비스의 스레드 사용량에 세밀한 알람을 더한다.
   • 운영체제 설정의 스레드 수 한도를 올리는 시험을 마친다.
   • 프런트엔드 서버군의 콜드 스타트 시간을 크게 줄이는 변경을 한다.
   • 프런트엔드 서버 캐시를 전용 서버군으로 옮긴다.
   • CloudWatch 같은 큰 AWS 서비스 몇 개를 따로 나눈 프런트엔드 서버군으로 옮긴다.
   • 백엔드에서 한 것처럼 프런트엔드 서버군의 셀 단위 분리를 크게 앞당긴다.
   • Cognito 웹 서버가 Kinesis API 오류를 겪어도 버퍼를 다 쓰지 않고 버티도록 고쳤다.
   • CloudWatch 로컬 지표 데이터 저장소에 지표 데이터 3시간 치를 보관해, CloudWatch 사용자와 AutoScaling 같은 서비스가 최근 지표를 바로 읽게 한다. US-EAST-1 에는 적용을 마쳤고 앞으로 몇 주 동안 전 세계에 배포한다.
   • 지원 엔지니어가 Service Health Dashboard 예비 게시 도구를 정기적으로 훈련받도록 지원 교육을 바꿨다.

   교훈

   프런트엔드 서버마다 유지할 스레드 수는 서버군의 서버 수에 비례하므로, 서버 수를 줄이면 스레드 수에 큰 여유가 생긴다. AWS 에 따르면 셀 단위 분리는 서비스 안에서 장애의 영향을 가두고, shard-map 캐시 같은 구성 요소가 이미 시험하고 운영해 본 범위 안에서 돌게 하는 방법이다. 프런트엔드 서버군의 셀 단위 분리는 진행 중이었지만 일이 커서 아직 끝나지 않았다. AWS 는 이 작업이 끝나면 앞으로 드러날 모르는 확장 한도에도 더 잘 대비할 수 있다고 봤다.

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

   Amazon Web Services2015

   증상

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

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

   촉발

   2:19am PDT 의 짧은 네트워크 장애가 DynamoDB 스토리지 서버 일부에 영향을 줬고, 이 서버들이 한꺼번에 메타데이터 서비스에 멤버십 정보를 요청했다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   용량 계획 부재모니터링 사각지대재시도 폭주순환 의존과도한 영향 범위

   감지

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

   조치

   • 용량 추가가 여러 번 실패한 뒤 5:06am PDT 에 메타데이터 서비스로 가는 요청을 멈췄다. 재시도가 줄어 메타데이터 서비스의 부하가 크게 덜어졌다.
   • 메타데이터 서비스가 관리 요청에 다시 응답하자 용량을 크게 늘렸다.
   • 메타데이터 서비스로 가는 요청을 다시 열고 스토리지 서버를 고객 요청 경로에 되돌렸다. 7:10am PDT 에 대부분의 고객과 AWS 서비스가 정상 운영을 이어 갈 만큼 오류율이 내려갔다.
   • 받아야 할 만큼 트래픽을 받지 못하던 메타데이터 파티션 하나를 전체 트래픽으로 되돌려 남은 오류를 월요일에 정리했다.

   후속 조치

   • 메타데이터 서비스의 용량을 이미 크게 늘렸다.
   • 멤버십 크기 같은 성능 지표를 더 엄격하게 모니터링해 상태를 파악하고 알맞은 용량을 미리 계획한다.
   • 스토리지 노드가 멤버십 정보를 요청하는 빈도를 줄인다.
   • 메타데이터 서비스가 요청을 처리하는 데 쓸 수 있는 시간을 늘린다.
   • DynamoDB 서비스를 나눠 메타데이터 서비스 인스턴스를 여럿 두고, 각 인스턴스가 스토리지 서버의 일부만 맡게 한다.
   • SQS 의 메타데이터 캐싱을 고쳐 메타데이터 테이블에 오래 접근하지 못해도 메시지 보내기와 받기가 계속되게 한다.
   • Auto Scaling 서버들에 작업을 나누는 방식을 바꿔 쌓인 스케일링 작업을 더 병렬로 처리한다.
   • 더 새로운 작업으로 대체된 오래된 스케일링 작업을 걸러 내는 장치를 넣는다.
   • 스케일링 작업을 처리하는 용량을 늘린다.
   • CloudWatch 가 DynamoDB 의 그룹 멤버십 데이터를 캐싱하는 방식을 바꿔, 갱신이 필요한 지표를 가능한 한 적게 줄인다.
   • write-through 캐싱으로 지표를 더 빨리 전달하는 기능을 개발한다. 이 캐시는 지표를 저장하기 전에 바로 보여 준다.
   • 타임아웃을 줄인 콘솔 로그인 코드를 며칠 안에 배포한다. 이 코드는 이미 테스트 과정에 들어가 있다.

   교훈

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

   사례 보기

원인별1