계정별 한도로 대체된 nginx piki_llm zone 제거

[m-a-king]

왜

nginx 에는 두 개의 레이트리밋 zone 이 있다.

zone	한도	걸리는 경로
piki_general	IP별 초당 20 (burst 40)	/api/ 전체, /admin, /docs/ 등
piki_llm	IP별 분당 30 (burst 20)	/wishlists, /wishlists/images, /tournaments/*/items/(link|images)

#339 로 계정별 아이템 등록 한도(위시 시간당 10, 토너먼트 시간당 30)가 들어가면서 piki_llm 이 잉여가 됐다.

• piki_llm 은 IP별 분당 30, 즉 시간당 1,800 이다
• 계정별 한도는 시간당 10 이라 180배 타이트하다
• 이 경로들은 전부 인증이 필요하므로 모든 요청이 계정별 검사를 거친다. 계정별에서 10에 걸리니 1,800에는 닿을 수 없다

즉 piki_llm 은 실질적으로 아무것도 막지 않으면서 nginx conf 의 복잡도만 차지한다. 경로 정규식 3개와 zone 정의, trailing slash 우회 방지 주석까지 딸려 있다.

무엇을

piki_llm zone 정의와 그것을 참조하는 location 3개를 제거한다. 대상 파일은 두 개다.

• core/infra/nginx/api.piki.day.conf
• core/infra/nginx/dev.api.piki.day.conf

제거 후 해당 경로들은 location /api/ 의 piki_general 을 그대로 상속한다.

piki_general 은 유지한다

두 zone 의 성격이 다르다.

zone	답하는 질문	앱이 대체 가능한가
piki_general	이 IP 가 서버를 죽이려 하나?	불가. 미인증 스캔·잘못된 경로·정적 자원까지 다 걸러야 하고, 인증 필터 이전에 끊어야 앱 스레드를 안 쓴다
piki_llm	이 IP 가 비싼 경로를 연타하나?	가능. 계정별 한도가 같은 질문에 훨씬 정확하게 답한다

선행 조건

바로 지우지 않는다. #339 배포 후 계정별 한도가 실제로 동작하는지 확인한 뒤 제거한다.

• 계정별 429 가 실제로 발생하는지 (메트릭·로그)
• 정상 사용자가 부당하게 막히지 않는지
• Redis 장애 시 fail-open 이 의도대로 도는지

지금 지우면 계정별 한도에 버그가 있을 때 그 경로의 방어가 통째로 사라진다.

참고

• userId별 애플리케이션 레벨 레이트리밋 (인증 사용자별 정밀 quota) #339 (계정별 한도. 이 제거의 전제)
• nginx IP별 레이트리밋 — 비싼 Gemini 경로 + 전역 2층 #332 (nginx IP 레이트리밋 도입)
• 아이템 파싱 시간당 가용량 상한 (전역 load shedding) #927 (전역 가용량 상한. piki_general 과도 축이 달라 무관)