[ML] 머신러닝 시스템 설계 : 10장 MLOps를 위한 인프라와 도구

해당 게시물은 ML 프로덕션 환경 속에 있는 내가 모델 개발에만 열중하고 전반적인 시스템 설계에 대한 배경지식이 없었던 와중에 옆자리 팀원한테 추천 받아서 읽게된 한빛미디어의 "머신러닝 시스템 설계"를 공부하면서 요약한 게시물로, 저작권은 한빛미디어에게 있겠습니다.

---

10. MLOps를 위한 인프라와 도구

• 많은 데이터 과학자는 ML 시스템을 개선하려면 무엇을 해야 하는지 알지만 그것을 지원하는 인프라가 제대로 설정돼 있지 않아 진행에 어려움을 겪음
• ML 시스템은 복잡해서, 인프라에 발생하는 편익 또한 큼
• 인프라를 올바르게 설정하면 프로세스를 자동화해 전문 지식과 엔지니어링 공수를 줄일 수 있어, ML 애플리케이션 개발과 제공 속도를 높이고 버그가 존재하는 영역을 줄여 새로운 유스 케이스를 만들어 냄
• 각 회사에 필요한 인프라는 개발하는 애플리케이션의 개수와 전문성 수준에 따라 다름
• 필요에 맞게 올바른 인프라를 구축하려면 인프라가 무엇을 의미하며 무엇으로 구성되는지 정확히 이해해야 함
• 인프라는 '가정과 기업의 지속 가능한 기능을 지원하는 기본 시설과 시스템 집합' 이고, ML 세계에서 인프라란 ML 시스템의 개발과 유지 관리를 지원하는 기본 시설의 집합

기본 시설
[1] 스토리지와 컴퓨팅

• 스토리지 레이어에서는 데이터가 수집되고 젖아되며, 컴퓨팅 레이어는 모델 훈련, 피처 연산, 피처 생성 등 ML 워크로드를 실행하는 데 필요한 연산 자원을 제공함

[2] 자원 관리
-자원 관리는 사용 가능한 연산 자원을 최대한 활용할 수 있도록 워크로드 일정을 수립하고 오케스트레이션하는 도구로 구성됨
에어플로(Airflow), 쿠버플로(Kubeflow), 메타플로(Metaflow)

[3] ML 플랫폼

• ML 플랫폼은 모델 스토어, 피처 스토어, 모니터링 도구 같은 ML 애플리케이션 개발을 위한 도구를 제공함.
  세이지메이커, MLflow

[4] 개발환경

• 개발 환경은 일반적으로 코드가 작성되고 실험이 실행되는 곳
  코드는 버전 관리 및 테스트가 수행되고 실험은 추적되어야 함

• 데이터와 연산은 ML 프로젝트에 반드시 필요한 필수 자원이므로 스토리지와 컴퓨팅 레이어는 ML을 적용하려는 모든 회사의 인프라 기반을 형성함.

• 개발 환겨애은 데이터 과학자가 매일 상호 작용해야 하는 대상으로 덜 추상적임

10-1. 스토리지와 컴퓨팅

• ML 시스템은 대량의 데이터로 작동하며 이 데이터는 어딘가에 저장돼야 함

• 스토리지 레이어는 데이터가 수집되고 저장되는 곳으로 가장 단순한 형태는 하드 드라이브 디스크(HDD) 나 솔리드 스테이트 디스크(SDD) 임

• 스토리지 레이어는 한곳에 있을 수도 있고, 다양한 위치에 분산돼 있을 수도 있음

• 스토리지 레이어는 프라이빗 데이터 센터의 온프레미스에 있을 수도 있고 클라우드에 있을 수도 있음

• 컴퓨팅 레이어는 회사가 접근할 수 있는 모든 연산 자원과 그 사용법을 결정하는 메커니즘

