8000 daiso-mcp/docs/ADAPTIVE-ROUTING.md at main · hmmhmmhm/daiso-mcp · GitHub
[go: up one dir, main page]

Skip to content

Latest commit

 

History

History
44 lines (27 loc) · 4.2 KB

ADAPTIVE-ROUTING.md

File metadata and controls

44 lines (27 loc) · 4.2 KB

직접 호출과 중계 경로 자동 선택

Cloudflare Worker가 5분마다 조회 종류별 직접 API와 맥 중계 상태를 확인합니다. 사용자 조회는 이 결과로 경로를 고릅니다. 매 조회 전에 연결 시험을 하거나 상태 저장소 응답을 기다리지 않습니다.

경로를 고르는 기준

상황 조회 경로
최근 점검에서 직접 API가 정상 직접 호출
직접 API가 차단되거나 응답 형식이 비정상 기존 맥 중계
서버에 상태가 없거나 30초 상태 캐시가 만료 중계로 응답하면서 상태만 백그라운드 갱신
마지막 점검이 10분을 초과함 중계
직접 조회 중 401·403·429·5xx, 연결·응답 오류 발생 직접 경로를 5분 차단하고 남은 시간 안에서 중계로 복구
직접과 중계가 모두 최근 점검에서 실패 연결 장애 503 반환
GS25 재고 조회 정상 로그인 세션을 사용하는 기존 맥 중계 유지

상품 검색과 재고 조회의 판정은 따로 저장합니다. CU 3종, GS25 상품 검색, 세븐일레븐 8종, 올리브영 4종, 디트릭스 3종이 직접 점검 대상입니다. 다이소 등 원래 직접 호출하던 서비스에는 이 중계 선택을 추가하지 않습니다.

올리브영 중계는 브라우저 없이 동작하는 기존 HTTP 방식입니다. 이 기능은 중계 프로그램을 재시작하거나 로그인 세션을 옮기지 않습니다. Google 지오코딩과 Zyte도 다시 활성화하지 않습니다.

정기 점검의 비용과 제한

wrangler.toml의 Cron */5 * * * *가 실행합니다. 직접 요청은 고정 대표 상품·매장으로 최대 3초, 본문 2 MiB, 재시도 없이 수행합니다. 최대 네 연결만 동시에 사용합니다. 실제 조회와 점검은 같은 URL·헤더·요청 구성·응답 검증을 사용합니다. HTTP 200만 보고 성공으로 판단하지 않습니다.

하루 상한은 직접 API 5,472회(19종 × 288회)와 중계 헬스 864회(3곳 × 288회)입니다. 중계 헬스는 상품·재고 요청을 하지 않으므로 중계 원장의 일일 한도를 소비하지 않습니다. 사용자 요청에 적용되는 기존 인증과 한도는 그대로 유지합니다.

저장과 오류 복구

공유 상태는 UPSTREAM_ROUTE_HEALTH 바인딩의 UpstreamRouteHealth Durable Object에 저장합니다. 처음 배포할 때 SQLite migration v2가 추가됩니다. 개별 Worker의 캐시는 판정의 짧은 사본이며, 공유 저장소를 대신하지 않습니다.

실제 직접 조회 실패는 해당 Worker에서 즉시 차단하고 공유 저장소에 비동기로 기록합니다. 늦게 도착한 점검 성공이나 실패 기록이 더 최근 실패를 지우지 않도록 순서와 차단 시간을 검증합니다. 기록 전송이 한 번 실패하더라도 차단 시간이 지난 뒤 새 점검이 성공하면 직접 경로로 복귀할 수 있습니다.

400·404·422와 사용자 취소는 연결 장애로 취급하지 않습니다. 중계 429도 중계 서버 장애로 취급하지 않습니다. 공식 API에는 중계 Bearer 토큰이나 Cloudflare Access 키를 보내지 않습니다.

운영 확인

HEALTH_CHECK_SECRET과 기존 운영 헬스 인증 방식을 사용합니다. 시크릿을 명령 인수·로그·저장소에 넣지 마세요.

  • GET /api/health/routes: 저장된 조회별 판정과 점검 시각을 확인합니다. 직접 API를 시험하지 않습니다.
  • POST /api/health/routes: 고정된 전체 점검을 실행하고 결과를 반환합니다. 임의 URL이나 상품 입력은 받지 않습니다.

인증 헤더는 Authorization: Bearer <운영 시크릿> 또는 x-health-check-key입니다. 새 배포 직후에는 POST로 판정을 채우고, 이후 GET의 checkedAt이 Cron 실행으로 갱신되는지 확인합니다. 공유 저장소 바인딩이 없는 기존 설치·로컬 사용은 기존 중계 우선 동작을 유지합니다.

장애 확인 시 직접 점검의 reason, 점검 시각, failedAt과 blockedUntil, 중계 그룹의 healthy를 먼저 확인합니다. 원문 응답·쿠키·인증 코드는 저장하지 않으며 고정된 진단 코드만 남깁니다.

0