Amazon SageMaker 훈련작업을 위한 최적의 데이터소스 선택하기

이 글은 AWS Machine Learning Blog에 게시된 Choose the best data source for your Amazon SageMaker training job by Gili Nachum and Alexander Arzhanov을 한국어로 번역 및 편집하였습니다.

Amazon SageMaker는 머신러닝 모델의 빌드, 훈련, 배포를 쉽게 만들어주는 관리형 서비스입니다. 데이터과학자들은 SageMaker 훈련작업을 통해 컴퓨팅 리소스 관리에 대한 고민을 할 필요 없이 사용한 시간 만큼만 비용을 지불해 쉽게 ML 모델을 훈련시킬 수 있습니다. 모든 훈련 파이프라인에 있어서 데이터 적재는 필수적인 요소이고, SageMaker 훈련작업은 광범위한 훈련 워크로드에 적합한 다양한 데이터 저장소와 입력모드를 지원하고 있습니다.

이 게시글에서는 SageMaker 훈련작업^{Training Job}이 기본적으로 지원하는 데이터소스 옵션들을 소개하며, 여러분이 SageMaker 훈련 유즈케이스에 맞는 최적의 데이터소스를 선택할 수 있도록 도움드리겠습니다. 각 데이터소스 유형과 입력모드에 대해 사용성과 성능, 비용, 그리고 제약사항에 대해 알아보겠습니다. 예시로 제공해 드리는 의사결정 플로우차트를 통해, 워크로드의 특성을 고려해가며 빠르게 데이터소스를 선택하실 수 있습니다. 또한 실제 훈련 시나리오들에 대해 여러 벤치마크를 수행하고, 전반적인 훈련 비용과 성능에 어떤 영향이 있는지 보여드리겠습니다. 우리가 수행한 벤치마크를 재현하거나 여러분의 실험을 SageMaker Bencher 유틸리티를 활용해 수행하는 방법을 가이드 드리겠습니다.

SageMaker 기본 데이터 소스 및 입력모드

머신러닝 훈련에 있어서 훈련 데이터를 고성능으로 쉽고 유연하게 읽어오는 것은 일반적으로 계속 고민되는 부분입니다. SageMaker는 데이터소스와 입력모드라고 하는 효율적이고 높은 처리량을 가지는 데이터 적재 매커니즘을 선택하는 방식으로 데이터 적재를 단순화하고 있습니다. 이를 통해 여러분은 훈련코드와 실제 데이터소스를 분리하고, 파일시스템을 자동으로 마운팅해서 고성능으로 읽어올 수 있으며, GPU와 인스턴스간의 데이터 병렬화를 위한 데이터 샤딩을 쉽게 적용하거나, 매 Epoch가 시작될 때 마다 데이터를 자동으로 셔플링할 수도 있습니다.

SageMaker 훈련 시, 적재 매커니즘은 기본적으로 아래의 세 가지 AWS 관리형 스토리지서비스와 통합되어있습니다.

• Amazon Simple Storage Service (Amazon S3)는 업계 최고의 확장성과 가용성, 보안 및 성능을 가진 오브젝트 스토리지 서비스 입니다.
• Amazon FSx for Lustre는 Lustre 파일시스템의 확장성과 성능을 가진 완전관리형 공유 스토리지 서비스입니다. 보통 미리 구성된 S3 버킷에 연결해 사용합니다.
• Amazon Elastic File System (Amazon EFS)는 범용으로 사용되는 공유 파일 시스템으로, 다양한 가격 티어에 따른 확장성과 고가용성을 지원합니다. Amazon EFS는 여러분이 파일을 추가하거나 삭제함에 따라 자동으로 확장되거나 축소되는 서버리스 구조입니다.

SageMaker 훈련을 활용하면, 여러분의 훈련 스크립트에서 로컬 파일시스템에 접근하는 것 처럼 Amazon S3, FSx for Luster, 또는 Amazon EFS에 저장된 데이터셋을 사용하실 수 있습니다. (POSIX 호환 파일시스템 인터페이스를 사용)

Amazon S3을 데이터소스로 사용한다면, 여러분은 File 모드, FastFile 모드, Pipe 모드를 선택하실 수 있습니다.

