ㅁ 배포 아키텍처

1. Model-as-service

ㅇ 정의:
– 학습된 AI 모델을 API 형태로 배포하여 외부 애플리케이션이 네트워크를 통해 호출하여 사용할 수 있도록 하는 방식.
– 모델은 중앙 서버나 클라우드 환경에서 실행되며, 요청에 따라 결과를 반환.

ㅇ 특징:
– 모델 업데이트 및 관리가 중앙집중식으로 용이.
– 다양한 클라이언트(웹, 모바일, IoT 등)에서 동일한 모델을 공유 가능.
– 확장성(Scalability) 확보가 용이하나 네트워크 지연(latency)에 영향을 받음.
– REST API, gRPC 등 표준 통신 프로토콜 사용.

ㅇ 적합한 경우:
– 여러 서비스나 애플리케이션에서 동일한 모델을 활용해야 하는 경우.
– 모델 크기가 커서 로컬 배포가 어려운 경우.
– 모델 보안 및 접근 제어가 중요한 경우.

ㅇ 시험 함정:
– Model-as-service는 반드시 클라우드에서만 동작한다(O/X) → X (온프레미스 서버에서도 가능)
– Model-as-service는 모델을 클라이언트에 직접 배포하는 방식이다(O/X) → X (서버에 모델이 위치)

ㅇ 시험 대비 “패턴 보기” 예시:
– “Model-as-service는 API 형태로 모델을 제공하며, 클라이언트는 모델의 내부 구조에 접근하지 않는다.” (O)
– “Model-as-service 방식은 로컬 환경에서만 동작하며, 확장성이 낮다.” (X)
– “Model-as-service는 REST API, gRPC 등을 통해 서비스화할 수 있다.” (O)

ㅁ 추가 학습 내용

추가 학습 정리

1. MLOps 파이프라인에서 Model-as-a-Service의 위치와 역할
– 모델 학습 이후 배포 단계에서 API 형태로 모델을 제공
– 예측 요청을 실시간으로 처리하며, 다른 서비스나 애플리케이션이 쉽게 접근 가능
– 모델 모니터링, 성능 관리, 자동 재배포와 연계

2. 서버리스 아키텍처와의 결합 가능성
– 서버 관리 없이 이벤트 기반으로 모델 호출 가능
– 필요 시 자동 확장, 유휴 시 비용 절감
– 짧은 응답 시간과 간헐적 요청 처리에 유리

3. 모델 버전 관리 및 A/B 테스트 전략
– 모델 변경 시 버전 태깅과 이력 관리 필수
– A/B 테스트로 서로 다른 모델 버전을 동시에 서비스하여 성능 비교
– 트래픽을 일정 비율로 분할하여 실험

4. 대규모 트래픽 처리 시 로드밸런싱 기법
– 요청을 여러 서버나 인스턴스로 분산 처리
– 라운드 로빈, 최소 연결 수, 지연 시간 기반 분산 등 다양한 방식 활용
– 장애 발생 시 자동으로 다른 인스턴스로 우회

5. Model-as-a-Service와 모델 임베디드 배포(Edge AI)의 차이점
– 네트워크 지연: Model-as-a-Service는 네트워크 왕복 지연 발생, Edge AI는 로컬 처리로 지연 최소화
– 보안: Model-as-a-Service는 전송 구간 보안 필요, Edge AI는 데이터가 로컬에 머물러 전송 위험 감소
– 유지보수: Model-as-a-Service는 중앙에서 모델 업데이트가 용이, Edge AI는 각 디바이스별 업데이트 필요