사례45건

45건 중 6~10번째

1. IL-0581 이구위크 첫날 Redis 커넥션이 실패하며 29CM 상품 전시 서버의 파드가 다운되고 Netty 이벤트 루프가 포화됐다

   MUSINSA2025

   증상

   이구위크가 시작되고 얼마 지나지 않아 검색 결과와 상품 리스팅 같은 전시 도메인을 맡은 서버에 이상 징후가 나타났다. 파드 일부가 다운되어 트래픽을 받지 못했고, 남은 파드도 처리할 수 있는 양을 넘어 Netty 이벤트 루프가 포화됐다.

   프로브 실패간헐적 연결 실패지연 시간 증가

   촉발

   2025년 11월 3일 29CM 최대 규모의 블랙프라이데이 행사인 이구위크가 시작되면서 트래픽이 몰렸다.

   원인

   용량 한계

   구성 요소

   인메모리 캐시라이브니스·레디니스 프로브

   기여 요인

   한계 미인지모니터링 사각지대의존성에 묶인 헬스 체크

   감지

   팀은 이구위크가 시작되고 얼마 지나지 않아 전시 서버의 파드 일부가 다운되고 Netty 이벤트 루프가 포화된 것을 보고 이상을 알아챘다. 원인을 분석하던 중 Redis 헬스체크 실패 로그를 보고 네트워크 지표에서 대역폭 초과를 찾았다.

   조치

   • 원인을 찾은 즉시 Redis 노드를 cache.r7g.large 에서 기본 대역폭이 1.875Gbps 로 약 2배인 cache.r7g.2xlarge 로 스케일업했다.

   후속 조치

   • 네트워크 In/Out 대역폭의 초과 여부를 실시간으로 볼 수 있게 모니터링 대시보드를 강화했다. 주요 지표는 aws.elasticache.network_bytes_in, aws.elasticache.network_bytes_out, aws.elasticache.network_bandwidth_in_allowance_exceeded, aws.elasticache.network_bandwidth_out_allowance_exceeded, aws.elasticache.traffic_management_active 다.
   • 네트워크 대역폭이 임계치를 넘으면 곧바로 알림이 오도록 Datadog Alert 를 연동했다.
   • 응답이 자주 바뀌지 않는 데이터를 중심으로 Redis 하나에 기대던 구조를 Caffeine 로컬 캐시, Redis 원격 캐시, DB 로 이어지는 캐시 계층 구조로 바꿨다.
   • Redis 네트워크 대역폭 사용량을 줄이려고 CPU 사용량이 적고 압축과 해제가 빠른 Snappy 로 캐시 데이터를 압축하는 방안을 검토한다.
   • JSON 으로 저장하던 캐시 데이터를 Protocol Buffers 형식으로 바꾸는 방안을 검토한다. 팀이 캐싱 중인 Item Document 데이터로 재 본 결과, Snappy 압축과 protobuf 를 함께 쓰면 용량을 약 73% 줄일 수 있을 것으로 예상됐다.
   • 캐시 구조 개선, 모니터링 고도화, 읽기 분리 적용으로 기술 부채를 해소했고, 이를 바탕으로 트래픽 증가에 대비한 아키텍처 개선을 진행한다.

   교훈

   CPU 와 Memory 지표만으로는 Redis 대역폭 초과를 알아채기 어려웠고, 팀은 네트워크 관점의 모니터링이 필요하다는 것을 다시 느꼈다. 버스트 크레딧 구간이 있으면 Baseline 을 넘은 시점과 Throttling 이 시작된 시점 사이에 시간이 벌어져 원인을 찾기가 늦어진다. 트래픽이 더 늘면 스케일업만으로는 같은 문제가 되풀이될 수 있어 근본적인 재발 방지가 필요하다고 봤다.

   사례 보기
