클라우드에서 대규모 기술 컴퓨팅을 위한 클러스터 사용

이 솔루션에서는 Google Cloud에서 대규모 기술 컴퓨팅을 수행하는 방법을 안내합니다. 기술 컴퓨팅 앱은 서로 클러스터로 연결된 대량의 개별 컴퓨팅 노드를 활용하면서 노드 간에 연산 조정 및 데이터 액세스를 수행해야 하는 경우가 많습니다.

클러스터 컴퓨팅의 기반을 이루는 개념과 기술은 지난 수십 년간 발전을 거듭하여 이제 성숙한 주류 솔루션으로 자리 잡았습니다. 소프트웨어 스택을 Google Cloud로 마이그레이션하는 작업은 다소 번거로울 수는 있지만, 오늘날의 고성능 컴퓨팅 환경에서 비용을 절감하고 기존의 병목 현상을 완화하는 데 여러모로 기여할 수 있습니다. 이 가이드에서는 Google Cloud에서 연산 클러스터를 실행하기 위한 기술, 과제, 현행 솔루션을 개략적으로 살펴봅니다.

클러스터 컴퓨팅은 여러 머신을 하나로 통합하고 조정하여 함께 작업을 수행하는 기술입니다. 클러스터는 일반적으로 1개의 헤드 노드(마스터 노드)와 여러 개의 컴퓨팅 노드로 구성되며 몇 개의 기타 특화 노드가 포함될 수 있습니다. 헤드 노드는 시스템의 중추로서 다음과 같은 역할을 수행합니다.

  • 시스템에 컴퓨팅 노드 등록
  • 노드 모니터링
  • 특정 노드에 작업 할당
클러스터는 1개의 헤드 노드와 몇 개의 컴퓨팅 노드로 구성됩니다.
그림 1. 클러스터는 1개의 헤드 노드와 일련의 컴퓨팅 노드로 구성됩니다. 사용자는 헤드 노드와 상호작용하고, 헤드 노드는 컴퓨팅 노드로 작업을 분배합니다.

사용자는 작업을 제출합니다. 이 작업은 기본적인 작업 단위인 태스크로 구성됩니다. 어떤 앱에서는 작업의 모든 태스크를 동시에 실행하고 태스크의 통신을 허용하여 병렬적 알고리즘을 구현해야 하고, 어떤 작업에는 복잡한 태스크 종속 항목으로 인해 특정 태스크를 다른 태스크보다 먼저 실행해야 하며, 어떤 태스크는 자신이 실행되는 메모리, CPU 등의 하드웨어와 관련하여 특정한 노드 구성을 요구합니다. 태스크는 스토리지에서 입력 데이터를 읽고, 데이터를 처리하여 결과를 산출하고, 최종 결과를 다시 스토리지에 기록하는 실행 파일입니다.

클러스터 컴퓨팅 워크로드에는 다음의 2가지 주요 유형이 있습니다.

  • 고성능 컴퓨팅(HPC) — 긴밀하게 연결된 수많은 워커 노드를 동시에 실행하여 태스크를 수행하는 컴퓨팅 유형입니다. 일반적으로 이러한 머신은 원활한 통신을 위해 낮은 네트워크 지연 시간을 요구합니다. 이 분야의 앱으로는 기후 모델링, 전산유체역학(CFD), 공학적 응력 모델링, 전자 장비 설계 등이 있습니다.

  • 대용량 컴퓨팅(HTC) — 앱에서 여러 태스크를 서로 독립적으로 처리하므로 개별 컴퓨팅 노드에서 통신할 필요가 없는 컴퓨팅 유형입니다. 이러한 워크로드를 절대적 병렬 또는 일괄 워크로드라고도 합니다. 일반적인 예로는 미디어 렌더링, 트랜스코딩, 유전체학, 입자물리현상 시뮬레이션 및 처리 등이 있습니다. 많은 수의 개별 파일을 처리해야 한다면 HTC 워크로드일 가능성이 높습니다.

클러스터 컴퓨팅 소프트웨어 스택

