Incident Library

IL-0408 OpenRouter · 2026-02-17ai-infradatabase

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

OpenRouter 는 API 키를 데이터베이스에서 빠르게 조회하려고 외부 캐시 계층을 쓴다. 평소에는 인증 확인의 대부분을 이 캐시가 처리하고, 데이터베이스로 직접 가는 요청은 일부뿐이다. 2026년 2월 17일 05:27 UTC 에 이 캐시 계층이 데이터베이스와의 연결을 모두 끊고 오류를 내기 시작했고, 요청의 약 20% 가 500 오류로 실패했다. 05:40 UTC 에 캐시가 다시 연결했지만 저장된 항목이 모두 무효가 돼 있어서 들어오는 요청마다 데이터베이스를 새로 조회해야 했다. 데이터베이스는 갑자기 몰린 조회를 감당하지 못했고, 그 타임아웃이 사용자에게 401 "User not found" 오류로 나갔다. 실패율은 80~90% 까지 올랐고, 06:05 UTC 에 캐시가 다시 다 채워지면서 서비스가 돌아왔다.

2월 17일에는 서비스 거부 공격이 같은 시각에 커지고 있었다. 이 캐시 의존성이 그동안 매우 안정적이었기 때문에 OpenRouter 는 처음에 장애를 공격 탓으로 보고 그 공격 경로를 막는 데 힘을 쏟았다. 캐시 제공업체도 첫 장애 직후 조사를 시작했지만 원인을 찾아 고치는 데 시간이 걸렸다. 2월 19일 07:36 UTC 에 공격 없이 같은 캐시 고장이 다시 났고, 같은 순서로 500 오류에서 401 오류로 번진 뒤 08:11 UTC 에 캐시가 다시 채워지며 복구됐다. 이때 진짜 원인이 드러났고, OpenRouter 는 몇 시간 안에 이 고장을 겨냥한 보호 장치를 배포했다.

OpenRouter 는 캐시 계층의 고장을 감지해 피해 범위를 줄이는 circuit breaker 를 넣었다. 이 circuit breaker 는 캐시가 비었을 때 모든 요청이 한꺼번에 데이터베이스로 가지 않도록 캐시를 통제된 방식으로 다시 채운다. 인프라 문제로 인가 조회를 끝내지 못하면 401 대신 503 을 내도록 바꿨다. 캐시 제공업체도 두 장애를 일으킨 고장 방식을 고쳤다.

심각도
–
영향 범위
All OpenRouter API endpoints and the chatroom: on 17 February about 20% of API requests failed, then 80-90%; on 19 February partial failures, then near-total downtime
영향 사용자
A portion of OpenRouter users
지역
–
감지까지
1m
복구까지
38m

증상

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

두 번 모두 고장 직전에 API 키 조회용 캐시 계층이 사용자에게는 영향이 없는 오류를 이따금 남기기 시작했다. 2월 17일에는 05:20 UTC 부터, 2월 19일에는 07:16 UTC 부터였다.

장애는 두 단계로 번졌다. 2월 17일에는 05:27 UTC 부터 05:40 UTC 까지 API 요청의 약 20% 가 500 오류로 실패했고, 05:40 UTC 부터 06:05 UTC 까지는 실패율이 80~90% 였다. 2월 19일에는 07:36 UTC 부터 07:42 UTC 까지 일부 요청이 실패했고, 07:42 UTC 부터 08:11 UTC 까지는 서비스가 거의 전부 멈췄다.

401 "User not found" 오류는 인증 문제가 아니라 인프라 문제에서 나왔다. 데이터베이스가 몰려든 키 조회를 처리하지 못해 타임아웃이 났고, 이 타임아웃이 사용자에게 401 로 전달됐다. 그래서 일부 고객은 자기 쪽에 잘못이 없는데도 API 키 설정을 디버깅하느라 시간을 썼다.

2월 17일에는 같은 시각에 서비스 거부 공격이 커지고 있었다. 엔지니어는 05:50 UTC 에 이 공격을 찾아 WAF 규칙으로 막았고, 처음에는 장애를 이 공격 때문이라고 보고 그 공격 경로를 막는 일을 먼저 했다. 2월 19일에 공격 없이 같은 캐시 고장이 다시 나고서야 진짜 원인이 드러났다.

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

원인

원인 의존성 장애

구성 요소 인메모리 캐시데이터베이스
기여 요인 데워진 캐시에 기댄 구조장애 중첩
촉발
API 키 조회 앞에 둔 외부 캐시 계층이 데이터베이스와의 연결을 모두 끊고 오류를 내기 시작했다. 캐시는 몇 분 안에 다시 연결했지만 저장된 항목이 모두 무효가 된 상태였다.

감지

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

조치

후속 조치

교훈

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

출처

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 인메모리 캐시, 데이터베이스. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.