[Feat] 지도 조회 용량과 후보 상한 초과 처리 정리 #252

📌 이슈 종류

• ✨ 기능 추가 (Feature)

📝 작업 내용

지도 조회를 공개하기 전에 실제 데이터와 예상 요청량으로 서버·Redis가 감당할 범위를 확인합니다.

PR #234에서 고정 128개 슬롯과 후보 500개 제한을 교체했습니다. 조회 ID별로 순서를 저장하고, 마지막 정상 조회부터 5분·최초 조회부터 최대 30분 유지합니다. 호출자별 요청 수, 세션 크기와 전체 메모리 예산을 함께 제한합니다.

현재 확인한 결과

호출자가 서로 다른 정상 탐색과 같은 IP에서 요청이 몰리는 상황을 나눠 다시 테스트했습니다. 모두 로컬 MySQL·Redis와 합성 식당 620개를 사용했습니다.

• 정상 탐색, 짧은 10초 TTL: 1,255건 모두 성공했습니다.
• 실제 5분 TTL, 세션 예산 16MiB: 783건 중 124건이 503이었습니다. 세션 예약 예산이 99.76%까지 찼습니다.
• 같은 조건에서 테스트 예산만 32MiB로 변경: 1,270건 모두 성공했습니다. 다만 예산을 96.17%까지 사용했으므로 운영 설정으로 확정한 값은 아닙니다.
• 같은 IP의 빠른 요청: 3,872건 중 429가 830건, 503이 137건이었습니다. 429는 호출자 요청 한도에 걸린 결과입니다. 503은 메모리 예산이 남은 상태라 동시 처리 제한 가능성이 높지만, 내부 원인별 지표가 없어 개별 원인을 확정하지는 않았습니다.
• 모든 유효한 실행에서 세션 만료 후 정리와 새 요청 복구를 확인했습니다. 합성 인증 키는 유지됐고 DB 연결 대기는 없었습니다.

5분 동안 세션이 누적되는 조건에서는 기존 예산이 부족했습니다. 숫자만 올리기 전에 세션 저장량과 실제 후보 분포를 확인하고, 공유 인증 Redis에 영향을 주지 않는 범위에서 예산을 정해야 합니다. 3,000/5,000개 테스트는 이 조정 후 진행합니다.

개발 환경 수치는 앞선 읽기 전용 점검 기준이며 이번 부하를 실제 서버에 보낸 것은 아닙니다. 공유 Redis 정책과 지도 저장소의 요구 조건 차이도 남아 있습니다. 정책 변경 또는 지도 Redis 분리는 인증 데이터에 미치는 영향을 확인한 뒤 결정하며, 실제 설정은 변경하지 않았습니다.

✅ 체크리스트

• 전체 결과를 10개씩 이어서 조회하는 기획 계약 확인
• 500개 초과 조회, 추천·동점 순서 유지, 같은 커서 재시도와 세션 만료 처리 구현
• 호출자별·전체 요청 제한과 공유 Redis 메모리 보호 구현
• 후보 500·501·620개 통합 테스트와 로컬 소규모 k6 실행
• 로컬 부하 확대, 제한 응답과 만료 후 복구 확인
• 개발 DB·Redis 현황 읽기 전용 점검
• 초기 지도 범위·관광 지역·필터별 실제 후보 수와 예상 증가량 확인
• 프록시 환경의 호출자 구분 및 ingress 제한 확인
• 예상 동시 사용자 조건에서 신규 조회·스크롤·정렬·필터 변경의 수용량 확인
• 로컬에서 실제 5분 TTL의 누적 예산·세션 정리·DB 연결·복구 확인
• 공유 Redis 정책·ACL·여유 용량 또는 지도 Redis 분리 결정 및 검증
• 측정 결과에 맞춘 설정값과 공개 활성화 여부 결정

💬 참고 사항

• PR [Feat] 지도 목록을 10개씩 이어서 조회 (#227) #234: 지도 페이지와 Redis 조회 세션
• PR [Feat] 지도 범위와 관광 지역별 식당 조회 추가 (#223) #229: 지도 후보 조회
• PR [Test] 식당 등록부터 지도·컬렉션까지 서버 흐름 검증 (#231) #236: 통합·부하 검증과 프런트 연동 가이드
• 이슈 [Feat] 관리자 관광 지역 설정과 식당 지역 지정 API 추가 #251: 관광 지역 설정과 식당 소속 관리

로컬 부하는 Google API를 호출하지 않습니다. 실제 Google 연동 테스트는 별도로 수행하며 부하 결과와 구분합니다. 운영 용량 검증이 남아 있으므로 이 이슈는 열린 상태로 유지하고 공개 지도 목록도 활성화하지 않습니다.