ch10.md

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

moderated by 샐리

📝 목차

• 10. MLOps를 위한 인프라와 도구
• 10.1. 스토리지와 컴퓨팅
  • 10.1.1. 퍼블릭 클라우드 vs. 프라이빗 데이터 센터
• 10.2. 개발 환경
  • 10.2.1. 개발 환경 설정
  • 10.2.2. 개발 환경 표준화
  • 10.2.3 개발 환경에서 프로덕션 환경으로: 컨테이너
• 10.3. 자원 관리
  • 10.3.1. 크론, 스케줄러, 오케스트레이터
  • 10.3.2 데이터 과학 워크플로 관리
• 10.4. 머신러닝 플랫폼
  • 10.4.1. 모델 배포
  • 10.4.2. 모델 스토어
  • 10.4.3. 피처 스토어
• 10.5. 구축 vs. 구매
• 10.6. 정리

---

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

• 개발하는 앱의 개수와 전문성 수준에 따라 회사마다 인프라 요구사항이 다르다.
  • 일반화된 인프라는 데이터를 하루에 기가바이트나 테라바이트 단위로 처리하는 회사들에서 주로 사용

• 인프라란?
  • ML 시스템의 개발과 유지 관리를 지원하는 기본 시설의 집합

인프라의 4가지 레이어

• 스토리지와 컴퓨팅 레이어
  • 스토리지 레이어: 데이터를 수집하고 저장한다.
  • 컴퓨팅 레이어: 모델 훈련, 피처연산, 피처 생성 등 ML 워크로드를 실행하는 데 필요한 연산 자원을 제공한다.
• 자원관리: 사용 가능한 연산자원을 활용할 워크로드 일정을 수립한다.
• ML 플랫폼: 모델 스토어, 피처 스토어, 모니터링 도구 같은 ML 애플리케이션 개발을 위한 도구를 제공한다.
• 개발 환경: 코드가 작성되고 실험이 실행되는 곳이다.

10.1. 스토리지와 컴퓨팅

• 컴퓨팅 레이어는 어떤 작업을 실행하는 엔진으로 볼 수 있다.
• 컴퓨팅 레이어를 더 작은 연산 유닛으로 분할할 수 있으며, 유닛들을 동시에 사용할 수 있다.(ex. 스레드)
• 반대로 여러 CPU 코어를 결합해 더 큰 작업을 실행하기 위한 더 큰 연산 유닛을 생성할 수도 있다.
• 연산 유닛 평가 지표: (1)메모리 크기 (2)작업 실행 속도
  • 메모리가 큰 연산 유닛이 더 많은 데이터를 처리할 수 있으며, 더 비싸다.
  • 데이터를 메모리 안팎으로 적재하는 속도도 중요시 한다.
  • 작업 속도의 일반적인 지표는 초당 부동 소수점 연산이지만, 사용하는 방식에 따라 논란의 여지가 있다.
  • 새로운 연산 유닛을 평가할 때는 해당 연산 유닛이 일반 워크로드를 수행하는 데 걸리는 시간을 평가하는 것이 중요하다.

10.1.1. 퍼블릭 클라우드 vs. 프라이빗 데이터 센터

• 클라우드 컴퓨팅을 사용하면 기업에서 컴퓨팅 레이어를 크게 걱정할 필요 없다.
• 워크로드 크기가 유동적인 회사에게 특히 유용하다. 데이터 과학 워크로드는 급증하는 경향이 있으므로 ML에 특히나 유용하다.
• 그러나 대부분의 클라우드 공급업체는 한 번에 사용할 수 있는 연산 자원에 제한을 둔다.
• 높은 비용이 들어서 점차 자체 데이터 센터로 이동하게 된다.
• 멀티 클라우드 전략: 기업이 단일 클라우드 공급업체에 대한 의존을 줄이기 위해, 워크로드를 여러 클라우드 공급업체에 분산하는 멀티 클라우드 전략을 쓰기도 한다. 그러나 데이터 이동과 워크로드 오케스트레이션하기가 어렵다.

^{⬆️ 위로 이동}

10.2. 개발 환경

• 대부분의 기술회사들은 개발 환경에 충분히 투자하지 않는다. 그러나 개발 환경이 개선되면 엔지니어링 생산성 또한 개선된다.

10.2.1. 개발 환경 설정

• ML 프로젝트에서는 특히 변경될 수 있는 항목(코드, 매개변수, 데이터 자체 등)이 많고 이전 실행을 추후 재현하기 위해 추적해야 하므로 더욱 중요하다.

