happybell80 49803344ff Add robing-gateway implementation troubleshooting document

- API Gateway 구현 과정 및 문제 해결
- Docker DB 연결, API 엔드포인트, 요청 형식 수정
- Phase 2 다음 단계 안내 포함

2025-08-09 11:58:06 +09:00

4.9 KiB

Raw Blame History

robing-gateway API 게이트웨이 구현 및 배포

날짜: 2025-08-09
작업자: happybell80 & Claude & 23서버팀
관련 서버: 51123 (Gateway 실행), 51124 (로빙 서비스)

배경

서비스 재구조화 계획에 따라 Frontend와 로빙 서비스 간 중앙 라우팅 레이어 구현 필요. 기존 frontend-base의 일부 기능을 분리하여 독립적인 API Gateway 서비스로 구축.

오전 10시 30분 - 초기 구현

구현 내용

프로젝트 구조:

robing-gateway/
├── app/
│   ├── main.py         # FastAPI 메인 앱
│   ├── cache.py        # 메모리 캐시 (30분 TTL)
│   ├── database.py     # PostgreSQL 연결
│   └── models.py       # SQLAlchemy 모델
├── scripts/
│   ├── init_db.sql     # 테스트 데이터
│   └── health_check.sh # 헬스체크 스크립트
├── docker-compose.yml
├── Dockerfile
└── .gitea/workflows/deploy.yml

핵심 기능:

사용자-로빙 매핑 관리
메모리 캐시로 성능 최적화
기존 auth_db 테이블 활용 (workspaces, workspace_members)
헬스체크 및 모니터링 엔드포인트

23서버팀 피드백

중요 변경사항 - 새 테이블 불필요:

기존 auth_db의 workspaces, workspace_members 테이블 활용
workspace_members에서 user_id로 robing 정보 조회
JOIN 쿼리로 사용자 → 워크스페이스 → 로빙 매핑

오전 11시 00분 - 배포 문제 해결

문제 1: API 엔드포인트 불일치

원인:

Gateway가 /api/chat으로 프록시 시도
rb10508_micro는 /api/message 엔드포인트 사용

해결:

# app/main.py 수정
target_url = f"{base_url}/api/message"  # rb10508_micro uses /api/message

문제 2: 요청 body 형식 불일치

원인:

Frontend는 message 필드 전송
rb10508_micro는 text 필드 예상

해결:

# MessageRequest 형식으로 변환
body = {
    'text': original_body.get('message', original_body.get('text', '')),
    'user_id': x_user_id,
    'context': original_body.get('context', {})
}

문제 3: Docker 컨테이너 DB 연결 실패

원인:

컨테이너 내부에서 localhost는 컨테이너 자신을 가리킴
호스트의 PostgreSQL 접근 불가

해결:

# .env.example 수정
DATABASE_URL=postgresql+asyncpg://robeings:패스워드@host.docker.internal:5432/auth_db

문제 4: Gitea Actions 환경변수

원인:

${{ gitea.workspace }} 변수 인식 실패

해결:

${{ github.workspace }} 사용 (Gitea가 GitHub Actions 호환 변수 지원)

오전 11시 45분 - 최종 배포 성공

배포 결과

정상 작동 확인:

# 헬스체크
curl http://localhost:8100/health
# 결과: {"status":"healthy","cache_size":0,"database":"connected"}

# DB 테이블 확인
SELECT COUNT(*) FROM workspaces;  # 2 (테스트 데이터)

현재 상태:

robing-gateway 포트 8100에서 정상 실행
PostgreSQL auth_db 연결 성공
DEFAULT_ROBING_ID: rb10508_micro 설정
메모리 캐시 활성화 (30분 TTL)

시스템 아키텍처

Frontend (React)
    ↓ POST /api/chat (message, user_id)
Gateway (8100)
    ↓ 캐시 확인 → DB 조회 → 라우팅 결정
    ↓ POST /api/message (text, user_id, context)  
rb10508_micro (10508)

다음 단계 (Phase 2)

1. Frontend 연동 테스트

// Frontend 요청 예시
fetch('http://localhost:8100/api/chat', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'x-user-id': 'user-uuid-here'
  },
  body: JSON.stringify({
    message: '안녕하세요',
    context: {}
  })
})

2. 워크스페이스 할당 테스트

-- 사용자를 워크스페이스에 할당
INSERT INTO workspace_members (
    id, user_id, workspace_id, role, robing_id, is_active
) VALUES (
    gen_random_uuid(),
    'USER_UUID',  -- 실제 사용자 ID
    (SELECT id FROM workspaces WHERE subdomain = 'test'),
    'member',
    'rb10508_micro',
    true
);

3. 모니터링 구현

robing-control 서비스 분리 (관리 대시보드)
robing-monitor 서비스 구현 (24서버 모니터링)
메트릭 수집 및 시각화

4. 인증 통합

auth-server와 연동
JWT 토큰 검증
세션 관리

교훈

기존 스키마 활용: 새 테이블 생성보다 기존 구조 재사용이 효율적
Docker 네트워킹: 컨테이너에서 호스트 DB 접근 시 host.docker.internal 사용
API 명세 확인: 프록시 대상 서비스의 정확한 엔드포인트와 요청 형식 사전 확인 필수
단계적 구현: Phase 1에서 기본 기능 구현 후 점진적 기능 추가

참고 자료

서비스 재구조화 계획: /DOCS/ideas/250807_서비스_재구조화_계획.md
Gateway 저장소: https://git.ro-being.com/ivada_Ro-being/robeing-gateway
포트 정보: 8100 (테스트) → 8000 (프로덕션, frontend-base 대체 시)

4.9 KiB Raw Blame History