티스토리 뷰

제목은 "과학계산"이라고 했으나 여기서는 "유전체 관련"이라고 한정지어 이야기를 하겠다. 왜냐고 그건 내 마음이니까. 요즘 국내에서도 많은 사람들이 자신의 연구에 클라우드를 사용하기 시작했다. 클라우드를 사용하기를 원하는 사람들 중 다음의 상황이 가장 많다.

빠른 시간내에 분석 결과를 내고 싶다.
대부분의 사람들은 샘플을 수집하고 이를 시퀀서와 같은 장비를 통해 데이터를 생산해 낸다. 즉, 분석할 데이터셋트가 만들어진다. 여기서 문제가 발생한다. 각종 연구에 있어서 논문으로의 출판까지 비교적 여유롭지 못하다는 것이다. 여기에는 많은 이유가 있을 수 있다. 가령 주어진 과제비에 대한 산출물(즉, 논문)을 내야하는 시기가 정해져 있다는 것이다.  어쩔 수 없는 이유들로 인해 데이터 생산까지의 시간을 일정내에 처리하지 못한 경우 이제 마지막 남은 카드는 분석을 최대한 빨리 진행하는 것이다.

"자. 내 데이터가 100만큼 있소, 1주일내에 가능하겠소." 물론 나의 대답은 "yes"이다. 물론 "yes"라는 대답은 단순히 클라우드 자원이 있어서가 아니다.  단순히 클라우드 자원은 AWS나 MS의 애저, 그리고 HP의 클라우드 등 많은 public cloud들이 존재하며 이를 사용하면 된다?? 문제는 이러한 클라우드는 단순히 IaaS(즉, 하드웨어만 제공)라는 것이다. 클라우드를 이용한 계산(분석)을 위해서는 고려할 것들이 많이 있다.

클라우드 자원 생성하기 (레고 블럭 준비하기)
우선 클라우드내 각각의 자원을 생성해야 한다. 아래 그림처럼 서버(어떠한 OS를 사용할 것이며, CPU와 Memory 사양, 서버의 이름 등등), 디스크(용량은 얼마짜리), 네트워크 및 요금은 시간제/월정액 등의 사항들을 일일히 선택하고 자원을 준비해야 한다.


100대를 저기에 들어가서 클릭하다가 보면 손목이 아파서 죽을 수도 있다. 바로 이러한 것들을 프로그래밍으로 손쉽게 할 수 있도록 API 형태로 제공하는데, GenomeCloud는 이 API를 이용하여 해당 자원을 생성하게 된다.

설정 자동화 (레고 블럭 쌓기)
두번째로는 위에서 각각 생성된 자원들을  결합해야 비로소 연구에 클라우드 컴퓨팅을 사용 가능하다. 만약 100대의 서버를 사용한다면 100대의 사양을 선택하고 일일히 startup시킨후 서버에 disk를 장착하고 접속할 수 있는 ip를 제공하고 방화벽이나 포트포워딩 룰등을 적용해야 한다. 이런 설정하다보면 하루는 족히 걸리게 된다. 어디 그뿐인가?  분석에 필요한 기반 시스템소프트웨어(가령 스케줄러) 소프트웨어(가령 BWA) 및 reference data(가령 human ref.)를 각 서버에 설정해야 한다. 

이러한 것들을 서버 자동화 툴(Server Configuration Management)들이 존재하고 이는 클라우드라는 새로운 환경에 맞추어 설정 되어야 한다. 이러한 툴중에 chef라는 것이 있는데 이를 이용하면 클라우드내 수많은 자원들을 설치, 배포, 관리가 가능하다. 또한 클라우드를 제공하는 서비스 provider들도 이러한 것들을 손쉽게 하기 위한 서비스(가령 ucloud biz의 packaging) 또한 활용이 가능하다.

