ㅁ 배포 아키텍처

ㅇ 정의:
모델을 API 형태로 배포하여 외부 애플리케이션이나 서비스에서 실시간으로 호출할 수 있도록 제공하는 방식.

ㅇ 특징:
– REST API, gRPC 등 네트워크 프로토콜을 통해 모델 예측 결과를 제공
– 모델과 애플리케이션이 분리되어 있어 확장성과 유지보수 용이
– 실시간 응답 속도가 중요하며, 서버 자원과 네트워크 대역폭 관리 필요
– 컨테이너(Docker)와 오케스트레이션(Kubernetes) 환경에서 자주 사용

ㅇ 적합한 경우:
– 다수의 애플리케이션에서 동일한 모델을 호출해야 하는 경우
– 모델 업데이트를 중앙에서 관리하고 즉시 반영해야 하는 경우
– 실시간 또는 준실시간 예측 서비스가 필요한 경우

ㅇ 시험 함정:
– Batch inference와 혼동하여 대량 처리 중심으로 설명하는 경우 오답
– 모델과 애플리케이션이 같은 프로세스에서 동작한다고 잘못 이해하는 경우
– 서버리스 함수형 배포와 구분하지 못하는 경우

ㅇ 시험 대비 “패턴 보기” 예시:
O: “REST API를 통해 실시간 예측을 제공하는 구조”
O: “모델과 애플리케이션이 네트워크를 통해 분리되어 동작”
X: “대량 데이터를 주기적으로 처리하는 데 최적화된 구조”
X: “모델이 애플리케이션 코드 내부에 직접 포함되어 배포되는 구조”

ㅁ 추가 학습 내용

추가 학습 정리

1. Model-in-service 성능 최적화 기법
– 모델 로딩 지연 최소화: 모델을 메모리에 미리 로드하거나, Lazy Loading 대신 Warm-up 요청을 통해 초기 응답 지연을 줄임
– 멀티스레딩/멀티프로세싱 적용: CPU/GPU 자원 활용 극대화를 위해 병렬 처리 구조 설계, Python의 경우 GIL 제약에 따른 multiprocessing 활용 고려

2. API Gateway와 Load Balancer를 통한 트래픽 분산 및 보안
– API Gateway: 인증, 권한 부여, 요청 라우팅, 속도 제한, 로깅 등 중앙 집중식 관리
– Load Balancer: 서버 인스턴스 간 트래픽 균등 분산, 장애 서버 자동 제외, SSL 종료 처리

3. 모델 버전 관리 전략
– A/B 테스트: 서로 다른 모델 버전을 동시에 서비스하여 성능 비교
– Canary Deployment: 신규 버전을 소량 트래픽에만 적용 후 점진적 확대

4. 서버리스 환경에서의 Model-in-service 구현 차이
– 인스턴스가 요청 시에만 실행되므로 콜드 스타트 지연 발생 가능
– 상태 저장이 어렵고, 외부 스토리지나 캐시 서비스 활용 필요
– 자동 확장과 비용 효율성 장점

5. 모니터링 및 로깅 체계 구축
– Prometheus: 메트릭 수집 및 시각화, 경보 설정
– ELK Stack(Elasticsearch, Logstash, Kibana): 로그 수집, 저장, 검색, 분석 및 대시보드 제공

6. 장애 복구 및 자동 확장 전략
– 장애 복구: 헬스 체크, 자동 재시작, 장애 감지 후 대체 인스턴스 생성
– 자동 확장(Auto-scaling): CPU/GPU 사용량, 요청 수, 지연 시간 등에 기반한 동적 자원 확장/축소