• 사용 가능한 연산 자원의 양은 워크로드 확장성을 결정함
  컴퓨팅 레이어는 어떤 작업을 실행하는 엔진으로 볼 수 있으며 가장 당순한 형태는 모든 연산을 수행하는 단일 CPU 코어 혹은 GPU 코어임
  가장 흔한 형태는 AWS Elastic Compute Cloud(EC2)나 GCP 같이 클라우드 공급업체가 관리하는 클라우드 컴퓨팅임

  • 컴퓨팅 레이어를 보통 더 작은 연산 유닛으로 분할 할 수 있고, 유닛들을 동시에 사용할 수 있는데 cpu 코어는 동시 스레드 두 개를 지원하며 각 스레드는 자체 작업을 실행하는 연산 유닛으로 사용됨
    여러 cpu 코어를 결합해 더 큰 작업을 실행하기 위한 더 큰 연산 유닛을 형성할 수 있음

• AWS step functions 이나 GCP Cloud Run과 같이 특정 단기 작업을 위한 연산 유닛을 생성할 수 도 있음. 이 유닛은 작업이 완료되면 제거됨

• 연산 유닛은 가상 머신처럼 보다 '영구적으로', 즉 작업에 얽매이지 않도록 생성할 수도 있는데 보다 영구적인 연산 유닛을 '인스턴스'라고도 함

• 컴퓨팅 레이어는 항상 스레드나 코어를 연산 유닛으로 사용하지는 않는데 ,코어 개수를 추상화해 다른 연산 유닛을 사용하는 컴퓨팅 레이어도 있음
  예를 들어 스파크나 레이 같은 연산 엔진은 '작업(job)'을 유닛으로 사용하고, 쿠버네티스는 컨테이너에 대한 래퍼, '파드(Pod)' 를 배포 가능한 혀앹의 가장 작은 유닛으로 사용함
  파드 하나에 여러 컨테이너가 있을 수 있지만 동일 파드에서 서로 다른 컨테이너를 독립적으로 시작하거나 중지할 수 는 없음

• 작업을 수행하려면 먼저 필요한 데이터를 연산 유닛 메모리에 적재한 다음 해당 데이터에서 필요한 연산등을 실행해야 함
  먼저 두 배열을 더하려면 둘을 메모리에 적재한 다음 덧셈을 수행함. 연산 유닛에 두 배열을 적재할 만큼 충분한 메모리가 없고 메모리 부족 연산을 처리해주는 알고리즘이 없으면 작업은 불가능함. 따라서 연산 유닛을 특정지을 때는 주로 메모리 크기와 작업 실행 속도라는 두 가지 지표를 사용함
  

• 메모리 지표는 기가바이트 같은 단위로 지정하고, 평가는 대개 단순함. 메모리가 8기가바이트인 연산 유닛은 메모리가 2기가바이트인 연산 유닛보다 더 많은 데이터를 메모리에서 처리할 수 있고 보통 더 비쌈
  일부 회사에서는 연산 유닛의 메모리 크기뿐 아니라 데이터를 메모리 안팎으로 적재하는 속도 또한 중요시 여기는데, 일부 클라우드 공급업체는 인스턴스가 '고대역(hig bandwidth) 메모리'를 갖추고 있다고 광고하거나 인스턴스의 I/O 대역폭을 지정할 수 있게함

• 작업 속도는 일반적인 지표로 초당 부동 소수점 연산 FLOPS(Floating point operations per second) 로, 연산 유닛이 초당 실행 가능한 부동 소수점 작업의 수임

• 새로운 연산 유닛을 평가할 때는 해당 연산 유닛이 일반 워크로드를 수행하는데 걸리는 시간을 평가하는 것이 중요함

• FLOPS에 대해 고민하는 것은 그다지 유용하지 않아, 많은 사람들이 연산 성능을 평가할 때 간단히 연산 유닛이 가진 코어 개수만 살펴봄
  예를 들어 CPU 코어 4개와 8기가바이트 메모리를 가진 인스턴스를 사용할 수 있음

퍼블릭 클라우드 VS 프라이빗 데이터 센터

