사례2건

2건 중 1~2번째

1. IL-0290 GitLab.com 의 Redis Sidekiq 클러스터에서 노드 여러 대가 메모리를 다 써 멈추고 쿼럼을 잃어, 웹과 Git 과 CI 전반에서 500 오류가 늘었다

   GitLab2026sev1

   증상

   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 의 메모리가 포화되자 엔지니어는 장애 한가운데서 가용성과 데이터 손실 사이의 어려운 선택을 해야 했다. 이 부분에는 안전장치와 설계 개선이 필요했다. 대시보드와 로그로 트래픽 급증을 먼저 배제한 덕분에 공용 의존성과 인프라 쪽 원인에 집중할 수 있었다. 대기열 비우기처럼 되돌릴 수 없는 선택을 미루고 안전한 완화부터 한 것도 도움이 됐다.

   사례 보기
2. IL-0291 GitLab.com 의 redis-sidekiq Sentinel 이 쿼럼을 만들지 못해 Sidekiq 이 30분 동안 멈추고 500 오류가 늘었다

   GitLab2023

   증상

   #production 채널에 Redis 클라이언트 오류 알림이 먼저 오고, 이어서 여러 서비스의 Error SLO 위반 알림이 잇따랐다. Sidekiq 작업을 쓰는 모든 서비스가 30분 동안 완전히 멈췄고 Web 과 API 요청에서도 500 오류가 늘었다.

   장애 조치 실패오류율 상승

   촉발

   primary 였던 redis-sidekiq-03-db-gprd 가 GCP 호스트 오류로 실패했고, 이 VM 은 리셋되어 다른 노드로 옮겨졌다.

   원인

   클라우드 제공자 장애

   구성 요소

   인메모리 캐시데이터베이스 장애 조치 관리자

   기여 요인

   단일 장애점모니터링 사각지대

   감지

   #production 채널에 여러 알림이 왔다. Redis 클라이언트 오류 알림부터 시작해 Webservice & API LoadBalancer 와 Puma 를 포함한 여러 서비스의 Error SLO 위반 알림으로 번졌다.

   조치

   • primary 를 뽑을 만큼 노드가 없다는 것을 확인한 뒤 실패한 노드를 재시작했다.

   후속 조치

   • Sentinel 서비스가 꺼지면 알림을 보낸다.
   • 머지 리퀘스트가 Redis Sidekiq 장애 뒤에 스스로 회복하도록 고친다.

   교훈

   꺼진 Sentinel 노드를 알림으로 잡았다면 장애 조치에 필요한 쿼럼을 만들 노드 수를 미리 확보해 이 장애를 아예 막을 수 있었다. 너무 시끄럽다는 이유로 알림을 지운 것이 꺼진 노드를 쿼럼 문제 전에 잡을 기회를 줄였을 수 있다. 복구가 몇 시간 길게 이어진 것은 머지 리퀘스트가 Redis Sidekiq 장애에서 스스로 회복하지 못했기 때문이다.

   사례 보기

원인별2