IDE

• 코드를 작성하는 편집기
• 노트북(주피터 노트북, 코랩)
  • 노트북은 이미지, 플롯, 표 형식 데이터 등을 포함하므로 EDA, 모델 훈련 결과 분석 작업에 유용하다.
  • 상태유지라는 속성이 있어서, 실행이 끝나도 상태 정보를 유지한다.
  • 프로그램이 도중에 실패하면 처음부터 다시 실행하지 않고 실패한 단계부터 실행할 수 있다.
  • 데이터를 메모리에 유지하므로 노트북을 사용하면 데이터를 한번만 적재하면 된다. 대규모 데이터셋을 처리할 때 특히 유용하다.
  • 셀을 순서대로 실행하지 않을 수 있으므로 순서 지침이 없다면 노트북의 재현성을 유지하기가 까다롭다.
  • 노트북을 위한 인프라 도구 목록
    • 페이퍼밀: 서로 다른 매개변수 집합으로 여러 노트북을 생성하기 위한 도구
    • 커뮤터: 조직 내에서 노트북을 보여주고 검색하고 공유하는데 사용하는 노트북 허브
    • nbdev: 문서와 테스트를 동일한 위치에 작성하도록 한다.

10.2.2. 개발 환경 표준화

• 개발환경 표준화는 패키지 버전 동기화, 버그 재현 등에 필요하다.
• 하드웨어의 변경은 개발환경 표준화에 어려움을 주기도 한다. 따라서 클라우드 개발 환경은 좋은 선택지가 될 수 있다.
  • 비용이 저렴한 일부 인스턴스가 있으며, 사용이 없으면 인스턴스 연결을 끊어주는 기능도 있다.
  • 로컬 개발 환경에서 클라우드 개발 환경으로 이동하면 IT 지원이 쉬워지며, 원격 작업이 편리해지고 보안에 도움이 된다.
  • 클라우드 개발환경 사용 시, 개발 환경과 프로덕션 환경 간의 차이를 줄일 수 있다.

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

• 개발 중에는 워크로드가 크게 변동하지 않으나, 프로덕션 서비스는 여러 인스턴스에 분산되어 있을 수 있다. 인스턴스 수는 유입되는 워크로드에 따라 수시로 바뀌며 예측 불가능하다.
• 예전에는 직접 인스턴스를 가동하고 종료해야 했지만, 최근에는 대부분의 퍼블릭 클라우드 공급업체가 자동 확장 부분을 처리해준다.
• 신규 인스턴스 설정 작업 시, 사전에 미리 정의한 지침 목록을 사용해 종속성 설치를 해야 한다. → 도커 사용
• 도커
  • 도커를 사용하면 도커파일을 생성하는데, 여기에는 모델 실행 환경을 재생성하는 방법에 관한 단계별 지침이 담겨있다.(패키지 설치, 사전 훈련된 모델 다운로드, 환경 변수 설정, 폴더 탐색 등)
  • 이미지와 컨테이너
    • 도커파일의 지침이 모두 실행되고 나면 도커 이미지가 만들어지고, 도커 이미지를 실행하면 도커 컨테이너가 반환된다.
    • 도커 이미지는 밑바닥부터 혹은 다른 도커 이미지로부터 빌드할 수 있다.
  • 컨테이너 레지스트리: 도커 이미지를 공유하는 장소(ex. 도커허브, 일레스틱 컨테이너 레지스트리)
  • 컨테이너 오케스트레이션: 여러 컨테이너는 동시에 실행될 수 있으며, 여러 컨테이너를 관리하는 데 도움이 되는 도구를 컨테이너 오케스트레이션이라고 한다.(ex. 도커 컴포즈, 쿠버네티스)

^{⬆️ 위로 이동}

10.3. 자원 관리

• 자체 데이터 센터에서는 유한한 자원을 효율적으로 사용하기 위해 복잡한 로직을 도입한다.
• 클라우드는 자원 활용도를 극대화하기 보다는, 자원을 비용 효율적으로 사용하는 방법에 초점을 둔다.

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

• ML 워크플로에서 자원관리에 영향을 주는 주요 특성: 반복성, 종속성
  • ML 워크로드는 반복 프로세스이며, 자원을 비용 효율적으로 실행되도록 일정을 수립하고 오케스트레이션 해야한다.