• File 모드 – SageMaker는 여러분의 훈련스크립트를 시작하기 전에 Amazon S3의 데이터셋을 머신러닝 인스턴스에 연결된 Amazon Elastic Block Storage(Amazon EBS) 스토리지 또는 인스턴스의 NVMe SSD 볼륨으로 복사합니다.
• FastFile 모드 – SageMaker는 Amazon S3에 탑재된 데이터셋을 훈련 인스턴스 상의 POSIX 파일시스템으로 노출합니다. 여러분의 훈련스크립트에서 읽는 데이터셋 파일들은 요청에 따라 Amazon S3에서 스트리밍 됩니다.
• Pipe 모드 – SageMaker는 Amazon S3에 있는 데이터셋을 Unix pipe를 통해 훈련 인스턴스로 스트리밍 합니다. 여러분의 훈련스크립트에서 읽는 데이터셋 파일들은 요청에 따라 Amazon S3에서 pipe를 통해 스트리밍 됩니다

FSx for Lustre 또는 Amazon EFS를 데이터소스로 사용하는 경우에는, SageMaker는 파일 시스템을 머신러닝 인스턴스로 먼저 마운팅 한 후 여러분의 훈련스크립트를 시작합니다.

Training Input Channels

SageMaker 훈련작업을 시작할 때, 여러분은 20개 까지의 training input channels를 지정하실 수 있습니다. 채널에 대해 간단히 설명드리자면, 여러분의 훈련작업이 어디에서 어떻게 데이터를 얻어오게 되는지에 대한 추상화된 개념으로 보시면 됩니다. 머신러닝 인스턴스 상에서 여러분의 스크립트가 파일을 읽어올 때에는, 예를들어 /opt/ml/input/data/input-channel-name과 같은 파일 시스템 경로에서 읽어오게 되는 것입니다. 지정된 training channel들은 훈련작업의 메타데이터로 전달되어 전체적인 모델 계보의 추적이 가능하게 됩니다. 이를 통해 훈련작업을 재현한다든지, 모델 거버넌스를 강화한다든지 하는 유즈케이스를 지원합니다.

Amazon S3를 여러분의 데이터소스로 활용하고자 한다면, TrainingInput을 정의할 때 아래 내용이 지정되어야 합니다.

• 입력모드 (File, FastFile 또는 Pipe 모드)
• Distribution, Shuffling 설정
• 다음 3가지 방법 중 하나로 S3DataType을 지정
  • S3Prefix (S3 prefix에 포함된 모든 객체)
  • Manifest file (S3 객체들의 목록)
  • Augmented manifest file (S3 객체들과 레이블 목록)

FSx for Lustre 또는 Amazon EFS를 데이터소스로 사용하는 경우에는, FileSystemInput을 정의합니다.

다음 그림은 5개의 각기 다른 데이터소스와 입력모드 조합으로 만들어진 훈련작업을 보여드립니다.

데이터소스와 입력모드

이번 섹션에서는 SageMaker의 데이터 적재 매커니즘으로서 Amazon S3(File모드, FastFile모드, Pipe모드), FSx for Lustre, 그리고 Amazon EFS가 어떻게 다른지 좀 더 자세히 살펴보겠습니다.

Amazon S3 File모드

따로 명시하지 않는다면 S3를 사용할 때 기본 입력모드로 File모드가 지정되며, 다른 방식들 보다 사용방식이 직관적입니다. 이 입력모드를 사용하면 SageMaker는 모델 훈련을 시작하기 전에 Amazon S3에서 ML 훈련 인스턴스 스토리지로 데이터셋을 다운로드 합니다. 이후 훈련 스크립트에서는 데이터셋을 로컬 파일시스템에서 읽어옵니다. 참고로 훈련 인스턴스 스토리지는 인스턴스 타입에 따라 Amazon EBS 또는 로컬 NVMe로 구성됩니다. 인스턴스 스토리지의 용량은 전체 데이터셋을 담을 정도로 설정 되어야 합니다.

데이터셋은 S3 Prefix, Manifest file 또는 Augmented Manifest file로 지정해 File모드를 구성하실 수 있습니다.

데이터셋의 모든 폴더 및 파일이 특정 S3 Prefix 경로 내에 존재한다면, S3 Prefix 방식을 사용하면 편리합니다. Manifest file은 데이터셋 파일 목록으로 구성되며, 보통 Data 전처리 Job에서 데이터셋의 파일목록을 manifest로 담아 둔다든지, 데이터셋이 여러 개의 S3 Prefix에 나누어 저장되어 있는 경우에 사용합니다. Augmented Manifest은 JSON 파일로, 각 라인의 속성 중 reference에는 Amazon S3 파일 경로가 참조로 잡혀있고, 레이블과 같은 추가적인 속성이 함께 담겨져 있습니다. Manifest와 유사한 사례에 활용할 수 있습니다.