2. IL-0100 노드가 파드의 CPU 요청에 비해 작아 CPU 가 포화되면서 PostHog 기능 플래그 서비스에 열흘 사이 장애가 세 번 났다.

   PostHog2025

   증상

   2025-10-21 21:45 UTC, 타임아웃 오류를 줄이려는 배포 직후 자동 모니터링이 기능 플래그 서비스의 오류율 상승을 잡았다. 2분 만에 롤백했지만 오류율은 내려가지 않았고, US 데이터센터에서 평가 요청의 약 38% 가 오류를 냈다.

   노드 CPU 고부하오류율 상승지연 시간 증가컨테이너 재시작 반복데이터베이스 과부하

   촉발

   10월 21일에는 증상만 고치려던 타임아웃 처리 배포가 장애를 일으켰다. 28일에는 플래그 서비스와 무관한 일상 배포가 파드 롤아웃을 일으켰고, 이 롤아웃이 장애로 이어졌다. 24일에는 로드밸런서 뒤에서 모든 트래픽을 IP 하나에서 온 것으로 본 레이트 리밋 배포가 장애를 일으켰다.

   원인

   용량 한계

   구성 요소

   노드 풀파드 스케줄링과 배치인메모리 캐시데이터베이스

   기여 요인

   한계 경보 부재재시도 폭주롤백 무효단일 장애점단계적 배포 부재스테이징 불일치

   감지

   21일에는 배포 2분 뒤 자동 모니터링이 오류율 상승을 잡았고, 28일에는 온콜이 높은 오류 수 경보를 받았다. PostHog 는 대부분의 경우 2분 안에 감지했다고 정리했다. 24일에는 429 오류 경보가 없어서 18:10 UTC 부터 들어온 고객 신고로 알았고, 감지까지 62분이 걸렸다. CPU 경보가 아예 없어서 공통 원인인 CPU 포화는 오래 드러나지 않았고, 29일에서 30일 사이 장애는 7시간 넘게 이어졌다.

   조치

   • 10월 21일 타임아웃 처리를 바꾼 배포를 2분 안에 롤백했지만 오류는 멈추지 않았다.
   • 10월 21일 23:00 UTC 부터 연결과 Redis 쓰기를 조절해 23:28 UTC 에 서비스를 복구했다.
   • 10월 28일 롤아웃을 멈추고 US 플래그 파드를 0개로 줄여 Redis 가 회복되기를 기다린 뒤, 파드를 차례로 다시 올렸다.
   • 10월 30일 00:03 UTC 에 하드웨어 변경을 롤백해 오류는 대부분 가라앉혔지만 지연은 남았다.
   • 파드 리소스 요청을 늘리고 쿠버네티스 플릿 크기를 조정해 노드당 파드 수를 줄였다.
   • 로드밸런서와 서비스 사이 Envoy 재시도에 한도를 걸었다.
   • 데이터베이스 연결 타임아웃과 다른 중요한 설정을 런타임 설정으로 옮기고, 타임아웃 값을 피크 부하에 맞게 늘렸다.
   • 노드마다, 파드마다 CPU 사용률이 80% 를 5분 동안 넘으면 온콜을 호출하는 CPU 경보를 추가했다.

   후속 조치

   • 플래그, 수집, 인프라 팀 엔지니어로 전담 팀을 꾸려 애플리케이션과 인프라 전체를 살피고 남은 병목을 찾는다.
   • 플래그 서비스의 Redis 를 본 애플리케이션의 Redis 와 분리하는 방안을 검토한다.
   • ArgoCD 동기화를 다시 켜기 전에 플래그 서비스 차트 설정을 ArgoCD 의 현재 값에 맞추고, 배포 전략과 Redis 전략을 정한다.
   • 플래그 관련 코드의 필수 코드 오너를 기능 플래그 팀으로 정한다.
   • 중요한 플래그 지표와 런북 링크를 한데 모은 대시보드를 만들고, 기능 플래그 런북을 고친다.
   • 기존 서비스 지표와 인프라 지표에 빠져 있는 경보를 추가한다.
   • readiness 검사가 liveness 검사를 그대로 따라 하지 않고, 데이터베이스에 ping 을 보내는 식으로 부하가 걸렸을 때 약해졌던 의존성을 확인하게 바꾼다.
   • 캐시 채우기 작업에 레이트 리밋을 걸어 Redis 에 감당하지 못할 만큼 작업이 몰리지 않게 한다.
   • 연결 풀을 모니터링해 풀이 바닥에 가까워지면 자동으로 요청을 조절하고, 동시 연결 수에 상한을 둔다.
   • 운영 규모의 부하 시험 체계를 만든다.
   • 점진적 롤아웃 기반을 만들어 배포가 미치는 범위를 줄인다.
   • Postgres 에서 Redis 로 가는 데이터 흐름을 문서로 정리하고, 데이터 전송이 한꺼번에 몰릴 때 쓸 런북을 만든다.

   교훈

   가장 큰 교훈은 CPU 크기 산정이었다. 노드가 파드 요청에 비해 작으면 노드 하나에 파드가 너무 많이 몰리고, CPU 포화가 과도한 병렬 처리, 연결 풀 고갈, 느린 쿼리처럼 서로 다른 모습으로 나타난다. 증상만 고친 수정 때문에 21일의 장애가 28일에 되풀이됐다. PostHog 는 CPU 를 넉넉히 받은 파드를 적은 수로 돌리는 편이 낫다고 정리했다. 기능 플래그 서비스와 본 애플리케이션이 Redis 를 같이 쓰면 한쪽 과부하가 다른 쪽을 쓰러뜨리는 단일 장애 지점이 된다. CPU 지표는 처음부터 경보로 걸어야 하고, Postgres 에서 Redis 로 가는 전송 급증도 경보 대상이다. 재시도, 캐시 채우기, 연결 생성에 한도가 없으면 장애가 커진다. 과부하 패턴은 운영 트래픽에서만 드러났으므로 부하 시험이 필요하고, 중요한 설정은 배포 없이 바꿀 수 있어야 한다.

   사례 보기
