그래프
사례2건
2건 중 1~2번째
IL-0290GitLab.com 의 Redis Sidekiq 클러스터에서 노드 여러 대가 메모리를 다 써 멈추고 쿼럼을 잃어, 웹과 Git 과 CI 전반에서 500 오류가 늘었다- 증상
2026-05-12 17:15 UTC 에 Prometheus Alertmanager 알림으로 장애가 접수됐다. 플랫폼 대시보드에서 web, Git, API, CI 러너, Sidekiq 의 오류율이 한꺼번에 올랐고, 사용자는 잦은 500 오류와 인증 실패, CI 파이프라인 실패를 겪었다.
- 촉발
같은 날 앞선 장애 inc-10084 를 완화하려고 감사 이벤트 작업을 지연 처리로 돌려 두었고, 지연된 작업이 Redis Sidekiq 클러스터에 쌓였다.
- 원인
- 구성 요소
- 기여 요인
- 감지
17:12 UTC 에 영향이 시작됐고 17:15:10 UTC 에 Prometheus Alertmanager 알림이 incident.io 에 장애를 트리아지 상태로 올렸다. 온콜이 17:16:59 UTC 에 Severity 2 로 받아들였고 17:32:49 UTC 에 Severity 1 로 올렸다. redis-sidekiq 메모리 알림은 온콜을 호출하지 않았고, 다른 신호들도 라벨과 라우팅의 틈 때문에 맞는 온콜에게 제대로 닿지 않았다.
- 조치
- 응답하지 않는 Redis 노드 두 대를 골라 재시작하고 강제로 리셋했다. 18:00 UTC 에 세 노드가 모두 올라왔고 O2 가 primary 가 됐다.
- Redis VM 을 한 대씩 멈추고 메모리와 CPU 를 두 배로 늘린 c2-standard-16 머신 타입으로 바꿨다. 18:40 UTC 에 세 노드의 교체가 끝났다.
- AuditEventStreamingWorker 를 다시 켜고 더는 지연 처리로 돌리지 않았다. 앞서 지연시킨 탓인지 이 워커의 대기열이 계속 늘어 지켜봤다.
- 후속 조치
- redis-sidekiq 메모리 알림이 왜 온콜을 호출하지 않았는지 조사한다.
- WebHookWorker poison pill 문제의 근본 원인과 실패 양상, 해결 진행 상황을 정리한다.
- 안전 한도를 끄는 완화 조치에는 담당자와 재검토 기한을 분명히 정하도록 절차를 고친다.
- AuditEvents::AuditEventStreamingWorker 가 장애를 되풀이해 일으키지 않도록 고친다.
- AuditEventStreamingWorker 의 런북을 만든다.
- PG 연결 풀 포화 문제를 후속 작업으로 다룬다.
- 교훈
web, Git, 인증, CI 러너, Sidekiq, 내부 API 가 한꺼번에 나빠져 원인 하나로 좁히고 그것을 짧게 전하기가 어려웠다. created 상태에 멈춘 파이프라인처럼 고객이 겪는 증상을 실시간으로 세고 확인할 방법이 부족했고, 관련 대시보드와 SLI 를 온콜이 찾기 어려웠다. 호스트가 응답하지 않아 SSH 로그인이 멈추면서 진단이 늦어지고 변경할 때의 위험도 커졌다. 신호가 있어도 라벨과 라우팅의 틈 때문에 맞는 온콜에게 닿지 않았다. redis-sidekiq 의 메모리가 포화되자 엔지니어는 장애 한가운데서 가용성과 데이터 손실 사이의 어려운 선택을 해야 했다. 이 부분에는 안전장치와 설계 개선이 필요했다. 대시보드와 로그로 트래픽 급증을 먼저 배제한 덕분에 공용 의존성과 인프라 쪽 원인에 집중할 수 있었다. 대기열 비우기처럼 되돌릴 수 없는 선택을 미루고 안전한 완화부터 한 것도 도움이 됐다.
IL-0333사양을 낮춘 RDS PostgreSQL 인스턴스가 피크 부하를 못 버텨 헬스 체크가 실패하고 Buildkite 대시보드가 몇 시간 동안 내려갔다Buildkite2016- 증상
2016년 8월 22일 17:21 UTC 부터 buildkite.com 에 아무도 로그인하지 못했고 빌드 로그와 문서도 볼 수 없었다. 빌드는 계속 돌았고 GitHub 와 Bitbucket 의 Pull Request 상태도 계속 갱신됐다.
- 촉발
AWS 크레딧이 곧 떨어질 상황이라 비용을 줄이려고, 주말 유지 보수 시간에 m4.10xlarge Multi-AZ RDS PostgreSQL 데이터베이스를 r3.2xlarge 로 낮췄다. 연결 하나당 메모리를 줄이려고 중앙 pgbouncer 로도 옮겼다. 월요일 미국 피크 시간에 이 데이터베이스가 부하를 버티지 못했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
New Relic, Pingdom, Datadog, Calibre, CloudWatch 가 문제를 감지하면 PagerDuty 알림이 온콜 개발자에게 전화를 건다. 하지만 온콜 담당자의 PagerDuty 설정에서 "Immediately phone me" 규칙이 빠져 소리 없는 푸시 알림만 갔다. 에스컬레이션을 받을 다른 팀원들은 휴대폰을 무음으로 두어 아무도 깨지 않았다. 팀은 21:00 UTC 에 깨어 이메일, 트윗, Slack 메시지로 장애를 알았다.
- 조치
- Agent API 서버 일부를 빼서 대시보드 요청을 받는 ELB 에 연결해 buildkite.com 을 다시 올렸다. 데이터베이스가 여전히 부하에 눌려 있어 요청은 느렸다.
- EC2 요청 한도에 걸린 뒤 Auto Scaling Group 의 헬스 체크를 EC2 헬스 체크로 바꾸고 원하는 서버 수를 고정했다.
- AWS Console 이 여전히 문제가 있어 aws-cli 로 데이터베이스를 부하를 감당할 수 있는 인스턴스 유형으로 올렸다.
- https://buildkite.com/_secret/version 을 참조하지 않는 새 AMI 를 만들고, 스스로 배포하는 문제를 고친 새 서버를 aws-cli 로 내보냈다.
- 중앙 pgbouncer 서버를 없애고, 잘 동작하던 이전 구성대로 호스트마다 pgbouncer 를 다시 두었다.
- 후속 조치
- 다른 사용자에게 영향을 주지 않고 큰 인프라 변경 뒤 부하 시험을 하는 방법을 계획한다.
- 헬스 체크가 애플리케이션에 닿기만 하면 "OK" 를 내도록 바꿨다. 이 요청에서는 더 이상 데이터베이스 연결을 확인하지 않는다.
- 애플리케이션이 데이터베이스와 의존 서비스에 접속되는지 확인하는 헬스 체크 엔드포인트를 따로 두고 Pingdom 이 호출하게 하는 방안을 검토한다.
- 최근 배포된 리비전을 S3 의 파일에 저장하고, 새로 뜬 서버가 스스로 배포할 때 그 파일을 참조하게 바꿨다.
- 팀원 모두가 PagerDuty 전화가 실제로 오는지 수동으로 시험했다.
- 모든 팀원의 설정이 맞는지 정기적으로 확인하는 회사 전체 시험을 할 수 있는지 알아본다.
- 팀원이 온콜에 들어갈 때 PagerDuty 가 전화를 걸게 하거나, 모든 Notification Rules 에 "Immediately phone" 규칙을 두도록 요구하는 방안을 PagerDuty 에 문의한다.
- 교훈
AWS 크레딧을 미리 지켜봐야 짧은 기간에 큰 인프라 변경을 서두르지 않는다. 크레딧을 쓰는 동안 AWS Billing Reports 는 0달러 청구서를 보여 줘서 실제 비용을 알기 어렵다. 큰 인프라 변경 뒤에는 부하 시험을 해야 한다. 헬스 체크가 실제로 무엇을 확인해야 하는지 다시 생각해야 한다. 의존하는 서버에 모두 접속되는지 확인하던 헬스 체크는 ELB 의 모든 서버가 실패할 때 어떻게 되는지 고려하지 않았다. 새 서버가 배포할 리비전을 자기 서비스에 물어보는 방식은 쓰면 안 된다. 온콜에 들어가기 전에 모든 팀원의 PagerDuty 와 iPhone 설정이 맞는지 확인해야 한다. AWS 에서 서버가 계속 떴다 내려가면 헬스 체크와 오토스케일링 규칙을 멈춰 EC2 요청 한도에 걸리지 않게 해야 한다. 팀은 사후 분석을 쓰면서 AWS 에서 Auto Scaling 프로세스를 일시 중지하고 재개할 수 있다는 것을 알았다.
이 2건에서 가장 많이 나오는 구성 요소: 인메모리 캐시, 클라우드 로드 밸런서. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.