사례4건

4건 중 1~4번째

1. IL-0150 DynamoDB DNS 자동화의 경쟁 조건이 us-east-1 리전 엔드포인트의 DNS 레코드를 비워 DynamoDB 와 EC2 인스턴스 시작이 실패했고, 그 여파로 EKS, ECS, Fargate 의 컨테이너 시작과 클러스터 스케일링이 14시간 넘게 막혔다

   Amazon Web Services2025

   증상

   2025년 10월 19일 23시 48분 PDT 부터 us-east-1 리전에서 공개 엔드포인트로 DynamoDB 에 연결하려던 모든 시스템이 DNS 조회에 실패했다. 고객 트래픽과 DynamoDB 에 기대는 AWS 내부 서비스가 함께 실패했다.

   DNS 조회 실패오류율 상승노드 증설 실패간헐적 연결 실패지연 시간 증가

   촉발

   DynamoDB DNS 관리 시스템에 잠재해 있던 경쟁 조건 때문에 리전 엔드포인트 dynamodb.us-east-1.amazonaws.com 의 DNS 레코드가 빈 값이 됐고, 자동화가 이를 복구하지 못했다.

   원인

   소프트웨어 결함

   구성 요소

   DNS 서버와 레코드데이터베이스클라우드 로드 밸런서

   기여 요인

   자동화 증폭재시도 폭주런북 부재

   감지

   영향받은 AWS 서비스의 엔지니어링 팀이 23시 48분 장애가 시작되자 바로 투입돼 조사했고, 00시 38분 DynamoDB 의 DNS 상태를 원인으로 찾았다. NLB 헬스 체크 문제는 06시 52분 모니터링 시스템이 감지했다.

   조치

   • 01시 15분 PDT 까지 임시 조치를 적용해 일부 내부 서비스가 DynamoDB 에 연결되게 하고 복구에 필요한 핵심 내부 도구를 고쳤다.
   • 운영자가 손으로 DynamoDB 리전 엔드포인트의 DNS 정보를 바로잡아 02시 25분 모두 복구했다.
   • 04시 14분 DWFM 으로 들어오는 작업을 스로틀링하고 DWFM 호스트를 골라 재시작해 큐를 비우고 droplet 리스를 다시 맺게 했다.
   • Network Manager 의 부하를 줄이고 복구를 앞당기는 조치를 해 10시 36분 네트워크 구성 전파 시간을 정상으로 되돌렸다.
   • 09시 36분 NLB 의 자동 헬스 체크 장애 조치를 꺼서 정상인 NLB 노드와 백엔드 대상을 모두 서비스로 되돌렸고, EC2 가 회복된 뒤 14시 09분 다시 켰다.
   • 11시 23분부터 EC2 하위 시스템을 보호하려고 걸어 둔 요청 스로틀링을 풀기 시작해 13시 50분 EC2 API 와 새 인스턴스 시작을 정상화했다.

   후속 조치

   • DynamoDB DNS Planner 와 DNS Enactor 자동화를 전 세계에서 껐다.
   • 자동화를 다시 켜기 전에 경쟁 조건을 고치고, 잘못된 DNS 계획이 적용되지 않도록 보호 장치를 더한다.
   • 헬스 체크 실패로 가용 영역 장애 조치가 일어날 때 NLB 하나가 서비스에서 뺄 수 있는 용량을 제한하는 속도 제어 장치를 넣는다.
   • 기존 규모 테스트에 더해 DWFM 복구 흐름을 실행해 보는 테스트 스위트를 만들어 회귀를 찾는다.
   • EC2 데이터 전파 시스템의 스로틀링을 개선해 대기 큐 크기에 따라 들어오는 작업의 속도를 제한한다.

   교훈

   DNS 자동화가 스스로 고칠 수 없는 상태에 빠지면 사람이 손대기 전까지 리전 엔드포인트가 통째로 사라진다. 계획이 더 새로운지 적용 전에 한 번만 확인하면, 처리가 길게 지연됐을 때 그 확인 결과는 낡은 정보가 된다. 기반 서비스가 돌아와도 그 위의 시스템은 밀린 작업 때문에 혼잡 붕괴에 빠질 수 있다. 이번에는 정해진 복구 절차가 없어 엔지니어들이 여러 조치를 조심스럽게 시도한 끝에 04시 14분에야 스로틀링과 호스트 재시작으로 풀었다. EKS 처럼 EC2 인스턴스 시작에 기대는 서비스는 DynamoDB 가 회복된 뒤에도 EC2 와 네트워크 전파가 정상화될 때까지 컨테이너 시작과 스케일링이 막혔다. 헬스 체크에 따른 자동 장애 조치는 상태 정보가 흔들릴 때 정상 용량까지 빼 버릴 수 있다.

   사례 보기
