사례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-0261 GCP 네트워크가 잠깐씩 끊기면서 Discord sessions 클러스터 노드가 연달아 망가지고 서비스 전체가 두 번 멈췄다

   Discord2017

   증상

   2017년 11월 17일 PST 11시 52분에 엔지니어들이 서비스 영향을 알아채고 사고 채팅방에 올렸다. 이어서 sessions 클러스터의 다른 노드들에서 메모리 부족 알림이 차례로 울렸다.

   네트워크 도달 불가메모리 압박서비스 중단

   촉발

   Google 이 Google Cloud Platform 네트워크 스택에 내보낸 업그레이드가 Discord VM 의 네트워크 연결을 짧게 여러 번 끊었다. 네트워크를 많이 쓰는 sessions 클러스터 노드에서만 16번 일어났다.

   원인

   클라우드 제공자 장애

   구성 요소

   서비스 디스커버리

   기여 요인

   디버그 접근 제한수동 조치 악화

   감지

   17일 11시 52분에 엔지니어들이 서비스 영향을 알아채고 사고 채팅방에 올렸다. 그 뒤로는 sessions 노드의 메모리 부족 알림으로 당번 엔지니어가 호출됐다. 18일에는 11시 38분 네트워크 문제로 당번 엔지니어가 호출됐고, 11시 40분에 고객 경험 팀이 지원 채널의 신고를 올렸다.

   조치

   • 12시 14분 sessions-1-9 를 안전하게 빼는 절차가 실패하자 노드를 강제로 종료했다. 같은 증상이 난 다른 sessions 노드도 강제로 종료했다.
   • 12시 42분 Google 지원 티켓을 가장 높은 등급인 P1 로 올리고 기술 담당 매니저에게 알렸다.
   • 14시 21분 Discord 의 핵심 서비스 여러 개를 재시작했다. 이 작업으로 연결된 클라이언트 수백만 대가 약 20분에 걸쳐 다시 연결됐다.
   • 17일 밤 강제 종료하고 재부팅한 노드가 다시 망가지지 않는 것을 보고 sessions 클러스터 전체를 종료하고 재부팅하기 시작했다.
   • 18일 12시 4분 서비스 복구를 도우려고 전 세계에서 메시지 전송을 껐다.
   • 18일 12시 4분 sessions 클러스터의 모든 멤버를 재시작했다.
   • 18일 12시 31분 첫 정상화를 알리고 메시지 전송을 다시 켰다.
   • Google 이 금요일에 네트워크 스택에 넣은 소프트웨어 변경을 18일 13시 30분 무렵부터 롤백했고, 15시 30분쯤 롤백이 끝났다.

   후속 조치

   • Discord 를 재부팅해야 했던 이전 장애에서 Erlang 클러스터가 노드 장애를 다루는 방식의 문제를 찾았다. 그 문제를 고치는 프로젝트를 이어 간다.
   • 그 개선을 안전하게 내보낼 수 있도록 이 서비스들의 업그레이드 부하 테스트 방식을 넓힌다.
   • Elixir 와 Erlang 서비스에서 쓰는 HTTP 라이브러리를 바꾼다.
   • Erlang 의 net_kernel 구성 요소에서 본 불안정을 재현했고 수정을 넣었다.
   • 장애 동안 성능이 떨어진 서비스 디스커버리 구성 요소의 일부를 더 성능이 좋은 구현으로 바꾼다.
   • 이번 장애를 Google 과 같이 처리하며 겪은 문제들을 Google 과 함께 고쳐 나간다.
   • P1 문제의 진행 상황을 제대로 추적하도록 Google 과 소통하는 내부 절차를 넓혔다.

   교훈

   Discord 는 두 번의 큰 장애가 그만큼 커진 데에는 Discord 시스템의 성능과 안정성 문제가 크게 작용했다고 봤다. 이런 형태의 네트워크 장애가 서비스의 연쇄 장애를 일으킬 수 있었기 때문이다. 일부 사용자에게만 머물렀어야 할 문제가 시스템 전체 장애 두 번으로 번진 데에는 여러 문제가 있었고, Discord 는 후속 조치로 그 문제 대부분을 풀 수 있다고 봤다.

   사례 보기

원인별2