클러스터 컴퓨팅 소프트웨어 스택은 다음으로 구성됩니다.

  • 클러스터를 프로비저닝하고 빌드하는 시스템 관리 소프트웨어
  • 작업 실행을 조정하는 스케줄러
  • 최종 사용자 앱

다음 섹션에서는 시스템 관리 소프트웨어 및 스케줄러에 대해 설명합니다.

시스템 관리 소프트웨어

클러스터링 소프트웨어를 온프레미스 클러스터와 같이 베어 메탈 하드웨어에서 직접 실행할 수도 있고, 클라우드 환경과 같이 가상화된 환경에서 실행할 수도 있습니다. 클러스터의 여러 노드를 직접 조정하는 작업은 시간이 많이 소요되고 오류가 발생하기 쉽습니다. 전문적인 클러스터 관리 소프트웨어를 사용하면 반복 가능하고 확정적인 방식으로 여러 노드와 리소스를 함께 프로비저닝하고 구성할 수 있습니다.

취리히 대학의 오픈소스 ElastiCluster 소프트웨어는 클라우드에 기초한 방식으로 클러스터를 관리하고, Compute Engine을 사용한 노드 프로비저닝을 지원하며, 일련의 Ansible 플레이북을 사용하여 노드를 구성할 수 있습니다. ElastiCluster는 노드를 프로비저닝하고 파일 제공을 위한 NFS, 사용자 계정 관리를 위한 NIS, 사용자 앱 실행을 위한 작업 스케줄러 등의 기본 소프트웨어 스택을 설치합니다. ElastiCluster는 다양한 스케줄러를 지원하며 기본 설정으로 즉시 사용하거나 중소규모 팀의 요구사항에 따라 맞춤설정할 수 있습니다.

Chef, Puppet, Terraform 등의 다른 구성 관리 시스템을 사용하여 HPC 클러스터를 관리하는 경우 Google Cloud로 마이그레이션하면서 제공되는 도구와 플러그인을 사용하여 기존의 투자를 활용할 수 있습니다.

Google Cloud는 멀티 노드 소프트웨어 시스템을 프로비저닝하고 배포하는 기본 서비스를 제공합니다. Cloud Deployment Manager로 Compute Engine, Compute Engine 관리형 인스턴스 그룹, Cloud Storage와 같은 여러 클라우드 리소스를 프로비저닝할 수 있습니다. HTCondor 가이드에서는 Cloud Deployment Manager와 관리형 인스턴스 그룹을 사용하여 클러스터를 프로비저닝하고 구성하는 방법을 보여줍니다.

작업 스케줄러

클러스터가 작동한 후 태스크 실행 및 노드 할당을 관리하는 소프트웨어를 작업 스케줄러라고 하며, 워크로드 관리자 또는 큐 관리자라는 명칭도 사용됩니다. 클러스터 관리자에는 작업 스케줄러가 내장되어 있는 경우가 많습니다. 작업 스케줄러는 작업 및 태스크를 관리하는 데 도움이 되는 다음과 같은 다양한 기능을 제공합니다.

  • 사용자 및 그룹 간 작업 우선순위를 지원하여 정책을 기반으로 작업을 예약할 수 있습니다.
  • 태스크가 실패할 경우 태스크를 큐에 추가하고 다시 예약합니다.
  • 태스크 할당 시 태스크 종속 항목과 리소스 요구사항을 고려합니다.
  • 대기열의 작업 수에 따라 클러스터 크기를 조정합니다.

다양한 상용 및 오픈소스 워크로드 관리자가 널리 사용되고 있습니다. 위스콘신 대학의 HTCondor, SchedMD의 Slurm, Univa Grid Engine, IBM의 LSF Symphony를 예로 들 수 있습니다. 각 제품은 고유한 장점이 있습니다.

비공유 철학에 기초하여 설계된 HTCondor는 여러 공유 리소스 간에 사용할 수 있으며 선택적 작업 예약을 통해 리소스의 유휴 상태를 방지합니다. 데이터 이동을 자체적으로 제공하므로 공유 파일 시스템이 필요하지 않습니다. 따라서 HTCondor는 수십만 개의 코어로 확장되며 여러 리전 및 영역 간에 사용할 수 있습니다. HTCondor는 온프레미스 시스템과 클라우드 기반 시스템 간에 작업이 공유 또는 분할되는 하이브리드 워크로드에 사용되고 있습니다. 그러나 이름에서 알 수 있듯이, 긴밀하게 연결된 병렬 작업보다는 대용량 작업에 중점을 둡니다.

