Incident Library
적용된 필터 원인용량 한계증상쓰기 거부기여 요인미검증 가정모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례1건

1건 중 1~1번째

  1. 증상

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

    원인
    구성 요소
    기여 요인
    감지

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

    조치
    • 메모리가 부족하다고 보고 Redis 인스턴스를 8GiB 에서 16GiB 로 늘렸지만, 쓰기 거부는 멈추지 않았다.
    • Redis 3.2 를 7.2 로 업그레이드했고, 그때 쓰기 거부가 멈췄다.
    • Redis 가 다시 쓰기를 거부해도 알림이 빠지지 않도록 보낸 상태를 Redis 가 아니라 RDB 에서 관리하게 바꿨다.
    후속 조치
    • 물리 메모리 사용량이 논리 메모리 사용량의 1.3배를 넘기 시작하면, Redis 를 멈추지 않고 단편화를 해소하는 active defrag 를 켜는 것을 검토한다.
    교훈

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

내 클러스터에도 있는지 확인하기

이 사례에서 가장 많이 나오는 구성 요소: 인메모리 캐시. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별1