ML 모델 서빙, 모니터링, 유지보수

모델 서빙 런타임의 특성

모델 서빙 런타임은 모델을 입력 데이터에 적용하는 환경이다.
런타임의 특성은 배포패턴에 따라 결정되는데 효과적인 런타임의 특성을 알아보자.

1. 보안 및 정확성

런타임은 사용자 인증과 사용자 요청 승인을 담당한다. 그래서 특정 사용자가 실행하려는 모델에 대한 접근권한이 있는지, 전달된 매개변수의 이름과 값이 모델 규격과 일치하는 지, 이러한 매개변수와 매개변숫값이 현재 사용자에게 제공되는지 여부를 파악해야한다.

2. 배포 용이성

런타임은 최소한의 노력으로 가장 이상적으로 전체 애플리케이션에 영향을 주지 않고 모델을 업데이트할 수 있어야합니다.

• 물리적 서버에 모델 배포
  모델 업데이트는 모델 파일을 다른 모델 파일로 교체 후 웹서비스 다시 시작
• 가상머신 인스턴스나 컨테이너
  이전 모델 실행 중인 인스턴스 점차 중지해가며 새 이미지에서 새로운 인스턴스 실행
• 스트리밍 기반 애플리케이션
  스트리밍 애플리케이션이 스테이트풀해야한다. 새로운 버전과 구성요소가 애플리케이션으로 스트리밍되면 애플리케이션 상태가 변경되고 이제 이러한 구성요소의 새 버전이 반영된다. 최신 스트림 처리 엔진은 상태 유지 가능한 애플리케이션을 지원한다.
  

3. 모델 유효성 보장

효과적인 런타임은 실행 중인 모델이 유효한지를 자동으로 확인한다. 모델, 특징 추출기, 기타 구성 요소가 동기화되어 있는지도 확인한다.
웹 서비스나 스트리밍 응용 프로그램을 시작할때마다 그리고 실행시간 동안 주기적으로 검증해야한다.

4. 복구 용이성

효과적인 런타임은 이전 버전으로 롤백하여 오류를 쉽게 복구할 수 있어야합니다.

5. 훈련/서빙 왜곡 방지

모델 훈련용과 운영 환경에서의 채점용 서로 다른 코드베이스를 사용하지 않는 것이 좋습니다. 특징 추출시, 두 버전의 특징 추출기 코드 사이에 작은 차이라도 있으면 모델 성능이 최적화 되지 않거나 부정확해질 수 있습니다.

6. 숨겨진 피드백 루프 방지

예를 들어, 모델 b는 모델 a가 모델 b의 출력을 특징으로 사용한다는 사실을 모른채 모델 a의 출력을 특징으로 사용하는 경우가 있습니다.

모델 서빙 모드

배치 모드 서빙

일반적으로 대량의 입력 데이터에 모델을 적용할 때 배치모드로 서빙됩니다.
가령, 제품이나 서비스의 모든 사용자 데이터를 모델로 처리하는 경우에 배치모드로 사용된다.
배치모드는 주문형 모드에 비해 자원 효율성이 더 높은데 약간의 시간 지연이 허용될 때 사용한다.
배치 모드로 서빙하는 경우 일반적으로 모델은 한 번에 100~1000개 특징 벡터를 사용합니다.
배치처리 출력은 특정 소비자에게 보내는 것이 아니라 데이터베이스에 저장합니다.

인간에 대한 주문형 서빙

주문형 모델을 서빙하는 6단계는
1. 요청 확인
2. 맥락 취합
3. 맥락을 모델 입력을 변환
4. 모델을 입력에 적용하고 출력을 얻는다.
5. 출력이 적절한지 확인한다.
6. 사용자에게 출력을 제공

운영 환경에서 사용자의 요청에 따라 모델을 실행하기 전에 해당 사용자가 이 모델에 대한 올바른 사용 권한을 가지고 있는지 확인해아합니다.

맥락
맥락은 사용자가 머신러닝 시스템에 요청을 보낼 때와 시스템의 응답을 받을 때 사용자의 상황을 나타낸다.
특징 추출기가 모델 훈련에 필요한 모든 특징값을 추출하기 위해 필요한 정보가 포함된다. 로그에 저장할 수 있을만큼 크기가 작고 디버깅을 위한 충분한 정보와 시간이 지남에 따라 모델을 개선하는 데 사용할 수 있는 정보를 포함하고 있다.

특징 추출기는 맥락을 모델 입력으로 변환한다. 인간 고객에게 서빙하는 경우 채점 결과를 그대로 전달하는 경우는 거의 없고 채점 코드는 사용자의 이해를 돕기 위해 모델의 예측을 보다 쉽게 해석할 수 있는 형식으로 변환한 후 전달한다.

머신에 대한 주문형 서빙

REST API를 구축하는 것이 적합하지만 종종 스트리밍을 통해 머신에게 서빙한다. 실제로 머신의 데이터 관련 요구 사항은 대체로 표준을 따르고 미리 결정되어 있습니다. 잘 설계된 고정된 스트리밍 애플리케이션 토폴로지를 통해 가용자원을 효율적으로 사용할 수 있습니다.