• 크론: 반복 작업이 지정한 시간에 실행되도록 일정을 수립한다.(작업간 종속성은 신경쓰지않음)
• DAG(방향성 비순환 그래프): 단계간의 종속성을 나타내도록 방향성이 지정돼있으며, 순환을 포함하지 않는다. 워크플로 관리 도구에서는 DAG 형식으로 워크플로를 지정해줘야한다.
• 스케줄러: 종속성을 처리할 수 있는 크론 프로그램
  • 워크플로의 DAG를 가져와 그에 맞게 단계별로 일정 예약을 한다.
  • 대기열을 활용해 작업을 추적한다. 작업을 대기열에 넣고 우선순위를 지정한 뒤 실행에 필요한 자원을 할당한다. 따라서 사용 가능한 자원과 각 작업을 실행하는 데 필요한 자원을 인식할 수 있어야 한다.
  • 일반적으로 오케스트레이터 위에서 실행된다.
  • 스케줄러의 주요 관심사는 작업을 실행할 시기와 실행에 필요한 자원이다.
  • DAG, 우선순위 대기열, 사용자 수준의 할당량과 같은 작업 유형을 처리한다.
  • ex. 슬럼, 구글 보그
• 오케스트레이터
  • 오케스트레이터의 주요 관심사는 자원을 입수할 장소이다.
  • 머신, 인스턴스, 클러스터, 서비스 수준의 그룹화, 복제와 같은 낮은 수준의 추상화 작업 처리
  • 워크로드를 처리하기 위해 더 많은 컴퓨터를 '프로비저닝'한다.(= 가용한 인스턴스 풀보다 더 많은 작업이 존재함을 인지하면 인스턴스 풀의 가용한 인스턴스 대수를 늘린다.)
  • ex. 쿠버네티스

10.3.2 데이터 과학 워크플로 관리

• 워크플로를 실행할 자원을 할당하기 위한 프로세스
• 데이터 과학 워크플로 관리 도구 비교
  • 에어플로: 코드로서의 설정 원칙의 모범. 데이터 워크플로가 복잡하므로 선언적 언어(YAML) 대신 코드를 사용해서 정의해야한다.
    • 단점: 워크플로를 컨테이너 하나로 패키징하여 사용하기 쉽지 않다. 에어플로의 DAG는 사용자 매개변수를 지원하지 않다. 에어플로 DAG는 정적 형태이므로 런타임시 필요하더라도 새로운 단계를 자동으로 생성할 수 없다.
  • 프리펙트: 에어플로의 단점을 해결하기 위해 만들어졌다. '코드로서의 설정' 원칙을 따르므로 워크플로가 파이썬으로 정위된다. 그러나 각 단계의 컨테이너화는 최우선 구현 사항이 아니다. 여전히 도커파일을 사용자가 직접 다루면서 생성된 도커를 프리펙트 워크플로에 등록해줘야 한다.
  • 아고: 위의 컨테이너 문제를 해결한다. 아고 워크플로의 모든 단계는 자체 컨테이너에서 실행된다. 워크플로가 YAML로 정의되므로 파일 하나에 각 단계와 요구 사항을 정의할 수 있다. 프로덕션 환경에서 사용하는 쿠버네티스 클러스터에서만 실행할 수 있다.
  • 쿠브플로, 메타플로: 에어플로나 아고를 실행하는 데 필요한 인프라 상용구 코드를 추상화하여 개발과 프로덕션 환경 양쪽에서 워크플로를 실행하는 데 도움이 된다. 사용자 매개변수를 지원하며 동적이다.
    • 쿠브플로는 파이썬 워크플로를 정의할 수 있지만 복잡하다.
    • 메타플로에서는 파이썬 데코레이터를 사용해 각 단계에 대한 요구사항을 지정할 수 있으며, 이런 요구사항 전체를 포함하는 컨테이너를 자동으로 생성할 수 있다. 동일한 스크립트를 통해 개발과 프로덕션 환경 양쪽에서 원활하게 작업할 수 있다.(데코레이터만 추가하면 된다.)

^{⬆️ 위로 이동}

10.4. 머신러닝 플랫폼

