사례6건

6건 중 1~5번째

1. 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 로 가는 전송 급증도 경보 대상이다. 재시도, 캐시 채우기, 연결 생성에 한도가 없으면 장애가 커진다. 과부하 패턴은 운영 트래픽에서만 드러났으므로 부하 시험이 필요하고, 중요한 설정은 배포 없이 바꿀 수 있어야 한다.

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

   사례 보기
3. IL-0324 External Storage 데이터베이스 클러스터에 과부하가 걸려 mw-api-int, mw-parsoid, mw-jobrunner 의 지연과 데이터베이스 오류가 늘었다

   Wikimedia Foundation2025

   증상

   2025-03-12 10:58 UTC 부터 백엔드 응답 시간이 높다는 알림이 들어왔다. 3월 12일과 13일 이틀 동안 mw-api-int, mw-parsoid, mw-jobrunner 에서 지연이 커지고 데이터베이스 오류가 늘었다. External Storage 클러스터의 부하와 연결 수도 크게 늘었다.

   데이터베이스 과부하지연 시간 증가오류율 상승로그 폭증모니터링 중단

   촉발

   mw-api-int, mw-parsoid, mw-jobrunner 를 PHP 8.1 로 옮기는 예정된 Scap 배포가 장애를 일으켰다. 3월 12일 10:44 UTC 에 1126607[puppet] 과 1126650 [deployment-charts] 를, 3월 13일 11:15 UTC 에 1127476[puppet] 과 1127478[deployment-charts] 를 배포했다.

   원인

   배포 결함

   구성 요소

   데이터베이스인메모리 캐시컨피그맵과 시크릿HelmCI 시스템

   기여 요인

   미검증 가정데워진 캐시에 기댄 구조잡음에 묻힌 신호

   감지

   3월 12일 10:58 UTC 에 백엔드 응답 시간이 높다는 알림이 들어오기 시작했다. 처음 세운 가설은 특정 네트워크나 클라이언트의 많은 트래픽, 잘못 실행된 예약 작업, 자원을 많이 먹는 changeprop-jobqueue 작업이었다. 원인을 가리켰을 MediaWikiMemcachedHighErrorRate 알림은 logstash-prometheus 파이프라인이 밀려 빠지거나 곧바로 회복됐다. 장애 중에는 알림 78개가 울리고 있어서, 그 알림이 울렸더라도 부수 증상으로 보고 넘겼을 가능성이 컸다.

   조치

   • 3월 12일 13:19 UTC 에 cirrus-streaming-updater 의 SUP 병렬도를 낮추는 패치 1126988[deployment-charts] 를 배포했다.
   • 13:33 에 1127000[deployment-charts] 로 changeprop-jobqueue 의 categoryMembershipChange 작업 동시성을 낮췄다.
   • 13:44 에 1126607[puppet] 과 1126650 [deployment-charts] 를 되돌리고 Scap 을 다시 돌렸다.
   • 3월 13일 11:34 UTC 에 changeprop-jobqueue 를 롤링 재시작했다.
   • 11:43 에 mw-api-int 를 롤링 재시작했다.
   • 11:44 에 1127500[deployment-charts] 로 changeprop-jobqueue 의 categorymembership 작업을 껐다.
   • 11:46 에 1127476[puppet] 과 1127478[deployment-charts] 를 되돌렸다.
   • 11:58 에 되돌린 내용을 반영하려고 mw-api-int 를 다시 배포했다.
   • 12:07 에 mw-api-int 의 레플리카 수를 늘렸다.
   • 12:28 에 되돌린 내용을 반영하려고 mw-jobrunner 를 다시 배포했다.
   • 14:06 에 되돌린 내용을 반영하려고 mw-parsoid 를 다시 배포했다.

   후속 조치

   • 장애 때 channel:Memcached 로 보내는 메시지 양을 줄인다.
   • Scap 에 helm 롤백 기능을 넣는다.
   • -Dbuild_mw_container_image:False 로 실행할 때도 Scap 이 helmfile-defaults 를 갱신해야 하는지 검토한다.
   • MediaWiki 이미지에서 envvars.inc 를 뺄지 검토한다.
   • 서로 관련된 구성 요소를 한꺼번에 보여 주고 따라갈 링크를 담은 "Why" 대시보드를 만들지 검토한다.
   • 장애 대응 조율을 개선한다. 누가 무엇을 맡았는지, 누가 대응에 들어오고 나갔는지 장애 조율자가 알 수 있어야 한다. 또 맥락 없는 의견과 대응과 관계없는 논의로 채널이 시끄러워지지 않아야 한다.
   • 장애 중에 MediaWiki 개발자와 연락해 개발자의 관점을 바로 들을 수 있게 한다.

   교훈

   Wikimedia 는 기술적 원인보다, 3월 12일 장애 때부터 MediaWiki 배포 세 곳이 Memcached 클러스터에 닿지 못하고 있다는 것을 알아채지 못한 이유가 더 중요하다고 봤다. 알림에 연결된 대시보드는 무엇이 일어나는지만 보여 줬다. Wikimedia 는 서로 의존하거나 영향을 주는 구성 요소를 함께 보여 주는 대시보드가 있었다면 달랐을 것이라고 적었다. 예를 들어 SQLBlobStore 키는 External Storage 와 바로 이어져 있다. 원인을 가리킬 알림은 곧바로 회복됐다. 그 알림이 울렸더라도 알림 78개 사이에서는 부수 증상으로 봤을 수 있었다. 응답자가 많았지만 누가 무엇을 하는지, 누가 대응에 들어오고 나갔는지 분명하지 않아 장애 조율자가 조율하기 어려웠다. 외부 사용자 영향을 제대로 가늠하지 못해 실제보다 심각하게 여겼다. trace.wikimedia.org 도 장애 중에 쓰지 않았다.

   사례 보기