클라우드에서 가상 자원을 사용하는 경우, 오토스케일링을 통해 필요할 때 더 많은 자원을 추가하고 수요를 감소하면 해제할 수 있습니다. 하지만 오토스케일이 갑작스런 수요 급증에 대처하지 못하는 경우도 있는데 이런 상황에 대처하기 위해 주문형 아키텍처에는 RabbitMQ나 아파치 카프카와 같은 메시지 브로가 있다.

메시지 브로커

메시지 브로커를 통해 한 프로세스가 큐에 메시지를 쓰고 다른 프로세스가 해당 큐에서 읽을 수 있다. 주문형 요청은 입력 대기열에 쌓이고, 모델 런타임 프로세스는 주기적으로 브로커를 통해 입력 큐로부터 입력 데이터 요소를 배치 단위로 읽고 배치 모드에서 각 요소에 대한 예측을 생성한다. 그 다음 출력 대기열에 예측을 기록합니다.
다른 프로세스는 주기적으로 브로커에 연결하고, 출력 큐에서 예측을 읽어와 요청을 보낸 사용자에게 전달한다.
이러한 접근방식은 수요 급증에 대처할 수 있을 뿐만 아니라 자원 효율적이다.

현실에서 모델 서빙

현실에서 사용자가 시스템과 실제 상호작용하게되면 여러가지 예측 불가의 상황을 마주하게된다.
따라서 현실적인 소프트웨어 시스템의 아키텍처는 오류, 변화, 인간 본성이라는 세가지 상황에 대비해야한다.

오류에 대비

모든 소프트웨어는 오류가 불가피하다. 따라서 모든 오류를 해결할 수 없기에 유일한 방법은 오류를 수용하는 것이다.

오류를 수용한다는 것은 오류가 발생해도 시스템이 계속 정상적으로 작동할 수 있도록 소프트웨어 시스템을 설계하는 것이다.

변화에 준비

일반적으로 머신러닝 기반 시스템의 성능은 시간이 지남에 따라 변한다.
성능 저하의 이유는 개념이동 때문이다. 올바른 예측인 무엇인지에 대한 개념은 사용자의 선호도와 관심사로 바뀔 수 있다. 따라서 최근에 레이블링한 데이터를 사용하여 모델을 다시 훈련해야한다.

그러나 변화된 모델의 결과가 사용자에게 긍정적으로 인식되면 좋지만 그렇지 안흥ㄹ 수도 있다.
따라서 사용자가 변화를 부정적으로 인식할 수 있다고 예상되는 경우, 사용자에게 적응할 시간을 주고, 변경사항과 새 모델을 기대할 수 있는 사항을 교육해야한다.

모델 모니터링

배포한 모델은 지속적으로 모니터링해야한다.
모니터링을 통해 모델이 올바르게 서빙되고 있는지, 모델의 성능이 허용 가능한 범위 내에서 유지되고 있는지를 확인할 수 있다.

모델에 신뢰도 테스트 세트를 적용해서 합리적인 성능 지표를 생성하는지 모니터링을 통해 확인해야한다. 신뢰도 테스트 세트는 분포 이동을 방지하기 위해 정기적으로 새로운 데이터로 업데이트해야한다. 또한 종단 간 세트의 견본으로 정기적으로 모델을 테스트해야한다.

정확도, 정밀도, 재현율 모두 좋은 모니터링 후보지만 시간경과에 따른 변화를 측정하는 데 특히 유용한 지표로 예측 편항이 있습니다.

또한, 모델의 수치적 안정성도 모니터링해야한다. NaN이나 무한대가 관찰되면 경고를 해야합니다.

분포이동을 방지하려면 다음과 같이 모니터링을 자동화해야합니다.

1. 일정기간동안 랜덤으로 입력 모은다.
2. 이러한 입력을 레이블링한다.
3. 모델을 실행하고 성능 지푯값을 계산한다.
4. 중대한 성능 저하가 이쓴ㄴ 경우 이해 관계자에게 알린다.

추천시스템은 추가적으로 클릭률(CTR)이 간소하면 모델을 업데이트해야합니다.

전체 프로세스를 추적할 수 있도록 모니터링 이벤트를 기록한다. 시각적으로 모델 성능을 분석하기 위해 모니터링 도구의 사용자 인터페이스는 시간이 지남에 따라 모델 저하가 어떻게 변화하는 지 보여주는 추세 차트를 제공해야한다.

모델 유지보수

업데이트 시기

업데이트 시기의 기준이 된 모델 신선도는 비즈니스 요구와 사용자의 요구에 따라 달라집니다.
또한, 모델에 따라 달라지는데요 초매개변수 검색이 필요한 모델의 경우, 모델 구축하는 데 시간이 오려걸리므로 쉽게 업데이트하기 어렵고 이런 경우 모델 업데이트 빈도를 줄입니다.

업데이트 방법

많은 회사에서는 새로운 훈련 데이터를 확보하는 즉시 자동으로 모델을 훈련하는 지속적인 통합 워크플로를 사용한다.