본 문서는 총 2부로 구성되어 있으며 이 글은 1부입니다.
2부 링크 : 대규모 머신 러닝 활용 — AWS에서 Parallelized Modeling to HPC 인프라 매핑 2/2
요약
이 백서에서는 AWS에서 규모에 맞게 머신 러닝(ML) 워크플로우를 실행하는 모범 사례를 소개합니다. ML 사용 사례에 적합한 인프라를 설계하기 위한 엔드 투 엔드 고려 사항, 과제 및 권장 솔루션의 개요를 제공합니다.
이 백서의 대상에는 IT 그룹, 엔터프라이즈 설계자, 데이터 과학자 및 AWS에서 HPC(High Performance Computing) 인프라를 사용하여 규모에 맞게 병렬화된 모델링 실행을 위한 기술 권장 사항을 이해하는 데 관심이 있는 사람들이 포함됩니다.
소개
기업은 그 어느 때보다 많은 데이터를 생성, 저장 및 분석하고 있습니다. 머신러닝(ML)의 최신 발전과 함께 이러한 방대한 데이터셋을 사용하여 비즈니스 성과를 창출할 수 있는 드라이브가 있습니다. ML 알고리즘은 20년 이상 사용되었지만, 최근 ML 채택의 모멘텀이 증가한 것은 알고리즘 프레임워크의 발전과 계산 가속기를 포함한 알고리즘을 실행하는 데 사용되는 컴퓨팅 인프라에 기인합니다. 따라서 비교적 짧은 시간 내에 데이터 세트에 복잡한 수학적 계산을 반복적으로 적용하고 자동으로 적용할 수 있게 되면서 ML 분석의 새로운 차원이 추가되었습니다. 기업은 구축된 다양한 장치 및 센서에서 데이터를 수집하고 분석하여 작업을 자동화하고, 최종 사용자에게 맞춤형 서비스를 제공하며, 운영 효율성을 높이는 머신 러닝에 점점 더 의존하고 있습니다. 기업은 규모의 경제와 향상된 민첩성을 활용하기 위해 ML 워크로드를 AWS 클라우드로 이동하고 있습니다. 예를 들어, Marinus Analytics는 인신매매와 싸우기 위해 얼굴 검색과 인식 기술을 사용하고 있습니다. Philips HealthSuite 디지털 플랫폼에 저장 및 분석되는 환자 데이터의 페타바이트는 ML 방법론을 사용하여 분석되고 있습니다. TuSimple은 AWS Cloud의 ML을 L4 자율 주행 시스템의 인식 거리 기능에 사용하고 있습니다.
현재 ML 워크로드를 확장하고 가속화하는 기능은 HPC(High Performance Computing) 방법론과 애플리케이션을 기반으로 합니다. 현대의 HPC는 GPPU(Graphics Processing Unit)를 범용 컴퓨팅(GPGPU), 대규모 병렬 데이터 스토리지, 낮은 지연 시간, 높은 대역폭의 네트워크 통신을 사용하여 컴퓨팅 및 메모리 집약적인 문제를 해결할 수 있습니다. 이러한 문제들은 기후 연구, 유체 역학, 생명 과학을 포함한 많은 과학 연구 분야에 공통적입니다. 이러한 학문은 DL(Deep Learning)과 같은 ML 영역과 연산 요구를 공유합니다. DL 워크로드의 컴퓨팅 요구사항은 HPC 메서드를 활용할 수 있는 최적의 후보입니다.
데이터 관리
데이터는 모든 ML 프로젝트를 뒷받침하고 어떤 ML 접근 방식이 가장 적합한지 뿐만 아니라 이를 지원하는 데 가장 적합한 인프라도 결정합니다. 데이터 소스, 데이터의 수정 또는 업데이트 빈도, 데이터가 저장될 위치 등은 모두 프로젝트가 시작되기 전에 해결해야 할 기본적인 질문입니다. ML 접근법을 사용하여 데이터를 분석하기 전에 표준화, 정규화 및 보강이 필요한 것은 드문 일이 아닙니다. 기존 HPC 또는 핵심 ML 제품에 비해 주변적이지만 AWS는 프로젝트의 전처리 단계에서 도움이 될 수 있는 ETL(추출, 변환, 로드) 처리 서비스를 제공합니다. 다양한 머신 러닝 분석 프로세스가 데이터를 수집, 생성 및 전송할 수 있는 다양한 방법이 있습니다. 이러한 워크플로우의 각 단계를 지원하려면 스토리지 인프라 및 데이터 관리 도구가 있어야 합니다. 각 단계에서 데이터의 내구성과 가용성을 고려해야 합니다. 스토리지 요구 사항을 결정하려면 데이터 집합의 크기와 데이터를 읽고, 쓰고, 전송하기 위한 성능 요구 사항을 고려해야 합니다.
머신 러닝 및 심층 학습 예측 모델링 애플리케이션에 필요한 데이터의 양은 문제와 알고리즘의 복잡성에 정비례합니다. 데이터 집합 크기가 충분한지 확인하기 위해 많은 데이터 과학자들이 학습 곡선, 소규모 데이터 집합에서 k-폴드 교차 검증 재샘플링 방법, 최종 결과의 신뢰 구간을 평가합니다. 또한 학습 데이터 세트로 적절하게 표현되어야 하는 클래스, 입력 기능 및 모델 매개변수를 기반으로 적절한 표본 크기에 대한 추정치를 계산하는 통계적 경험적 방법이 있습니다. 따라서 머신러닝 애플리케이션에 필요한 데이터 세트는 데이터베이스 웨어하우스, 스트리밍 IoT 입력 또는 중앙 집중식 데이터 호수에서 추출되는 경우가 많습니다. 많은 고객이 Amazon Simple Storage Service(Amazon S3)를 학습 데이터셋의 타겟 엔드포인트로 사용합니다. ETL 처리 서비스(Amazon Athena, AWS Glue, Amazon Redshift Spectrum)는 기능적으로 보완적이며 Amazon S3에 저장되거나 대상으로 지정되는 사전 처리 데이터 세트로 설계될 수 있습니다. Amazon Athena 및 Amazon Redshift Spectrum과 같은 서비스를 사용하여 데이터를 변환하는 것 외에도 AWS Glue와 같은 서비스를 사용하여 메타데이터 검색 및 관리 기능을 제공할 수 있습니다. 또한 ETL 처리 도구의 선택은 사용자의 데이터 유형에 따라 결정됩니다. 예를 들어 Amazon Athena를 사용한 표 형식의 데이터 처리는 시퀀스 쿼리 언어(SQL)를 사용하여 Amazon S3의 데이터 파일을 조작할 수 있는 기능을 제공합니다. 데이터 세트 또는 계산이 SQL과 최적으로 호환되지 않는 경우 Amazon Glue를 사용하여 Amazon S3 버킷에 저장된 데이터에 대해 Spark Job(Scala 및 Python 지원)을 원활하게 실행할 수 있습니다.
데이터를 분석할 때는 데이터 사전 처리 및 모델링 선택에 대한 정보를 제공할 수 있는 추세를 시각화할 수 있는 여러 그림을 만드는 것이 유용합니다. 시각화는 데이터 세트가 충분히 대표성이 있는지 여부를 나타내는 우발적인 상관 관계, 샘플링 편견 또는 응답하지 않는 편견을 식별하는 데 도움이 되며 보이지 않는 새로운 데이터로 일반화될 수 있습니다. 데이터 품질은 오류 또는 누락 값의 빈도, 노이즈 대 신호 비율 및 데이터 분포의 이질성을 평가하여 정량화할 수 있습니다. AWS는 사용자의 선호도에 따라 호소 수준이 다른 데이터를 시각화할 수 있는 두 가지 서버 없는 옵션을 제공합니다. 그래픽 사용자 인터페이스(GUI)를 선호하는 경우 Amazon QuickSight를 사용하여 Amazon S3에 저장된 데이터를 사용하여 대화형 대시보드에 플롯을 작성할 수 있습니다. 코드를 더 쉽게 작성할 수 있는 경우 Amazon SageMaker는 Amazon S3 버킷의 데이터에 연결하고 시각화 작업을 위해 Amazon Athena 및 AWS Glue 작업을 실행할 수 있는 관리되는 Juppyter 노트북을 제공합니다.
더 빠른 프로세서와 더 많은 코어를 포함하는 컴퓨팅 계층의 개선을 통해 점점 더 복잡한 알고리즘을 사용하여 더 큰 데이터 워크로드를 처리할 수 있습니다. 불행히도 이러한 개선으로 인해 머신 학습 워크로드를 확장할 때 스토리지 I/O 처리 병목 현상이 발생합니다. 메타데이터 및 I/O를 여러 컴퓨팅 노드 또는 모든 컴퓨팅 노드에서 관리하는 고성능 병렬 파일 시스템은 라우팅 관리를 위해 단일 관리 노드를 사용하는 파일 시스템에서 발생하는 병목 현상을 완화할 수 있습니다. 병렬 파일 시스템을 동기화하는 데 필요한 지연 시간과 응답 시간은 병렬 파일 시스템의 성능을 최적화하는 데 필요한 요소입니다.
딥러닝 학습 애플리케이션에는 낮은 지연 시간과 높은 처리량으로 지속적으로 데이터를 제공할 수 있는 스토리지 시스템이 필요합니다. 다양한 머신 러닝 및 심층 학습 애플리케이션에 대한 I/O 프로파일은 다양하고 랜덤할 수 있으므로 사용 사례에 맞게 설계할 때 고려해야 할 상당한 성능 문제가 발생합니다. 예를 들어 GPU 가속화 분석에서는 대개 큰 스레드 수를 사용하며, 각 스레드 수에는 데이터 입력 세그먼트에 대한 짧은 지연 시간이 필요합니다. 객체 감지를 위한 CNN의 경우 스트리밍 대역폭과 빠른 메모리 매핑을 통해 랜덤 액세스를 활성화하면 성능이 향상됩니다. 고성능 랜덤 세그먼트 I/O 액세스는 RNN 및 NLP 유형 스터디의 성능을 최적화합니다. 높은 수준의 컴퓨팅에서 공통적으로 발생하는 병목현상은 GPU 작업자에게 데이터가 충분히 전달되지 않는다는 것입니다. AWS는 여러 스토리지 옵션을 통해 GPU를 포화 상태로 유지함으로써 유연성을 제공합니다. K80 P2 인스턴스 같은 이전 세대 NVIDIA GPU를 실행하는 애플리케이션의 경우 Amazon S3는 I/O 처리 시 바람직한 동시성을 유지하기에 충분합니다. 높은 처리량이 필요한 P3 인스턴스의 경우 Amazon Elastic File System(Amazon EFS) 또는 Amazon FSx for Lustre(Amazon FSx)와 같은 대규모 병렬 파일 시스템을 선택하여 수요에 맞춰 탄력적으로 확장할 수 있습니다.
대규모 데이터 세트를 한 위치에서 다른 위치로 이동하는 작업은 비용이 많이 들 수 있으므로 데이터를 이동하기 전에 모든 요구 사항과 시사점을 고려했는지 확인해야 합니다. Amazon S3 읽기가 Amazon S3의 읽기 성능 능력을 능가하지 못할 것으로 예상되는 상황에서는 데이터를 고성능 스토리지 위치로 이동할 필요가 없습니다. 비즈니스에 더 빠른 학습 속도가 필요하지 않은 경우 모델을 더 느린 속도로 학습하고 이러한 성능 요구 사항에 맞는 스토리지 위치를 사용할 수 있습니다.
다른 상황에서는 비즈니스 요구 사항을 충족하기 위해 학습 속도가 필수적일 수 있습니다. 이러한 시나리오에서 준비된 데이터 세트를 병렬 파일 시스템으로 마이그레이션하면 학습 성능이 향상될 수 있습니다. 표 1은 일부 다른 파일 시스템의 예와 해당 시스템이 이미지를 컴퓨팅 클러스터로 전송할 수 있는 상대 속도를 보여 줍니다. 이 성능은 단일 측정에 불과하며 주어진 워크로드에 사용할 수 있는 파일 시스템을 제안하는 것일 뿐입니다. 지정된 워크로드의 세부 정보가 이러한 결과를 변경할 수 있습니다.
모델을 학습한 후에는 모델을 평가하는 프로세스가 학습 단계만큼 데이터에 종속되지 않는 경우가 많습니다. 따라서 평가 데이터를 Amazon S3에 저장할 수 있습니다. 이렇게 하면 Amazon SageMaker Batch Transform과 같은 도구를 사용하여 서버가 없는 환경에서 모델을 평가할 수 있습니다.
배포의 경우 데이터 요구 사항은 문제에 크게 좌우됩니다. 배치 변환에 모델을 사용할 경우 데이터를 미리 준비하여 Amazon S3 또는 이전에 언급한 다른 파일 시스템 중 하나를 사용하여 모델에 제공할 수 있습니다.
현재 Amazon S3 단일 개체 업로드가 5GB로 캡쳐되어 있으며 파일 크기는 최대 5TB로 설정되어 있습니다. 사용할 파일 시스템을 결정하려면 처리해야 하는 데이터의 크기와 처리 속도에 대한 비즈니스 요구 사항을 고려해야 합니다.
실시간 예측 시스템은 짧은 시간 동안만 실시간으로 간주되기 때문에 더욱 복잡합니다. 이러한 경우 추론 시간이 요구 사항을 충족하도록 추론 파이프라인의 각 단계를 분석하고 조정해야 할 수 있습니다. AWS에서 실시간 추론을 위해 모델 끝점으로 전송되는 API 요청을 충족하도록 자동 확장된 로드 밸런서 뒤에 서버를 둔 Amazon SageMaker 배포를 사용할 수 있습니다. 또 다른 옵션은 Amazon Elastic Inference를 정확한 양의 GPU 가속으로 설정한 것을 비용 절감으로 사용하여 확장된 추론을 제공하는 것입니다. 마찬가지로 SageMaker Neo에 널리 사용되는 딥러닝 프레임워크 모델을 배치하여 대상 하드웨어 플랫폼에 맞게 학습된 모델을 최적화할 수 있습니다.
극단적인 경우 SageMaker 배포의 지연 시간이 너무 길 수 있습니다. 이러한 상황에서 병목 현상을 찾으려면 추론을 위한 데이터가 어디에서 왔는지, 모델에 대한 경로, 모델을 실행하는 하드웨어 및 응답 경로에 대한 광범위한 감사를 수행해야 합니다. 그런 다음 모델을 배치해야 하는 위치와 추론 수행 방법에 대해 평가할 수 있습니다. 경우에 따라 서로 다른 데이터 소스에서 필요한 데이터를 가져오는 것이 제한될 수 있으므로 실시간 추론을 사용하도록 데이터 액세스 패턴을 다시 설계해야 합니다. 다른 경우에는 모델을 데이터 소스에 더 가깝게 만들어야 합니다. 이 경우 모형을 가장자리에 배포하여 데이터 생성기와 직접 상호 작용할 수 있습니다. AWS는 추론 파이프라인을 제대로 구현하기 위해 Amazon SageMaker 모델을 에지 디바이스에 배포하는 AWS IoT GreenGrass를 제공하지만 파이프라인의 데이터 요구 사항과 사용자 정의를 결정해야 합니다. 이러한 경우 모델 배포가 제때 완료되고 성능 요구 사항이 충족되도록 하려면 AWS Professional Services에 도움을 요청하는 것이 좋습니다.
분산 연산 프레임 워크
분산 연산 프레임워크는 데이터 처리 및 노드 작업 배포 및 관리에 대한 프로토콜을 제공합니다. 또한 MapReduce 및 Apache Spark와 같은 프레임워크는 데이터 세트를 서브셋으로 분할하여 컴퓨팅 클러스터의 노드 간에 배포하는 알고리즘을 제공합니다. Apache Spark 클러스터를 Amazon EMR에서 실행하면 대량의 데이터를 처리할 수 있는 관리 프레임워크가 제공됩니다. Amazon EMR은 HPC 애플리케이션에 적합한 CPU와 네트워크 성능이 비례적으로 높은 클러스터 컴퓨팅 인스턴스를 포함하여 여러 인스턴스 유형을 지원합니다. 또한 Amazon SageMaker 노트북 인스턴스를 스파크 EMR 클러스터에 연결하여 대규모 데이터셋 처리를 위한 분산 프레임워크를 통해 제공되는 데이터 과학 및 머신 러닝 워크플로우를 위한 완벽한 관리 서비스를 사용자에게 제공할 수 있습니다.
예를 들어, 규모에 맞게 DL(Deep Learning)을 수행할 때 데이터 세트는 일반적으로 메모리에 맞추기에는 너무 커서 데이터 세트의 파티션을 분할하는 사전 처리 단계가 필요합니다. 일반적으로 여러 시스템에 분산된 데이터를 병렬로 패키징하는 것이 좋습니다. 한 번의 실행으로 이 작업을 수행하고 데이터를 동일한 수의 파티션으로 소수의 파일로 분할해야 합니다. 데이터를 분할하면 데이터에 쉽게 액세스할 수 있으며 여러 시스템에 일괄적으로 쉽게 액세스할 수 있습니다. 데이터를 소수의 파일로 분할하면 준비 작업을 병렬로 하여 더 빠르게 실행할 수 있습니다. Amazon Spark EMR 클러스터 외에도 Amazon SageMaker 파이프 및 AWS Glue와 같은 다른 도구를 사용할 수도 있습니다(데이터 세트 크기에 따라 다름).
Spark 또는 Python에서 실행되는 Spark의 Big DL과 같은 타사 솔루션도 많이 있습니다. 이러한 솔루션은 기존 데이터 준비 파이프라인에 통합할 수 있습니다.
데이터 로드 프로세스 중에 새로운 데이터가 GPU 작업자에게 제공되어 DL 알고리즘을 학습합니다. 일반적으로 DL 데이터 로더는 인접 위치에서 연속적으로 데이터를 읽고, 데이터를 소형으로 저장하며, 다른 스레드에 로드 및 학습하고, RAM을 능동적으로 변환할 수 있어야 합니다. 모든 데이터 처리는 CPU 측에서 실행되어야 하며, CPU가 다음 배치의 데이터를 처리하여 GPU에 공급될 준비가 되어 있어야 합니다. GPU를 데이터 처리에 사용하지 않는 것이 좋습니다. 대신 DL 모델을 학습할 때만 GPU를 사용하여 CPU(생산자)와 GPU(소비자) 간에 소비자 또는 생산자가 겹치지 않도록 합니다. 이미지 조작과 같은 경우에 데이터 준비는 컴퓨팅 집약적일 수 있습니다. 이러한 경우 GPU 지원 인스턴스에 액세스할 수 있는 AWS 배치 작업을 사용하여 대규모 데이터 세트를 조작할 수 있습니다. AWS Batch의 스폿 인스턴스 가격과 NVIDIA GPU의 OpenCV 가속화를 쉽게 확장하고 액세스할 수 있으면 이미지 데이터 세트를 효율적으로 준비할 수 있습니다.
로드 프로세스의 일부로 데이터를 일괄 처리(임의 정렬)합니다. 규모에 맞게 입력된 데이터의 경우 데이터 로드 프로세스가 시작되기 전에 데이터를 섞고 버퍼 크기를 더 낮은 숫자로 설정하는 것이 좋습니다. 셔플링이 성능에 부정적인 영향을 미치지 않고 수행되도록 하려면 파티셔닝된 작은 파일에서 이 작업을 실행합니다. 로드 프로세스를 병렬로 실행하는 것이 좋으며, 경우에 따라 처리 시간이 다를 때와 같이 둘 이상의 배치를 미리 가져오는 것이 유용할 수 있습니다.
Tensorflow, PyTorch 및 MxNet과 같은 대부분의 프레임워크는 디스크에서 파일을 로드하는 데 사용할 수 있는 데이터 로드 클래스를 제공합니다. 이러한 기능은 다음 번 데이터 청크가 필요할 때마다 데이터 로더 기능을 호출하므로 빅 데이터를 일괄 처리할 수 있습니다. 또한 많은 프레임워크에는 사용자 지정 파이프라인을 python 코드 및 라이브러리 도우미 기능으로 쓰는 데 사용할 수 있는 데이터 파이프라인 기능도 포함되어 있습니다. 단일 프레임워크에는 둘 이상의 옵션이 있고 사용 가능한 범용 형식(예: Open Neural Network Exchange Format onNX4)이 없으므로 데이터 파이프라인을 다른 DL 플랫폼으로 이동하기가 어려울 수 있습니다. 또한 Dask, Ray, PyToolz 및 ipyparallel과 같이 분석을 위한 작업 스케줄링을 통해 병렬 컴퓨팅을 지원하는 몇 가지 오픈 소스 라이브러리가 있습니다.
ML 모델을 학습하는 과정은 ML 프로세스에서 가장 계산 집약적인 단계가 될 수 있습니다. 모델 학습은 컴퓨팅 집약적이므로 수평적 확장 전에 수직적 확장을 완료하는 것이 좋습니다. 모델 학습을 위해 CPU에서 GPU로 이동하면 성능이 크게 향상되므로 기존 CPU에서 복잡한 ML 모델을 학습하는 것은 권장하지 않습니다. GPU 카드의 학습 시간이 비즈니스 요구 사항에 맞지 않을 경우 여러 GPU로 이동하기 전에 보다 강력한 GPU를 사용해 보는 것이 좋습니다. 마찬가지로 다중 노드 솔루션으로 이동하기 전에 단일 노드에서 여러 GPU를 활용하는 것이 좋습니다. 이러한 접근 방식은 일반적으로 최상의 성능을 제공하며 복잡성이 필요할 때까지 시스템의 복잡성을 제한합니다.
단일 GPU 인스턴스에서 보다 복잡한 학습 인프라로 변경하기 전에 모든 영향을 고려하는 단계별 분석 프로세스를 완료하는 것이 좋습니다. 단일 GPU 인스턴스가 충분히 빠르게 학습되지 않는 경우 가장 먼저 평가해야 할 것은 GPU 활용도입니다. 현재, DL 모델을 학습하는 가장 일반적인 방법은 GPU로 데이터 묶음을 보내는 것입니다. GPU는 모델을 통해 데이터를 실행한 후 모델 가중치가 업데이트됩니다. 이 접근 방식을 통해 GPU는 사이클을 거칩니다. GPU는 데이터를 기다리고, 그 데이터를 계산한 다음, 더 많은 데이터를 기다립니다. GPU가 데이터를 소비하는 속도보다 빠르게 GPU에 대비할 수 없는 경우 데이터 준비 병목 현상이 발생하며, GPU가 빠를수록 모델 학습 속도가 크게 증가하지 않습니다.
대부분의 DL 프레임워크는 데이터 준비가 병목 현상을 일으키지 않도록 데이터 세트를 병렬로 준비하고 일반적으로 CPU를 사용하여 준비된 데이터 세트를 GPU 소비에 맞게 메모리에 저장하도록 설계된 데이터 준비 프레임워크를 구현합니다. 이러한 CPU 작업이 이상적으로 작동하는 경우 이러한 CPU 작업은 GPU가 데이터를 소비할 수 있는 속도보다 빠르게 데이터를 준비하지만 시스템이 항상 최신 GPU를 준수할 수는 없습니다. 학습 중 GPU 활용률이 극대화되지 않은 경우 일반적으로 수를 증가시키기가 쉽기 때문에 먼저 컴퓨팅 리소스가 데이터 준비 전용 프로세스(Python, 그러나 잠재적으로 다른 언어로 된 스레드)를 더 많이 처리할 수 있는지 확인합니다.
CPU가 더 많은 프로세스를 처리할 수 없는 경우, 데이터 준비 프로세스가 IO 제한인지 또는 컴퓨팅 제한인지를 확인하는 것이 중요합니다. IO가 데이터 준비를 제한하는 경우 데이터를 다른 데이터 저장소로 이동하는 것을 고려할 수 있습니다. 컴퓨팅 프로세스가 데이터 준비를 제한하는 경우 먼저 필요한 프로세스만 실행 중인지 확인합니다. 예를 들어 모델에서 256 x 256 픽셀의 해상도로 영상을 가져오지만 영상이 1920 x 1080 픽셀의 해상도로 저장된 경우, 먼저 모든 영상을 학습 프로세스가 시작되기 전에 256 x 256 픽셀로 줄이는 것이 알고리즘에 따라 가능할 수 있습니다. 이렇게 변경하면 이미지를 로드하는 데 필요한 시간이 줄어들고 일부 처리 단계가 제거됩니다. 극단적인 경우 사전 처리를 줄일 수 없는 경우 데이터 준비 클러스터를 사용하여 모델에 공급할 데이터 배치를 생성해야 할 수 있습니다. 데이터 준비 클러스터를 사용하면 데이터를 준비하는 데 임의의 수의 프로세스를 사용할 수 있습니다.
단일 GPU가 완전히 포화 상태이고 학습 시간이 여전히 비즈니스 요구 사항을 충족하기에 충분하지 않은 경우, 보다 강력한 GPU를 사용할 수 있습니다. 현재 P3 인스턴스(instance) 제품군은 AWS에서 가장 강력한 GPU(Volta V100)를 보유하고 있습니다. 보다 강력한 GPU로 전환한 후에는 위의 프로세스를 반복하여 새로운 GPU가 병목 현상을 GPU에서 데이터 준비로 이동하지 않았는지 확인해야 합니다. GPU가 여전히 제한되어 있고 학습 시간이 충분하지 않으면 다음 단계는 GPU가 더 많은 노드로 이동하는 것입니다.
여러 GPU를 사용하는 단일 노드는 여러 노드에 분산된 동일한 수의 GPU보다 몇 가지 장점이 있습니다. 첫째, 단일 노드의 GPU 간 통신은 NVLink를 초과하는 경우가 많으며 노드가 배치 그룹에 있는지 여부에 관계없이 네트워크를 통해 다른 노드로 이동하는 것보다 훨씬 빠릅니다. 둘째, GPU 메모리와 시스템 메모리 간의 정보 이동이 네트워크를 통한 통신보다 빠릅니다. 따라서 동일한 노드의 많은 GPU가 네트워크를 통해 통신하는 여러 노드보다 더 빠르게 매개 변수 업데이트를 집계할 수 있습니다.
가장 큰 단일 노드 GPU 시스템이 충분히 빠르지 않고 데이터 준비가 병목 현상이 아닌 경우 GPU 컴퓨팅 노드 클러스터가 가능한 솔루션입니다. 심층 학습 프레임워크는 멀티 노드 모델 학습을 지원하는 다양한 방법을 가지고 있으므로 이상적인 클러스터 설정은 프레임워크에 따라 다릅니다. 모든 프레임워크에 대한 개요는 본 문서의 범위를 벗어나지만 몇 가지 공통점이 있습니다. 우선, 네트워크 대역폭과 지연 시간이 중요한 리소스를 만드는 데이터 로딩 및 매개 변수 업데이트에 대한 네트워크 통신이 있어야 합니다. AWS에서 분산 학습을 최적화하기 위한 중요한 첫 번째 단계에는 대역폭이 가장 높은 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 선택하고 배치 그룹에서 모든 인스턴스를 찾는 작업이 포함됩니다. Horovod와 같이 네트워크 통신을 감소시키는 알고리즘과 파라미터의 정밀도를 낮추는 알고리즘은 네트워크 대역폭이 제한되어 있기 때문에 성능 향상을 위해 필수적입니다.
워크로드에 맞게 컴퓨팅 클러스터 구축
심층 학습 학습을 위한 좋은 기본 아키텍처에는 Amazon S3, Amazon EC2, Amazon Virtual Private Cloud(Amazon VPC), Amazon EC2 Auto Scaling, Kubernetes용 Amazon EKS Container Service(Amazon EKS), AWS Identity and Access Management(IAM) 서비스가 포함됩니다. 그림 1의 심층 학습 CFN 클러스터와 같이 AWS CloudFormation 템플릿에 구축된 이러한 AWS 서비스를 함께 사용하면 유연성, 안정성 및 낮은 수준의 투명성이 향상됩니다. Amazon EC2 자동 확장을 사용하면 애플리케이션을 몇 개의 노드에서 백 개 이상으로 동적으로 확장할 수 있으며, 복제본 세트의 리소스에 대한 다중 영역 커버리지를 제공할 수 있습니다. Amazon EKS의 Kubernetes를 사용하여 컨테이너에 넣고 제어하면 통합된 모니터링 및 로깅 프레임워크를 사용하여 종속성 분리를 생성할 수 있습니다. 또한 OS와 장치 드라이버 계층 종속성을 분리할 수 있습니다. 응용 프로그램에 대한 템플릿을 생성할 때 사용합니다. 잠재적인 병목 현상과 개선 영역을 신속하게 식별할 수 있습니다. CloudFormation 템플릿(또는 코드 프레임워크로서의 다른 인프라)의 유연성을 통해 리소스를 온디맨드 방식으로 확장하고 사용할 수 있으므로 인프라가 견고함을 보장할 수 있습니다.
심층 학습 클러스터에 대한 CloudFormation 템플릿에는 VPC, SSH 연결 액세스 권한이 있는 마스터 인스턴스, 자동 확장, 마스터 및 작업자 구성을 위한 SQS, 보안 그룹이 포함됩니다. 또한 데이터 액세스를 위한 EFS 마운트를 자동으로 생성하고 AWS Lambda 및 Amazon Simple Notification Service(Amazon SNS)를 사용하여 활동 모니터링을 시작합니다.
추가 머신 러닝 클러스터 아키텍처 다이어그램은 부록을 참조합니다.
머신러닝 워크플로우에서는 데이터 세트의 크기와 실행할 컴퓨팅 알고리즘의 복잡성에 따라 다양한 유형의 컴퓨팅 인스턴스를 활용할 수 있습니다. 현대 심층 신경 네트워크의 대규모 병렬 특성은 그래픽 처리 장치(GPU)의 진보에 의해 크게 도움이 되었습니다. NVIDIA는 공통적이고 심층적인 학습 운영자를 위한 하드웨어와 소프트웨어를 개발했습니다.
Amazon EC2 P3 인스턴스는 최대 8개의 NVIDIA® V100 Tensor Core GPU와 최대 100Gbps의 네트워크 처리량을 갖춘 고성능 컴퓨팅을 제공합니다. 최근에 추가된 P3dn.24xlar 인스턴스는 P3.16xlar 인스턴스의 네트워크 대역폭을 최대 4배까지 제공합니다. 최대 100Gbps의 네트워킹 처리량, 96개의 사용자 지정 Intel® Xeon® Scalable(Skylake) vCPU, 각각 32GB의 메모리를 갖춘 8개의 NVIDIA® V100 Tensor Core GPU, 1.8TB의 로컬 NVMe 기반 SSD 스토리지, P3dn.24xlarge 인스턴스 유형은 분산 시스템 학습 및 HPC 애플리케이션에 최적화되어 있습니다. P3 인스턴스 제품군은 인스턴스당 최대 1페타플롭의 혼합 정밀한 성능을 제공하여 성능을 크게 향상시킵니다. P3 제품군 인스턴스(instance)는 머신 러닝 시간을 며칠에서 몇 분으로 단축할 수 있으며 고성능 컴퓨팅을 위해 완료된 시뮬레이션 횟수를 3 x4배 늘릴 수 있습니다.
더 큰 Deep Neural Networks를 계속 테스트할 때 GPU 메모리에 대한 제한은 항상 경계를 제공합니다. 이 문제로 인해 소형 배치 크기가 작아지고 결국 전체 모델의 크기가 제한됩니다. 네트워크 크기 및 주기적 학습 속도를 줄이는 등의 기법이 도움이 될 수 있습니다. 예를 들어 구배 검문소 지정 및 부동 소수점 정밀도 수준 낮출 수 있습니다. Amazon CloudWatch는 GPU 메모리뿐 아니라 온도, 활용률 및 기타 메트릭을 모니터링할 수 있는 다양한 도구를 제공합니다. 또한 이러한 메트릭에 대한 알림을 구성하고 조직, 사용자 및 작업 수준에서 상세 모니터링을 실행할 수도 있습니다.
FPGA(Field Programmable Gate Array) 인스턴스 유형은 활용률이 높기 때문에 덜 일반적으로 사용되지만, 머신 러닝 애플리케이션의 결과 대비 시간에서 이점을 보여 주는 전문 하드웨어 가속 기능을 제공합니다. 또한 GPU 또는 높은 메모리 추론 연구가 필요하지 않은 덜 계산적으로 집약적인 컴퓨터 학습 애플리케이션을 위해 Amazon은 사용자의 요구에 맞는 메모리, 스토리지 및 네트워킹 옵션이 포함된 다양한 CPU 인스턴스를 제공합니다. 예를 들어, Amazon C5 인스턴스에 통합된 Intel® Xeon®Scalable 프로세서는 Intel MKL-DN 라이브러리에 최적화된 딥러닝 기능을 통해 일부 딥러닝 학습 워크로드에 충분한 컴퓨팅 용량을 제공할 수 있습니다.
Amazon EC2 인스턴스를 위한 EFA(Elastic Fabric Adaptor) 네트워크 인터페이스와 같은 네트워킹의 발전은 컴퓨팅 유체 역학, 날씨 모델링 및 대규모 시뮬레이션과 같은 강력한 노드 간 통신이 필요한 HPC 워크로드도 지원합니다.
빌드업웍스에서 AWS 무료 컨설팅을 진행합니다.
AWS에 대하여 궁금하신 내용이 있으시거나, 도입을 검토 중이시라면 편하게 신청해주세요.
[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Power Machine Learning at Scale (2019, 영문) 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