3. 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 와 네트워크 전파가 정상화될 때까지 컨테이너 시작과 스케일링이 막혔다. 헬스 체크에 따른 자동 장애 조치는 상태 정보가 흔들릴 때 정상 용량까지 빼 버릴 수 있다.

   사례 보기
4. IL-0413 Microsoft 클라우드 LLM 추론 서비스의 추론 엔진이 몰린 트래픽에 포화돼 HTTP 429·5xx 와 타임아웃을 냈다

   Microsoft2025

   증상

   Microsoft 의 클라우드 LLM 추론 서비스에서 추론 엔진이 요청을 감당하지 못해 고객이 HTTP 429, 5xx 오류와 타임아웃을 받았다. 2025년 4월부터 6월까지의 높은 심각도 장애 156건 가운데 94건, 약 60% 가 추론 엔진 장애였다.

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

   촉발

   몰려드는 트래픽에 이미지 인코더와 모델 컨테이너가 포화됐다. 샘플링 파라미터가 유난히 높은 트래픽까지 겹쳐 서빙이 감당하지 못했다.

   원인

   용량 한계

   구성 요소

   모델 추론 서버

   기여 요인

   모니터링 사각지대

   감지

   논문은 고객 신고보다 먼저 헬스 프로브나 DRI 파이프라인이 낸 알림을 자동 감지로 셌다. 전체 156건 가운데 115건, 약 74% 가 자동 감지됐고 나머지는 자동으로 감지되지 않았다.

   조치

   • 로드 밸런서에서 대기 토큰과 대기 요청에 상한을 두는 동적 pushback 을 켰다.
   • request batching 과 GPU·CPU 레플리카 수를 조정했다.
   • gRPC backoff 와 오류 매핑을 고쳤다.
   • 샘플링 파라미터에 제한을 두고 클라이언트별 throttling 을 걸었다.
   • 오래 걸리는 요청에서 엔진 연결이 타임아웃 나는 문제에는 스트리밍을 켜고, request batching 을 조정하고, 대기 토큰에 상한을 뒀다. 그 결과 HTTP 408 이 줄고 성공률이 높아졌다.
   • 용량 증설, 트래픽 라우팅, 재시작을 주로 추론 엔진 장애를 완화하는 데 썼다.

   후속 조치

   • 오래 걸리는 요청과 높은 샘플링 조건에 맞게 서빙을 최적화해 타임아웃과 자원 고갈을 줄인다.
   • 헬스 프로브 기반 failover 와 GPU 용량 인지 라우팅을 넓혀, 상태가 나빠진 엔드포인트에서 트래픽이 스스로 빠져나가게 한다.
   • 토큰과 처리량 증가를 예측하고 용량 증설 결정을 자동화해, 완화 시간을 늘리는 수동 핫픽스와 수동 증설을 피한다.
   • 적응형 알림을 배포하고 엔진 수준 텔레메트리를 늘려, 트래픽이 적은 엔드포인트에서, 그리고 오류가 모호하게 변환되는 곳에서 생기는 감지 빈틈을 메운다.

   교훈

   논문은 AIOps 를 써도 적지 않은 장애가 여전히 사람의 감지나 판단을 거쳐야 했다고 밝혔다. 핫픽스는 정확성을 되찾지만 완화까지 걸리는 시간을 늘렸고, 과부하와 타임아웃 유형에서는 트래픽 라우팅과 노드 재조정이 더 빨리 완화했다. 그래서 헬스 프로브 기반 트래픽 라우팅, 재시작, 용량 증설 결정을 먼저 자동화해야 한다고 봤다. 대부분의 장애가 코드 변경이 아니라 운영 조치나 자가 복구로 끝났으므로 관측 가능성, 자동화, 잘 정해진 장애 대응 절차가 중요하다. HTTP 500 이 많았던 것은 엔진이 요청을 처리할 수 없는데도 요청을 라우팅하게 둔 모니터링 빈틈 때문이었다.

   사례 보기
