ML 시스템에 적합한 인프라를 설정하는 방법을 알아본다.

본론으로 들어가기에 앞서 주의할 점은 회사마다 인프라 요구 사항이 다르다는 점이다. 가령 간단한 ML 유스 케이스 하나만 있는 경우에는 인프라가 크게 필요하지 않다. 텐서플로 라이트 같은 안드로이드 호환 ML 프레임워크만 있으면 된다.

ML 세계에서 인프라란 ML 시스템의 개발과 유지 관리를 지원하는 기본 시설의 집합이다. 이 절에서는 다음 네 가지 레이어를 살펴본다.

스토리지와 컴퓨팅

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

자원 관리

사용 가능한 연산 자원을 최대한 활용할 수 있도록 워크로드 일정을 수립하고 오케스트레이션하는 도구로 구성된다. 이 범주에 속하는 도구의 예로는 에어플로, 쿠브플로, 메타플로가 있다.

ML 플랫폼

모델 스토어, 피처 스토어, 모니터링 도구 같은 ML 애플리케이션 개발을 위한 도구를 제공한다. 이 범주에 속하는 도구의 예로는 세이지메이커와 ML플로가 있다.

개발 환경

일반적으로 코드가 작성되고 실험이 실행되는 곳이다. 코드는 버전 관리 및 테스트가 수행돼야 하며 실험이 추적돼야 한다.

무엇을 직접 구축하고 무엇을 다른 회사에서 구매하는지에 따라 결과로 만들어지는 인프라는 매우 다를 수 있다. 두 접근법에 관한 의사 결정을 논의하고, 표준화되고 통합된 ML 인프라 추상화에 대한 바람 또한 논의한다.

10.1 스토리지와 컴퓨팅

스토리지 레이어는 데이터가 수집되고 저장되는 곳으로, 가장 단순한 형태는 HDD나 SSD이다.

데이터 스토리지는 매우 저렴해져 대부분의 회사에서 거의 비용 지출 없이 보유한 데이터를 모두 저장한다. 3장에서 데이터 레이어를 깊게 다뤘다.

컴퓨팅 레이어는 회사가 접근할 수 있는 모든 연산 자원과 그 사용법을 결정하는 매커니즘이다. 사용 가능한 연산 자원의 양은 워크로드 확장성을 결정한다. 어떤 작업을 실행하는 엔진으로 볼 수 있으며 가장 단순한 형태는 모든 연산을 수행하는 단일 CPU 코어 혹은 GPU 코어이다. 가장 흔한 형태는 EC2나 GCP와 같이 클라우드 공급업체가 관리하는 클라우드 컴퓨팅이다.

컴퓨팅 레이어를 보통 더 작은 연산 유닛으로 분할할 수 있으며, 유닛들을 동시에 사용할 수 있다. (CPU 코어의 스레드, 혹은 여러 CPU 코어 사용)

컴퓨팅 레이어가 항상 스레드나 코어를 연산 유닛으로 사용하지는 않는다. 코어 개념을 추상화해 다른 연산 유닛을 사용하는 컴퓨팅 레이어도 있다. (ex. 스파크, 레이, 쿠버네티스)

작업을 실행하려면 먼저 필요한 데이터를 연산 유닛 메모리에 적재한 다음 해당 데이터에서 필요한 연산(덧셈, 곱셈, 나눗셈, 합성곱 등)을 실행해야 한다. 따라서 연산 유닛을 특징지을 때는 주로 메모리 크기와 작업 실행 속도라는 두 가지 지표를 사용한다.

메모리 지표는 기가바이트 같은 단위로 지정하며 평가는 대개 단순하다. 일부 회사에서는 연산 유닛의 메모리 크기뿐 아니라 데이터를 메모리 안팎으로 적재하는 속도 또한 중요시한다.

작업 속도에 대한 일반적인 지표는 FLOPS로 연산 유닛이 초당 실행 가능한 부동 소수점 작업 수를 의미한다.

이 지표는 다음과 같은 이유로 논쟁의 여지가 있다.

1. 회사에 따라 무엇을 작업으로 간주할지
2. 연산 유닛이 1조 FLOPS를 처리할 수 있다고 해서 1조 FLOPS 속도로 작업을 실행할 수 있다는 뜻은 아니다. (사용률 100%를 달성하기는 거의 불가능하다.)

새로운 연산 유닛을 평가할 때는 해당 연산 유닛이 일반 워크로드를 수행하는 데 걸리는 시간을 평가하는 것이 중요하다(ex. MLPerf 벤치마크).