Amazon S3 FastFile모드

FastFile모드는 S3 객체들을 POSIX 호환 파일시스템 인터페이스로 노출해, 마치 훈련 인스턴스의 로컬 디스크에 파일이 들어있는 것 처럼 사용하실 수 있습니다. 데이터는 훈련 스크립트에서 요청 할 때 마다 스트리밍을 통해 전송됩니다. 다시 말해, 데이터셋의 크기를 훈련 인스턴스 스토리지 크기에 맞출 필요가 없고, 훈련 인스턴스를 띄울 때 마다 훈련을 시작하기에 앞서 데이터셋을 다운로드 하는 것이 필요 없다는 것입니다.

SageMaker는 훈련스크립트를 시작하기 전에, 지정된 S3 Prefix 안의 모든 객체의 메타데이터를 리스트합니다. 그리고 이 메타데이터로 읽기 전용의 FUSE(file system in userspace)를 생성해 훈련 스크립트가 /opt/ml/data/training-channel-name 경로를 통해 접근할 수 있게 해 줍니다. S3 객체들의 리스팅은 그 크기에 무관하게 초당 5,500개의 객체를 처리할 수 있기 때문에, File 모드를 통해 직접 다운로드하는 것 보다 훨씬 빠르게 작동합니다. 훈련 스크크립트가 실행되는 동안에는 로컬 디스크에서처럼 파일을 읽어올 수 있습니다. 각각의 읽기 작업은 FUSE 서비스를 통해 Amazon S3에 GET 요청을 보내 수행합니다. 로컬 파일시스템과 같이 FastFile은 바이트 단위로 파일을 다루고 있기 때문에 파일의 형식에 제한이 없습니다. FastFile모드의 성능은 대용량 파일들을 여러 개의 worker를 통해 연속적으로 읽어들일 때 1GB/s 이상의 처리량을 가지고 있지만, 작은 파일 또는 랜덤 액세스 패턴에서는 처리량이 낮아질 수 있습니다. 이 경우에는 읽기 엑세스 패턴을 다수의 작은 파일을 큰 파일에 담고, 연속적으로 읽어오도록 최적화 할 필요가 있습니다.

참고로 FastFile모드는 현재 S3 Prefix만 지원하고 있으며, SageMaker Local모드와 호환 가능합니다.

Amazon S3 Pipe모드

Pipe모드는 또 다른 스트리밍 모드로, 새롭고 더 간단한 Fast File모드로 대체가능합니다.
Pipe모드를 사용하면 Amazon S3에서 UNIX FIFO 파이프들로 데이터를 준비하고^pre-fatch, 높은 처리량과 동시성을 지원합니다. 각 pipe는 단일 프로세스에서만 읽을 수 있습니다. SageMaker 전용 확장기능을 통해 TensorFlow에서는 손쉽게 Pipe모드를 TensorFlow data loader와 통합할 수 있습니다. 텍스트 스트리밍, TFRecords 또는 RecordIO 파일형식을 지원합니다. Pipe모드는 관리형 샤딩과 데이터 셔플링도 지원합니다.

FSx for Lustre

FSx for Lustre는 낮은 지연시간의 파일검색과 수백만의 IOPS와 수백 GB/s의 처리량으로 확장 가능한 파일 시스템입니다.
SageMaker는 훈련작업을 시작할 때 FSx for Lustre 파일시스템을 훈련 인스턴스 파일시스템으로 마운트 하고, 이어서 훈련 스크립트를 시작합니다. 마운트 자체는 FSx for Lustre에 저장된 데이터셋의 크기와 무관하게 상대적으로 빠르게 수행됩니다.

일반적으로 FSx for Lustre 파일시스템을 생성하고 S3 버킷과 Prefix에 연결해 사용합니다. S3 버킷을 데이터 소스로 연결하면, 훈련스크립트에서 파일을 읽을 때 실제 파일이 지연로딩됩니다. 다시 말하자면, 첫번째 에포크^epoch가 수행된 이후에는 전체 데이터셋이 Amazon S3에서 FSx for Lustre 저장소로 복사된다는 것입니다. 그 이후 epoch 부터, 그리고 같은 데이터셋에 대해 새로운 훈련작업을 수행 할 때 부터는 낮은 지연시간으로 파일 접근이 가능해 집니다. (첫번째 epoch에서 전체 훈련 데이터셋을 스캔하는 것으로 정의하고, FSx for Lustre 스토리지에 할당된 용량이 충분히 크다고 가정합니다.)