• 컴퓨팅 레이어는 데이터 스토리지와 마찬가지로 대부분 상품화 돼 있음
• 기업에서 스토리지와 컴퓨팅을 위해 데이터 센터를 자체적으로 만드는 대신, AWS나 에저 같은 클라우드 공급업체에 사용한 연산량 만큼 비용을 지불하면 됨
• 클라우드 컴퓨팅을 사용하면 기업에서 컴퓨팅 레이어를 크게 걱정할 필요 없이 개발을 매우 쉽게 시작할 수 있고, 워크로드가 유동적인 회사에게 크게 매력적임
• 클라우드 컴퓨팅은 탄력적이지만 실제로 무한한 연산 자원은 없고, 대부분 클라우드 공급업체는 한 번에 사용할 수 있는 연산 자원에 제한을 둠
• 기업이 클라우드를 활용하는 초기는 스토리지와 컴퓨팅 레이어를 직접 구축할 때보다 수익이 더 높은 경향이 있지만 기업이 성장함에 따라 수익 방어가 어려워져, 기업들은 워크로드를 자체 데이터 센터로 다시 옮기기 시작하는 클라우드 송환(repatriation) 을 함

멀티클라우드 전략

• 기업이 단일 클라우드 공급업체에 대한 의존을 줄이는 방법은 '멀티클라우드 전략' 으로, 워크로드를 여러 클라우드 공급업체에 분산하는 것임
  기업은 시스템이 여러 클라우드와 호환될 수 있도록 설계에 벤더에 락인(lock-in) 도지 않고, 단일 클라우드 공급업체가 제공하는 서비스에 얽매이지 않고 최상의 비용 효율적인 기술을 활용할 수 있음
• 그러나 클라우드 간에 데이터를 이동하고 워크로드를 오케스트레이션 하는 일은 어려움
• 멀티클라우드는 조직의 서로 다른 부분들이 독립적으로 운영되고 각 부분이 자체적으로 클라우드 선택에 대한 결정을 내리면서 발생함

10-2. 개발 환경

• ML 엔지니어는 개발 환경에서 코드를 작성하고 실험을 수행하며, 성능이 가장 우수한 모델이 배포되고 새로운 모델이 평가되는 프로덕션 환경과 상호 작용함
• 개발 환경은 IDE(통합 개발 환경), 버전 관리와 CI/CD 라는 구성 요소로 이뤄짐

개발 환경 설정

• 개발 환경 설정 시, 버전 관리 도구 또한 포함해야 하는데
  코드 버전 관리를 위해 깃을 데이터 버전 관리를 위해 DVC(Data Version Control)을 개발 중 실험 추적을 위해 Weights & Biases 또는 Comet.ml을 배포 시 모델 아티팩트 주적을 위해 MLflow 같은 모델을 적당히 모아 ML 워크플로 버전을 관리함
• 개발 환경을 설정할 때 코드를 스테이징 또는 프로덕션 환경으로 푸시하기 전에 테스트 하기 위한 CI/CD 세트 스위트를 함께 설정해야 함

< IDE >

• IDE는 코드 작성 편집기로 여러 프로그래밍 언어 지원
• VS 코드나 VIM , 주피터 노트북
• 노트북은 데이터 탐색과 실험에 유용해 데이터 과학자와 ML 에 없어서는 안될 도구
• 일부회사에서는 노트북이 데이터 과학 인프라의 중심이기도 함

개발 환경 표준화

• 개발 환경에 대한 첫 번째 준칙은 표준화돼야 한다는 점
• 많이 사용하는 방법은 클라우드 개발 환경을 로컬 IDE와 함께 사용하는 것으로, 컴퓨터에 설치된 VS 코드를 사용하고 Secure Shell(SSH)와 같은 보안 프로토콜을 사용해 로컬 IDE를 클라우드 환경에 9연결

개발 환경에서 프로덕션 환경으로 : 컨테이너

