docs: 서비스 재구조화 계획 문서 추가
- API 게이트웨이 패턴 도입 (robing-gateway) - 모니터링 서비스 분리 (robing-control, robing-monitor) - 인증 흐름 개선 계획 - Phase별 구현 우선순위 정의
This commit is contained in:
happybell80
parent
f6cb53b2f7
commit
8dc798ba19
223
ideas/250807_서비스_재구조화_계획.md
Normal file
223
ideas/250807_서비스_재구조화_계획.md
Normal file
@ -0,0 +1,223 @@
|
|||||||
|
# 서비스 재구조화 계획 - 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:10408 (추가)
|
||||||
|
├── 스킬 서비스
|
||||||
|
│ ├── skill-email:8501
|
||||||
|
│ ├── skill-news:8502
|
||||||
|
│ └── skill-embedding:8015
|
||||||
|
└── ChromaDB (벡터 DB)
|
||||||
|
```
|
||||||
|
|
||||||
|
## 제안하는 새 구조
|
||||||
|
|
||||||
|
### 1단계: 서비스 분리
|
||||||
|
|
||||||
|
#### robing-gateway (구 frontend-base 일부)
|
||||||
|
- **위치**: 51123 서버
|
||||||
|
- **포트**: 8000 (기존 유지)
|
||||||
|
- **역할**:
|
||||||
|
- API 게이트웨이 (사용자 요청 → 로빙 라우팅)
|
||||||
|
- 인증 체크 (auth-server 연동)
|
||||||
|
- 사용자-로빙 매핑
|
||||||
|
- 세션 관리
|
||||||
|
|
||||||
|
#### robing-control (구 frontend-base 일부)
|
||||||
|
- **위치**: 51123 서버
|
||||||
|
- **포트**: 8100 (새 포트)
|
||||||
|
- **역할**:
|
||||||
|
- 전체 시스템 모니터링 통합
|
||||||
|
- admin 대시보드 UI 제공
|
||||||
|
- 23서버 프로세스 직접 체크
|
||||||
|
- 24서버 상태는 API로 조회
|
||||||
|
- 향후 간단한 관제 기능 추가 가능
|
||||||
|
|
||||||
|
#### robing-monitor (신규)
|
||||||
|
- **위치**: 51124 서버
|
||||||
|
- **포트**: 8200
|
||||||
|
- **역할**:
|
||||||
|
- 24서버 로컬 모니터링
|
||||||
|
- 로빙 상태 체크
|
||||||
|
- 스킬 서비스 상태
|
||||||
|
- 리소스 사용량 수집
|
||||||
|
- API로 정보 제공
|
||||||
|
|
||||||
|
### 2단계: 인증 흐름 개선
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
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: 세션 생성
|
||||||
|
F->>U: 로그인 완료
|
||||||
|
|
||||||
|
U->>F: 채팅 입력
|
||||||
|
F->>G: /api/chat (세션)
|
||||||
|
G->>R: 라우팅 (user_id 포함)
|
||||||
|
R->>G: 응답
|
||||||
|
G->>F: 응답
|
||||||
|
F->>U: 표시
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3단계: 데이터베이스 통합
|
||||||
|
|
||||||
|
#### 단기 계획
|
||||||
|
- auth-server PostgreSQL을 메인 DB로 사용
|
||||||
|
- user_id를 모든 서비스에서 통일
|
||||||
|
- 세션 정보는 Redis 추가 (선택사항)
|
||||||
|
|
||||||
|
#### 장기 계획
|
||||||
|
- 로빙별 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 (1주)
|
||||||
|
1. robing-gateway 기본 구조 생성
|
||||||
|
2. 인증 흐름 연결
|
||||||
|
3. 단순 라우팅 (모든 사용자 → rb10508_test)
|
||||||
|
|
||||||
|
### Phase 2 (1주)
|
||||||
|
1. robing-monitor 구현
|
||||||
|
2. robing-control 분리
|
||||||
|
3. 모니터링 대시보드 연결
|
||||||
|
|
||||||
|
### Phase 3 (2주)
|
||||||
|
1. 사용자-로빙 매핑 로직
|
||||||
|
2. 워크스페이스 기반 할당
|
||||||
|
3. 세션 관리 고도화
|
||||||
|
|
||||||
|
### Phase 4 (선택)
|
||||||
|
1. 간단한 관제 기능
|
||||||
|
2. DB 통합
|
||||||
|
3. 성능 최적화
|
||||||
|
|
||||||
|
## 기대 효과
|
||||||
|
|
||||||
|
1. **명확한 책임 분리**
|
||||||
|
- 각 서비스가 단일 역할만 수행
|
||||||
|
- 유지보수 용이
|
||||||
|
|
||||||
|
2. **독립적 배포**
|
||||||
|
- 서비스별 독립 배포 가능
|
||||||
|
- 장애 격리
|
||||||
|
|
||||||
|
3. **확장성**
|
||||||
|
- 로빙 추가 시 gateway만 수정
|
||||||
|
- 모니터링 기능 점진적 확장
|
||||||
|
|
||||||
|
4. **보안 강화**
|
||||||
|
- 중앙 집중식 인증
|
||||||
|
- 로빙 직접 접근 차단
|
||||||
|
|
||||||
|
## 리스크 및 대응
|
||||||
|
|
||||||
|
1. **개발 기간**
|
||||||
|
- 리스크: 4주 이상 소요 가능
|
||||||
|
- 대응: Phase별 점진적 구현
|
||||||
|
|
||||||
|
2. **기존 서비스 중단**
|
||||||
|
- 리스크: 마이그레이션 중 서비스 중단
|
||||||
|
- 대응: 병렬 운영 후 전환
|
||||||
|
|
||||||
|
3. **복잡도 증가**
|
||||||
|
- 리스크: 서비스 개수 증가
|
||||||
|
- 대응: 명확한 문서화, 자동화 도구
|
||||||
|
|
||||||
|
## 다음 단계
|
||||||
|
|
||||||
|
1. [ ] 팀 리뷰 및 승인
|
||||||
|
2. [ ] 상세 API 스펙 작성
|
||||||
|
3. [ ] 개발 환경 구성
|
||||||
|
4. [ ] Phase 1 구현 시작
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 참고사항
|
||||||
|
|
||||||
|
- 이 계획은 초안이며, 구현 과정에서 수정될 수 있음
|
||||||
|
- 기존 frontend-base의 코드를 최대한 재활용
|
||||||
|
- 서버팀과 사전 협의 필요 (포트, 도메인 등)
|
||||||
Loading…
x
Reference in New Issue
Block a user