많은 사람이 연산 성능을 평가할 때 간단히 연산 유닛이 가진 코어 개수만 살펴본다.

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

클라우드 컴퓨팅을 사용하면 기업에서 컴퓨팅 레이어를 크게 걱정할 필요 없이 개발을 매우 쉽게 시작할 수 있다. 이는 워크로드 크기가 유동적인 회사에게 특히 매력적이다(워크로드에 연중 딱 하루만 1,000개의 CPU 코어가 필요하고 나머지는 10개만 필요하다면?).

클라우드 컴퓨팅은 탄력적이지만 마술은 아니다. 대부분의 클라우드 공급업체는 한 번에 사용할 수 있는 연산 자원에 제한을 둔다. 연산 자원이 많다고 항상 사용하기 쉬운 것은 아니다. 특히 비용 절약을 위해 스팟 인스턴스로 작업해야 하는 경우에는 더욱 어렵다.

클라우드를 사용하는 초기에는 스토리지와 컴퓨팅 레이어를 직접 구축할 때보다 수익이 더 높은 경향이 있지만 기업이 성장함에 따라 수익 방어가 어려워진다. -> 클라우드 송환 발생

클라우드를 시작하기는 쉬워도 벗어나기는 어렵다. 점점 더 많은 기업이 하이브리드 접근 방식을 따르고 있다. 워크로드의 대부분을 클라우드에 유지하면서 데이터 센터에 대한 투자를 천천히 늘린다.

+ 멀티클라우드 전략: 단일 클라우드 공급업체에 대한 의존을 줄이는 전략, 워크로드를 여러 클라우드 공급업체에 분산한다. 클라우드 간에 데이터를 이동하고 워크로드를 오케스트레이션하는 일은 매우 어렵기 때문에 보통 의사 결정에 따라 발생하는 일은 아니다.

10.2 개발 환경

개발 환경은 엔지니어가 작업하는 곳이므로 개발 환경이 개선되면 엔지니어링 생산성 또한 개선된다.

개발 환경의 여러 구성 요소를 알아보고 개발 환경의 표준화를 논의한 뒤 컨테이너를 사용해 개발 환경의 변경 사항을 프로덕션 환경으로 가져오는 방법을 알아본다.

10.2.1 개발 환경 설정

IDE

코드를 작성하는 편집기, 보통 여러 프로그래밍 언어를 지원한다.

노트북은 IDE는 아니지만 유용하다. 그 중 상태 유지 속성은 데이터셋을 한 번 적재한 후 계속 사용할 수 있게 도와주기에 매우 편리하지만, 셀은 순서대로 실행하지 않아도 되기에 재현성 유지를 까다롭게 한다.

넷플릭스의 중요한 블로그 글 ‘인터랙티브를 넘어서: 넷플릭스의 노트북 혁신‘에는 노트북을 더욱 강력하게 만드는 데 사용할 수 있는 인프라 도구 목록이 있다(페이퍼밀, 커뮤터가 포함되어 있다).

노트북 경험 개선을 목표로 하는 또 다른 흥미로운 프로젝트로 nbdev가 있다.

10.2.2 개발 환경 표준화

개발 환경에 대한 첫 번째 준칙은 표준화돼야 한다는 점이다.

도구와 패키지를 표준화해야 한다는 데는 대체로 동의하지만 일부 회사는 IDE 표준화에 주저한다.

로컬 개발 환경에서 클라우드 개발 환경으로 이동했을 때 이점

1. IT 지원이 훨씬 쉬워진다.
2. 원격 작업이 편리해진다.
3. 클라우드 개발 환경이 보안에 도움이 될 수 있다. (일부 기업은 보안 문제 때문에 클라우드 개발 환경으로 이전하기를 꺼린다. 코드나 데이터를 보관하는 것을 꺼린다.)
4. 개발 환경과 프로덕션 환경 간의 차이를 줄일 수 있다.

비용과 보안을 비롯한 문제가 있기에 모든 회사에 적합하지는 않다.

한편, 개발 환경의 표준화는 데이터 과학자의 삻을 보다 윤택하게 해주며 장기적으로 비용을 줄여준다.

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

개발 중에는 워크로드가 크게 변동하지 않는다. 따라서 작업하는 머신 또는 인스턴스 개수는 일반적으로 고정돼 있다.