2. IL-0177 다른 팀의 설정 배포로 공유 L7 HAProxy 가 재로드될 때마다 messaging-hub 의 웹소켓 연결이 한꺼번에 끊겼다.

   LINE Plus2022

   증상

   LINE 의 messaging-hub 는 일본 음식 배달 서비스 Demaecan 의 Merchant 앱과 Driver 앱에 웹소켓으로 메시지를 보낸다. 어느 날 최대 트래픽 시간이 아닌데도 웹소켓 연결 수 그래프가 순간적으로 크게 떨어졌다. 이 현상은 한 번으로 끝나지 않고 불규칙하게 계속 일어났다.

   연결 리셋데이터베이스 과부하간헐적 연결 실패지연 시간 증가

   촉발

   같은 L7 로드밸런서를 공유하는 다른 서비스 담당자가 자기 LB 설정을 배포하면 HAProxy 가 재로드됐다. hard-stop-after 로 정한 30분이 지나 이전 프로세스가 종료되면서 거기 붙어 있던 웹소켓 연결이 모두 끊겼다.

   원인

   설정 변경

   구성 요소

   HAProxy클라우드 로드 밸런서conntrack 테이블인그레스 컨트롤러

   기여 요인

   늦게 드러난 변경과도한 영향 범위재시도 폭주미검증 가정

   감지

   웹소켓 연결 수 그래프에서 최대 트래픽 시간이 아닌데도 연결 수가 순간적으로 뚝 떨어지는 것을 보고 알았다. Nginx 패킷 드롭은 네트워크 모니터링으로 원인을 찾았다.

   조치

   • Merchant 팀이 토큰 발급 API 를 따로 떼어 배포해 토큰 요청이 몰려도 다른 Merchant API 가 지연되지 않게 했다.
   • Nginx 를 늘리고 파드 안티 어피니티와 레이블 셀렉터로 Nginx 파드가 서로 다른 노드에 뜨게 해서 NF_CONNTRACK 테이블 포화로 생기던 패킷 드롭을 없앴다.
   • Ingress Nginx 의 proxy-read-timeout 과 proxy-send-timeout 을 300s 에서 3600s 로, LB timeout 도 3600s 로 올렸지만 웹소켓 드롭은 멈추지 않았다.
   • 공유하던 L7 LB 를 L4 LB 로 바꿔 웹소켓 드롭을 없앴다.

   교훈

   문제의 범위를 미리 단정해 스스로 제한하면 안 된다. 인프라 팀과 네트워크 팀이 문제없다고 답했다는 이유로 직접 다룰 수 있는 영역만 뒤지다가 공유 L7 LB 를 늦게 의심했다. LB 같은 기술 리소스를 다른 서비스와 공유하면 다른 팀의 배포가 내 서비스의 연결을 끊을 수 있다. Nginx 를 늘려 NF_CONNTRACK 부담을 나눌 때는 파드가 서로 다른 노드에 뜨게 해야 하고, 노드 수보다 많이 늘리면 Pending 상태로 남는 파드가 생긴다는 점도 알아야 한다.

   사례 보기