Slurm 및 Univa Grid Engine은 보다 전형적인 HPC 클러스터 환경을 제공하며 대용량 앱과 고성능 병렬 앱을 모두 지원합니다. 두 제품 모두 노드 간에 공유 파일 시스템이 있다고 가정하므로 데이터를 이동할 필요가 없으며, 온프레미스에서 사용하는 것과 거의 같은 도구를 통해 편리하고 친숙한 앱 개발 사용자 환경을 제공합니다. 중소규모 클러스터에서는 이러한 전형적인 작업 스케줄러로도 문제가 없지만, 클러스터가 커지면 파일 서버의 부하가 성능 병목 현상을 유발합니다. 병렬 및 분산 파일 시스템은(다음 섹션 참조) 대규모 환경에서 문제 해결에 도움이 될 수 있습니다. 지연 시간이 짧은 파일 액세스가 필요하지는 않지만 POSIX 호환성이 요구된다면 API 또는 gcsfuse를 통해 병렬 객체 액세스를 제공하는 Cloud Storage를 활용하는 방법도 있습니다.

마지막으로, Google Cloud는 대용량 워크로드를 위해 Compute Engine에 Docker 기반 태스크를 예약하는 Cloud Life Sciences Pipelines API라는 간편한 서비스를 포함합니다. 이 서비스에서는 사용자가 작업을 태스크로 분할하고, 태스크 간 종속 항목을 관리하고, 태스크 수명 주기를 관리해야 합니다. dsub 오픈소스 프로젝트는 Cloud Life Sciences Pipelines API를 지원하며 일괄 작업을 실행할 수 있는 명령줄 도구를 제공합니다.

스토리지

대부분의 HPC 애플리케이션에는 POSIX API를 지원하는 파일 스토리지 솔루션이 필요합니다. 작은 클러스터의 경우 FileStore가 Google에서 관리하는 NFS 기반 파일 스토리지 서비스를 제공합니다. 그러나 큰 클러스터의 경우 애플리케이션 I/O에서 성능 병목 현상이 발생할 수 있습니다. Elastifile(구글에 인수됨), Lustre, Quobyte와 같은 수평 확장 및 병렬 파일 시스템은 큰 클러스터 또는 I/O가 많은 작은 클러스터로의 확장을 지원합니다.

지연 시간이 짧은 파일 액세스가 필요하지는 않지만 POSIX 호환성이 요구된다면, API 또는 gcsfuse를 통해 병렬 객체 액세스를 제공하는 Cloud Storage를 활용하는 방법도 있습니다.

클라우드의 클러스터 컴퓨팅 기회