FSx for Lustre 파일 시스템이 계속 실행 중이면, 파일 시스템을 생성하기 전에 새로운 훈련작업을 시작할 수 있으며, 첫 번째 에포크에서의 Cold Start를 걱정할 필요가 없습니다(파일이 아직 FSx for Lustre 파일 시스템에 캐싱되어 있을 수 있기 때문입니다). 이 시나리오에서의 단점은 파일 시스템을 실행 중 유지하는 데 따르는 추가 비용입니다. 대신에, 각 훈련작업 전후에 파일 시스템을 생성하고 삭제할 수도 있지만(스크립트 자동화를 사용하면 도움이 될 수 있을 것입니다.), FSx for Lustre 파일 시스템을 초기화하는데는 시간이 걸리게 되며, 이는 다루고자 하는 파일 개수에 비례합니다(예를 들어 Amazon S3에서 약 2백만 개의 객체를 색인하는데는 약 1시간이 걸립니다.)

Amazon EFS

이미 Amazon EFS에 기계 학습 훈련 이외의 용도로 훈련 데이터가 적재되어 있는 경우에는 이를 사용하시는 것을 추천드립니다. Amazon EFS를 데이터 소스로 사용하려면 훈련 전에 데이터가 Amazon EFS에 미리 적재되어 있어야 합니다. SageMaker는 지정된 Amazon EFS 파일 시스템을 훈련 인스턴스에 마운트한 다음 훈련 스크립트를 시작합니다. Amazon EFS 파일 시스템을 구성할 때는 작은 파일들에 최적화된 지연 시간의 기본 General Purpose 모드와 높은 수준의 집계 처리량과 초당 작업 수를 지원하는 Max I/O 모드 중 하나를 선택해야 합니다(훈련작업에는 많은 I/O 워커를 사용하는 것이 좋습니다). 자세한 내용은 적절한 성능 모드 사용을 참조하세요.

추가적으로, 처리량 옵션은 busting 과 provisioned 두 가지로 선택할 수 있습니다. 1 TB 파일 시스템에 대한 busting 처리량은 기본 150 MB/s를 제공하며, 하루 12 시간동안 300 MB/s로 증폭 할 수 있습니다. 기본 처리량이 더 높거나 버스트 크레딧을 전부 소진하는 일이 많은 경우, 파일 시스템의 크기를 키우거나 provisioned로 전환할 수 있습니다. provisioned 처리량은 최대 3072 MB/s 읽기를 지원하는 원하는 기본 처리량에 대해 비용을 지불합니다.
훈련작업은 Amazon EFS에 액세스하기 위해 VPC(VPCConfig 설정 참조)에 연결해야 합니다.

최적의 데이터소스 선택하기

훈련작업에 대한 최적의 데이터 소스는 데이터 세트 크기, 파일 형식, 평균 파일 크기, 훈련 시간, 순차 또는 랜덤의 읽기 패턴 및 모델이 훈련 데이터를 소비할 수 있는 속도와 같은 작업량 특성에 따라 달라집니다.
다음 플로우 차트는 시작하는 데 도움이 되는 가이드라인을 제공합니다.

Amazon EFS를 사용해야 하는 경우

데이터 세트가 주로 Amazon EFS에 저장되어 있다면, Amazon EFS를 저장소로 사용하는 전처리 또는 Annotation 프로그램을 가지고 있을 수 있습니다. Amazon EFS 파일 시스템을 가리키는 데이터 채널을 구성해 훈련작업을 쉽게 실행할 수 있습니다(자세한 내용은 Amazon SageMaker에서 Amazon FSx for Lustre 및 Amazon EFS 파일 시스템을 사용하여 훈련 속도를 높이는 방법을 참조하세요). 성능이 예상한 것보다 좋지 않다면, Amazon EFS 성능 가이드와 최적화 옵션을 확인하거나 다른 입력 모드를 고려하세요.

적은 데이터셋에는 File 모드를 사용

데이터 세트가 Amazon S3에 저장되어 있고 전체 용량이 비교적 작다면(예를 들어 50-100 GB 미만) File 모드를 사용하는 것을 시도하세요. 훈련작업 시작 시 50 GB의 데이터 세트를 다운로드한다고 할 때, 소요되는 오버헤드는 총 파일 수에 따라 달라질 수 있습니다(예를 들어 100MB 샤드로 쪼개진 경우 약 5분). 이러한 오버헤드가 받아들일 수 있는 수준인지는 주로 훈련 작업의 전체 소요시간에 따라 달라집니다, 왜냐하면 긴 훈련 시간을 가진다면 이러한 다운로드에 걸리는 오버헤드는 전체 훈련시간에 비해 작은 부분을 차지하게 되기 때문입니다.

