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

사례2건

2건 중 1~2번째

  1. 증상

    Oregon 리전에 배포한 일부 웹 서비스와 정적 사이트가 간헐적으로 404 응답을 냈다. 장애 동안 이 클러스터들에 새로 만든 서비스는 모두 404 를 받았다.

    촉발

    2025-11-05 에 코드에서 더는 참조하지 않는 기능 플래그를 시스템에서 정리했다. 이 플래그에 아직 기대던 메타데이터 서비스가 효율이 낮은 옛 데이터 전송 방식으로 돌아갔다.

    원인
    구성 요소
    기여 요인
    조치
    • 메타데이터 서비스가 쓸 수 있는 메모리를 늘렸다. 이 조치는 나중에 되돌렸다.
    • 라우팅 서비스와 메타데이터 서비스 사이에 효율적인 데이터 전송을 쓰도록 기능 플래그를 잠시 다시 켰다. 이 플래그는 나중에 지웠다.
    • 메타데이터 서비스가 더는 기능 플래그에 기대지 않도록 다시 배포했다.
    후속 조치
    • 메타데이터 서비스의 모니터링을 보강해 이번과 같은 방식의 장애가 나면 알림이 오게 했다.
    • 아직 서비스가 값을 읽고 있는 기능 플래그는 지울 수 없도록 기능 플래그 관리 관행을 고친다.
    • 메타데이터 서비스에서 상태를 한 번도 받아 오지 못한 라우팅 서비스 인스턴스에는 트래픽이 가지 않게 한다.
  2. 증상

    특정 시점 복구 기능인 PITR 을 켠 Render Postgres 데이터베이스에 새 연결을 맺으면, PITR 백업 작업이 도는 동안 50% 확률로 실패했다. 커넥션 풀링처럼 이미 맺어 둔 연결은 영향이 없었다.

    촉발

    Render 는 2023년 4월 21일 Point-in-time Recovery 기능을 조건이 맞는 새 데이터베이스에 내놨다. 이 기능의 백업 작업은 데이터베이스와 비슷한 네트워크 레이블로 설정되어 있었다.

    원인
    구성 요소
    기여 요인
    –
    조치
    • 영향받은 데이터베이스의 백업을 트래픽이 적은 시간에 예약할 수 있을 때까지 껐다.
    • 백업 작업의 네트워크 레이블 설정을 고쳐, 라우팅 계층이 백업 작업을 연결 대상 서비스로 잡지 않게 했다.
    후속 조치
    • 장애 업데이트를 공유하는 절차를 엄격하게 바꿔, 문제가 실제로 끝나기 전에 해결됐다고 알리지 않게 한다.
    • 데이터베이스 라우팅 계층에 더 구체적인 네트워크 레이블 설정을 둬, 연결 대상이 아닌 IP 가 서비스 설정에 들어가지 않게 한다.
    • 비동기 작업을 건너뛰었을 때 곧바로 실행하지 않고 다음 예약 시간대로 다시 예약한다.
    • 오픈소스 벤치마크 도구로 시스템을 측정하고, 고객이 알아챈 문제를 재현한다.
내 클러스터에도 있는지 확인하기

이 2건에서 가장 많이 나오는 구성 요소: 서비스 디스커버리, 클라우드 로드 밸런서. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별2