클라우드에서 컴퓨팅 클러스터를 실행하는 이유는 다양합니다.

  • 솔루션 구현 시간. 사용 가능한 코어가 수백 개인 소규모 10노드 클러스터부터 코어가 수십만 개 이상인 대규모 클러스터까지, 프로덕션 품질의 클러스터를 클라우드에 배포하는 데 몇 분밖에 걸리지 않습니다. 반면, 온프레미스로 새 클러스터를 빌드하려면 운영 준비 완료까지 몇 개월이 걸릴 수 있습니다. 온프레미스 클러스터가 준비되었더라도, 이러한 클러스터는 일반적으로 사용률이 높고 작업 실행 예약까지 대기 시간이 몇 시간에서 며칠에 이를 정도로 긴 것이 보통입니다. 클라우드에 직접 클러스터를 구축하면 클러스터를 필요할 때만 간편하게 사용하고 분석이 끝나면 종료할 수 있습니다.

  • 총 소유 비용 감소. Google Cloud는 솔루션 구현 시간을 단축할 뿐 아니라 선점형 VM, 장기 사용 할인, 동적 확장을 통해 실행당 총 비용을 절감할 수 있습니다. 작업 큐가 생기면 노드를 추가하고 필요가 없어지면 노드를 삭제할 수 있습니다.

  • 공동작업 지원. 컴퓨팅 분석은 여러 조직에 속하는 다양한 사용자와의 공동작업으로 개발되는 경우가 많습니다. Google Cloud가 제공하는 프로젝트 수준 ID 및 액세스 관리 도구를 사용하면 데이터 및 분석 도구에 대한 액세스를 제어할 수 있습니다. 승인된 여러 사용자가 동일한 앱, 데이터, 클러스터에 액세스하여 같은 정보를 공유할 수 있으므로 데이터를 복사하거나, 버전을 관리하거나, 클러스터 구성을 동기화할 필요가 없습니다.

  • 태스크별 맞춤 리소스. 클라우드에서 클러스터를 실행하면 작업의 비용이 인스턴스 수가 아닌 총 코어 시간에만 좌우되므로 각 팀이나 그룹에서 자체 전용 클러스터를 운영할 수 있습니다. 이 접근 방식은 여러 그룹의 사용과 관련된 정책 개발에 따른 번거로움을 상당히 완화해 줍니다. 그런 다음 각 전용 클라우드 클러스터를 맞춤설정하여 대상 앱에 맞게 조정할 수 있습니다. 온프레미스 클러스터는 다양한 그룹과 앱에서 공유하는 획일적인 리소스로 구성되는 경향이 있습니다. 이러한 환경에서는 그룹 간 공유 정책을 설정하고 관리하기가 복잡해지기 쉽습니다.

  • 통합. 연구자들은 대규모 컴퓨팅 작업을 실행하기 전에 데이터세트를 준비하는 데 막대한 노력을 기울입니다. 클라우드로 이전하면 연구자들은 클라우드에 제공되는 빅데이터 도구를 활용할 수 있습니다. 컴퓨팅 시스템의 출력도 분석해야 합니다. BigQuery, Datalab 등의 도구를 사용할 경우 온프레미스 시스템에서 제공되는 도구보다 상당한 이점을 기대할 수 있습니다.

일반적인 온프레미스 클러스터는 여러 사용자와 그룹 간에 공유되며 다양한 앱 요구사항을 지원합니다.
그림 2.일반적인 온프레미스 클러스터는 여러 사용자와 그룹 간에 공유되며 다양한 앱 요구사항을 지원합니다. 반면 Google Cloud로 이전하면 사용자가 앱의 요구사항에 따라 클러스터 속성을 맞춤설정하여 비용을 줄이고 성능을 높일 수 있습니다.

아키텍처 고려사항

지금까지 설명한 장점은 분명히 매력적이지만, 플랫폼 이전 프로젝트에 어려움을 주는 몇 가지 기술적인 과제가 있습니다.

  • 데이터 이동. 클러스터의 컴퓨팅 노드가 처리하는 데이터세트는 일반적으로 작업 실행 전에 클라우드에 준비되어야 합니다. 데이터의 양과 관리 방식에 따라서는 데이터 이동을 관리하기가 복잡할 수 있습니다. 필요 시 자동으로 데이터를 이동하는 클라우드 캐싱 레이어를 제공하는 Avere 등의 도구가 도움이 될 수 있지만, 앱의 데이터세트를 수동으로 준비해야 하는 경우도 많습니다.

  • 데이터 액세스. HPC 앱은 일련의 파일 및 디렉토리에 대한 공유 액세스를 요구하는 경우가 많습니다. 이러한 액세스를 제공하는 방법은 앱 성능에 상당한 영향을 줄 수 있습니다. 스토리지 섹션에 설명된 대로 Cloud Storage, FileStore와 같은 NFS 서버에 저장된 공유 데이터를 활용하거나 병렬 파일 시스템을 사용할 수 있습니다.

  • 보안. 민감한 데이터를 다루는 경우 항상 승인된 액세스만 허용해야 하며 저장 데이터와 전송 중인 데이터를 적절히 암호화해야 합니다. Cloud Storage는 저장 데이터와 전송 중인 데이터를 암호화하지만, 추가 제어 레이어를 적용하고 Cloud Key Management Service를 사용하거나 방법을 직접 강구하여 키를 관리할 수 있습니다. 작업 실행 전에 키를 검색하거나 컴퓨팅 노드에 설치해야 합니다.

  • 노드 간 지연 시간. 긴밀하게 연결된 HPC 앱에서는 클러스터의 노드 간 지연 시간이 성능에 민감한 영향을 줄 수 있습니다. Google Cloud가 제공하는 노드의 최대 크기는 64코어이므로 여러 노드를 거치지 않고 64중 병렬 작업을 수행할 수 있습니다. 대부분의 경우 작업에 필요한 코어 수가 1,000개 정도이거나 그 미만이라면 특화되지 않은 네트워크 하드웨어에서도 비교적 원활한 성능을 보입니다.

  • 소프트웨어 라이선스 관리. 상용 앱에는 키 서버라고도 하는 라이선스 서버가 필요한 경우가 많습니다. 라이선스 서버가 내장되어 있거나 특정 서버를 권장하는 앱도 있고, 기존 라이선스 서버 제품과 호환되는 앱도 있습니다. 일부 작업 스케줄러는 라이선스 관리에 도움을 주며, 라이선스가 제공될 때까지 작업 실행을 중지합니다.