다수의 작은 파일들을 Serialize하기

데이터 세트 크기가 작지만(50-100 GB 미만) 작은 파일로 구성되어 있다면(50MB 미만) 파일 모드 다운로드 오버헤드가 증가합니다. 이는 각 파일이 Amazon S3에서 훈련 인스턴스 볼륨으로 개별적으로 다운로드되기 때문입니다. 이 오버헤드를 줄이고 데이터 조회를 빠르게 하려면 작은 파일들의 그룹을 더 작은 파일 컨테이너(TensorFlow의 경우 TFRecord, PyTorch의 경우 WebDataset, MXNet의 경우 RecordIO)에 Serialize 시켜서 작은 파일들을 보다 적은 수의 큰 파일 그룹으로 만들 수 있습니다. 이러한 형식은 데이터 로더가 데이터셋을 순차적으로 Iterate해 사용해야 합니다. 물론 파일을 랜덤하게 셔플링하는 것도 가능합니다. 예를 들어, 각 에포크 후에 TFRecord 파일의 목록을 무작위로 재정렬하고 로컬 셔플 버퍼에서 데이터를 무작위로 샘플링 할 수 있습니다. (다음 TensorFlow 예를 참조하세요).

FastFile 모드를 사용해야 하는 경우

전체 데이터셋 크기가 크고 50MB 이상의 큰 파일들로 구성되어 있다면, 우선 FastFile 모드를 시도해 볼 수 있습니다. FSx for Lustre보다 사용하기 쉬운 특징이 있으며, 파일 시스템을 생성하거나 VPC에 연결할 필요가 없습니다. FastFile 모드는 큰 파일 컨테이너(150MB 이상)에 적합하며, 50MB 이상의 파일도 잘 처리할 수 있습니다. POSIX 인터페이스를 제공하므로 랜덤 읽기(비 순차적 바이트 범위 읽기)를 지원합니다. 그러나 이는 이상적인 사용 사례가 아니며, 순차적 읽기보다 처리량이 낮을 수 있습니다. 하지만 상대적으로 크고 계산 부담이 큰 ML 모델이 있다면 FastFile 모드는 훈련 파이프라인의 유효 대역폭을 매우 잘 사용하여 I/O 병목을 일으키지 않을 수 있습니다. 실험을 통해 확인해 보시기 바랍니다. SageMaker Python SDK를 사용하여 입력 채널을 정의할 때 input_mode=’FastFile’ 매개 변수만 넣어준다면 File모드에서 FastFile 모드로 손쉽게 전환하실 수 있습니다.

sagemaker.inputs.TrainingInput(S3_INPUT_FOLDER, input_mode='FastFile')

이외 다른 코드나 설정의 변경이 필요 없습니다.

FSx for Lustre를 사용해야 하는 경우

여러분의 데이터세트가 File모드를 쓰기에는 너무 크다거나, 쉽게 Serialize할 수 없는 다수의 작은 파일들로 이루어져있거나, 임의 읽기접근 패턴이 있다면, FSx for Lustre가 고려하실 수 있는 좋은 방법입니다. 이 파일 시스템은 수백 GB/s의 처리량과 수백만의 IOPS를 지원하므로 작은 파일이 많을 때 적합합니다. 하지만 이전에 언급한 것처럼, lazy loading에 의한 cold start 문제와 FSx for Lustre 파일 시스템 설정 및 초기화의 오버헤드를 유의해야 합니다.

비용산정 시 고려사항

대다수의 ML 훈련작업, 특히 GPU을 사용하거나 ML 목적으로 만들어진 칩을 사용하는 경우, 훈련비용 중 가장 큰 부분을 차지하는 것은 ML 훈련 인스턴스에 초당 과금되는 요금입니다. 이외에 데이터 소스로 인해 발생하는 추가적인 비용은 월간 저장용량, API 요청 횟수, 예약된 처리량이 있습니다.

월간 저장용량 (GB)

비디오, LiDAR 센서 데이터, 온라인광고의 실시간 로그 등 큰 데이터 세트를 저장할 때는 월간 저장용량이 상당히 클 수 있습니다. 예를 들어, Amazon S3 Intelligent-Tiering Frequent Access Tier에 1TB를 저장하면 1달 기준으로 $23이 듭니다. Amazon S3 위에 FSx for Lustre 파일 시스템을 추가하면 추가 비용이 발생합니다. 예를 들어, SSD-backed Scratch 2 유형의 1.2TB 파일 시스템을 데이터 압축을 사용하지 않고 생성하면 추가적으로 $168/달(1TB 당 $140)가 듭니다.