3. IL-0364 'default' 인그레스 컨트롤러로 들어오는 트래픽의 25% 가 느려졌다

   UK Ministry of Justice2022

   증상

   2022-07-11 09:33 에 사용자들이 #ask-cloud-platform 에 애플리케이션이 가끔 느리다고 알렸다. 영향을 받은 것은 인그레스 트래픽의 25% 였다.

   지연 시간 증가간헐적 타임아웃

   촉발

   AWS 에서 헬스 체크 인스턴스 일부가 재시작될 때 잠재해 있던 소프트웨어 경쟁 상태가 드러났다. 그 뒤 NLB 의 헬스 체크 하위 시스템이 한 가용 영역에 있는 대상을 알지 못하게 됐다.

   원인

   클라우드 제공자 장애

   구성 요소

   클라우드 로드 밸런서인그레스 컨트롤러

   기여 요인

   –

   감지

   사용자들이 #ask-cloud-platform 에 애플리케이션이 가끔 느리다고 알렸다. 첫 감지는 09:33 이었고 사고 선언은 10:11 이었다.

   조치

   • AWS 가 헬스 체크 하위 시스템을 재시작해 대상 목록을 새로 읽게 했고, 그 뒤 영향을 받은 가용 영역의 NLB 가 돌아왔다.

   후속 조치

   • 사고 뒤 검토에서 정한 완화 작업을 ministryofjustice/cloud-platform 저장소에 post-aws-incident 이슈로 올렸다.

   사례 보기
4. IL-0208 GitLab Helm 차트 업그레이드가 Service 와 Deployment 의 포트 이름을 바꿔 GCP 로드 밸런서가 다시 구성되는 동안 GitLab.com 요청이 느려지고 50x 오류가 났다

   GitLab2022

   증상

   2022-03-31 07:53 UTC 에 GitLab.com 웹 서비스의 50x 오류가 늘기 시작했고, 1분 뒤 당직 엔지니어가 오류율 증가 페이지를 받았다. 사용자에게는 GitLab.com 이 느려졌고 간헐적으로 500 오류 페이지가 떴다.

   오류율 상승지연 시간 증가간헐적 타임아웃

   촉발

   gitlab-com/gl-infra/k8s-workloads/gitlab-com!1643 머지 요청을 배포하는 파이프라인이 07:49 UTC 에 gprd-cny 로 배포를 시작했다. 이 변경에는 GitLab 차트 버전 업그레이드가 들어 있었고, 새 차트는 Prometheus ServiceMonitor, PodMonitor 설정과 관련된 변경으로 Kubernetes Service 와 Deployment 의 포트 이름을 바꿨다.

   원인

   설정 변경

   구성 요소

   Helm클라우드 로드 밸런서HAProxy

   기여 요인

   자동화 증폭

   감지

   07:53 UTC 에 50x 오류가 늘기 시작했고 07:54 에 PagerDuty 알림이 당직 엔지니어를 호출했다. 변경을 배포하던 엔지니어가 오류를 보고 그 변경과 연결해 원인을 짚었다.

   조치

   • 08:05 UTC 에 당직 엔지니어가 카나리 환경을 트래픽에서 뺐다가 08:25 에 다시 넣었다.
   • 08:15 에 cluster c 와 cluster d 배포 작업을 시작 전에 취소했다.
   • 08:51 에 HAProxy 에서 gprd-us-east1-d 클러스터를 뺐다가 08:56 에 다시 넣었다.
   • 09:31 에 최소 레플리카 수를 100 넘게 올리는 변경 !1650 을 머지했다.
   • 09:53 에 HAProxy 에서 gprd-us-east1-c 클러스터를 빼고, 09:57 에 이 클러스터에 !1643 을 배포한 뒤 10:07 에 다시 넣었다.
   • 10:19 에 최소 레플리카 상향을 되돌리는 변경 !1652 를 머지했다.

   후속 조치

   • 리전 클러스터 하나에서 트래픽을 통째로 안전하게 빼는 graceful drain 기능을 만든다.
   • PagerDuty 를 유지보수 모드로 바꾸는 ChatOps 명령을 만든다.

   교훈

   알림은 정확하게 울렸다. 원인이 바로 직전에 배포한 변경이라는 것을 알았기 때문에, 그 변경을 배포하던 파이프라인을 멈추는 것이 자연스러운 첫 대응이었다.

   사례 보기

원인별3