기술 컴퓨팅과 관련하여 상황별로 수많은 도구와 접근 방식이 제시됩니다. 옵션이 너무 많아서 무엇부터 시작해야 할지 막막할 수도 있습니다. 어떠한 클러스터 관리 소프트웨어 및 스케줄러를 선택하든 Google Cloud에서 실행할 때는 다음과 같은 권장사항을 참고하시기 바랍니다.

  • 가능한 경우 선점형 VM 활용. 선점형 VM은 Compute Engine의 일반 VM과 기능상 동일하지만 가격이 최대 80% 저렴하며, 예고 없이 회수될 수 있다는 제한사항이 있습니다. 대용량 워크로드의 경우 작업 스케줄러는 노드 손실을 감지하여 노드 장애로 간주하고 해당 노드에서 실행 중인 모든 태스크를 다른 리소스에 다시 예약합니다. 손실 노드에서 수행된 작업은 사라지지만, 노드 손실이 발생할 확률은 상당히 낮으므로 저렴한 가격이 충분히 합리화됩니다. 예상 손실률은 5~15%입니다. 선점형 VM은 사용 시간이 최대 24시간으로 제한되며 그 이후에는 회수됩니다.
  • 병렬 파일 시스템을 자체적으로 운영하는 대신 Cloud Storage의 비용과 대역폭 활용. Cloud Storage는 저렴한 총 비용으로 강력한 일관성과 확장 가능한 병렬 성능을 제공합니다. 첫 바이트 지연 시간은 약 100ms로서 긴 편이지만, Compute Engine에 병렬 파일 서버를 실행하는 대신 앱에서 Cloud Storage를 활용할 수 있다면 비용 효율성이 개선됩니다. Cloud Storage와 컴퓨팅 노드 간에 사용 가능한 대역폭은 대부분의 앱에 충분하며, 일부 고객은 23GB/s 이상의 집계 대역폭이 지속됨을 보고했습니다.
  • 단일 앱 또는 단일 그룹 클러스터 구축. 전형적인 클러스터는 여러 사용자, 그룹, 앱 간에 공유되므로 작업의 대기 시간이 길어지고 앱이 리소스를 비효율적으로 사용할 수 있습니다. Google Cloud를 사용한다면 그룹 또는 프로젝트별로 여러 클러스터를 만들고, 클러스터에서 실행되는 특정 앱에 따라 클러스터를 최적화하여 사용하시기 바랍니다. 클러스터 1개를 2시간 동안 실행하든 클러스터 2개를 각각 1시간 동안 실행하든 총 비용은 동일하지만, 후자의 경우 큐 대기 시간이 감소하고 앱 성능이 개선됩니다.

모든 구현에는 각자 고유한 특징이 있지만, 다음 섹션에서는 보편적인 3가지 사례에 대한 일반적인 권장사항을 제시합니다.

