ㅁ 웹 배포 및 서버리스

ㅇ 정의:
서버리스 모델 서빙은 애플리케이션이나 머신러닝 모델을 실행하기 위해 서버 인프라를 직접 관리하지 않고, 클라우드 제공자의 서버리스 컴퓨팅 서비스를 활용하여 요청 시 자동으로 실행되는 방식이다.

ㅇ 특징:
– 서버 관리 불필요: 인프라 프로비저닝, 확장, 패치 작업을 클라우드가 처리
– 이벤트 기반 실행: HTTP 요청, 메시지 큐, 스케줄러 등에 의해 트리거됨
– 초 단위 과금: 실행 시간과 리소스 사용량 기반 비용 부과
– 확장성: 요청량에 따라 자동 확장/축소

ㅇ 적합한 경우:
– 예측 불가능한 요청 패턴의 모델 서빙
– 간헐적 사용이 많아 상시 서버 유지가 비효율적인 경우
– 빠른 프로토타이핑 및 배포가 필요한 경우

ㅇ 시험 함정:
– 서버리스는 ‘서버가 없는 것’이 아니라 ‘서버 관리를 하지 않는 것’임을 혼동
– 장시간 지속 실행 작업에는 부적합하다는 점 간과
– 콜드 스타트 지연이 발생할 수 있음

ㅇ 시험 대비 “패턴 보기” 예시:
O: 서버리스 모델 서빙은 이벤트 기반으로 자동 확장되며, 사용량에 따라 과금된다.
X: 서버리스 모델 서빙은 서버가 전혀 존재하지 않는 환경에서만 동작한다.

ㅁ 추가 학습 내용

서버리스 모델 서빙 추가 학습 정리

1. 대표 서비스 예시와 ML 서빙 통합 방식
– AWS Lambda: Amazon SageMaker, API Gateway, S3 등과 연계하여 모델 호출 가능
– Google Cloud Functions: AI Platform, Cloud Storage, Pub/Sub 등과 통합
– Azure Functions: Azure Machine Learning, Blob Storage, Event Grid 등과 연계
– 각 서비스는 이벤트 기반 호출과 클라우드 내 ML 서비스 연동을 통한 유연한 배포 가능

2. 콜드 스타트 문제 해결 방안
– 프로비저닝된 동시성(Provisioned Concurrency) 설정으로 인스턴스 미리 준비
– 주기적 호출(keep-alive)로 함수 인스턴스가 종료되지 않도록 유지
– 코드 및 의존성 최소화로 초기 로딩 시간 단축

3. 서버리스와 컨테이너 기반 서빙 비교
– 성능: 컨테이너는 지속 실행으로 지연이 적음, 서버리스는 콜드 스타트로 지연 가능
– 비용: 서버리스는 사용량 기반 과금으로 유휴 자원 비용 절감, 컨테이너는 상시 실행 비용 발생
– 유지보수: 서버리스는 인프라 관리 부담 적음, 컨테이너는 환경 제어 가능하지만 관리 필요

4. 보안 고려사항
– 무상태 아키텍처에서의 인증·인가: 토큰 기반 인증(JWT 등) 활용, API Gateway와 연계
– 환경변수 관리: 비밀정보는 Secret Manager, Parameter Store 등 안전한 저장소 사용

5. 데이터 전송 지연과 네트워크 비용 영향
– 모델 응답시간은 네트워크 지연(latency)에 민감
– 대규모 데이터 전송 시 전송 시간 증가 및 네트워크 사용 비용 발생
– 데이터 압축, 지역(Region) 최적화로 지연 최소화

6. 로그 수집 및 모니터링 도구 활용
– AWS: CloudWatch Logs, X-Ray
– Google Cloud: Cloud Logging, Cloud Monitoring
– Azure: Application Insights, Monitor
– 로그를 통한 성능 분석, 오류 추적, 호출 빈도 모니터링으로 안정적 운영 가능