AI 프로젝트가 인프라 팀에 주는 이점
데이터 세트를 더 빠르게 로드하고 복사하기를 원하시나요? 코드나 도커 이미지를 어디에 넣을지 고민할 필요가 없다면 더 좋지 않을까요? 쿠버네티스(Kubernetes) 서비스에 간편한 영구 스토리지(persistent storage)를 추가하는 것은 어떨까요?
데이터 과학자로서 AI 프로젝트에 사용되는 스토리지가 탁월하다면 이러한 문제를 고민하면서 시간을 낭비할 필요가 없다는 것을 알게 되었습니다.
뛰어난 스토리지는 다음과 같은 8가지 방식으로 데이터 과학 문제를 해결하는 데 도움을 줄 수 있습니다. 물론 이들 중 일부는 명확하게 드러나고, 일부는 그렇지 않습니다.
#1 모델 트레이닝은 데이터 세트를 반복해서 읽는 것을 의미합니다.
모델 트레이닝은 개발자와 스토리지 간의 가장 명확한 상호작용입니다. 트레이닝 작업에서 데이터 세트를 반복해서 읽으면 지속적으로 랜덤 읽기 워크로드가 발생합니다. GPU는 데이터를 빠르게 처리하므로 데이터 액세스 속도는 가능한 한 최대화하는 것이 좋습니다. 그리고 스토리지에 대한 비순차적(랜덤) 읽기 처리량은 최소화하는 것이 좋습니다.
#2 읽기 처리량은 다른 활동 중에도 부하를 가중시킵니다.
트레이닝을 시작하기 전에 데이터 세트를 반드시 검토해야 합니다. 데이터 형식과 콘텐츠 배포를 살펴보고 데이터 세트를 만져야 하는 경우가 많습니다. 예를 들어, 데이터에 클래스 불균형(class imbalance)이 심각한 경우를 생각해 보십시오. 클래스가 적절하게 감지되는지 확인하려면 일련의 실험이 필요할 수 있습니다. 이 경우 레이블 병합, 언더샘플링, 초점 손실(focal loss) 조정 등 다양한 검사를 해야 할 수 있습니다. 이러한 작업으로 인해 스토리지의 읽기 처리량 부하가 가중될 수도 있습니다.
데이터가 “정리”되었더라도 데이터 과학자는 반복적인 작업을 하는 과정에서 종종 트레이닝 데이터 세트를 조정하고 특정 데이터 포인트를 포함 또는 제외하기도 합니다. 따라서, 전체 데이터 세트를 대상으로 이와 같은 광범위한 읽기 작업을 계획할 필요가 있습니다. IT 예산이 방대한 데이터 송신 요금을 충분히 감당할 수 있는지 확인하는 것도 이러한 계획에 포함될 수 있습니다.
#3 AI 워크로드가 대용량 이미지 파일만 읽는 것은 아닙니다.
많은 데이터 세트에는 기본 트레이닝 데이터에 속하지 않는 레이블 또는 주석이 있습니다. 이들은 흔히 별도의 디렉토리나 버킷 안에 있습니다. 주석은 다양한 파일 형식으로 저장됩니다. 데이터 과학자는 원본 주석 파일과 해당 알고리즘 유형에 적합한 형식 간의 변환을 생성해야 할 수도 있습니다.
놀랍게도 일부 스토리지는 특정 파일 크기와 액세스 패턴에 맞게 튜닝되어 있습니다. 이는 대개 수백만 개의 작은 파일을 읽는 것보다 큰 파일을 읽는 것이 성능 기준에 더 잘 맞기 때문입니다. 하지만 AI 워크로드는 여러 가지 유형과 크기의 파일을 읽을 때 주로 랜덤 읽기 액세스에 의존하는 편입니다. 하나의 액세스 패턴에 대해서만 성능이 우수한 스토리지의 경우 AI 워크플로우 일부에서 병목 현상이 발생할 수 있습니다.
#4 더 많은 데이터 세트를 생성하게 될 수 있습니다.
학술 AI 프로젝트는 주로 GPU 작업에 중점을 두지만, 실제 구축 환경에서는 데이터 로드 작업(입력 파이프라인)도 고려할 필요가 있습니다. 실제 데이터는 학술 데이터보다 용량이 큰 경우가 많습니다. 예를 들어 설명해보겠습니다.
- ResNet-50의 입력 크기는 224×224픽셀입니다.
- 대부분의 파일은 크기가 500×500픽셀보다 작습니다.
- 디지털 병리 영상은 100,000×60,000픽셀이 될 수 있습니다.
즉석에서 이미지 크기를 조정하는 것은 비현실적인 방법입니다. 시간이 너무 오래 걸리고 GPU 서버의 CPU에서 더 많은 시간을 써야 하기 때문입니다. 많은 팀은 데이터 세트의 “조각화된” 버전을 영구적으로 저장하여 새로운 트레이닝 데이터 세트로 재사용하는 방식을 선택하기도 합니다.
데이터 과학자가 딥러닝에 쉽게 활용할 수 있는 데이터 세트를 구축하기 위해 풍부한 저장 공간을 확보할 수 있을 때, 결과 산출에 소요되는 시간을 기하급수적으로 단축할 수 있습니다.
#5 모델 체크포인트에 대한 쓰기 처리량이 대규모로 늘어날 수 있습니다.
스토리지에서 스토리지 트래픽 볼륨을 가장 많이 차지하는 작업은 읽기 작업입니다. 하지만 동시 프로젝트가 많은 경우 쓰기 작업도 스토리지에 과도한 부담을 줄 수 있습니다. 트레이닝 작업 중에 대부분의 스크립트는 모델 파일의 체크포인트를 다시 스토리지에 작성합니다. 여러 개발자가 동시에 모델 파일을 작성할 경우 스토리지에서 이를 감당할 수 있는지 확인해야 합니다.
#6 흔히, 실행이 시작될 때마다 모든 단일 데이터 세트 항목이 나열됩니다.
트레이닝 작업은 데이터 처리 순서를 무작위로 지정하여 모델에서 유연하고 안정적으로 모든 클래스를 예측할 수 있도록 지원합니다. 이 때 파일 순서를 무작위로 지정하기 전에 데이터 세트의 모든 항목을 나열해 섞어야 하는 모든 파일을 인식합니다.
많은 DL 데이터 세트가 수많은 하위 디렉토리를 포함하는 디렉토리로 구성되어 있습니다. 각 하위 디렉토리의 파일들은 섞이기 전에 먼저 나열되는 과정을 거칩니다. 이 과정은 흔히 os.walk의 일환으로 ls 명령을 통해 이루어집니다. 데이터 세트에 포함된 항목이 수백만 개에 이르는 경우 모든 파일을 나열하는 데 몇 분이 걸릴 수 있습니다.
이는 모든 트레이닝 작업이 시작될 때마다 발생하는 반복적인 작업으로 많은 시간이 소모됩니다. 이 문제는 스토리지를 통해 다음 두 가지 방법으로 해결할 수 있습니다.
- ls와 같은 명령어는 기본적으로 순차적으로 실행됩니다. 스토리지에서 ls의 병렬 버전을 지원하는 경우 파일 나열 성능을 최대 100배까지 향상시킬 수 있습니다. 따라서 각 작업을 시작할 필요한 시간을 크게 줄일 수 있습니다. 예를 들면 AI 워크로드에서 “parallel ls”를 실행하면 됩니다(영문자료).
- 특히 스태틱(static) 데이터 세트의 경우 개발자는 데이터 세트 콘텐츠 목록을 저장할 수도 있습니다. 이 단일 파일은 각 트레이닝 작업을 시작할 때 전체 파일 트리를 검토하는 과정 없이도 데이터 세트를 섞는 데 필요한 정보를 제공할 수 있습니다(즉, 임의 순서대로 읽음).
#7 데이터 과학자는 주피터 노트북(Jupyter Notebook)을 사용하는 가장 쉬운 경로를 따릅니다.
데이터 과학자는 팀 차원의 계획 없이 분산되고 비공식적인 환경에서 작업하는 경우가 많습니다. IT 팀이 데이터 과학자를 위한 중앙 집중식 개발 플랫폼을 제공했다면 개발 작업을 더 안전하게 유지 및 백업하고 데이터 세트 중복을 최소화하며 신규 사용자의 온보딩을 더 수월하게 할 수 있었을 것입니다.
이러한 모든 데이터 특성을 중앙 스토리지 서버에 통합하여 인프라 관리를 간소화하세요. 이러한 중앙 데이터 허브는 도커 이미지 및 모니터링/로깅 도구를 포함한 다른 플랫폼의 데이터도 고성능으로 지원합니다.
#8 운영 AI 파이프라인은 다양한 스토리지 요구 사항을 제시합니다.
모델을 운영할 준비를 마치면 이를 어딘가에 호스팅해야 합니다. 또한 모델을 새로운 데이터로 지속적으로 다시 트레이닝시키는 파이프라인을 설정하는 방안을 마련하고 모니터링도 실시해야 합니다. 들어오는 데이터가 저장될 곳을 마련해야 하며 추론 결과는 보존하고 공유해야 합니다. 전체 파이프라인을 지원하는 스토리지를 사용하면 데이터 복사 시간을 최소화하고 파이프라인 간 모니터링, 알림 및 보안을 활성화할 수 있습니다.
핵심 요약
딥러닝 모델을 구축하는 작업은 스토리지에서 다양한 I/O 패턴을 실행하는 과정입니다. 언뜻 보면 스토리지가 대용량 파일의 랜덤 액세스 읽기 처리량에 맞춰 최적화해야 하는 것처럼 생각되지만, 개발 프로세스를 전체적으로 볼 경우 이는 일부에만 해당하는 이야기입니다. 이러한 워크로드는 작은 파일, 메타데이터 및 쓰기에 대한 스토리지 성능에도 부담을 줍니다.
즐겨 사용하는 도구가 있다면 가능한 한 신뢰할 수 있는 고품질 버전을 이용하는 것이 좋습니다. 대규모 딥러닝을 계획하고 있다면, 다양한 AI 요구 사항을 모두 충족하는 다기능 고속 스토리지 솔루션을 사용하여 개발자와 IT 팀의 프로세스를 모두 간소화할 수 있는지 확인하시기 바랍니다.