Amazon S3와 Amazon EFS는 사용한 만큼만 요금이 부과되므로 실제 데이터 세트 크기에 따라 요금이 부과됩니다. FSx for Lustre는 예약된 파일 시스템 크기(최소 1.2 TB)에 따라 요금이 부과됩니다. EBS 볼륨과 함께 ML 인스턴스를 실행할 때는 Amazon EBS는 ML 인스턴스와 별개로 요금이 부과됩니다. 이는 인스턴스 운영 비용과 비교해봤을 때 매우 낮은 비용입니다. 예를 들어, 1시간동안 ml.p3.2xlarge 인스턴스와 100GB EBS 볼륨을 사용할 경우 인스턴스 운영비는 $3.825, EBS 볼륨 운영비는 $0.02가 부과됩니다.

API 요청 및 예약된 처리량 비용

훈련작업을 수행하는 동안 데이터셋을 리스팅하고 파일을 가져오면서 Amazon S3 API 요청을 보냅니다. 예를 들어, 각 백만개의 GET 요청은 Intelligent-Tiering 클래스에서 $0.4 만큼 과금됩니다. Amazon S3에서 인바운드와 아웃바운드로 전송되는 대역폭 비용은 없다고 기대해도 무방합니다, 이는 훈련이 하나의 가용영역(AZ)에서 이루어지기 때문입니다.

S3 버킷과 연결된 FSx for Lustre를 사용할 때, 파일 시스템에 아직 캐시되지 않은 데이터를 읽을 때는 Amazon S3 API 요청 비용이 발생합니다. 이는 FSx for Lustre가 Amazon S3로 요청을 전달하고 결과를 캐싱하기 때문입니다. FSx for Lustre 자체에는 직접적인 API 요청비용이 발생하지 않습니다. 다만 파일 시스템을 생성한 동일한 가용영역에서 훈련작업을 실행해 가용영역 간 데이터 전송에 따르는 추가비용을 피하는 것을 권장드립니다.

Amazon EFS의 경우에는 월간 저장용량 외에도 예약된 처리량 비용에 따르는 추가 비용을 고려해야 합니다.

성능 사례 연구

앞서 언급한 훈련 성능을 위한 고려사항들에 대해 실제 사례를 통해 설명하기 위해, 컴퓨터 비전 분야의 사례에 대한 벤치마크를 수행했습니다. 이 섹션의 벤치마크 및 결론은 모든 상황에 적용되지 않을 수 있으며, DNN 구조와 같은 요소에 의해 영향을 받을 수 있습니다. 본 사례에서는 다음과 같은 12가지 조합에 대해 실험을 진행했습니다.

• 입력모드 – FSx for Lustre, File 모드, FastFile 모드
• 데이터셋 크기 – Smaller 데이터셋(1 GB), Larger 데이터셋(54 GB)
• 파일 크기 – Smaller 파일(JPG 파일들, 약 39KB), Larger 파일(TFRecord, 약 110MB)

본 사례에서는 가장 널리 사용되고 있는 입력모드들을 진행했기 때문에, Amazon EFS와 Pipe 모드는 제외 했습니다.
벤치마크는 ml.p3.2xlarge 단일 GPU 인스턴스에서 SageMaker TensorFlow 훈련작업으로 설계되었습니다. 분류 작업의 백본 모델로 유명한 ResNet-50에서 Caltech-256을 Smaller 데이터셋으로 선택했습니다 (이를 50배 복제하여 Larger 데이터셋 버전을 만들었습니다). 훈련작업은 1 Epoch만을 수행해 전체 학습데이터셋을 1회 풀 스캔하도록 정의했습니다. 이 벤치마크를 재현하기 위한 SageMaker Bencher config 파일은 GitHub에서 확인하실 수 있습니다.

다음 그래프는 각 벤치마크 시나리오별 SageMaker 훈련작업에서 전체 과금시간(total billable time)을 보여줍니다. 전체 과금시간은 Downloading, Training, 그리고 Other(컨테이너의 시작, 훈련된 모델 아티팩트를 Amazon S3에 업로드하는 등)로 구성됩니다. 시간이 짧을 수록 훈련작업에 소요되는 비용이 적은 것으로 이해하시면 됩니다.

