사례6건

6건 중 3~6번째

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-0435 Aurora MySQL 이 OOM 을 피하려고 커넥션을 끊고 쿼리를 거부해 애플리케이션 오류율이 올랐다

   CyberAgent2026

   증상

   어느 날 갑자기 애플리케이션 오류율이 나빠졌다는 알림이 울렸다. 그 시간대 Aurora MySQL RDS 인스턴스의 오류 로그에는, Aurora MySQL 이 메모리 부족으로 OOM 이 나는 것을 피하려고 커넥션을 끊고 쿼리를 거부한 기록이 남아 있었다.

   오류율 상승메모리 압박

   촉발

   FreeableMemory 가 내려가기 시작한 날의 애플리케이션 릴리스에서 쿠버네티스 CronJob 으로 매분 도는 배치 처리가 더해졌다.

   원인

   용량 한계

   구성 요소

   데이터베이스잡과 크론잡

   기여 요인

   기본 설정 방치늦게 드러난 변경

   감지

   애플리케이션 오류율이 나빠졌다는 알림이 울렸다.

   조치

   • Aurora MySQL 파라미터 그룹에서 Performance Schema 를 자동 관리를 뜻하는 0 에서 수동 관리를 뜻하는 1 로 바꾸고, 기본값 -1 로 무제한이던 관련 파라미터 두 개에 상한 100 을 두었다. 적용에는 RDS 인스턴스 재시작이 필요했고, 이 조치로 FreeableMemory 감소와 SwapUsage 발생이 멈췄다.

   교훈

   시스템 알림이 울렸는데 DB 부하 지표가 조용하면 Performance Schema 가 불어난 것도 의심해야 한다. 상한을 둔 두 파라미터는 기본값이 무제한이라 이번처럼 기록이 계속 쌓였다. 상한을 두면 퍼포먼스 인사이트의 호스트별 집계에서 상한을 넘은 호스트의 정보가 빠지는 단점이 있다. 애플리케이션과 Aurora MySQL 사이에 RDS Proxy 를 두어 DB 에 접속하는 HOST 를 일정하게 유지하는 방법도 있다.

   사례 보기
3. IL-0453 하쿠나의 API latency 가 매일 ElastiCache Redis 백업 시간마다 치솟았다

   Hyperconnect2022

   증상

   하쿠나 서비스의 API latency 가 특정 시간에 주기적으로 치솟았다. APM 의 Dependency 별 Latency 분석에서 병목은 Redis 였다.

   지연 시간 증가메모리 압박

   촉발

   가용 메모리가 부족한 상태에서, 하루 한 번 primary 노드에서 도는 ElastiCache 백업이 forkless 방식으로 실행됐다.

   원인

   용량 한계

   구성 요소

   인메모리 캐시데이터베이스 백업과 스냅숏

   기여 요인

   한계 경보 부재

   감지

   특정 시간에 주기적으로 치솟는 API latency 를 그래프에서 보았고, APM 의 Dependency 별 Latency 분석으로 병목이 Redis 임을 알아냈다.

   조치

   • ElastiCache 백업을 primary 노드가 아니라 secondary 노드에서 실행하도록 바꿨다.
   • TTL 없이 저장되던 데이터에 TTL 을 걸어 저장하도록 코드를 고쳤다.
   • Redis Hash CrudRepository 를 쓰던 곳을 RedisTemplate 으로 다시 구현한 CustomRepository 로 바꿨다.
   • 이미 쌓여 있던 필요 없는 데이터를 지우는 스크립트를 실행했다.

   교훈

   백엔드 팀은 Redis 운영과 모니터링에 미흡한 부분이 있었다고 돌아봤다. 데이터 사이에 관계가 있거나 값으로 검색해야 하면 관계형 데이터베이스를 쓰고, 영속성이 필요한 데이터는 되도록 Redis 가 아닌 on-disk 기반 저장소에 둔다. ElastiCache Snapshot 을 만들어야 하면 가용 메모리를 50% 이상으로 유지한다. DEL collection 처럼 O(n) 인 명령 때문에 운영 Redis 가 멈추지 않게 조심한다. 애플리케이션과 데이터베이스 사이에 불필요한 I/O 가 없는지도 주기적으로 확인한다. Spring Data Redis Repository 는 secondary index 를 프레임워크가 관리해 주므로, TTL 이 필요 없고 쿼리 성능이 많이 요구되는 업무에서는 좋은 선택지가 될 수 있다.

   사례 보기
4. IL-0382 Newark 와 Atlanta 의 Linode Object Storage 가 느려지고 모든 클라이언트에 503 - Slow Down 으로 응답했다

   Linode2022

   증상

   10월 19일과 20일 Newark 와 Atlanta 데이터 센터의 Linode Object Storage 에서 성능과 가용성이 떨어졌다. 고객은 “503 - Slow Down” HTTP 응답 코드로 나타나는 속도 제한을 더 많이 받았다.

   오류율 상승메모리 압박

   촉발

   10월 19일과 20일 Newark 와 Atlanta 의 Object Storage 클러스터로 요청 수와 처리량이 모두 아주 높은 트래픽이 들어왔다.

   원인

   용량 한계

   구성 요소

   오브젝트 스토리지

   기여 요인

   미패치 알려진 버그과도한 영향 범위

   조치

   • Object Storage 클러스터 경계의 속도 제한을 고쳐 공개한 한도인 버킷당 초당 750 요청을 정확히 지키게 했다. 이전에는 클라이언트가 이 값보다 훨씬 많은 I/O 를 할 수 있었다.
   • 일부 내부 Object Storage 인프라에서 메모리를 지나치게 쓰게 하던 Ceph 버그를 해결하고, 하드웨어나 네트워크 고장 뒤 클러스터 복구 같은 스토리지 압박 상황에서 메모리가 폭주하지 않게 설정 값을 조정했다.
   • 자원 경합을 겪던 내부 Object Storage 구성 요소를 덜 붐비고 더 안정적이며 성능이 더 높은 인프라로 옮겼다.
   • 내부 Object Storage 구성 요소와 백엔드 클러스터의 성능 설정 값 몇 개를 조정해 고객을 너무 일찍 속도 제한하지 않게 했다.

   후속 조치

   • 처리량 제한을 더 세밀하게 만든다.
   • 부하를 더 효율적으로 나누도록 내부 Object Storage 인프라를 키운다.
   • 내부 Object Storage 인프라의 하드웨어 성능을 더 높일 방법을 찾는다.
   • 클러스터에 부하가 한곳에 몰리지 않도록 부하 분산 알고리즘을 다듬는다.

   교훈

   백엔드 속도 제한은 한번 걸리면 공개한 한도를 넘지 않은 클라이언트까지 모든 클라이언트에 영향을 준다. Linode 는 버킷당 프런트엔드 속도 제한이 뜻한 대로 동작한다면 클라이언트를 가리지 않는 이런 백엔드 제한은 아예 걸리지 않아야 한다고 봤고, 그래서 백엔드 설정 값을 바꿨다.

   사례 보기

원인별1