빅데이터분석

클라우드로 만드는 슈퍼컴퓨터

hongiiv 2014. 10. 16. 14:18
반응형
대규모의 계산이 필요하다. 단돈 418 달러 즉 40만원대로 클라우드를 이용하여 슈퍼컴퓨터를 사용할 수 있다. 물론 당신은 손하나 까딱하지 않아도 된다. 물론 클러스터 슈퍼컴퓨터를 손수 설정한다고하면 이는 더 싸질 수도 있지만, 당신은 아마도 실패할 확률이 더 높다. 본 글의 내용은 Cycle Computing의 "Lessons learned building a 4096-core Cloud HPC Supercomputer for $418/hr"이라는 글을 참고하여 작성하였다. 

4096 코어의 클러스터 컴퓨터

4096코어 8코어짜리 서버로 계산한다면 512대의 서버가 필요하다. 이를 클라우드를 통해 만들 수 있을까? 만들수 있다면 어떠한 것들이 고려되어야 할 것인가? 물론 이는 내가 직접 수행한 것은 아니고 위에 언급한 Cycle Computing이 삽질한 내용이다.

고려해야하는 것들

  • 4096개의 코어가 과연 아마존의 EC2내에서 단일 사용자에게 가능한가?
  • 클러스터 구성을 위한 소프트웨어를 유지할 수 있을 것인가?
  • 스케줄러는 충분히 그 역할을 할것인가?
  • 그렇다면 가격은 어떨까?

가용 가능한 서버는 존재하는가?

앞서 말했듯이 4096 코어는 아마존의 c1.xlarge (8코어) instance 512개가 필요하다. 이것들은 또한 같은 region안에 존재해야 클러스터링이 가능하다. 기본적으로  클라우드는 region이 존재하며 각 region 마다 가용 가능한 클라우드 컴퓨팅등 여러가지로 서로 다른 클라우드라고 봐도 된다. 따라서 아마존 전체가 아닌 해당 region내 512개의 instance를 만들 수 있어야 한다. 일반 사용자들은 자신의 계정에서 생성할 수 있는 instance의 갯수에 제한을 받으며, 물론 가용 가능한 갯수도 해당 region이 busy하다면 그것마저 사용이 불가능할 수도 있다. 그러면 이 문제는 어떻게 해결하는가? 한마디로 아마존과 긴밀한 협력관계를 유지하고 있는 곳이 아니라면 좀 복잡해진다. GenomeCloud의 경우도 클라우드 부서와의 긴밀한 협력하에서 이러한 문제들에 대해서 비교적 자유롭다. 첨언을 하자면 GenomeCloud는 평균 1000코어 이상을 사용하고 있다. 

Instance 생성 실패와 성공

Cycle의 경우에는 us-east region의 a, b, c, d 총 4개의 zone을 돌아가면서 instance를 생성한다. 그들은 자체적 fail-over 알고리즘으로 각 zone을 round-robin 형태로 돌아가면서 instance를 생성한다. 이때 10분 간격으로 64개의 instance를 동시에 순차적으로  모든 512개의 instacne에 대해 약 1시간 동안 생성한다.

결론적으로  0.75-1.00% instance failure rate로 모든 instance를 생성한다. fail을 종류별로 보면 instance가 시작되면서 바로 종료되는 에러 (aws-terminated), instance는 생성되었으나 원하는 instance가 아닌 경우로 이는 instance에 접속이 불가능하여 해당 instance를 에러로 처리하는 경우 발생한다. 마지막으로는 instance는 생성되었으나 기본 disk를 생성하는 시점에서 에러가 발생하는 경우(disk failure)이다. 이러한 에러들로 인해 100대중 1대꼴로 instance 생성에 실패한다. 그럼 KT의 클라우드의 failure rate는 어떨까? 그리고 어떠한 이유로 인해 fail이 발생할까? 비밀.

클러스터 구성 관리 소프트웨어

instance가 생성되었으면 이제 각 instance들을 하나의 컴퓨터처럼 묶어야 한다. 즉 클러스터링을 구성해야 한다. 이러한 작업은 이전 블로그 포스팅에도 언급되었던 Chef와 같은 것을 이용한다. Cycle도 마찬가지로 Chef를 이용하여 클러스터에서 소프트웨어를 설치하고 구성을 자동화한다. Chef는 매 10분마다 생성되는 64개의 instance를 효율적으로 처리한다. 뭐 이제는 노하우가 쌓여 한번에 256대를 동시에 Chef로 핸들링이 가능해졌다고 합니다. 

스케줄러는 버텨줄것인가?

이제 job을 처리해줄 스케줄러에 대한 부분이다. 이번에는 Torque를 이용해달라고 했다는데 Torque의 경우 예전의 PBS나 OpenPBS를 기반으로 하는 것으로 알고 있는데, 암튼 문제는 스케줄러를 튜닝해야 한다는 것이다. 물론 source를 고치거나 하는건 아니고 설정을 몇몇 바꾸어주어야 한다고 한다. pbs_sched를 위한 alarm 파라메터, job_stat_rate 등을 default 설정으로 하는 경우 4096 test job을 제출한 경우 대부분이 job이 running 되지 않고 scheduled되고 실행되지 않았다고 한다. 결론은 Torque보다는 Condor를 사용하라고 권장. 참고로 우린 SGE를 사용합니다.

가격

마지막으로 가격은 c1.xlarge instance 512개를 사용한 경우 아마존의 공식가격 + 자사의 서비스 비용을 합쳐 시간단 $417.79 원래 c1.xlarge 가격에 약 40%정도의 가격을 더 받네요.

이제까지 Cycle Computing이라는 회사가 약 4000개의 코어를 엮은 HPC 클러스터 컴퓨터를 아마존의 클라우드를 이용하여 구축할때 고려해야 할것들과 가능한지에 대한 내용을 봤다. KT 클라우드도 GenomeCloud의 서비스를 이용하여 이러한 HPC를 구축하는것이 가능하다. 물론 여기서는 제대로 다루지 않았지만 genome 데이터를 위한 스토리지를 구축하는 것 또한 고려되어야 하는데 이부분에서도 역시 GenomeCloud는 확실한 솔루션을 가지고 있다는 것 또한 알아두심 되겠음.
반응형