1. 전체 요청 흐름 요약

• 사용자는 여러 장의 이미지를 업로드하고,
  • 시스템은 먼저 이 이미지들을 자동으로 분류/필터링/하이라이트 사진 추천 등을 처리한다.
• 이후 사용자는 특정 이미지를 선택해, 원하는 스타일(지브리 등)로 변환을 요청할 수 있다.

---

2. 구성 요소 간 상세 연동 흐름

a. 사용자 요청 수신

사용자 → Backend → GCS 저장
				↓
이미지 URL 목록 전달
				↓
Load Balancer → 트래픽 분산 라우팅
				↓
FastAPI → 처리 시작

• 사용자가 여러 장의 이미지를 업로드
• 업로드된 이미지는 Backend 서버가 직접 GCS(Cloud Storage)에 저장
• 저장이 완료되면, Backend는 각 이미지의 pre-signed URL 목록을 FastAPI에 전달
• Cloud Load Balancer가 요청을 수신하고, FastAPI 인스턴스들 중 하나로 트래픽을 분산 라우팅
• FastAPI는 전달받은 이미지 URL들을 기반으로 후속 처리(임베딩, 분류 등)를 수행

컴포넌트	역할
사용자	여러 장의 이미지를 업로드
Backend	이미지를 GCS에 저장하고, 각 이미지의 pre-signed URL을 생성
Cloud Storage (GCS)	이미지 파일 저장소 역할 (binary, 고용량 이미지 저장에 최적화)
Cloud Load Balancer	Backend에서 FastAPI로 전달되는 요청을 인스턴스에 분산 라우팅
FastAPI	전달받은 이미지 URL들을 기반으로 후속 AI 처리 흐름(임베딩, 중복 판별 등)을 시작

b. FastAPI 서버 → 이미지 임베딩 처리

[각 이미지 URL] 
				↓
Redis → 캐시에서 임베딩 존재 여부 확인
				↓ (존재할 경우)
FastAPI → 캐시된 임베딩 재사용
		    ↓ (존재하지 않을 경우)
FastAPI → 이미지 로드 → CLIP 모델로 임베딩 생성
		    ↓
FastAPI → Redis에 임베딩 캐싱

• FastAPI는 각 이미지에 대해:
  • Redis 캐시에서 임베딩 존재 여부 확인
  • 없으면 CLIP 기반 임베딩 생성
  • 생성된 임베딩은 Redis에 캐싱

컴포넌트	역할
FastAPI	전달받은 각 이미지 URL에 대해 임베딩 캐시 여부를 조회하고, 처리 흐름을 제어
Redis (캐시)	임베딩 결과가 있는지 확인
Cloud Storage (GCS)	FastAPI가 이미지 URL을 통해 이미지 데이터를 로드하는 대상 (직접 접근)
CLIP 모델 (CPU 서버)	임베딩이 없을 경우 FastAPI가 이미지를 입력으로 사용하여 임베딩을 생성
FastAPI	새로 생성된 임베딩 결과를 Redis에 캐싱하여 추후 중복 연산 방지

c. FastAPI 서버 → 임베딩 후속 작업 처리

[임베딩 완료]  
     ↓  
FastAPI → Backend로 "처리 완료" 통보  
     ↓  
Backend → 후속 작업 요청 (중복 필터링 / 분류 등) 도착  
     ↓  
FastAPI → Redis 메시지 큐 등록  
     ↓  
각 작업 전용 Worker에서 처리

• FastAPI는 모든 이미지에 대한 임베딩이 완료되면, 해당 사실을 Backend에 전달하여 상태를 갱신
• 이후, Backend에서 후속 처리 요청(카테고리 분류, 중복 사진 판별 등)이 비동기적으로 발생
• FastAPI는 이러한 요청을 받아, 아래와 같은 작업별 Redis 메시지 큐에 등록
• 각 큐는 전용 Worker 프로세스가 실시간으로 작업을 소비

