Western Digital HDD 시뮬레이션 사례 소개 – 4만개 스팟 인스턴스로 2500만 건의 고성능 컴퓨팅(HPC) 작업 활용

Western Digital에서 어떻게 AWS에 클라우드 규모의 HPC 클러스터를 구축하여 차세대 하드 디스크 드라이브(HDD) 헤드 설계의 핵심 요소를 시뮬레이션하는 데 사용했는지에 대해 HPC Wire에 기고한 바 있습니다.

본 사례에 언급된 시뮬레이션 작업은 백만 개의 vCPU를 가진 Amazon EC2 클러스터에서 2500만 건을 단 8시간 만에 완료하였습니다. Western Digital의 시뮬레이션 작업 중 상당 부분은 HDD를 구성하는 다양한 기술 및 솔루션의 조합을 평가해야 하는 필요성에 의해 진행됩니다.

웨스턴 디지털의 엔지니어 팀은 같은 저장 공간에 더 많은 데이터를 저장하여 스토리지 용량을 개선하고 이에 따라 전송 속도도 향상하는 데 초점을 맞추고 있습니다. 소재, 에너지 레벨 및 회전 속도를 조합한 수 백만 가지의 경우를 시뮬레이션하는 방식으로 팀은 최고의 밀도와 최고 속도의 읽기-쓰기 시간을 찾아냅니다. 이러한 작업에서 보다 빠르게 결과를 얻어낸다는 것은 더 나은 결과를 도출하고 신제품을 더욱 신속하게 시장에 출시할 수 있음을 의미합니다.

아래는 Western Digital의 에너지 보조 레코딩이 진행되는 과정을 보여줍니다. 상단의 줄은 자기화를 나타내고 가운데 줄은 추가된 에너지(열)을 나타냅니다. 그리고 하단의 줄은 자기화와 열의 조합을 통해 매체에 기록된 실제 데이터를 나타냅니다.

저는 최근에 AWS와 이러한 힘든 작업을 현실로 만들기 위해 협력했던 Western Digital 및 Univa의 팀과 대화의 시간을 가졌습니다. 제 목표는 이 작업을 어떻게 준비했으며 어떤 학습 효과가 있었는지에 대해 자세히 알아보고 대규모 작업을 수행할 준비가 된 다른 고객들과 이러한 내용을 공유하는 것이었습니다.

준비 하기
약 2년 전, Western Digital 팀은 비용 효과적인 운영을 위해 EC2 스팟 인스턴스를 통해 vCPU 8만 개에 이르는 클러스터를 실행하고 있었습니다.

Western Digital은 vCPU 8000개, 16000개, 32000개를 반복해서 성공적으로 실행하면서 8만개 수준에까지 도달했습니다. 이러한 초기 성공을 바탕으로 그들은 경계를 허물고 목표를 대폭 높게 수정하여 1백만 개의 vCPU 실행을 추진했습니다. 이러한 작업은 기존 도구에 부담을 줄 것으로 예상되었으므로 검색/수정/점진적 확대라는 방법론이 채택되었습니다.

Univa의 Grid Engine은 배치 스케줄러로서, 사용 가능한 컴퓨팅 리소스(EC2 인스턴스)를 추적하고 가장 빠르고 효율적인 방식으로 인스턴스에 작업을 할당하는 일을 책임집니다. 목표는 최소한의 시간과 가장 낮은 비용으로 작업을 수행하는 것입니다. Univa의 Navops Launch는 컨테이너 기반의 컴퓨팅을 지원할 뿐 아니라 이 작업에서 Grid Engine과 AWS Batch에 동일한 컨테이너를 사용할 수 있게 하는 중요한 역할을 수행했습니다.

규모 조정 작업의 흥미로운 문제 중 하나는 5만 개의 호스트가 Grid Engine 스케줄러에 대한 동시 연결을 생성하면서 발생했습니다. 일단 시작된 스케줄러는 초당 최대 3000개의 작업을 할당할 수 있으며, 드물지만 인스턴스가 예상치 않게 종료되는 경우에는 추가적인 버스트가 가능하고, 64개 이상의 작업을 최대한 빠르게 재예약하는 신호를 전송합니다. 그 뿐 아니라 팀은 IP 주소를 기반으로 작업자 인스턴스를 참조함으로써 탄력적 네트워크 인터페이스당 DNS 조회 수에 대한 일부 내부 (AWS) 제한을 우회할 수 있다는 사실을 발견했습니다.

전체 시뮬레이션은 사용의 편의를 위해 Docker 컨테이너에 패키징됩니다. 새롭게 시작된 인스턴스가 온라인 상태가 되면 해당 사양(인스턴스 유형, IP 주소, vCPU 개수, 메모리 등)이 ElastiCache for Redis 클러스터에 등록됩니다. Grid Engine은 이 데이터를 사용하여 인스턴스를 찾고 관리합니다. 이 방식은 연속적으로 DescribeInstances를 호출하는 것에 비해 더욱 효율적이고 확장 가능합니다.