우선, 여러 개의 작은 파일로 구성된 데이터 세트에서 입력 모드 사이의 성능 차이를 쉽게 보여주는 Scenario A와 Scenario C를 살펴보겠습니다.

Scenario A (작은 파일, 작은 데이터 세트)는 FSx for Lustre 파일 시스템을 사용한 훈련작업이 가장 적은 과금시간을 가진다는 것을 알 수 있습니다. 다운로드 단계가 가장 짧고, 훈련 단계는 File mode와 비슷하며 FastFile보다 빠릅니다. 1 에포크를 수행하는 테스트에서는 FSx for Lustre가 가장 좋은 결과를 보여주었으나, 여러 에포크를 가진 유사한 워크로드을 고려해 본다면, File mode의 상대적인 오버헤드는 에포크가 더 많아질 수록 줄어듭니다. 이와 같은 경우, 우리는 File mode를 사용하는 것을 고려해 볼 수 있겠습니다. 약 100초 정도의 데이터를 다운받는 시간에 대해서 추가지불하는 것이 FSx for Lustre 파일 시스템을 추가로 구성하고 비용을 들이는 것보다 더 좋은 선택일 수 있기 때문입니다.

Scenario C (작은 파일, 큰 데이터 세트)에서는 FSx for Lustre가 총 과금시간이 5,000초로 가장 빠른 모드로 나타납니다. 또한, FSx for Lustre 파일 시스템을 마운트하는 것은 파일 시스템의 파일 수에 의존하지 않아서(이 경우 1.5백만 파일) 다운로드 단계가 가장 짧습니다. FastFile의 다운로드 오버헤드도 작은 편입니다. FastFile은 지정된 S3 버킷 Prefix 하위에 있는 파일의 메타데이터만 가져오며, 파일의 내용은 실제 훈련 단계에서 읽어들이기 때문입니다. File mode은 가장 느린 모드로, 훈련을 시작하기 전에 전체 데이터 세트를 10,000초 동안 다운로드합니다. 훈련 단계에서는, FSx for Lustre과 File mode는 비슷한 우수한 성능을 보여줍니다. 그리고 FastFile 모드에서는 Amazon S3에서 직접 스트리밍할 때, 각 파일에 대한 새로운 GET 요청을 처리하는 오버헤드가 전체 파일 전송 시간에 비해 상대적으로 중요해집니다(높은 병렬 데이터 로더와 프리패치 버퍼를 사용했음에도 불구하고). 이로 인해 FastFile 모드의 전체 처리량이 낮아지며, 훈련작업에 대한 I/O 병목 현상이 발생합니다. 따라서 이 시나리오에서는 FSx for Lustre가 명백하게 우수한 결과를 보여줬습니다.

Scenario B와 D는 데이터셋이 큰 파일들로 구성될 때 입력 모드별 성능 차이를 보여줍니다. 큰 파일을 이용해 순차적으로 읽는 경우 I/O 성능이 더 좋은 경우가 많습니다. 이는 효과적인 버퍼링을 허용하고 I/O 작업의 수를 줄일 수 있기 때문입니다.

Scenario B (큰 파일, 작은 데이터 세트)는 모든 모드에서 비슷한 훈련 단계 시간을 보여줍니다 (훈련이 I/O에 영향을 덜 받는 결과). 이러한 시나리오에서는 FastFile모드가 File모드보다 짧은 다운로드 단계를 보여주고, FastFile모드가 FSx for Luster보다 사용하기 쉽기 때문에 FastFile모드를 선호할 수 있겠습니다.

Scenario D (더 큰 파일, 더 큰 데이터 세트)는 세 가지 모드 모두의 총 과금 시간이 비슷합니다. File 모드의 다운로드 단계는 FSx for Lustre와 FastFile보다 오래 걸립니다. File 모드는 훈련 단계를 시작하기 전에 Amazon S3에서 전체 데이터 세트(54GB)를 훈련 인스턴스로 다운로드합니다. 훈련작업에 걸리는 시간은 GPU 속도에 의존적이고 세 가지 모드에서 데이터를 가져오는 것은 이미 충분히 빠르기 때문에, 훈련단계에 소요되는 시간은 비슷합니다. 하지만 ml.p4d.24xlarge 같은 추가 CPU 또는 GPU 자원을 가진 ML 인스턴스를 사용할 경우, 컴퓨팅 리소스를 제대로 활용하기 위해서는 데이터 I/O 처리량도 함께 늘어나야 합니다. 이 경우, FastFile과 FSx for Lustre을 사용해 처리량을 늘릴 수 있습니다(단, FSx for Lustre 처리량은 지정된 파일 시스템 크기에 따라 달라집니다). File 모드의 처리량은 인스턴스에 연결된 디스크 볼륨의 처리량에 따라 달라집니다. 예를 들어, Amazon EBS를 기반으로한 인스턴스 (ml.p3.2xlarge, ml.p3.8xlarge, ml.p3.16xlarge와 같은)는 최대 처리량이 250MB/s로 제한되지만, 로컬 NVMe를 기반으로한 인스턴스 (ml.g5.* 또는 ml.p4d.24xlarge와 같은)는 더 큰 처리량을 처리할 수 있습니다.

