docs: Gateway 메모리 캐시 전략 추가

- 매번 DB 조회 대신 메모리 캐시 사용
- 로그인 시 캐싱, 로그아웃 시 제거
- 성능 대폭 개선 예상
This commit is contained in:
happybell80 2025-08-07 21:37:17 +09:00
parent cd318892c4
commit cce4804d86

View File

@ -62,7 +62,8 @@
- **역할**: - **역할**:
- API 게이트웨이 (사용자 요청 → 로빙 라우팅) - API 게이트웨이 (사용자 요청 → 로빙 라우팅)
- 인증 체크 (auth-server 연동) - 인증 체크 (auth-server 연동)
- 사용자-로빙 매핑 - 사용자-로빙 매핑 (메모리 캐시)
- 캐시 관리: 로그인 시 추가, 로그아웃 시 제거
#### robing-control (구 frontend-base 일부) #### robing-control (구 frontend-base 일부)
- **위치**: 51123 서버 - **위치**: 51123 서버
@ -105,7 +106,7 @@ sequenceDiagram
U->>F: 채팅 입력 U->>F: 채팅 입력
F->>G: /api/chat (user_id 포함) F->>G: /api/chat (user_id 포함)
Note over G: DB 조회: user_id → port 8001 Note over G: 메모리 캐시 확인<br/>없으면 DB 조회 후 캐싱
G->>R: 프록시 (port 8001) G->>R: 프록시 (port 8001)
R->>G: 응답 R->>G: 응답
G->>F: 응답 G->>F: 응답
@ -115,7 +116,9 @@ sequenceDiagram
**수정된 흐름 설명:** **수정된 흐름 설명:**
1. 로그인 완료 후 Frontend는 user_id만 알면 됨 1. 로그인 완료 후 Frontend는 user_id만 알면 됨
2. 모든 API 요청에 user_id 포함 (JWT 토큰 또는 헤더) 2. 모든 API 요청에 user_id 포함 (JWT 토큰 또는 헤더)
3. Gateway가 매번 DB 조회하여 해당 사용자의 robing_port 확인 3. Gateway가 메모리 캐시 확인 (대부분 여기서 처리)
- 캐시 hit: 즉시 라우팅
- 캐시 miss: DB 조회 후 캐싱
4. Gateway가 적절한 로빙으로 프록시 4. Gateway가 적절한 로빙으로 프록시
5. Frontend는 로빙 포트를 전혀 알 필요 없음 5. Frontend는 로빙 포트를 전혀 알 필요 없음