• 개발 중에는 워크로드가 크게 변동하지 않음. 모델이 요청을 시간당 1,000개 처리하다가 갑자기 100만개 처리하는 식으로 바뀌지 않아, 일반적으로 작업하는 머신 또는 인스턴스 개수는 고정되어 있음

• 그러나 프로덕션 서비스는 여러 인스턴스에 분산되어 있을 수 있어, 인스턴스 수는 유입되는 워크로드에 따라 수시로 바뀌며 예측 불가능함

• 필요에 따라 신규 인스턴스를 가동해야 하고, 인스턴스에 워크로드를 실행하는데 필요한 도구와 패키지를 설정해줘야 함
  : 대부분 퍼블릭 클라우드 공급업체에서 자동 확장 부분을 처리 해주지만, 신규 인스턴스 설정 작업은 신경 써야함

• 동일한 인스턴스로 작업한다면 종속성을 한 번 설치하고 해당 인스턴스를 원할 때마다 사용하면 되는데, 프로덕션 환경에서 필요에 따라 인스턴스를 동적 할당하는 경우 환경은 본질적으로 무상태(stateless)임. 워크로드에 신규 인스턴스가 할당되면 사전에 미리 정의한 지침 목록을 사용해 종속성을 설치해야 함

• 신규 인스턴스에서 환경을 재생성하는 법은 도커(Docker)로 가장 유명한 컨테이너 기술을 사용함
  도커를 사용하면 도커파일(Dockerfile)을 생성하게 되는데, 모델 실행 환경을 재생성하는 방법에 관한 단계별 지침이 담겨 있음. 이 지침으로 하드웨어 어디서나 코드를 실행할 수 있음

  • 도커의 핵심 개념 두 가지는 이미지 와 컨테이너 임
    도커파일의 지침이 모두 실행되면 이미지가 만들어지고, 도커 이미지를 실행하면 도커 컨테이너가 반환됨
    도커파일은 도커 이미지라는 틀을 제조하는 레시피로, 이 틀을 사용해 실행되는 인스턴스를 여러 개 찍어낼 수 있고 이 각각이 도커 컨테이너

  • 도커 이미지는 밑바닥부터 혹은 다른 도커 이미지로부터 빌드할 수 있음.
    엔비디아 GPU용 텐서플로를 최적화 하는데 필요한 모든 라이브러리와 텐서플로가 포함된 도커 이미지를 제공함.
    GPU에서 텐서플로를 실행하는 애플리케이션을 개발하는 경우 해동 도커 이미지를 기본으로 사용하고, 이 기본 이미지 위로 애플리케이션에 한정된 종속성을 설치하는 전략이 있음

  • 컨테이너 레지스트리는 도커 이미지를 공유하거나, 다른 사람이 만든 이미지를 찾아 공개적으로 혹은 조직 내부 사람들과 공유할 수 있는 장소로, 흔히 사용되는 컨테이너 레지스트리는 도커 허브(Docker Hub) 와 Elastic Container Registy(AWS ECR)이 있음

• 애플리케이션이 작업을 수행하는 동안 컨테이너가 두 개 이상 필요할 수 있는데, 프로젝트가 실행 속도는 빠르지만 메모리 사용량이 큰 피처 생성 코드와 실행 속도는 느리지만 메모리 사용량이 적은 모델 학습 코드로 이뤄졌다고 가정할 때, 동일한 GPU 인스턴스에서 두 코드를 모두 실행하면 메모리가 높은 GPU 인스턴스가 필요하고 비용이 비쌀 수 있음. 한편 CPU 인스턴스에서 피처 생성 코드를 실행하고, GPU 인스턴스에서 모델 학습 코드를 실행하면 이 때는 피처 생성을 위한 컨테이너 하나와 학습을 위한 컨테이너 하나가 필요함

• 파이프라인의 여러 단계 간 종속성이 충돌할 때도 서로 다른 컨테이너가 필요할 수 있음. 피처 생성 코드에서 넘파이 0.8이 필요하지만 모델은 1.0이 필요할수 있음

