happybell80
725ad0876c
- 모든 .md, .html 파일 권한을 644로 정상화 - .gitignore 파일 권한도 644로 수정 - 문서 파일에 실행 권한은 불필요하고 보안상 바람직하지 않음 - deprecated 아이디어 폴더 생성 및 레벨별 UI 변경 아이디어 이동
6.8 KiB
6.8 KiB
서비스 재구조화 계획 - API 게이트웨이 및 모니터링 분리
작성일: 2025-08-07
작성자: happybell80 & Claude
상태: 계획 단계
현재 문제점
1. 복잡한 연결 구조
- frontend-customer와 로빙 직접 연결 부재
/api/assistant/{id}엔드포인트 미구현- 어떤 사용자가 어떤 로빙과 연결되는지 결정 로직 없음
2. 인증 흐름 불완전
- auth-server에서 인증 → frontend로 토큰 전달 경로 없음
- 로빙이 사용자 인증 정보 받는 방법 없음
- OAuth 콜백 후 frontend로 돌아가는 로직 부재
3. 데이터베이스 분산
- PostgreSQL (auth-server) - users, workspaces
- ChromaDB (51124) - 벡터 메모리
- SQLite (각 로빙) - 로컬 데이터
- user_id 동기화 문제
4. 서비스 역할 혼재
- frontend-base가 admin UI + 백엔드 역할 혼재
- 모니터링과 라우팅이 분리되지 않음
현재 서버 구조
51123 서버 (메인 서버)
├── frontend-customer (https://ro-being.com/)
│ └── React 정적 파일, nginx 직접 서빙
├── frontend-base:8000 (https://ro-being.com/admin)
│ └── 관리자 대시보드 + 백엔드
├── auth-server (https://auth.ro-being.com)
│ └── OAuth 인증, PostgreSQL DB
└── nginx (리버스 프록시, SSL)
51124 서버 (로빙/스킬 서버)
├── 로빙 컨테이너
│ ├── rb8001:8001 (프로덕션)
│ ├── rb10508_test:10508 (테스트)
│ └── rb10408_test:10408 (테스트)
├── 스킬 서비스
│ ├── skill-email:8501 (Gmail 연동)
│ ├── skill-news:8502
│ ├── skill-embedding:8515 (포트 변경됨)
│ └── skill-slack (멀티봇 지원)
└── ChromaDB (벡터 DB)
제안하는 새 구조
1단계: 서비스 분리
robing-gateway (구 frontend-base 일부)
- 위치: 51123 서버
- 포트: 8000 (기존 유지)
- 역할:
- API 게이트웨이 (사용자 요청 → 로빙 라우팅)
- 인증 체크 (auth-server 연동)
- 사용자-로빙 매핑 (메모리 캐시)
- 캐시 관리: 로그인 시 추가, 로그아웃 시 제거
robing-control (구 frontend-base 일부)
- 위치: 51123 서버
- 포트: 9023
- 역할:
- 전체 시스템 모니터링 통합
- admin 대시보드 UI 제공
- 23서버 프로세스 직접 체크
- 24서버 상태는 API로 조회
- 향후 간단한 관제 기능 추가 가능
robing-monitor (신규)
- 위치: 51124 서버
- 포트: 9024
- 역할:
- 24서버 로컬 모니터링
- 로빙 상태 체크
- 스킬 서비스 상태
- 리소스 사용량 수집
- API로 정보 제공
2단계: 인증 흐름 개선
sequenceDiagram
participant U as User
participant F as Frontend
participant G as Gateway
participant A as Auth
participant R as Robing
U->>F: 로그인 클릭
F->>G: /api/auth/login
G->>A: OAuth 시작
A->>U: Google OAuth
U->>A: 인증 완료
A->>G: 토큰 + user_id
G->>F: 로그인 성공 (user_id)
F->>U: 로그인 완료
U->>F: 채팅 입력
F->>G: /api/chat (user_id 포함)
Note over G: 메모리 캐시 확인<br/>없으면 DB 조회 후 캐싱
G->>R: 프록시 (port 8001)
R->>G: 응답
G->>F: 응답
F->>U: 표시
수정된 흐름 설명:
- 로그인 완료 후 Frontend는 user_id만 알면 됨
- 모든 API 요청에 user_id 포함 (JWT 토큰 또는 헤더)
- Gateway가 메모리 캐시 확인 (대부분 여기서 처리)
- 캐시 hit: 즉시 라우팅
- 캐시 miss: DB 조회 후 캐싱
- Gateway가 적절한 로빙으로 프록시
- Frontend는 로빙 포트를 전혀 알 필요 없음
3단계: 데이터베이스 통합
단기 계획
- auth-server PostgreSQL을 메인 DB로 사용
- user_id를 모든 서비스에서 통일
- user_id → robing_port 매핑 테이블 관리
장기 계획
- 로빙별 SQLite → PostgreSQL 마이그레이션
- 중앙 집중식 데이터 관리
4단계: API 설계
robing-gateway API
POST /api/auth/login # 로그인 시작
GET /api/auth/callback # OAuth 콜백
POST /api/auth/logout # 로그아웃
GET /api/auth/status # 인증 상태
POST /api/chat # 채팅 (자동 라우팅)
GET /api/robing/info # 할당된 로빙 정보
robing-control API
GET /admin # 대시보드 UI
GET /api/monitor/overview # 전체 시스템 상태
GET /api/monitor/23 # 23서버 상태
GET /api/monitor/24 # 24서버 상태 (robing-monitor 호출)
POST /api/control/restart # 서비스 재시작 (향후)
robing-monitor API
GET /api/status/robings # 로빙 상태
GET /api/status/skills # 스킬 상태
GET /api/status/resources # 리소스 사용량
GET /api/health # 헬스체크
구현 우선순위
Phase 1
- robing-gateway 기본 구조 생성
- 인증 흐름 연결
- 단순 라우팅 (모든 사용자 → rb10508_test)
Phase 2
- robing-monitor 구현
- robing-control 분리
- 모니터링 대시보드 연결
Phase 3
- 사용자-로빙 매핑 로직
- 워크스페이스 기반 할당
- 로빙 포트 자동 할당
Phase 4 (선택)
- 간단한 관제 기능
- DB 통합
- 성능 최적화
기대 효과
-
명확한 책임 분리
- 각 서비스가 단일 역할만 수행
- 유지보수 용이
-
독립적 배포
- 서비스별 독립 배포 가능
- 장애 격리
-
확장성
- 로빙 추가 시 gateway만 수정
- 모니터링 기능 점진적 확장
-
보안 강화
- 중앙 집중식 인증
- 로빙 직접 접근 차단
리스크 및 대응
-
개발 복잡도
- 리스크: 서비스 분리로 인한 복잡도
- 대응: Phase별 점진적 구현
-
기존 서비스 중단
- 리스크: 마이그레이션 중 서비스 중단
- 대응: 병렬 운영 후 전환
-
복잡도 증가
- 리스크: 서비스 개수 증가
- 대응: 명확한 문서화, 자동화 도구
추가 통합 계획 (2025-08-17)
Email Skill 통합
- Gmail OAuth 토큰 관리: PostgreSQL 기반
- 토큰 위치: auth-server/tokens/ → DB 이전 예정
- 멀티 로빙 지원: 각 로빙별 Gmail 계정 매핑
Slack 멀티봇 지원
- rb8001: robeing 봇
- rb10408: hj-robeing 봇
- 봇 토큰 중앙 관리 필요
다음 단계
- 팀 리뷰 및 승인
- 상세 API 스펙 작성
- 개발 환경 구성
- Phase 1 구현 시작
- Email/Slack 토큰 DB 마이그레이션
참고사항
- 이 계획은 초안이며, 구현 과정에서 수정될 수 있음
- 기존 frontend-base의 코드를 최대한 재활용
- 서버팀과 사전 협의 필요 (포트, 도메인 등)