중요한건 꺾이지 않는 맥북
ML Ops 본문
모델러 + 엔지니어
모델러는 모델을 개발하고 학습시키며 성능 평가를 하는 사람을 뜻하고 개발된 모델을 서빙가능한 형태로 최적화시키는 사람을 엔지니어라 정의한다.
그렇다면 이 둘을 어떻게 조합시킬 수 있을까?
아무리 잘 만들어진 모델이라도 서빙하는 과정에서 제한된 리소스를 얼마나 최적으로 사용할 수 있고
이 훌륭한 모델을 엔지니어링을 통해 검증하고 배포하고 다시 재학습시키고의 순환을 가능케 해야한다.
하지만 과거에는 두 기술이 유기적으로 작동해야했지만 영역이 달라서 매끄럽지 못했다.
1. 쿠버네티스의 활용 (K8S)
추상화된 리소를 활용하게 하는 노드 스케줄링, 안정화에 많은 기능을 제공하기 때문에 쿠버네티스를 활용하여 모델 서빙을 위한 컴포넌트를 구성했다.
2. 모델 서빙을 위한 필수 요소
3. CLops 개요 - 각 5대요소에 대한 디테잏한 설명 추가, 5대요소가 왜 필요한지?
- 쿠버네티스의 스케줄러 커스텀하여 구현
3. 전체적인 아키텍처 -
모델서버에는 executor라는 것이 같이 배포되어있다. 모델 서버의 리버스 프록스 역할을 한다. 동기 비동기 호출에 대한 지원, 메트릭 관리, 인증지원 등 많은 역할을 수행중이다.
그리고 서빙되는 모델에 대한 트래픽은 Istio를 활용하여 관리하고 있다. https://velog.io/@beryl/Istio-%EA%B0%9C%EB%85%90
- Authenticator
접근 제어, 프로젝트별 권한 관리
이 중 Webhook 인증 방식을 사용하고 있음. 사내 시스템 깃헙 등 연동 가능, 사용자관련 롤 정보 지정 가능
해당 프로젝트는 쿠버네티스 상에서의 네임스페이스를 의미한다. 해당 프로젝트 권한, C/GPU, 다른사용자 추가 가능
디테일은 아래와 같다.
웹훅 컨피그 파일을 다음과 같이 설정해서 사용가능하다.
- Operator
모델 엔지니어링 경험이 적을 경우 필요한 기능을 만드는 데 많은 비용이 발생, 대부분의 기능은 재사용이 가능하게 구현이 가능하기 때문에 표준화하여 제공한다면 쉽고 빠르게 배포할 수 있다. 이는 위의 SDK를 활용해서 쉽게 구현 가능하다.
kubebulider https://ssup2.github.io/programming/Kubernetes_Kubebuilder/
쿠버네티스 리소스는 다음과 같이 사용이 가능하다. 기본적으로 제공해주는 리소스 외에 쿠버네티스 확장을 할 수 있도록 커스텀 리소스를 제공해주고 있다.
사용자의 요구사항명세를 커스텀 리소스 형태로 저장하고 이 오브젝트의 변화 이벤트를 트리거로 받아서 현재 상태와 비교한다.
요구상태와 현재상태를 비교하여 변화된 내용을 바탕으로 현재 상태를 조정한다.
이렇게 단순하지만 선형적인 형태이기 때문에 쉽게 쿠버네티스를 확장할 수 있었다.
operator는 reconciler 하기 전에 커스텀 리소스가 문제없는지 검증하고 조건에 맞게 값 변경이 필요
위 세개의 단계가 모두 통과하면 비로소 요구사항이 오퍼레이터에게 전달된다.
이 때 요구사항이 바로 오퍼레이터에 전달되는 것이 아니라 이벤트가 오퍼레이터가 관리하는 큐에 적재된다.
이런 큐의 존재로 오퍼레이터는 요구상태과 현재상태를 순차적으로 비교하고 리컨실러 과정을 쉽게 수행한다.
최종적으로 쿠버네티스의 코어 리소스(deployment,service...)를 생성하는 구조를 띄게 된다.
위 사진의 프로세스를 설명하자면, 순차적으로 A 요구상태과 현재상태를 비교하여 상태가 다르다면 상태에 맞게 조정한다.
그리고 어떠한 액션을 취하거나 조정과정 중 에러가 발생한다면 다시 처음부터 상태 비교를 할 수 있도록 requeueing 과정이 일어나난ㄷ,
이러한 Requeueing 과정은 리컨실러 과정을 검증하는 단계이다.(요구사항에 맞게 변경된 현재상태가 요구상태와 다른지 검증)
이 때, A의 현재상태는 요구상태로 조정이 완료되었기 때문에 reconcile을 하지않고 다음 리소스인 B의 요구상태를 추출하여 현재상태와 비교한다.
모든 과정이 조정되었다면 최종적으로 커스텀 리소스의 Status를 업데이트하고 Reconcile 단계를 마무리한다.
모델 어플리케이션을 건드리지 않고 앞 단에 executor 추가로 주입하여 일반화된 endpoint를 제공하거나 프록싱하는 과정에서 로깅, 메트릭과 같은 미들웨어 추가가 용이해진다.
- Scheduler
스케줄링할수있는 대상노드를 선정하는 과정이다. 필터링 이전에 스케줄링 팟을 원하는 순서로 소팅하는 queue sort단계가 있다. 이후 해당 팟이 필터링 대상인지 걸러낸다. 이렇게 선별된 팟은 스케줄링 노드를 선정하는 필터링 단계를 거치게 된다.
이때 필터링할 팟이 하나도 없는 경우, postfilter를 통해 클린업 단계를 진행하고 남은 스테이지 실행 안함.
만약 하나라도 잇으면 노드 스코어링 단계로 넘어간다. 스코어링단계는 앞서 선정된 대상 노드들의 점수를 매기는 단계이다.
앞서 선정된 노드를 예약할지말지 결정하는 Reserve단계, 승인을 하는 Permit단계...등
메인 스레드가 돌아가면서 이와 동시에 permit스레드가 해당 스케줄을 승인, 대기 처리하고 실제 팟과 노드간의 바인딩을 처리하는 Bind스레드로 구성
경쟁조건의 우위 문제 때문에 스케줄링에 대한 이해가 중요!!!
-> 병렬 스레드간 경쟁 상태가 없도록 구현, 단일 스케줄 사이클 내 정보 공유
- Horizontal Pod Autoscaler (HPA) https://medium.com/dtevangelist/k8s-kubernetes%EC%9D%98-hpa%EB%A5%BC-%ED%99%9C%EC%9A%A9%ED%95%9C-%EC%98%A4%ED%86%A0%EC%8A%A4%EC%BC%80%EC%9D%BC%EB%A7%81-auto-scaling-2fc6aca61c26
기존 쿠버네티스 HPA의 한계: CPU/메모리 기반 HPA 는 모델 서빙을 위한 HPA 메트릭으로 적합하지 않음
사용자 정의(요청수,Latency, GPU 등) 기반 HPA 메트릭 필요
이스티오 텔레메트리를 통해 네트워크 통계정보를 프로메테우스를 통해 모은다.
이 정보들은 커스텀 메트릭 어댑터를 통해 쿠버네티스 HPA 리소스가 사용할 수있도록 제공
-> 내부적으로 얻은 메트릭을 통해 모델 어플리케이션 HPA 를 적용할 수 있음
따라서, 요청량에 따른 오토스케일링을 단순화 할 수 있었다.
모델러는 사용하고자 할 메트릭 종류를 설정하고 임계값에 대한 요구 명세를 제출, 이 명세를 통해 HPA는 주기적으로 스케일 아웃/인의 액션을 결정
- model registry
학습 머신러닝 모델
하나의 공간에서 모델이 작동가능
모델 버전관리
롤백의 단순화, A/B 테스트 가능
재사용성
SDK로 개발 가능
저장공간 확보
실행환경과 학습 모델을 분리
따라서 리빌딩할 때 손쉬운 관리
리빌딩한 모델을 재 다운로드 받을 시 엄청난 용량의 문제점이 수반되기 때문에 저장공간에 대한 캐싱 처리
따라서, 거대 사이즈의 모델을 업로드할 시 시간 많이 소요되는 문제점을 해결했고 멀티스레드 방식을 사용하여 데이터전송률을 향상시켰다.
네트워크 스토리지는 대부분 디스크 저장공간 보다 비싸기 때문에 캐싱 모델을 사용함으로써 장점이 생겼고 모델 배포에 용이해졌고, 거대 모델의 사용성을 확대했다.
- Synchronous / Asynchronous
리퀘스트와 예측까지의 걸리는 시간이 거의 동기에 처리된다.(비디오같은 경우는 예외)
1. 메시지 큐를 비동기 인풋으로 사용
2. 리퀘스트 바디가 크다면 예측 데이터를 저장
3. 메시지큐를 통해 결과 정보 획득
4. 웹훅을 통해 결과 정보 획득
비동기식 API 서버를 활용하여 client의 queue를 message queue로 변환, storage에 저장된 결과값를 읽어옴
이를 통해 ,
provider는 리퀘스트를 접근하는 방식과 엔드포인트에 대한 제한을 컨트롤
사용 가이드 필요
consumer는 리퀘스트를 보낸 클라이언트임을 알 수 있음
단체/개인고객인지 연결
클라이언트 별 접근 제한 및 검사 가능
API 토큰 포함