4. IL-0202 갑자기 몰린 쿼리와 데이터베이스 쓰기로 Honeycomb 수집 호스트가 메모리 부족으로 죽었고, 쿠버네티스 CrashLoopBackOff 가 용량 회복을 막아 US1 이벤트 수집이 한 시간 넘게 불안정했다

   Honeycomb2023sev1

   증상

   02:15 UTC 무렵부터 API 수집 엔드포인트의 이벤트 처리가 느려졌다. 실패는 났다가 멎기를 되풀이했고, 끝내 몇 분 동안 수집이 완전히 멈췄다. 기본으로 걸어 둔 알림이 수집 성능과 안정성 문제를 온콜 엔지니어에게 알렸다. 상태 페이지 첫 공지는 수집 서비스의 오류율과 응답 시간이 평소보다 높다는 알림을 조사하고 있다는 내용이었다.

   오류율 상승지연 시간 증가컨테이너 재시작 반복서비스 중단데이터베이스 과부하

   촉발

   몇 분 사이에 여러 곳에 흩어진 연결에서 비정상적으로 많은 쿼리가 들어왔다.

   원인

   용량 한계

   구성 요소

   데이터베이스인메모리 캐시

   기여 요인

   재시도 폭주자동화 증폭

   감지

   기본으로 걸어 둔 알림이 수집 성능과 안정성 문제를 온콜 엔지니어에게 알렸다. 자동 로드 셰딩 장치도 작동하면서 알림을 더 보냈다. 상태 페이지 첫 공지는 18:28 PST 에 올라왔다.

   조치

   • 엔지니어들이 용량을 확보하려고 수집 호스트 수를 수동으로 크게 늘렸다.
   • 몇 분 동안 수집 트래픽 대부분을 끊고 수집 호스트 용량을 다시 확보했다.
   • 가장 공격적으로 트래픽을 보내던 발신처의 속도 제한을 트래픽이 가라앉을 때까지 임시로 낮춰 클러스터를 안정시켰다.

   후속 조치

   • 장기 해결책을 마련하는 동안 같은 장애가 반복되지 않도록 수집 호스트 수를 늘려 두었다.
   • 이번 장애 경로를 막을 프로젝트를 정하는 일에 집중한다.

   교훈

   Honeycomb 은 이번 장애를 이미 대비책이 있던 장애의 변형으로 보았다. 이번 장애는 그 대비책 일부를 비켜 가는 방식으로 일어났다. 실패했던 호스트들이 쿠버네티스의 CrashLoopBackOff 상태에 걸려 오프라인으로 남으면서 급하게 늘린 용량을 깎아 먹었다. OTel 처럼 배치 단위로 성공과 실패를 알리는 프로토콜에서는 서버가 일부만 버려도 클라이언트가 배치 전체를 다시 보내 트래픽이 크게 불어날 수 있다.

   사례 보기