데이터 처리를 원하는 독립 연구자

일반적으로 개별 연구자는 데이터를 종합하여 앱을 실행하면서 최대한 빠르게 작업을 완료하고 싶어 합니다. 이들은 해당 앱의 전문가이지만 클러스터 관리의 전문가까지 되고 싶어하지는 않습니다.

대용량 워크로드를 실행하는 경우 Cloud Life Sciences Pipelines API를 사용해 볼 수 있습니다. Pipelines API를 사용하려면 앱을 Docker 컨테이너에 넣고 입력 파일을 Cloud Storage 버킷에 저장해야 합니다. 그런 다음 gcloud 명령줄 도구를 사용하여 Cloud Storage 버킷의 각 파일에 대해 앱을 실행할 수 있습니다. 그 결과는 다른 Cloud Storage 버킷에 저장할 수 있습니다.

다음은 SAMtools를 사용하여 입력 BAM 파일로부터 BAM 색인 파일을 생성하는 명령어의 예입니다.

gcloud alpha genomics pipelines run --pipeline_id [PIPELINE_ID] \
--logging gs://[YOUR_BUCKET/YOUR_DIRECTORY]/logs \
--inputs inputFile=gs://genomics-public-data/gatk-examples/example1/NA12878_chr22.bam \
--outputs outputFile=gs://[YOUR_BUCKET]/[YOUR_DIRECTORY]/output/NA12878_chr22.bam.bai

각 항목의 의미는 다음과 같습니다.

  • [PIPELINE_ID]: Pipelines API에서 앱의 ID입니다.
  • [YOUR_BUCKET]: Cloud Storage 버킷 이름입니다.
  • [YOUR_DIRECTORY]: 디렉터리 이름입니다.

클러스터를 프로비저닝하거나 관리할 필요가 없습니다. Pipelines API이 프로비저닝하고 관리하는 VM에서 태스크가 완료될 때까지 실행됩니다. Compute Engine은 초당 사용료를 청구하므로 이 방법은 비용 효율적입니다.

단일 프로젝트 또는 팀을 위한 중소규모 클러스터

프로젝트 또는 팀에 속한 구성원은 중앙 팀에서 회사 전체의 사용자를 위해 운영하는 클러스터에 액세스할 수도 있고, 외부의 HPC 센터에 있는 대규모 리소스에 액세스할 수도 있습니다. 두 경우 모두 클러스터는 전문적으로 관리되며 표준 도구를 사용하여 액세스됩니다. 예를 들어 사용자는 헤드 노드에 ssh를 통해 연결되고 Grid Engine submit 스크립트를 사용하여 실행할 작업을 제출할 수 있습니다.

이러한 팀에서 활용할 수 있는 방식 중 하나는 ElastiCluster를 사용하여 온프레미스 시스템과 유사한 클러스터 환경을 정의하는 것입니다. 앱에 가장 적합한 Compute Engine 머신 유형을 선택하여 클러스터를 맞춤설정하고, 앱의 소프트웨어 종속 항목을 설치하도록 시작 스크립트를 수정할 수 있습니다. 입력 데이터는 여전히 Cloud Storage에 스테이징할 수 있으며 컴퓨팅 노드에 gcsfuse를 설치하여 입력 데이터를 마운트할 수 있습니다.

이러한 세부정보는 ElastiCluster 구성 파일에 기록되고, 연산이 필요한 시점에 명령줄 도구를 통해 클러스터가 가동됩니다. 예를 들면 다음과 같습니다.

% elasticluster start astrocluster1

구성 파일에서 astrocluster1라는 클러스터가 지정된 대로 프로비저닝 및 구성됩니다. 구성 파일의 정의는 가변적이며 헤드 노드 및 컴퓨팅 노드의 다양한 노드 유형, 스크래치 공간을 위한 Compute Engine 영구 디스크, 대용량 워크로드의 비용을 낮추기 위한 선점형 VM, 작업 가속을 위한 GPU를 지원합니다. 다음은 컴퓨팅 노드 10개와 헤드 노드 1개를 포함하며 CentOS를 기반으로 하는 32코어 가상 머신을 사용하는 Slurm 기반 클러스터에 대한 기본적인 구성 파일의 예입니다.