시뮬레이션 작업은 방대한 데이터를 저장하고 어떤 요청 속도도 처리할 수 있는 Amazon Simple Storage Service(S3)의 기능을 활용하여 S3로부터 데이터를 읽고 씁니다.

시뮬레이션 작업 방식
각각의 헤드 디자인 후보는 일련의 매개 변수에 의해 설명되며 전체 시뮬레이션 실행은 이 매개 변수 공간의 분석으로 구성됩니다. 작업 실행의 결과는 설계자가 구축 가능하고 신뢰적이며 제조 가능한 설계를 찾는 데 도움이 됩니다. 이 특정 실행 작업은 쓰기 작업을 모델링하는 데 초점을 맞추고 있습니다.

각 시뮬레이션 작업은 EC2 인스턴스 유형에 따라 2~3시간 동안 실행됩니다. 스팟 인스턴스가 종료되려고 할 때 작업이 유실되지 않게 하기 위해 작업은 스스로 15분마다 S3에 체크포인트를 수행하며 추가적인 로직을 통해 작업이 종료 신호와 실제 종료 사이에 종료되는 중요 사례를 포함합니다.

작업 실행하기
단 6주에 걸친 계획 및 준비 작업(입력 파일 생성을 위한 다중 대규모 AWS Batch 실행 포함)을 거쳐 Western Digital /Univa/AWS 연합 팀은 풀스케일 실행을 수행할 준비가 되었습니다. 이들은 AWS CloudFormation 템플릿을 사용하여 Grid Engine과 클러스터를 시작했습니다. 앞에서 설명드린 Redis 기반 추적으로 인해 팀은 인스턴스가 사용 가능 상태가 되는 즉시 작업 할당을 시작할 수 있었습니다. 클러스터는 1시간 32분 만에 1백만 vCPU로 성장하여 전체 규모로 6시간 동안 실행되었습니다.

더 이상 미할당 작업이 없게 되자 Grid Engine은 인스턴스의 종료를 개시하여 약 1시간 만에 제로 인스턴스 상태에 도달했습니다. 작업을 실행하는 동안 Grid Engine은 전체 기간의 99% 동안 인스턴스에 작업이 완전히 공급된 상태를 유지할 수 있었습니다. 이 실행은 C3, C4, M4, R3, R4, M5 인스턴스의 조합을 사용했습니다. 다음은 전체 실행 기간에 전반적인 분석을 보여줍니다.

작업은 미국 동부(버지니아 북부) 리전의 6개 가용 영역 모두를 사용했습니다. 스팟 경매는 온디맨드 요금으로 입찰되었습니다. 실행 기간 전체에 걸쳐 플릿의 인스턴스 중 1.5%가 종료되고 자동으로 교체되었으며 인스턴스 대부분은 전체 기간 내내 실행 상태를 유지했습니다.

결론
이 작업은 8시간 동안 실행되었으며 137,307 USD의 비용이 발생했습니다(시간 당 17,164 USD). 제가 만나본 사람들은 이 비용이 내부 클러스터에서 시행하는 비용의 약 절반이라고 추정했습니다. 물론 이 정도 규모의 내부 클러스터가 있는 경우에 한해서입니다!

Western Digital의 CIO인 Steve Phillpott 씨는 실행 성공에 대한 평가를 내리면서 다음과 같이 말했습니다.

“스토리지 기술은 놀라울 정도로 복잡하며 당사는 차세대 용량 및 기술 혁신의 제공을 목표로 물리적 한계과 엔지니어링 한계를 극복하기 위해 지속적으로 노력하고 있습니다. AWS와의 이 성공적인 협업은 클라우드 기반 HPC가 제공하는 극한 규모, 파워 및 민첩성이 미래의 스토리지 아키텍처 분석 및 재료 과학 탐구를 위해 복잡한 시뮬레이션의 실행을 어떻게 지원하는지 보여줍니다. Western Digital R&D 팀은 AWS를 통해 시뮬레이션 시간을 20일에서 8시간으로 쉽게 단축하는 역량을 사용함으로써, 이전에는 상상도 할 수 없었던 속도로 새로운 설계와 혁신을 탐구할 수 있습니다.”

이 작업을 지원했던 Western Digital 팀에서는 R&D 엔지니어링 기술자를 찾고 있습니다. 이 외에도 다양한 채용 기회가 있으니 참고하시기 바랍니다! 10만 ~ 1백만 개 이상의 코어에서 작업을 실행하려는 경우 AWS의 HPC 팀과 Univa의 담당자가 도움을 드릴 수 있습니다. 시작하려면 HPC 영업 팀에 문의하세요!

— Jeff;