• 마이크로서비스 100개가 있고 각 마이크로서비스에 자체 컨테이너가 필요한 경우 컨테이너가 100개 동시에 실행될 수 있음. 컨테이너 100개를 수동으로 빌드, 실행, 자원 할당 및 중지하는 일은 번거로운데 이러한 컨테이너를 관리하는데 도움이 되는 도구를 컨테이너 오케스트레이션 이라고 함. '도커 컴포즈(Docker Compose)'는 단일 호스트에서 컨테이너를 관리할 수 있는 경량 컨테이너 오케스트레이터임

  각 컨테이너가 자체 호스트에서 실행될 수 있을 때, 도커 컴포즈는 한계가 있음
  이때 쿠버네티스(K8s)는 이를 도와주는 도구임
  K8s는 컨테이너 간에 통신하고 자원을 공유하는 네트워크를 만들어줘, 더 많은 연산 및 메모리가 필요하면 더 많은 인스턴스에서 컨테이너를 가동하고 더 이상 필요하지 않으면 컨테이너를 종료하면 됨. K8s는 시스템의 고가용성을 유지하는 도움이 됨

10-3. 자원 관리

• 클라우드가 생겨나기 전에 스토리지와 연산 능력은 유한한 성질이었는데, 자원 관리는 제한된 자원을 최대한 활용하는 방법에 초점을 맞춤
• 한 애플리케이션에 사용하는 자원이 증가하면 다른 애플리케이션에 사용하는 자원이 감소함을 의미해서, 엔지니어링 시간이 더 걸리더라도 자원 활용을 극대화하기 위해 복잡한 로직을 도입해야 했음
• 반면 스토리지와 연산 자원이 탄력적인 클라우드 세상에서 자원 활용도를 극대화하기 보다 자원을 비용 효율적으로 사용하는 방법에 초점을 맞춤
  : 한 애플리케이션에 자원을 추가한다고 해서 다른 애플리케이션에 대한 자원이 감소하는 게아니라 할당 문제는 크게 단소화됨

크론, 스케줄러, 오케스트레이터

• ML 워크플로에서는 자원 관리에 영향을 미치는 주요 특성은 두가지 (1) 반복성, (2) 종속성이 있음

• ML 워크로드 또한 일회성 작업이 아니라 반복적인 작업이므로, 반복 프로세스는 가용 자원을 활용해 원활하고 비용 효율적으로 실행되도록 일정을 수립하고 오케스트레이션할 수 있음

• 크론(cron) 은 반복 작업이 지정한 시간에 실행되도록 일정을 수립함
  미리 정한 시간에 스크립트를 실행하고 작업 성공 여부를 알려줌.
  실행하는 작업 간의 종속성은 신경 쓰지 않아, 크론을 사용해 작업 B 다음에 작업 A를 실행할 수 있지만, A가 성공하면 B를 실행하고 A가 실패하면 C를 실행하는 등의 복잡한 작업은 예약할 수 없음

• 이는 종속성으로 이어지는데, ML 워크플로의 각 단계는 서로 복잡한 종속성 관계를 갖음.

[ML 워크플로 5단계]

(1) 데이터 웨어하우스에서 지난주 데이터 가져옴
(2) 가져온 데이터에서 피처 추출
(3) 추출한 피처로 두 모델 A,B 훈련
(4) 테스트 세트에서 A,B 비교
(5) A가 나으면 A 배포, B가 나으면 B 배포

=> 이는 DAG, 방향성 비순환 그래프임
단계 간의 종속성을 나타내도록 방향성이 지정돼 있고, 순환을 포함하지 않음
DAG는 ML 워크플로뿐 아니라 연산의 워크 플로를 나타내는데 흔히 사용되는 방식으로 , 대부분 워크플로 관리 도구에서는 DAG 형식으로 워크플로를 지정해줘야 함