GenoeCloud도 고객의 요구사항에 따라 적절하게 컴퓨팅을 생성하는데 이러한 기술들을 사용한다. 100대의  바로 분석할 준비가 된 서버도 몇 분 안에 제공이 가능하다.  아래 그림은 서버(클러스터)를 생성할때 해주어야 하는 것들을 정의한 것이다. 각 기어모양의 박스는 step들이고 해당 step들을 마쳐야 비로서 ready된 분석환경이 만들어진다. 

 
아래 그림은 위의 step중 하나의 세부 정의를 보여준다. 간단히 디스크를 추가하고 사용할 수 있도록 설정하는 부분이다. 각종 에러 처리 및 명령어들이 복잡하게 설정되어 있는 것을 확인 할 수 있다. 저것들을 일일히 사람이 직접 몇 백대를 하다가는 죽을 수도 있다.


그들만의 노하우(커스텀 레고)
레고의 장점은 서로 다른 모델들을 조합해서 전해 새로운 모델을 만들 수 있다는 것이다. -hongiiv-

그냥 컴퓨터를 자동으로 만들고 엮어 놓아도 분석은 할 수 있다. 하지만, 단순히 그렇다고 한다면 굳이 우리(GenomeCloud) 유전체 연구자들에게 내세울 강점이 없다. 바로 연구자들이 AWS나 MS가 아닌 GenomeCloud를 사용해야만 하는 이유가 여기에 있다. "GenomeCloud의 강점은 세세한 기능과 유전체 분야 고객의 요구사항에 대한 많은 노하우를 가지고 있으며, 이를 기반으로 클라우드 컴퓨터를 제공한다는 것이다." 똑같은 100코어 800GB 메모리를 가진 클라우드 자원이라도 우리의 손을 거친 클라우드는 다르다는 것이다.

세세한 모든 노하우를 나열하지는 못하지만 간단히 다음과 같은 것들이 있을 수 있다. KT의 ucloud의 성능에 대한 근거 데이터를 가지고 있다는 것이다. 각 분석 작업에 알맞는 최적화된 클라우드 벤치마크 데이터가 그것이다. 당연히 좋은 사양의 클라우드 자원이 좋다. 하지만, 좋은 사양일 수록 가격 또한 올라가기에 이에 대한 적절한 절충안을 찾아야 한다는 것이다. 두번째로 유전체 데이터 분석에서 있어서 각 알고리즘에 따른 적절한 클라우드 자원의 구성이다. reference data의 경우 분석시 메모리에 적재되어 활용되고 또한 이들을 파일 사이즈를 무시하지 못한다. 따라서 이러한 ref data만 따로 모아 제공하여 스토리지 자원을 절약하고 분석 결과를 temporary 디스크를 사용하는 경우 로컬 디스크를 사용하게하는 한편 OS의 temp를 사용하는 경우 자칫 용량문제로 소프트웨어가 정지하는 일이 발생하는데 이를 미연에 방지한다. 이러한 특징을 분석하여 총 4계층의 스토리지를 구축한다. ref data, temporary result, final result, 장기저장의 용도에 따른 스토리지를 구성하고 이를 적용하는 것이다. 이외에도 많은 것들이 고려되어야 시간과 비용면에서 유리하도록 할 수가 있다.

결론
클라우드를 이용한 과학계산에 있어서 단순히 클라우드 서비스를 이용한다는 것외에도 고려할 사항들이 많다. 사용자와 클라우드제공자와의 간격을 좁혀주기 위해서 해외에서는 cycle computing과 같이 이들을 서로 연결해주는 회사도 있다. 몇백에서 몇천대를 한꺼번에 사용하는데에 있어서 자칫 실수라도 한다면 엄청난 비용을 물어야 하기 때문이다. 저 분석 잘못했으니 클라우드 사용비용 안낼거에요. 라고 하고 싶겠지만, 당신은 이미 분석결과를 냈던 안냈던 클라우드 자원을 사용한 후이고 그에 대한 비용을 지불해야 하기 때문이다.

물론 클라우드에 대한 많은 지식과 경험이 있다면 필요가 없는 것이겠지만, 그런것들은 우리에게 맡겨두고 당신은 연구에만 몰두하면 된다.

저작자 표시 비영리 동일 조건 변경 허락
신고
댓글
댓글쓰기 폼