요약해 보자면, Scenario B와 D에서는 FastFile이 가장 좋은 옵션일 수 있습니다. File모드보다 빠르고, FSx for Luster만큼 빠르지만 사용하기 쉽고 비용효율적이기 때문입니다. 그리고 필요한 수준에 따라 처리량을 쉽게 늘릴 수도 있습니다.

만약 우리가 수 TB에 이르는 크기의 훨씬 큰 데이터셋을 가졌다면, File 모드를 사용하면 훈련이 시작되기 이전에 데이터셋을 다운로드 하는데만 수 시간이 걸릴 것입니다. 반면 FastFile 모드에서는 훈련작업을 훨씬 빠르게 시작할 수 있습니다.

자체 데이터 적재방식 사용하기(Bring your own data ingestion)

SageMaker에서 기본으로 제공하고 있는 데이터 소스들은 대부분의 머신러닝 훈련 시나리오를 만족시키지만, 특정 시나리오에서는 그렇지 않을 수 있습니다. 가령, 서드파티 저장소에서 S3로 데이터를 이관하는 것이 어려워 데이터를 직접 서드파티 저장소에서 읽어온다던지, 하나의 훈련 스크립트를 바꾸지 않고 SageMaker, Amazon EC2나 Amazon EKS에서 동일하게 사용해야 하는 제약사항이 있을 수 있습니다. 이런 경우에는 데이터 적재에 필요한 코드를 훈련 스크립트에 직접 구현해서 사용하실 수 있습니다. 해당 코드는 데이터셋을 외부 데이터소스에서 훈련 인스턴스로 읽어오는 역할을 수행하게 됩니다. 예를들어, Tensorflow에서 제공하는 tf.data 라이브러리의 TFRecordDataset을 Amazon S3 저장소에서 직접 읽어올 수 있는 것이지요.

만약 여러분이 구현 할 데이터 적재방식이 Amazon RDS(Relational Database Service)와 같이 AWS 서비스를 호출해야 하는 것이라면, 여러분의 훈련작업이 필요한 IAM 정책을 가질 수 있도록 AWS IAM(Identity and Access Management) 역할을 부여해 줘야 합니다. 만약 데이터소스가 Amazon VPC(Virtual Private Cloud)에 있다면, 훈련작업이 동일한 VPC에서 수행하셔야 합니다.

여러분이 자체 데이터 적재방식을 사용하신다면, SageMaker의 Lineage 트래킹이 데이터셋을 자동으로 기록할 수 없게 됩니다. 그렇기 때문에, 이 경우에는 훈련작업에 Tag나 하이퍼파라미터를 지정해 필요한 메타데이터를 기록하는 방법을 고려해 볼 수 있습니다.

결론

올바른 SageMaker 훈련 데이터소스를 선택하면 머신러닝 모델 훈련 시 속도, 사용편의성, 비용에 많은 개선을 가져올 수 있습니다. 본 게시글에서 제공한 플로우차트를 사용해 빠르게 시작하고 결과를 관찰해 가며 필요한 추가실험을 진행해 보세요. 각 데이터소스에 따른 장단점과 제약사항을 고려해 여러분의 훈련작업에 얼마나 적합한지를 생각해 보실 수 있습니다. 추가적인 정보나 도움이 필요하시다면 AWS에 문의해 주세요.

참고

SageMaker Bencher에서는 SageMaker 훈련작업을 활용해 복잡한 벤치마크 실험을 위한 데이터셋을 준비, 설계, 오케스트레이트, 트래킹, 분석 기능을 자동으로 수행 할 수 있게 도와줍니다. SageMaker Bencher를 사용해 데이터셋 준비와 벤치마크 실행 프로시저에 대한 규칙들을 하나의 YAML 파일로 구성하실 수 있고, 이를 벤치마크를 직접 수행하고 싶어하는 이들에게 공유 할 수도 있습니다.