컴포넌트	역할
FastAPI	모든 이미지의 임베딩이 완료되면, 해당 상태를 Backend로 전달하여 처리 완료를 알림
Backend	처리 완료 상태를 수신하고, 필요한 후속 작업 요청(중복 탐지, 분류 등)을 FastAPI에 전송
FastAPI	후속 작업 요청을 받아, 작업 종류별로 Redis 메시지 큐에 등록
Redis (메시지 큐)	AI 작업 큐를 통해 요청을 비동기 처리 방식으로 전달
각 작업 전용 Worker	각 큐를 실시간으로 polling하여 소비하고, 해당 작업(중복 판별, 카테고리 분류 등)을 수행한 후 결과 저장 또는 응답 구성

d. FastAPI → 인물 분류

Backend → 인물 분류 요청 (앨범 단위)
     ↓
FastAPI → Redis 메시지 큐 등록
     ↓
Worker (Face Recog)
    → 이미지 URL → 얼굴 Crop
    → ArcFace 모델로 얼굴 임베딩 추출
    → 클러스터링 수행
     ↓
FastAPI → Backend에결과 전달

• Backend가 앨범 내 사진 속 인물을 자동으로 그룹핑해달라고 요청
• FastAPI는 요청을 받아, 메시지 큐에 작업 등록
• 해당 큐를 소비하는 Face Recognition 전용 Worker가 작업을 처리

컴포넌트	역할
FastAPI	사용자 요청 수신 + 메시지 큐 등록
Redis	비동기 인물 분류 요청 큐
Face Recog Worker	얼굴 Crop → ArcFace 임베딩 → 클러스터링
ArcFace 모델 (CPU 서버)	인물 식별을 위한 전용 임베딩 모델
FastAPI	결과를 사용자에게 전달 또는 정리된 뷰로 반환

e. FastAPI 서버 → 스타일 변환 요청 처리

Backend → 선택된 이미지 url + 스타일 요청
				↓
FastAPI → Gemini API 호출 (via Cloud NAT)
				↓
Gemini → 스타일용 프롬프트 응답
				↓
FastAPI → Redis GPU 스타일 큐 등록
				↓
GPU 서버 → 스타일 변환 수행
				↓
FastAPI → 결과 GCS 저장 → 결과 URL 반환

• 사용자가 요청한 사진과 스타일에 따라 Backend에서 스타일 변환 요청
• FastAPI는 요청을 받아:
  1. Cloud NAT를 통해 Gemini API에 이미지와 스타일 설명을 전달
  2. Gemini는 해당 이미지에 맞는 스타일 변환용 positive prompt를 생성하여 반환
• 생성된 프롬프트와 이미지 정보를 FastAPI가 Redis 스타일 요청 큐에 등록
• GPU 서버는 큐를 polling하여 요청을 소비하고, Stable Diffusion으로 스타일 변환을 수행
• 결과 이미지는 GCS에 저장되며, FastAPI가 결과 URL을 Backend에게 응답으로 전달

컴포넌트	역할
Backend	사용자가 선택한 이미지 URL과 스타일 정보를 FastAPI로 전달
FastAPI	스타일 요청 수신 → 이미지 + 스타일을 기반으로 Gemini API에 프롬프트 생성 요청
Cloud NAT	FastAPI 인스턴스가 GCP 외부로 나가 Gemini API를 호출할 수 있도록 인터넷 게이트웨이 역할 수행
Gemini API	이미지 및 스타일을 바탕으로 positive prompt(텍스트 설명) 생성
FastAPI	Gemini 응답으로 받은 프롬프트와 이미지 정보를 Redis 메시지 큐에 등록
Redis (GPU 큐)	Stable Diffusion용 스타일 요청을 GPU 서버에 비동기 전달
GPU 서버	큐를 polling하여 요청을 소비하고, Stable Diffusion 모델을 통해 이미지 스타일 변환 연산 수행
Cloud Storage (GCS)	변환된 이미지 결과를 저장
FastAPI	GCS에 저장된 이미지 URL을 조회해 Backend에 최종 결과로 전달