프로덕션 서비스는 여러 인스턴스에 분산돼 있을 수 있다. 인스턴스 수는 유입되는 워크로드에 따라 수시로 바뀌며, 이는 때때로 예측 불가능하다.

프로덕션 환경의 필요에 따라 인스턴스를 동적 할당하는 경우 환경은 본질적으로 무상태이다. 워크로드에 신규 인스턴스가 할당되면 사전에 미리 정의한 지침 목록을 사용해 종속성을 설치해야 한다.

신규 인스턴스에서 환경을 어떻게 재생성할까? 도커로 가장 유명한 컨테이너 기술은 이 질문에 답하기 위해 만들어졌다.

도커의 핵심 개념 두 가지는 이미지와 컨테이너이다. 도커 파일은 도커 이미지라는 틀을 제조하는 레시피로 볼 수 있다. 이 틀을 사용해 실행되는 인스턴스를 여러 개 찍어낼 수 있다. 각각이 도커 컨테이너이다.

도커 이미지는 밑바닥부터 혹은 다른 도커 이미지로부터 빌드할 수 있다.

컨테이너 레지스트리는 도커 이미지를 공유하거나, 다른 사람이 만든 이미지를 찾아 공개적으로 혹은 조직 내부 사람들과 공유할 수 있는 장소이다.

애플리케이션이 작업을 수행하는 동안 컨테이너가 두 개 이상 필요할 수 있다.

파이프라인의 여러 단계 간에 종속성이 충돌할 때도 서로 다른 컨테이너가 필요할 수 있다.

여러 컨테니어를 관리하는 데 도움이 되는 도구를 컨테이너 오케스트레이션이라고 한다. 도커 컴포즈는 단일 호스트에서 컨테이너를 관리할 수 있는 경량 컨테이너 오케스트레이터이다.

각 컨테이너가 자체 호스트에서 실행될 수 있으며 이때 도커 컴포즈는 한계가 있다. 쿠버네티스(K8s)는 바로 이것을 위한 도구이다. 컨테이너 간에 통신하고 자원을 공유하는 네트워크를 만들어준다.

K8s에 관해 더 자세히 알고 싶다면 제러미 조던이 작성한 글 ‘쿠버네티스 개론‘을 참조하면 좋다.

다만 데이터 과학자에게 친화적인 도구가 아니며, K8s에 대한 직접적인 접근 없이 데이터 과학 워크로드를 다룰 방법에 대해 많은 논의가 있었다.

10.3 자원 관리

ML 워크플로에 대한 자원을 관리하는 방법을 살펴본다.

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

ML 워크플로에는 자원 관리에 영향을 미치는 주요 특성 두 가지, 반복성과 종속성이 있다.

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

크론은 반복 작업이 지정한 시간에 실행되도록 일정을 수립한다. 미리 정한 시간에 스크립트를 실행하고 작업 성공 여부를 알려준다. 실행하는 작업의 종속성은 신경쓰지 않는다.

ML 워크플로의 각 단계는 서로 복잡한 종속성 관계를 갖는다. 예를 들어 ML 워크플로는 다음처럼 다섯 단계로 구성될 수 있다.

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

각 단계는 이전 단계 성공 여부에 따라 달라지고, 다섯 번째 단계는 조건부 종속성을 갖는다.

스케줄러는 종속성을 처리할 수 있는 크론 프로그램이다. 스케줄러를 사용하면 작업이 실패할 경우와 성공할 경우 다음에 수행될 작업을 지정할 수 있다.

스케줄러는 주로 대기열을 활용해 작업을 추적한다. 작업을 대기열에 넣고 우선순위를 지정한 뒤 실행에 필요한 자원을 할당한다.

인기 있는 스케줄러 중 하나로 슬럼(Slurm)이 있다.

구글의 보그(Borg)같은 정교한 스케줄러는 작업에 실제로 필요한 자원의 양을 추정하고 사용하지 않는 자원은 다른 작업을 위해 회수해 자원 활용을 더욱 최적화한다.

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

오케스트레이터는 머신, 인스턴스, 클러스터, 서비스 수준의 그룹화, 복제와 같은 낮은 수준의 추상화 작업을 처리한다. 오케스트레이터는 가용한 인스턴스 풀보다 더 많은 작업이 존재함을 인지하면 인스턴스 풀의 가용한 인스턴스 대수를 늘린다. 이를 워크로드 처리를 위해 더 많은 컴퓨터를 ‘프로비저닝’한다고 말한다.

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

오늘날 가장 잘 알려진 오케스트레이터는 쿠버네티스이다.

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

가장 단순한 형태의 워크플로 관리 도구는 워크플로만 관리한다. 일반적으로 다음 그림과 같이 워크플로를 DAG(방향성 비순환 그래프)로 지정할 수 있다. 워크플로는 피처화 단계, 모델 훈련 단계, 평가 단계로 구성될 수 있다. 워크플로는 코드(Python)나 구성 파일(YAML)을 사용해 정의하며 워크플로의 각 단계를 태스크라고 한다.

거의 모든 워크플로 관리 도구는 스케줄러와 함께 제공되므로, 개별 작업이 아니라 전체 워크플로에 초점을 맞추는 스케줄러로 볼 수 있다. 워크플로가 정의되면 기본 스케줄러는 워크플로를 실행할 자원을 할당하기 위해 오케스트레이터와 함께 작동된다.

2014년에 출시된 초창기 워크플로 오케스트레이터 에어플로를 소개하고, 에어플로의 단점과 그 단점을 개선하여 등장한 프리펙트와 아고를 소개한다. 그 다음으로 프리펙트와 아고의 단점을 말하고, 쿠브플로와 메타플로를 소개한다. 쿠브플로가 더 많이 사용되기는 하지만 저자는 사용자 경험 관점에서 메타플로가 좀더 우월하다고 말한다.

10.4 머신러닝 플랫폼

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

ML 플랫폼 구성 요소는 회사마다 다르고 심지어 같은 회사 내에서도 계속 논의가 이뤄지고 있다.

이 절에서는 모델 배포, 모델 스토어, 피처 스토어를 비롯해 ML 플랫폼에서 가장 흔히 보이는 구성 요소에 중점을 둔다.

이러한 구성 요소를 평가하는 일은 유스 케이스마다 다르지만 일반적으로 다음 두 가지 측면을 염두에 둬야 한다.

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

• 오픈 소스인가 관리형 서비스인가

10.4.1 모델 배포

배포 서비스는 모델과 해당 종속성을 프로덕션 환경에 푸시하고 모델을 엔드포인트로 노출하는 데 도움이 된다.

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

몇몇 도구를 사용하면 온라인 예측을 위한 요청을 배치 예측과는 다른 형태로 처리할 수 있다. 많은 기업에서 온라인 예측과 배치 예측 각각을 위해 별도의 배포 파이프라인을 보유한다.

모델 배포 이전에 모델 품질을 보장하는 방법은 좀 더 연구될 필요가 있다. 배포 서비스를 선택할 때는 해당 서비스로 원하는 테스트를 쉽게 수행할 수 있는지 확인해야 한다.

10.4.2 모델 스토어

많은 회사에서 모델을 개체 스토리지에 저장하는 것만으로는 충분하지 않다는 걸 깨달았다. 디버깅과 유지 관리 작업을 원활하게 하려면 모델 관련 정보를 가능한 한 많이 추적해야 한다. 다음은 저장 가능한 여덟 가지 유형의 아티팩트다. 이 중 여러 아티팩트가 모델 카드에 포함돼야 하는 정보이다.

• 모델 정의
• 모델 매개변수
• 피처화와 예측 함수
• 종속성
• 데이터
• 모델 생성 코드
  • 사용한 프레임워크
  • 훈련 방법
  • 훈련, 검증, 테스트 데이터셋을 분할한 방법에 관한 세부 정보
  • 실험 실행 횟수
  • 고려 대상인 하이퍼파라미터 범위
  • 최종 모델이 사용한 하이퍼파라미터 실젯값 집합
• 실험 아티팩트
• 태그

대부분의 회사에서 이러한 아티팩트 중 일부를 저장하지만 전부 저장하는 회사는 드물다. 회사에서 보관하는 아티팩트들은 모여 있지 않고 흩어져 있을 수 있다.

유스 케이스를 범용적으로 저장할 수 있는 모델 스토어는 아직 갈 길이 멀다.

10.4.3 피처 스토어

ML 실무자들은 피처 스토어가 가져야 할 기능을 정의하기 위해 다양한 시도를 했다. 그 핵심에는 피처 관리, 피처 변환, 피처 일관성 보장이라는 세 가지 주요 문제가 있다. 이를 해결하는 데 피처 스토어가 도움이 될 수 있다.

피처 관리(Feature Management)

회사에는 여러 가지 ML 모델이 있을 수 있으며 각 모델은 수많은 피처를 사용한다. 한 모델에 사용한 피처가 다른 모델에도 유용한 경우가 있다.