• 스케쥴러 는 종속성을 처리할 수 있는 크론 프로그램
  워크플로의 DAG를 가져와 그에 맞게 단계별로 일정 예약을 함
  이벤트 기반 트리거를 기준으로 작업을 시작하도록 일정 예약을 할 수 있는데, 이벤트 X가 발생하면 작업을 시작하는 식으로 진행함
  스케줄러를 사용하면 작업이 실패할 경우와 성공할 경우 다음에 수행될 직업을 지정할 수 있음

  스케줄러는 대기열을 활용해 작업을 추적하는데, 작업을 대기열에 넣고 우선순위를 지정한 뒤 실행에 필요한 자원을 할당함. 즉, 스케줄러는 사용 가능한 자원과 각 작업을 실행하는 데 필요한 자원을 인식할 수 있어야 함
  필요한 자원은 작업 일정을 수립할 때 선택사항으로 입력하거나 스케줄러에서 자체적으로 예상함

  스케줄러는 사용 가능한 자원, 실행할 작업, 각 작업에 필요한 자원에 대한 정보를 가지고 자원 활용도를 최적화해야 하는데, 사용자가 지정한 자원의 양이 항상 올바르지는 않음

  범용적인 스케줄러를 설계하기는 어려운데, 발생하는 모든 수의 동시 시스템과 워크플로를 관리할 수 있어야 하기 때문임. 스케줄러가 다운되면 해당 스케줄러가 손대는 워크플로가 모두 중단됨

• 스케줄러의 주요 관심사가 작업을 실행할 '시기'와 실행에 필요한 작원이라면 오케스트레이터는 이러한 자원을 입수라 '장소'임

  스케줄러는 DAG, 우선순위 대기열, 사용자 수준의 할당량(사용자가 주어진 시간에 사용할 수 있는 인스턴스 최대 대수)같은 추상화된 작업 유형을 처리하는데,
  오케스트레이터는 머신, 인스턴스, 클러스터, 서비스 수준의 그룹화, 복제화 같은 낮은 수준의 추상화 작업을 처리함

  오케스트레이터는 가용한 인스턴스 풀보다 더 많은 작업이 존재함을 인지하면 인스턴스 풀의 가용한 인스턴스 대수를 늘려, 워크로드를 처리하기 위해 더 많은 컴퓨터를 프로비저닝 함

  스케줄러는 정기적인 작업에 자주 사용되고, 오케스트레이터는 요청에 응답해야 하는 장기 실행 서버가 존재하는 서비스에 자주 사용됨

• 오늘날 가장 잘 알려진 오케스트레이터는 쿠버네티스임
  k8s는 온프레미스에서 사용가능하며, Minikube를 통해 노트북으로도 사용 가능함
  대부분 회사는 K8S와 Elastic Kubernates Service(EKS) 나 구글 쿠버네티스 엔진(GKE) 등 클라우드 공급업체에서 관리하는 호스팅 서비스를 통해 사용함

데이터 과학 워크플로 관리

• 데이터 과학에 특화된 워크플로 관리 도구는 Airflow, 아고, 프리펙트, Kubeflow, MetaFLow 가 있음
• 가장 단순한 형태의 워크플로 관리 도구는 워크플로만 관리하는데, 워크플로를 DAG로 지정할 수 있음
• 워크플로는 피처화 단계, 모델 훈련 단계, 평가 단계로 구성할 될 수 있고, 워크플로는 코드(파이썬) 이나 구성 파일(YAML)을 사용해 정의하고, 각 워크플로 단계를 태스크(task)라고 함
• 거의 모든 워크플로 관리 도구는 스케줄러와 함께 제공되어, 개별 작업이 아니라 전체 워크프롤에 초점을 맞추는 스케줄러라고 볼 수 있음. 워크플로가 정의되면 기본 스케줄러는 일반적으로 워크플로를 실행할 자원을 할당하기 위해 오케스트레이터와 함께 작동됨

[ 온라인 워크플로 관리 도구 ]

(1) Airflow