• 여러 애플리케이션에 동일한 도구 집합을 활용함으로써 보다 큰 효용을 얻을 수 있다.
• ML 배포를 위한 도구 집합이 ML 플랫폼을 구성한다.
• ML 플랫폼을 고를 때 고려할 점
  • 도구가 클라우드 공급업체와 함께 작동하는가 혹은 자체 데이터 센터에서 사용 가능한가
    • 보편적인 도구들은 소수의 클라우드 공급업체와 통합되어 실행된다.
  • 오픈소스인가 관리형 서비스인가
    • 오픈소스라면 직접 호스팅할 수 있고 보안과 개인정보를 걱정하지 않아도 된다. 하지만 유지관리에 필요한 엔지니어링 시간을 증가시킨다. 관리형 서비스는 모델과 일부 데이터가 해당 서비스에 올라갈 수 있어 특정 규제에 위배될 수 있다.

10.4.1. 모델 배포

• 모델을 배포하는 가장 간단한 방법은 프로덕션 환경에서 접근 가능한 위치에 모델과 관련 종속성을 푸시한 다음 모델을 엔드포인트를 통해 사용자에게 노출하는 것이다. 배포 서비스는 이에 도움이 된다.
• 해당 도구로 온라인 예측과 배치 예측을 수행하는 게 얼마나 쉬운지 고려해야한다. 대부분 규모가 작은 온라인 예측이 더 간단하다.

10.4.2. 모델 스토어

• 스토리지에 모델을 그냥 업로드해도 되지만 일련의 입력값에 대해 특정 모델의 성능이 하락한 경우에는 문제를 로컬에서 재현할 수 없다는 단점이 있다.
• 모델 이외에 스토리지에 저장해야하는 8가지 유형의 아티팩트
  • 모델 정의: 모델 형상을 만드는 데 필요
  • 모델 매개변수: 예측 모델을 재생성
  • 피처화와 예측함수: 피처를 추출하고 모델에 입력해 예측값을 얻기 위함
  • 종속성: 모델을 실행하는 데 필요한 종속성(버전 등)
  • 데이터
  • 모델 생성 코드: 모델을 생성한 방식 지정(사용한 프레임워크, 훈련방법, 검증/테스트 데이터셋 분할 방식 등)
  • 실험 아티팩트: 손실곡선과 같은 그래프나 테스트셋에서의 모델 성능 등
  • 태그: 소유자, 태스크 등
• 모델이 모델 스토어에 업로드되면 해당 모델에 직렬화된 모델에 대한 링크, 모델을 실행하는 데 필요한 종속성이나 깃 커밋, 태그 등이 붙는다.

10.4.3. 피처 스토어

• 피처 관리, 피처 변환, 피처 일관성 보장에 도움이 된다.
• 피처 관리
  • 팀에서 피처를 공유, 검색하고 각 피처에 대한 담당과 공유 설정을 관리하는 데 큰 도움이 된다.
• 피처 연산(피처 변환)
  • 연산비용이 크다면 처음 필요할 때 한 번 계산한 뒤 다음번 피처 사용을 위해 저장해두는 편이 좋다.
• 피처 일관성 보장
  • 배치 피처와 스트리밍 피처에 대한 로직을 통합해 훈련에 사용하는 피처와 추론에 사용하는 피처 간의 일관성을 보장

^{⬆️ 위로 이동}

10.5. 구축 vs. 구매

• 인프라 구축과 인프라 구매에 대한 결정은 아래와 같은 요인에 달려있다..
• 회사가 속하는 성장 단계
  • 초기에는 공급업체 솔루션을 활용해 가능한 빨리 사업을 시작하고, 제한된 자원을 제품의 핵심적인 기능을 구현하는 데 집중해야한다. 추후 자체 시스템 제작에 투자해야한다.
• 회사의 주안점 또는 경쟁 우위라고 생각하는 것
  • ML 인프라가 회사의 주안점인지 확인한다.
• 사용 가능한 도구의 성숙도
  • 요구사항을 충족할 만큼 성숙한 공급업체가 없다면 자체 모델 스토어를 구축한다.

^{⬆️ 위로 이동}

10.6. 정리

• 스토리지와 컴퓨팅 레이어는 ML 프로젝트처럼 집약적인 데이터와 연산 자원이 필요한 엔지니어링 프로젝트에 중요한 자원을 제공한다. 클라우드 서비스 사용 시 손쉽게 사업을 시작할 수 있으나, 성장함에 따라 비용이 점차 커진다.
• 프로덕션 환경과 상호작용하는 개발환경의 개선은 생산성 향상으로 이어진다. 개발환경 표준화가 권장된다.
• 자원 관리는 데이터 과학 워크플로에 매우 중요한 문제이다.
• ML 플랫폼의 필수적 세가지 도구집합: 배포, 모델 스토어, 피처 스토어

^{⬆️ 위로 이동}