[cluster/astrocluster1]
 cloud=google
 login=google
 setup=ansible-slurm
 security_group=default
 image_id=centos-7-v20170327
 flavor=n1-standard-32
 frontend_nodes=1
 compute_nodes=10
 ssh_to=frontend
 boot_disk_size=50
 

마지막으로, 시스템에서 실행 중인 작업이 더 이상 없으면 클러스터를 종료할 수 있습니다.

% elasticluster stop astrocluster1

이보다 큰 워크로드에서는 다음을 수행할 수 있습니다.

  • 클러스터 머신 유형을 맞춤화하여 비용을 더욱 절감합니다.
  • 외부 병렬 파일러를 추가하여 대규모 처리 성능을 높입니다.
  • 자동 확장 기능을 추가하여 큐 길이에 따라 노드를 더하거나 줄입니다.

기존 클러스터에 급증 대비 용량을 추가하는 HPC 센터

중앙 HPC 센터는 막대한 컴퓨팅 용량을 보유하지만 회사 또는 조직 전체의 수많은 그룹에서 사용하므로 HPC 센터는 지속적으로 높은 사용률과 긴 대기 시간을 보이는 경향이 있습니다. 이러한 시설은 특정한 프로덕션 용량을 고려하여 구매가 이루어지기 때문에 예기치 않은 워크로드가 더해지면 처리 속도가 눈에 띄게 저하될 수 있습니다.

이러한 상황에서는 클러스터에 임시로 컴퓨팅 노드를 추가하여 Google Cloud 환경으로 급증을 분산할 수 있습니다. 클러스터는 헤드 노드와 일부 컴퓨팅 노드는 온프레미스에서 실행되고 다른 컴퓨팅 노드는 Google Cloud에서 실행되는 하이브리드 상태가 됩니다. 작업 큐가 소진되면 추가 노드를 해제할 수 있습니다.

클라우드로 급증을 분산하면 다음과 같은 편리함이 있습니다.

  • 작업 제출 및 관리에서 일관적인 사용자 환경이 유지됩니다. 사용자는 노드가 더 추가된 것을 알 수 없으며 알 필요도 없습니다.
  • IT 관리자가 급증 분산 시점에 대한 정책을 정의하여 비용을 통제할 수 있습니다.

가장 어려운 점은 온프레미스 노드와 Google Cloud 노드의 사용자 작업에 일관적인 데이터 및 파일 네임스페이스를 제공하는 것입니다. Google Cloud 노드는 온프레미스 노드와 동일한 내부 파일 시스템에 액세스하지 못할 수도 있습니다. 이러한 경우 해당 파일을 참조하는 작업이 실행에 실패합니다.

Google Cloud 노드를 구성하여 내부 파일 액세스 권한을 부여하면 작업이 실행되기는 하지만 완전히 같은 방식으로 작동하지는 않을 수도 있고 네트워크 대역폭 및 이그레스 비용이 추가로 발생할 수 있습니다. 또한 병렬 작업이 온프레미스 노드와 클라우드 노드에 분산된 경우 앱의 서로 다른 부분 사이에 지연 시간이 추가되어 성능이 다소 저하될 수도 있습니다.

대용량 작업에서는 HTCondor를 사용하여 클라우드 리소스로 급증을 분산하면 이러한 과제를 상당 부분 해결할 수 있습니다. HTCondor는 GlideInWMS를 사용한 동적 프로비저닝을 지원합니다. 작업 큐에 작업이 제출됨과 동시에 노드를 프로비저닝하여 클러스터에 추가할 수 있습니다. 노드가 추가되면 condor 스케줄러가 지정된 노드에 입력 파일을 전송하고 해당 추가 노드를 사용하여 태스크를 실행한 후 큐를 배출합니다.

다음 단계

Google Cloud의 클러스터 컴퓨팅 사용 사례 자세히 알아보기:

자세히 알아보기:

클러스터 시작하기:

GitHub의 프로젝트 예: