Introduction

• ML 시스템은 복잡하다. 시스템이 복잡할수록 인프라에서 발생하는 편익 또한 크다. 인프라를 올바르게 설정하면 프로세스를 자동화해 전문 지식과 공수를 줄일 수 있다. 이는 결과적으로 ML 애플리케이션 개발과 제공 속도를 높이고 버그가 존재하는 영역을 줄이며 새로운 유스 케이스를 만들어낸다. 반면에 잘못 설정하면 인프라는 사용하기 어려워지고 교체하는 데 비용이 많이 들게 된다.
• 본론으로 들어가기에 앞서 주의할 점은 회사마다 인프라 요구 사항이 다르다는 점이다. 각 회사에 필요한 인프라는 개발하는 애플리케이션 개수와 전문성 수준에 따라 다르다.
• 필요에 맞게 인프라를 구축하려면 인프라가 무엇을 의미하며 무엇으로 구성되는지 정확히 이해해야 한다. 위키백과에 따르면 물리적 세계에서 인프라란 “가정과 기업의 지속 가능한 기능을 지원하는 기본 시설과 시스템의 집합”이다. ML 세계에서 인프라란 ML 시스템의 개발과 유지 관리를 지원하는 기본 시설의 집합이다.
  • 스토리지와 컴퓨팅
    • 스토리지 레이어에서는 데이터가 수집되고 저장되며, 컴퓨팅 레이어는 모델 훈련, 피처 연산, 피처 생성 등 ML 워크로드롤 실행하는 데 필요한 연산 자원을 제공한다.
  • 자원 관리
    • 자원 관리는 사용 가능한 연산 자원을 최대한 활용할 수 있도록 워크로드 일정을 수립하고 오케스트레이션하는 도구로 구성된다. 이 범주에 속하는 도구의 예로는 에어플로Airflow, 쿠브플로Kebeflow, 메타플로Metaflow가 있다.
  • ML 플랫폼
    • ML 플랫폼은 모델 스토어, 피처 스토어, 모니터링 도구 같은 ML 애플리케이션 개발을 위한 도구를 제공한다. 이 범주에 속하는 도구의 예로는 세이지메이커와 ML플로가 있다.
  • 개발 환경
    • 개발 환경은 일반적으로 코드가 작성되고 실험이 실행되는 곳이다. 코드는 버전 관리 및 테스트가 수행돼야 하며 실험은 추적돼야 한다.

10.1 스토리지와 컴퓨팅

