이미지 임베딩 / 태깅 / 중복사진 서비스 컨테이너

1. 세 기능을 한 컨테이너로 묶은 이유

• 현재 온기 서비스는 이미지 업로드 시 실시간으로 전처리 → 임베딩 → 태깅 + 중복 판별까지 순차적으로 처리함
• 이 기능들은 하나의 요청 흐름에서 긴밀히 연결되어 있어, 초기에 분리된 컨테이너로 운영하는 것은 운영 복잡성에 비해 얻는 이점이 적음
• 현재는 FastAPI 기반 단일 컨테이너에 함께 배치하여 관리 효율과 개발 민첩성을 확보
  • 다만 컨테이너 내부에서는 모듈 분리를 통해 테스트, 유지보수, 확장성도 고려

각 기능은 코드 레벨에서 명확히 모듈화되어 있으며, 추후 병목 또는 인프라 분리에 따라 마이크로서비스화가 가능하도록 설계할 예정

---

2. 현재 구조 및 모듈화 방식

• 하나의 FastAPI 앱 안에 다음과 같은 네 가지 역할을 서비스 단위로 모듈화

  [FastAPI Router]
   ├── Preprocessor # 이미지 URL → Tensor 전처리
   ├── EmbeddingService # Tensor → 임베딩 벡터 추출
   ├── TaggingService # 임베딩 → 태그 추출 및 카테고리 매핑
   └── DuplicateService # 임베딩 간 유사도 분석 및 중복 탐지
  

---

3. 예상 병목 지점 및 마이크로서비스 분리 계획

모듈	예상 병목	분리 필요성	향후 대응 방안
Preprocessor	이미지 로딩 지연, 오류 이미지 처리	낮음	예외 처리 고도화, 캐싱 고려
EmbeddingService	CLIP 기반 추론 부하, 추후 GPU 전환 가능성	높음	CPU 서버 내에서 별도의 서비스로 분리하거나, GPU 인스턴스에서 별도 추론 서버로 분리
TaggingService	벡터 유사도 계산	낮음	대규모 비교 필요 시 병렬 처리 or 분리 고려
DuplicateService	벡터 유사도 계산	낮음	대규모 비교 필요 시 병렬 처리 or 분리 고려

RAM++ vs CLIP: 병목 위치 비교 분석

⚠️ 증분 시간 = 전체 시간 − 임베딩 시간

항목	RAM++ (임베딩만)	RAM++ (임베딩+태깅)	증분 시간	CLIP (임베딩만)	CLIP (임베딩+태깅)	증분 시간
CPU (batch 32)	149.93s	186.91s	+36.98s	4.49s	3.53s	-0.96s
GPU (batch 32)	7.59s	12.69s	+5.10s	0.96s	1.00s	+0.04s

---

4. GPU 사용 시 마이크로서비스 분리 필요성

• GPU는 자원 경합에 매우 민감하므로, FastAPI 서버 내 다른 처리와 함께 쓰면 충돌 가능성 ↑
• GPU 서버는 CPU 서버와 인프라 구성이 다르기 때문에 추론 서버만 분리하는 것이 관리와 비용 면에서 유리
• 따라서 GPU 사용이 시작되면 EmbeddingService를 마이크로서비스로 분리하는 것이 사실상 필수에 가까움

[AI 처리 서버 (CPU)]
      └─→ POST /embed → [Embedding Server (GPU)]

---

5. 결론

• 현재는 CPU 기반 단일 컨테이너 + 내부 모듈화 구조로 시작
• 추론 흐름을 명확히 나눠두어 향후 GPU 전환, 부하 분산, 서비스 확장 시 구조 변경이 용이
• 추후 GPU 서버 도입 시, EmbeddingService만 독립 마이크로서비스화하고 나머지는 기존 구조 유지