5. IL-0206 GKE 파드 안의 Consul 에이전트가 메모리 급증으로 거듭 OOM kill 되어 Rails 파드가 데이터베이스 복제본을 찾지 못했고, 모든 쿼리가 primary 로 몰려 GitLab.com 이 느려졌다.

   GitLab2022

   증상

   2022-04-25 15:13 UTC 에 engwan 이 Slack 에서 Sidekiq Apdex 하락으로 장애를 선언했다. Apdex 는 목표 시간 안에 끝난 작업의 비율로 만족도를 나타내는 지표다. 사용자는 사이트가 간헐적으로 느려지는 것을 겪었고, 파이프라인 생성이나 가져오기와 내보내기 같은 비동기 작업이 평소보다 오래 걸렸다.

   지연 시간 증가데이터베이스 과부하OOMKilled오류율 상승

   촉발

   GKE 파드 안의 Consul 에이전트가 특정 상황에서 메모리를 갑자기 많이 요구했고, 쓸 수 있는 메모리가 없어 Consul 프로세스가 죽었다. 당시 파드 메모리 한도는 500MB 였다.

   원인

   용량 한계

   구성 요소

   컨테이너 메모리 한도서비스 디스커버리데이터베이스

   기여 요인

   –

   감지

   2022-04-25 15:13 UTC 에 engwan 이 Slack 에서 Sidekiq Apdex 하락으로 장애를 선언했다. 다음 날 01:21 UTC 에는 모니터링이 오류율 상승을 잡았고, 01:26 에 cindy 가 장애를 다시 선언했다.

   조치

   • 16:13 에 gitlab 데이터베이스 사용자의 연결 한도를 올리고 main pgbouncer 의 백엔드 풀을 늘리는 방안을 세웠고, 17:26 에 msmiley 가 변경을 적용해 17:47 에 적용을 확인했다.
   • 임시 조치로 파드 메모리 한도를 500MB 에서 1GB 로 올려 Consul 에이전트가 메모리 급증 때도 계속 돌 수 있게 했다.

   후속 조치

   • 메모리 한도를 1GB 로 올린 것으로 충분한지 GKE 파드의 Consul 에이전트를 지켜본다.
   • Consul 의 메모리 수요 급증을 조사해 하드 메모리 한도를 올리는 것 말고 개선할 방법이 있는지 찾는다.

   교훈

   파드 안에서 함께 도는 Consul 에이전트의 메모리 한도가 모자라자 서비스 디스커버리가 끊겼고, 그 영향이 데이터베이스 primary 포화와 사이트 전체의 지연으로 번졌다. 처음 의심한 pgbouncer 풀 변경과 다음 날 별개로 보였던 오류율 상승이 모두 같은 원인으로 이어졌다. 메모리 한도를 올린 것은 임시 조치였고, Consul 의 메모리 급증이 정상 동작인지 GitLab 설정 탓인지는 아직 조사해야 했다.

   사례 보기

원인별3