사례2건

2건 중 1~2번째

1. IL-0408 API 키 조회 캐시가 비워진 채 돌아와 OpenRouter API 가 두 번에 걸쳐 500 과 401 "User not found" 오류를 냈다

   OpenRouter2026

   증상

   OpenRouter 사용자 일부가 모든 API 엔드포인트에서 500 오류를 받았고, 몇 분 뒤에는 401 "User not found" 오류를 받았다. 2026년 2월 17일 05:27 UTC 부터 38분, 2월 19일 07:36 UTC 부터 35분 동안 같은 장애가 났고, 그때마다 내부 알림이 1~2분 안에 울렸다. 이 시간 동안 chatroom 도 제대로 동작하지 않았다.

   오류율 상승서비스 중단데이터베이스 과부하

   촉발

   API 키 조회 앞에 둔 외부 캐시 계층이 데이터베이스와의 연결을 모두 끊고 오류를 내기 시작했다. 캐시는 몇 분 안에 다시 연결했지만 저장된 항목이 모두 무효가 된 상태였다.

   원인

   의존성 장애

   구성 요소

   인메모리 캐시데이터베이스

   기여 요인

   데워진 캐시에 기댄 구조장애 중첩

   감지

   OpenRouter 는 내부 알림으로 장애를 알았다. 2월 17일에는 영향이 시작되고 1분 뒤인 05:28 UTC 에, 2월 19일에는 2분 뒤인 07:38 UTC 에 알림이 울렸고 대응 팀이 바로 조사를 시작했다.

   조치

   • 2월 17일 05:50 UTC 에 장애와 함께 진행되던 서비스 거부 공격을 찾아 WAF 규칙으로 막았다.

   후속 조치

   • 캐시 계층의 고장을 감지하고 피해 범위를 줄이는 circuit breaker 를 넣었다. 이 circuit breaker 는 캐시가 비었을 때 모든 요청이 한꺼번에 데이터베이스로 가지 않게 캐시를 통제된 방식으로 다시 채운다.
   • 인프라 문제로 인가 조회를 끝내지 못하면 401 대신 503 service unavailable 을 내도록 바꿨다. 고객이 진짜 인증 문제와 일시적인 인프라 문제를 구별할 수 있게 하려는 것이다.
   • 캐시 제공업체가 두 장애를 일으킨 고장 방식을 고치는 수정을 배포했다.
   • 캐시 계층이 오래 내려가도 버틸 수 있도록 대체 캐시 구성을 곧 배포한다.

   교훈

   OpenRouter 는 원인이 외부 의존성의 고장이었더라도, 의존성이 고장 나도 버티는 중복 구성을 갖추는 일은 자기 책임이라고 밝혔다. 실제로는 인프라 문제인데 인증 오류를 낸 것이 고객에게 큰 혼란을 줬고, 고객이 자기 쪽 잘못이 아닌 문제를 디버깅하게 만들었다. 첫 장애 때 같은 시각의 서비스 거부 공격을 원인으로 보고 대응 순서를 정했기 때문에 같은 고장이 이틀 뒤 다시 났다.

   사례 보기
2. IL-0489 Kubernetes 위 3노드 MySQL 클러스터에 노드를 다시 붙이다 메타데이터가 깨져 Magic Pages 고객 사이트가 내려갔다

   Magic Pages2025

   증상

   2025-01-15 09:55 CET 무렵부터 11:36 CET까지 데이터베이스 장애로 Magic Pages의 고객 웹사이트가 영향을 받았다. 노드 세 대로 된 MySQL 클러스터에서 내려간 노드를 다시 붙이려 하자 데이터베이스 서버가 메타데이터 정보가 없다는 모호한 오류를 냈다.

   서비스 중단

   촉발

   그날 앞서 MySQL 클러스터의 세 노드 중 하나가 내려갔고, 창업자가 그 노드를 클러스터에 다시 붙이려 했다.

   원인

   의존성 장애

   구성 요소

   데이터베이스영구 볼륨과 스테이트풀셋

   기여 요인

   수동 조치 악화단일 장애점모니터링 사각지대

   조치

   • PVC 프로비저닝 문제를 풀려고 스토리지 서버를 재시작했다. 재시작은 몇 초 만에 끝났다.
   • 스토리지가 돌아온 뒤 클러스터 메타데이터를 다시 만들 수 있도록 MySQL 노드들이 복원되고 서로 동기화되기를 약 45분 기다렸다.
   • 깨진 클러스터 메타데이터를 정리했다.
   • 데이터베이스 노드로 트래픽을 보내는 MySQL Router를 다시 배포했다.

   후속 조치

   • 스토리지 시스템의 상태 모니터링을 강화한다.
   • MySQL Router의 장애 조치 절차를 개선한다.
   • 상태 페이지가 믿을 만한 정보를 보이도록 문제를 조사하고 고친다.

   교훈

   고가용성 구성 덕분에 데이터는 잃지 않았고 첫 노드 장애도 클러스터가 문제없이 넘겼다. 하지만 중복 구성인데도 클러스터 메타데이터가 단일 장애 지점이었다. PVC 상태를 더 잘 모니터링했다면 비슷한 문제를 막을 수 있었고, 45분 걸린 복구는 더 줄일 여지가 있다. 상태 페이지는 고객 사이트 실패를 감지하도록 설정했는데도 이 장애를 바로 알아채지 못했다.

   사례 보기

원인별1