5. IL-0247 쿠버네티스로 옮긴 검색 시스템 Manas 에서 요청 백만 건에 한 건이 평소보다 100배 느려졌다

   Pinterest2025

   증상

   2025년 초 쿠버네티스 플랫폼 PinCompute 로 옮긴 검색 시스템 Manas 의 시험 클러스터에 트래픽을 보내자, 적지만 꾸준한 비율의 요청이 타임아웃을 냈다.

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

   원인

   소프트웨어 결함

   구성 요소

   텔레메트리 에이전트리눅스 커널

   기여 요인

   기본 설정 방치

   감지

   이전을 검증하려고 시험 클러스터에 트래픽을 보내며 성능 시험을 하던 중, 적지만 꾸준한 비율의 요청이 타임아웃을 내는 것을 발견했다.

   조치

   • 한 줄 설정 변경으로 모든 PinCompute 노드에서 cAdvisor 의 작업 집합 크기 추정을 껐다. 같은 내용을 cAdvisor 저장소에 GitHub 이슈로 올렸다.

   교훈

   자원 격리는 까다롭다. CPU 격리를 해도 프로세스가 이웃 프로세스의 영향에서 완전히 벗어나지는 않는다. 문제 범위를 좁히는 일이 중요했다. PinCompute AMI 가 원인이 아님을 확인하자 범위가 좁아졌고, 소득 없는 조사를 많이 피할 수 있었다. 시스템이 제대로 동작하지 않게 될 때까지 하나씩 꺼 보는 단순한 블랙박스 디버깅도 효과가 있었다. 이것도 문제를 반씩 나눠 범위를 좁히는 방법의 하나다.

   사례 보기

원인별7