• ML 시스템은 대량의 데이터로 작동하며 이 데이터는 어딘가에 저장돼야 한다. 스토리지 레이어는 데이터가 수집되고 저장되는 곳으로, 가장 단순한 형태는 하드 드라이브 디스크(HDD)와 솔리드 스테이트 디스크(SSD)이다. 스토리지 레이어는 한곳에 있을 수도 있고(예컨대 모든 데이터가 아마존 S3나 스노우 플레이크에 있는 경우) 다양한 위치에 분산돼 있을 수도 있다. 스토리지 레이어는 프라이빗 센터의 온프레미스에 있을 수도 있고 클라우드에 있을 수도 있다. 과거에는 기업이 자체 스토리지 레이어를 관리하려고 노력했지만 지난 10년 동안에는 스토리지 레이어가 대부분 상품화되고 클라우드로 이동했다. 데이터 스토리지는 매우 저렵해져 대부분의 회사에서 거의 비용 지출 없이 보유한 데이터를 모두 저장한다.
• 컴퓨팅 레이어는 회사가 접근할 수 있는 모든 연산 자원과 그 사용법을 결정하는 메커니즘이다. 사용 가능한 연산 자원의 양은 워크로드 확장성을 결정한다. 컴퓨팅 레이어는 어떤 작업을 실행하는 엔진으로 볼 수 있으며 가장 단순한 형태는 모든 연산을 수행하는 단일 CPU 코어 혹은 GPU 코어이다. 가장 흔한 형태는 AWS 일래스틱 컴퓨트 클라우드(EC2, Elastic Compute Cloud)나 GCP와 같이 클라우드 공급업체가 관리하는 클라우드 컴퓨팅이다.
• 컴퓨팅 레이어를 보통 더 작은 연산 유닛으로 분할할 수 있으며, 유닛들을 동시에 사용할 수 있다. 예를 들어, CPU 코어는 동시 스레드를 두 개를 지원하며 각 스레드는 자체 작업을 실행하는 연산 유닛으로 사용된다. 반대로 여러 CPU 코어를 결합해 더 큰 작업을 실행하기 위핸 더 큰 연산 유닛을 형성할 수도 있다. AWS 스텝 펑션Step Function이나 GCP 클라우드 런Cloud Run과 같이 특정 단기 작업을 위한 연산 유닛을 생성할 수 있다. 이 유닛은 작업이 완료되면 제거된다. 연산 유닛은 가상 머신처럼 보다 ‘영구적으로’, 즉 작업에 얽매이지 않도록 생성할 수도 있다. 보다 영구적인 연산 유닛을 ‘인스턴스’라고도 한다.
• 하지만 컴퓨팅 레이어가 항상 스레드나 코어를 연산 유닛으로 사용하지는 않는다. 코어 개념을 추상화해 다른 연산 유닛을 사용하는 컴퓨팅 레이어도 있다. 예를 들어, 스파크와 레이 같은 연산 엔진은 ‘작업Job’을 유닛으로 사용하며 쿠버네티스는 컨테이너에 대한 래퍼, 즉 ‘포드Pod’를 배포 가능한 형태의 가장 작은 유닛으로 사용한다. 포드 하나에 여러 컨테이너가 있을 수 있지만 동일한 포드에서 서로 다른 컨테이너를 독립적으로 시작하거나 중지할 수는 없다.
• 작업을 실행하려면 먼저 필요한 데이터를 연산 유닛 메모리에 적재한 다음 해당 데이터에서 필요한 연산(덧셈, 곱셈, 나눗셈, 합성곱 등)을 실행해야 한다. 예를 들어, 두 배열을 더하려면 먼저 둘을 메모리에 적재한 다음 덧셈을 수행해야 한다. 연산 유닛에 두 배열을 적재할 만큼 충분한 메모리가 없고 메모리 부족 연산을 처리해주는 알고리즘이 없다면 작업은 불가능하다. 따라서 연산 유닛을 특징지을 때는 주로 메모리 크기와 작업 실행 속도라는 두 가지 지표를 사용한다.
  • 메모리 지표는 기가바이트 같은 단위로 지정하며 평가는 대개 단순하다. 일부 회사에서는 연산 유닛의 메모리 크기 뿐 아니라 데이터를 메모리 안팎으로 적재하는 속도 또한 중요시한다.
  • 작업 속도는 좀 더 논쟁의 여지가 있다. 가장 일반적인 지표는 초당 부동 소수점 연산(FLOPS, floating point operations per second)이다. 이름에서 나타내듯 이 지표는 연산 유닛이 초당 실행 가능한 부동 소수점 작업 수를 의미한다. 하지만 이 지표는 논쟁의 여지가 있다.
    1. 회사에 따라 무엇을 작업으로 간주할지가 서로 다를 수 있다.
    2. 연산 유닛이 1조 FLPOS를 처리할 수 있다고 해서 1조 FLPOPS 속도로 작업을 실행할 수 있다는 뜻은 아니다. 작업에서 수행할 수 있는 FLOPS 수와 연산 유닛이 처리할 수 있는 FLOP 수의 비율을 사용률이라고 한다. 그리고 사용률은 다음 작업을 수행하기 위해 메모리에 데이터를 어라만 빨리 적재할 수 있는지에 따라서도 달라진다. 따라서 I/O 대역폭이 중요하다.
  • 새로운 연산 유닛을 평가할 때는 해당 연산 유닛이 일반 워크로드를 수행하는 데 걸리는 시간을 평가하는 것이 중요하다.
  • FLOPS에 대해 고민하는 것은 그다지 유용하지 않으므로, 많은 사람이 연산 성능을 평가할 때 간단히 연산 유닛이 가진 코어 개수만 살펴본다.

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