• 초창기 워크플로 오케스트레이터 하나, 에어비앤비에서 개발
• 에어플로는 '코드로서의 설정(configuration as code)'의 원칙 모범을 보여줌
• 에어플로는 대부분 도구보다 만들어져서, 많은 문제점을 지니기는 함
  모놀리 식으로, 전체 워크플로를 컨테이너 하나로 패키징함. 워크프롤의 서로 다른 두 단계 간의 요구 사항이 다를 경우 이론적으로 에어플로의 도커오퍼레이터(DockerOperator)를 사용해 서로 다른 컨테이너를 만들 수 있지만 그렇게 하기 쉽지 않음
  또한 에어플로 DAG는 사용자 매개변수를 지원하지 않아, 매개변수를 워크플로에 전달할 수 없어서 동일한 모델을 서로 다른 학습률로 실행하려면 다른 워크프로를 만들어야 함. 에어 플로의 DAG는 정적인 형태로 런타임시 반드시 필요하더라도 새로운 단계를 자동 생성할 수 없음

(2) 아고, 프리텍트

• 차세대 워크플로 오케스트레이터로 에어플로의 단점을 해결하기 위해 만들어짐
• 프리펙트는 사용자 매개변수를 지원하고 동적인 형태
• '코드로서의 설정' 우너칙을 따라 워크플로가 파이썬으로 정의됨
• 에어플로 마찬가지로 프레펙트에서 각 단계의 컨테이너화는 최우선 구현 사항이 아니라, 컨테이너에서 각 단계를 실행할 수 있지만 여전히 도커파일을 사용자가 직접 다루면서 생성된 도커를 프리펙트 워크플로에등록함
• 반면 아고는 컨테이너 문제를 해결하는데, 아고 워크플로의 모든 단계는 자체 컨테이너에서 실행됨.
  아고의 워크플로는 YAML으로 정의되어 파일 하나에 각 단계와 요구 사항을 정의할 수 있음
  YAML 파일이 지저분하다는 점을 빼면 아고의 주요 단점은 프로덕션 환경에서 사용하는 K8s 클러스터에서만 실행할 수 있다는 점임
  동일한 워크플로를 로컬에서 테스트하려면 미니쿠브를 사용해 노트븍 컴퓨터에서 K8s를 시뮬레이션 해야하고, 이는 굉장히 나잡함

(3) Kubeflow, Metaflow

• 에어플로나 아고를 실행하는데 필요한 인프라 사용구 코드를 추상화해 개발과 프로덕션 환경 양쪽에서 워크플로를 실행하는 데도움이 됨
• 두 도구 모두 일정 예약 기능이 일부 있으나 완전한 스케줄러, 오케스트레이터와 함께 사용하도록 개발됨
• Kubeflow의 구성 요소 중 하나는 아고 위로 구축된 kubeflow pipelines으로 K8s 위에서 사용 가능함
• Metaflow는 AWS 배치 혹은 K8s와 함께 사용 가능
• 두 도구 모두 완전히 사용자 매개변수를 지원하여 동적이고, 현재 kubeflow가 좀더 많이 사용되긴함
• kubeflow는 파이썬으로 워크플로를 정의할 수 있지만 파이썬 워크플로에 연결하기 위해서는 도커파일과 YAML 파일을 작성해 각 구성 요소의 사양(데이터 처리, 학습, 배포)를 지정해줘야하는데, KubeFlow는 kubeflow 상용구 코드를 작성함으로써 다른 도구의 상용구 코드를 추상화하는데 도움이 됨
• Metaflow의 파이썬 데코레이터 @conda를 사용해 각 단계에 대한 요구 사항(필 수라이브러리, 메모리와 연산 요구 사항)을 지정할 수 있고, 메타플로는 이러한 요구 사항 전체를 포함하는 컨테이너를 자동으로 생성하고, 도커파일이나 YAML 파일에 저장하는 것도 가능함
  Metaflow는 동일한 노트북 및 스크립트를 통해 개발과 프로덕션 환경 양쪽에서 원활하게 작업 가능함.
  로컬 머신에서 크기가 작은 데이터셋으로 실험할 수 있고, 클라우드의 경우 크기가 큰 데이터셋으로 실행할 준비가 되면 @batch 데코레이터를 추가해 AWS 배치로 실행함
  동일한 워크플로의 서로 다른 단계를 별개의 환경에서도 실행 할수도 있음.
  예를 들어 메모리 공간이 적게 필요한 단계는 로컬 머신에서 실행하고, 다음 단계에서 메몰 ㅣ공간이 크게 필요하면 @batch를 추가해 클라우드에서 실행함

