AI: 배포 아키텍처
ㅁ 배포 아키텍처
ㅇ 정의:
ㅇ 특징:
ㅇ 적합한 경우:
ㅇ 시험 함정:
ㅇ 시험 대비 “패턴 보기” 예시:
================================
1. Model-in-service
ㅇ 정의:
– 모델을 애플리케이션 코드 내부에 직접 포함하여 배포하는 방식으로, 모델 로직과 서비스 로직이 동일한 프로세스에서 실행됨.
ㅇ 특징:
– 배포 단순, 외부 호출 지연 없음.
– 모델 업데이트 시 애플리케이션 전체 재배포 필요.
ㅇ 적합한 경우:
– 모델 변경 빈도가 낮고, 소규모 애플리케이션에서 지연 최소화가 중요한 경우.
ㅇ 시험 함정:
– 모델이 애플리케이션과 분리 배포되는 것으로 잘못 혼동.
ㅇ 시험 대비 “패턴 보기” 예시:
– O: “모델과 서비스 로직이 동일 프로세스에서 동작한다.”
– X: “모델 업데이트 시 서비스 재배포 없이 가능하다.”
================================
2. Model-as-service
ㅇ 정의:
– 모델을 독립된 서비스로 배포하여 API 형태로 호출하는 방식.
ㅇ 특징:
– 모델과 애플리케이션이 분리되어 독립적 확장 가능.
– 네트워크 호출로 인한 지연 존재.
ㅇ 적합한 경우:
– 여러 애플리케이션에서 동일 모델을 공유하거나, 모델 변경이 잦은 경우.
ㅇ 시험 함정:
– 모든 경우에 지연이 없다고 오해.
ㅇ 시험 대비 “패턴 보기” 예시:
– O: “모델 변경 시 애플리케이션 재배포 없이 가능하다.”
– X: “네트워크 지연이 발생하지 않는다.”
================================
3. REST API
ㅇ 정의:
– HTTP 프로토콜 기반으로 리소스를 표현하고 조작하는 API 스타일로, 모델 서빙 시 표준화된 호출 방식 제공.
ㅇ 특징:
– 언어/플랫폼 독립적, 요청-응답 구조.
– 상태 비저장(stateless) 특성.
ㅇ 적합한 경우:
– 다양한 클라이언트에서 모델을 호출해야 하며, 표준화된 접근이 필요한 경우.
ㅇ 시험 함정:
– 상태 저장 방식으로 동작한다고 착각.
ㅇ 시험 대비 “패턴 보기” 예시:
– O: “HTTP 기반 요청-응답 구조를 사용한다.”
– X: “클라이언트 상태를 서버가 지속적으로 저장한다.”
================================
4. Batch Serving
ㅇ 정의:
– 다수의 요청을 모아 한 번에 처리하는 모델 서빙 방식.
ㅇ 특징:
– 처리 효율 높음, 지연 시간 증가 가능.
– 대량 데이터 처리에 적합.
ㅇ 적합한 경우:
– 실시간성이 덜 중요한 대규모 데이터 분석.
ㅇ 시험 함정:
– 실시간 처리에 항상 적합하다고 오해.
ㅇ 시험 대비 “패턴 보기” 예시:
– O: “여러 요청을 모아 한 번에 처리한다.”
– X: “응답 지연이 거의 없다.”
================================
5. Real-time Serving
ㅇ 정의:
– 요청이 들어올 때마다 즉시 모델 추론을 수행하는 서빙 방식.
ㅇ 특징:
– 지연 시간 최소화, 요청 단위 처리.
– 고가용성 및 빠른 응답 필요.
ㅇ 적합한 경우:
– 챗봇, 실시간 추천 등 즉시 응답이 필요한 서비스.
ㅇ 시험 함정:
– 항상 처리 효율이 높다고 착각.
ㅇ 시험 대비 “패턴 보기” 예시:
– O: “요청 시 즉시 추론을 수행한다.”
– X: “여러 요청을 모아 처리한다.”
================================
6. Version Compatibility
ㅇ 정의:
– 모델 버전 간 호환성을 유지하여, 서비스 중단 없이 모델 교체 또는 롤백이 가능하게 하는 개념.
ㅇ 특징:
– API 스펙, 입력/출력 형식 일관성 필요.
– 다중 버전 동시 운영 가능.
ㅇ 적합한 경우:
– 지속적인 모델 개선이 필요한 프로덕션 환경.
ㅇ 시험 함정:
– 버전 호환성을 무시해도 서비스에 영향이 없다고 오해.
ㅇ 시험 대비 “패턴 보기” 예시:
– O: “모델 변경 시 API 형식이 동일해야 한다.”
– X: “버전이 달라도 입력 형식이 달라져도 무방하다.”
ㅁ 추가 학습 내용
1) Model-in-service vs Model-as-service 비교
– 성능: Model-in-service는 애플리케이션 내부에 모델이 포함되어 네트워크 호출이 적어 지연이 낮으나, 애플리케이션 업데이트 시 모델 재배포 필요. Model-as-service는 모델이 독립 서비스로 동작하여 네트워크 호출로 인한 지연이 있으나, 모델만 독립적으로 업데이트 가능.
– 확장성: Model-in-service는 애플리케이션과 함께 확장되므로 모델 부하에 따른 유연한 확장이 어려움. Model-as-service는 모델 서버를 독립적으로 확장 가능.
– 유지보수성: Model-in-service는 코드와 모델이 결합되어 있어 변경 시 영향 범위가 큼. Model-as-service는 서비스 간 결합도가 낮아 유지보수가 용이.
2) REST API, gRPC, GraphQL 비교
– REST API: HTTP 기반, 표준화된 인터페이스, 언어와 플랫폼 독립적, 상대적으로 단순하지만 데이터 전송량이 많아질 수 있음.
– gRPC: HTTP/2 기반, 바이너리 프로토콜(Protocol Buffers) 사용, 빠른 속도와 양방향 스트리밍 지원, 클라이언트와 서버 간 강한 타입 보장.
– GraphQL: 클라이언트가 필요한 데이터만 요청 가능, over-fetching/under-fetching 문제 해결, 단일 엔드포인트 사용, 쿼리 복잡성 관리 필요.
3) Batch Serving
– 배치 크기와 처리 지연: 배치 크기가 커질수록 처리 효율은 증가하지만 응답 지연이 길어짐. 작은 배치는 지연이 짧으나 처리 효율이 낮음.
– 구현 예시: Spark를 이용한 분산 데이터 처리, Hadoop MapReduce 기반의 대규모 데이터 배치 예측 처리.
4) Real-time Serving
– 캐싱 전략: 자주 요청되는 예측 결과를 캐시에 저장하여 응답 속도 향상.
– 로드 밸런싱: 여러 모델 서버에 요청을 분산하여 부하를 균등화.
– Auto-scaling: 트래픽 변화에 따라 서버 인스턴스를 자동으로 증감.
5) Version Compatibility 유지 방법
– Canary Deployment: 일부 사용자에게만 새 버전 배포 후 안정성 확인 후 전체 배포.
– Blue-Green Deployment: 두 개의 환경을 유지하며 새 버전을 배포한 환경으로 트래픽 전환.
– A/B 테스트: 사용자 그룹별로 다른 버전을 사용하여 성능 비교.
6) 모델 서빙 시 보안 고려사항
– 인증/인가: 사용자 및 서비스의 접근 권한 검증.
– 데이터 암호화: 전송 및 저장 데이터의 암호화 처리.
– 요청 제한: 과도한 요청으로 인한 서비스 장애 방지.
7) 클라우드 환경 배포 아키텍처 사례
– AWS SageMaker: 모델 학습, 배포, 모니터링을 통합 지원, 엔드포인트 생성으로 실시간/배치 서빙 가능.
– Google AI Platform: 모델 버전 관리, REST/gRPC API 제공, Auto-scaling 지원.
– Azure ML: 모델 패키징, 컨테이너 기반 배포, Kubernetes 연동 가능.