• 클라우드 컴퓨팅을 사용하면 기업에서 컴퓨팅 레이어를 크게 걱정할 필요 없이 개발을 매우 쉽게 시작할 수 있다. 이는 워크로드 크기가 유동적인 회사에게 특히 매력적이다. 필요에 따라 연산 자원을 추가하거나 인스턴스를 종료할 수 있어 편리하다. 대부분의 클라우드 공급업체는 이를 자동으로 수행해 엔지니어링 운영에 대한 오버헤드를 줄여준다. 이는 ML에 특히나 유용한데, 데이터 과학 워크로드는 급증하는 경향이 있기 때문이다. 데이터 과학자는 개발 중 몇 주 동안 여러 번의 실험을 실행하는 경향이 있으며 이때 엄청난 연산 성능이 필요하다. 추후 프로덕션 환경에서는 워크로드 크기가 보다 일관되게 유지된다.
  • 클라우드 컴퓨팅은 탄력적이지만 무한하지는 않기에 대부분의 클라우드 공급업체는 한 번에 사용할 수 있는 연산 자원에 제한을 둔다. 일부 제한은 별도 요청을 통해 상향할 수 있다.
• 기업이 클라우드를 활용하는 초기에는 스토리지와 컴퓨팅 레이어를 직접 구축할 때보다 수익이 더 높은 경향이 있지만 기업이 성장함에 따라 수익 방어가 어려워진다. 높은 클라우드 비용으로 인해 기업들은 워크로드를 자체 데이터 센터로 다시 옮기기 시작했다. 이를 ‘클라우드 송환repatriation’이라고 한다. 클라우드 송환에는 상품과 엔지니어랑 양쪽에 대해 결코 적지 않은 선행 투자가 필요하다. 점점 더 많은 기업이 하이브리드 접근 방식을 따르고 있다. 워크로드의 대부분을 클라우드에 유지하면서 데이터 센터에 대한 투자를 천천히 늘리는 것이다.
• 멀티 클라우드 전략
  • 기업이 단일 클라우드 공급업체에 대한 의존을 줄이는 또 다른 방법은 멀티클라우드 전략이다. 즉, 워크로드를 여러 클라우드 공급업체에 분산한다. 이를 통해 기업은 시스템이 여러 클라우드와 호환될 수 있도록 설계해 벤더에 락인lock-in되지 않고, 즉 단일 클라우드 공급업체가 제공하는 서비스에 얽매이지 않고 최상의 비용 효율적인 기술을 활용할 수 있다. 2019년 가트너 연구에 따르면 조직의 81%가 둘 이상의 퍼블릭 클라우드 공급업체와 협력하고 있다. 필자가 본 ML 워크로드의 일반적인 패턴은 GCP나 애저에서 훈련을 수행하고 AWS에 배포하는 것이다.
  • 멀티클라우드 전략을 보통 의사 결정에 따라 발생하는 일은 아니다. 클라우드 간에 데이터를 이동하고 워크로드를 오케스트레이션하는 일은 매우 어렵다.
  • 멀티클라우드는 종종 조직의 서로 다른 부분들이 독립적으로 운영되고 각 부분이 자체적으로 클라우드 선택에 대한 결정을 내리면서 발생한다.
  • 기업 인수 후에 마이그레이션이 수행되지 않아 멀티 클라우드가 발생할 수 있다.
  • 전략적 투자로 인해 멀티 클라우드가 발생하는 일도 있다. AWS를 사용하던 여러 회사들이 마이크로소프트와 구글에게 투자를 받고 나서 애저와 GCP로 이전했다.

10.2 개발환경

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