10-4. 머신러닝 플랫폼

• 회사마다 점점 더 많은 애플리케이션에 ML 을 사용함에 따라, 각 애플리케이션에 별도의 도구 지합을 지원하는 대신 여러 애플리케이션에 동일한 도구 집합을 활용함으로써 보다 큰 효용을 얻을 수 있음

• ML 배포를 윟나 도구 집합이 ML 플랫폼을 구성함

• ML 플랫폼의 구성 요소는 회사마다 다르지만 일반적으로 모델 배포, 모델 스토어, 피처 스토어 등 ML 플랫폼에서 가장 흔히 보이는 구성 요소에 중점을 둠

• 이러한 구성 요소의 범주에 따라 도구르 평가하는 일은 유스 케이스마다 다르지만 이 두 가지 측면은 염두해 둬야함

  (1) 도구가 클라우드 공급업체와 함께 작동하는가 혹은 자체 데이터 센터에서 사용 가능한가?

  • 컴퓨팅 레이어에서 모델을 실행하고 제공해야 하는데, 보편적인 도구들은 소수 클라우드 공급업체와 통합돼 실행됨.
    특정 도구들 때문에 클라우드 공급업체를 새로 도입해야 하는 상황은 달갑지 않음

  (2) 오픈 소스인가 관리형 서비스인가?

  • 오픈 소스이면 직접 호스팅할 수 있으며, 데이터 보안과 개인 정보 보호를 걱정하지 않아도 되지만 자체 호스팅은 유지 관리에 필요한 엔지니어링 시간의 증가를 의미함
  • 관리형 서비스이면 모델과 일부 데이터가 해당 서비스에 올라갈 수 있고, 따라서 특정 규제에 위배될 수 있음. 일부 관리형 서비스는 가상 프라이빗 클라우드와 함께 동작하므로 자체 클라우드 클러스터에 시스템을 배포함으로써 규정을 준수할 수 있음

모델 배포

• 모델이 훈련됐으면 사용자에게 예측값을 제공할 수 있어야 하는데, 모델을 배포하는 가장 간단한 방법은 프로덕션 환경에서 접근 가능한 위치에 모델과 관련 종속성을 푸시한 다음 모델을 엔드포인트를 통해 사용자에게 노출하는 것임

• 온라인 예측을 수행하는 경우 이 엔드포인트는 모델이 예측값을 생성하도록 유도하고, 배치 예측을 수행하는 경우 이 엔드포인트는 미리 계산해놓은 예측값을 가져옴

• 배포 서비스는 모델과 해당 종속성을 프로덕션 환경에 푸시하고 모델을 엔드포인트로 노출하는데 도움이됨. 배포는 필수부락결하므로 모든 ML 플랫폼 구성 요소 중에서 가장 성숙한 형태이며 배포를 위한 도구 또한 다양함

• 주요 클라우드 공급업체는 모두 배포 도구를 제공함 AWS의 세이지메이커, GCP의 버텍스AI, 애저의 애저 ML, 알리바바의 머신러닝 스튜디오, MLflow 모델즈

• 배포 도구를 살펴볼 때는 해당 도구로 온라인 예측과 배치 예측을 수행하는 게 얼마나 쉬운지 고려해야 함. 대부분의 배포 서비스에는 규모가 작은 온라인 예측이 더 간단하고 배치 예측이 좀 더 어려움

모델 스토어

• 모델스토어는 모델을 저장함을 의미하는데 S3 같은 스토리지에 모델을 그냥 업로드해도 되지만 간단한 문제가 아님