사례3건

3건 중 1~3번째

1. IL-0432 Memorystore for Redis 가 메모리 단편화로 쓰기를 거부해 AutoReserve 예약 알림 일부가 조용히 빠졌다

   Hello Inc.2026

   증상

   레스토랑 예약 서비스 AutoReserve 에서 예약 관련 알림 일부가 도착하지 않는다는 버그 보고가 들어왔다. 여러 종류의 알림 가운데 한 종류만 갔다 안 갔다 했고, 로그에는 정상으로 보이는 Notification already scheduled 가 찍혔다.

   쓰기 거부메모리 압박

   원인

   용량 한계

   구성 요소

   인메모리 캐시

   기여 요인

   모니터링 사각지대안전하지 않은 실패 동작미검증 가정

   감지

   AutoReserve 에서 예약 관련 알림 일부가 도착하지 않는다는 버그 보고가 들어왔다.

   조치

   • 메모리가 부족하다고 보고 Redis 인스턴스를 8GiB 에서 16GiB 로 늘렸지만, 쓰기 거부는 멈추지 않았다.
   • Redis 3.2 를 7.2 로 업그레이드했고, 그때 쓰기 거부가 멈췄다.
   • Redis 가 다시 쓰기를 거부해도 알림이 빠지지 않도록 보낸 상태를 Redis 가 아니라 RDB 에서 관리하게 바꿨다.

   후속 조치

   • 물리 메모리 사용량이 논리 메모리 사용량의 1.3배를 넘기 시작하면, Redis 를 멈추지 않고 단편화를 해소하는 active defrag 를 켜는 것을 검토한다.

   교훈

   보낸 상태를 판정하는 데 중요한 것은 속도가 아니라 값이 사라지지 않는 것과 여러 처리가 동시에 와도 결과가 하나로 정해지는 것이었다. 캐시는 사라져도 되살릴 수 있는 값을 두는 곳이고, 처음부터 쓰기가 실패할 수 있다고 보고 만든 것이다. 그러므로 값의 성질에 맞춰 둘 곳과 다루는 방식을 정해야 한다. 로그와 인스턴스 화면 메트릭처럼 겉으로 보이는 정보만으로는 원인을 잡지 못했고, Redis 안까지 들어가 봐야 했다.

   사례 보기
2. IL-0299 Wikimedia CirrusSearch 의 OpenSearch 클러스터에서 인덱스 약 60개가 red 상태가 되어 쓸 수 없었다

   Wikimedia Foundation2025

   증상

   2025-05-28 21:27 부터 CirrusStreamingUpdaterFlinkJobUnstable 알림이 울렸다. 검색 업데이트 파이프라인이 red 상태가 된 인덱스 약 60개에 쓰지 못하고 있었다.

   쓰기 거부

   촉발

   2025-05-28 21:08 에 폐기할 호스트 elastic/cirrussearch10[53-67] 의 클러스터 접근을 없애는 Puppet 패치가 머지됐다. 이 중 일부 호스트가 아직 primary 샤드를 가지고 있었다.

   원인

   설정 변경

   구성 요소

   Elasticsearch 와 OpenSearch

   기여 요인

   미검증 가정런북 부재미검증 백업

   감지

   사람이 발견했다. 2025-05-28 21:27 부터 CirrusStreamingUpdaterFlinkJobUnstable 알림이 울렸지만, 클러스터 유지보수 작업 때문에 다른 알림 다수가 억제돼 울리지 않았다. 엔지니어가 다음 날 07:24 에 조사를 시작했다.

   조치

   • 09:29 에 red 인덱스를 지워 클러스터를 green, 즉 쓸 수 있는 상태로 되돌렸다. 업데이트 파이프라인이 회복하기 시작했다.
   • 09:47 에 망가진 인덱스 복구를 시작했고 14:50 에 모든 인덱스가 돌아왔다.

   후속 조치

   • 운영 CirrusSearch 의 스냅샷 저장소를 다시 켠다.
   • 운영 대응에 맞춘 OpenSearch 대시보드를 만든다.
   • Search Platform 이 맡은 OpenSearch 클러스터의 Logstash 파이프라인을 확인하고 고친다.

   교훈

   노드 ban 은 성공을 보장하지 않는 동작이라 기대대로 되지 않았다. 같은 종류의 서버를 한꺼번에 여러 대 폐기하는 큰 작업에 유지보수 계획이나 런북이 없었다. 스냅샷과 대시보드, 로깅 같은 중요한 도구를 쓸 수 없거나 문서가 모자랐다. 데이터센터가 depool 돼 있던 덕분에 사용자 영향이 없었다.

   사례 보기
3. IL-0241 데이터베이스 shard 하나가 primary 를 뽑지 못해 Stripe API 요청 대부분이 두 차례 실패했다

   Stripe2019

   증상

   2019년 7월 10일 16:35 UTC 에 데이터베이스 클러스터의 primary 노드가 고장 났고, 1분 뒤 자동 모니터링이 선출 실패를 잡아 알림을 보냈다. Stripe API 요청 대부분이 실패하기 시작했다.

   오류율 상승장애 조치 실패쓰기 거부간헐적 타임아웃노드 CPU 고부하

   촉발

   16:35 UTC 에 데이터베이스 클러스터의 primary 노드가 고장 났다. 그 shard 에는 멈춘 노드가 여럿 있어 석 달 전 마이너 버전 업그레이드로 들어온 장애 조치 결함이 드러났다. 두 번째 장애는 선출 프로토콜을 이전 마이너 버전으로 되돌린 변경 때문에 일어났다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스데이터베이스 장애 조치 관리자

   기여 요인

   늦게 드러난 변경모니터링 사각지대과도한 영향 범위수동 조치 악화미검증 가정장애 중첩

   감지

   첫 장애는 자동 모니터링이 1분 안에 선출 실패를 잡았고, 16:36 UTC 에 팀이 알림을 받아 대응을 시작했다. 두 번째 장애는 21:14 UTC 에 클러스터의 shard 몇 개를 사용할 수 없다는 자동 알림으로 알았다.

   조치

   • 17:00 UTC 에 데이터베이스 클러스터의 모든 노드를 재시작해 새 primary 선출을 성공시켰다. 17:02 에 Stripe API 가 완전히 복구됐다.
   • 22:34 UTC 에 운영 설정을 고쳐 새로 배포하고 데이터베이스 클러스터의 노드를 재시작해 영향받은 shard 를 되살렸다.
   • 클러스터가 정상인지 확인한 뒤 사용자가 직접 보낸 API 요청에 필요한 서비스부터 트래픽을 다시 올렸다. 22:47 UTC 에 완전히 복구됐다.

   후속 조치

   • 노드가 복제 지연 지표를 보내지 않으면 알리는 모니터링을 더했다.
   • shard 가 데이터베이스 장애 조치 시스템의 이 선출 결함을 일으킬 수 있는 상태에 들어가면 알리는 모니터링을 더했다.
   • 이 결함을 고치는 수정을 데이터베이스 메인테이너와 함께 만든다.
   • 특정 클러스터로 가는 작업이 실패하면 끊어 내는 서킷 브레이커를 더 넣는다. 이번 사고의 클러스터도 대상이다.
   • shard 하나가 고장 나도 그 영향을 가두는 장애 격리 기법을 더 도입한다.
   • 실패한 요청을 거듭 재시도하는 클라이언트가 쓰는 자원을 제한한다.
   • 장애 대응 중 운영자가 설정을 빠르게 바꿀 때 더 안전하게 할 수 있도록 절차와 도구를 더 만든다.

   사례 보기

원인별3