피처 스토어는 팀에서 피처를 공유, 검색하고 각 피처에 대한 담당과 공유 설정을 관리하는 데 큰 도움이 된다.

피처 관리를 위한 도구로는 아문센과 데이터허브 등이 있다.

피처 연산(Feature computation)

피처 연산은 피처 변환이라고도 한다. 피처 엔지니어링 로직은 명확히 정의가 이뤄진 다음 연산이 진행된다.

피처의 연산 비용이 크다면 처음 필요할 때 한 번 계산한 뒤 다음번 피처 사용을 위해 저장해두는 편이 좋다.

피처 스토어는 피처 연산을 수행하고 이 연산 결과를 저장하는 데 도움이 된다. 이런 측면에서 피처 스토어는 데이터 웨어하우스와 같은 역할을 한다.

피처 일관성 보장(Feature consistency)

학습 파이프라인은 과거 데이터에서 피처를 배치 추출하고 추론 파이프라인은 피처를 스트리밍 처리를 통해 추출한다. 개발 중에 파이썬으로 작성한 피처 정의를 프로덕션 환경에서 사용하는 언어로 변환해야 할 수도 있다. 즉, 동일한 피처를 한 번은 훈련용으로, 한 번은 추론용으로, 총 두 번 작성한다. 이런 일은 귀찮고 시간이 많이 걸리는 데다가 버그가 발생할 수 있는 영역을 넓혀 모델 오작동을 유발하기도 한다.

최신식 피처 스토어의 주요 셀링 포인트는 배치 피처와 스트리밍 피처에 대한 로직을 통합해 훈련에 사용하는 피처와 추론에 사용하는 피처 간의 일관성을 보장하는 것이다.

이 책이 쓰여진 시점에 가장 인기 있는 오픈 소스 피처 스토어는 피스트이다. 피스트의 강점은 스트리밍 피처가 아닌 배치 피처에 있다.

10.5 구축 vs. 구매

구축과 구매에 대한 결정은 여러 요인에 달려 있다. 인프라 책임자와 이야기할 때 자주 접하는 보편적인 검토 사항 세 가지를 살펴보자.

회사가 속하는 성장 단계

초기에는 공급업체 솔루션을 활용해 가능한 한 빨리 사업을 시작하고, 제한된 제품의 핵심적인 기능을 구현하는 데 집중해야 한다. 추후 유스 케이스가 커짐에 따라 공급업체에 지불하는 비용이 가파르게 상승할 수 있으며 자체 솔루션에 투자하는 편이 더 저렴할 수 있다.

회사의 주안점 또는 경쟁 우위라고 생각하는 것

“정말 잘하고 싶은 일이라면 사내에서 관리할 것이고 그렇지 않다면 공급업체를 이용하겠다.”

소매, 은행, 제조업이라면 대부분 ML 인프라가 주안점은 아니므로 구매에 편중되는 경향이 있다.

기술 회사에서는 기술이 경쟁 우위이며 능력이 우수한 엔지니어링 팀이 기술 스택에 주도권을 갖기를 선호하는데, 이러한 회사는 구축에 편중되는 경향이 있다.

사용 가능한 도구의 성숙도

요구 사항을 충족할 만큼 성숙한 공급업체가 없다면 오픈 소스 솔루션 위에 추가 개발하는 등의 방식으로 자체 구축이 필요하다.

구축과 구매를 결정하는 일은 복잡하고 상황에 따라 크게 다르다.

10.6 정리

ML 모델을 프로덕션 환경으로 가져오는 일 자체가 인프라 문제이다. 데이터 과학자가 ML 모델을 개발하고 배포하도록 하려면 도구와 인프라를 올바르게 설정해야 한다.

ML 시스템에 필요한 다양한 인프라 레이어를 다뤘다.

데이터 과학자가 코드를 작성하고 프로덕션 환경과 상호 작용하는 개발 환경을 논의했다.

그리고 자원 관리를 논의했다. 크론에서 스케줄러, 오케스트레이터에 이르기까지 진화하는 자원 관리 도구의 궤적을 따라가봤다.

ML 플랫폼은 최근 ML 도입 단계가 성숙해지면서 등장한 개념이다. 필수적인 세 가지 도구 집합(배포, 모델 스토어, 피처 스토어)에 집중해 살펴봤다.

마지막으로 필요한 인프라를 직접 구축할지 혹은 구매해야 할지에 관한 문제를 논의했다.