2018.03.23

김진철의 How-to-Big Data | 빅데이터 주요 기술의 조건 (1)

김진철 | CIO KR

LCG 데이터 병렬 처리 프레임워크 - PROOF
본 연재의 여섯 번째 글에서 잠시 소개했던 LHC 이벤트 데이터를 분석 과정을 잠시 되새겨 보기로 하자. LHC 이벤트 데이터 분석 과정은 먼저 검출기의 Level-1 트리거와 고수준 트리거(high-level trigger)에서 수행되는 이벤트 데이터 파편(fragment)들을 검출기 센서의 위치에 맞게 배치, 병합하고, 물리학자들이 물리학적인 분석이 가능하도록 기초적인 메타데이터를 추가하는 자동화된 데이터 분석 과정이었다. 이렇게 자동화된 데이터 분석 과정은 물리학자들이 힉스 보존과 같은 새로운 입자를 쉽게 찾게 해주거나, 입자의 특성을 더 정밀하게 분석하길 원하는 입자에서 필요한 정보를 쉽게 계산해낼 수 있도록 이벤트 데이터를 가공하는 과정이다.

위와 같이 검출기의 온라인 데이터 수집 시스템을 통해서 이벤트 데이터를 자동으로 가공한 후에는 물리학적인 분석을 위한 단계에 들어간다. 이런 추가의 물리학적인 정밀한 분석이 필요한 이유는 자동화된 분석 단계에서 쓰이는 인공지능 기술이 아직 물리학자들이 물리학적 분석을 하는 것과 같이 복잡하고 창조적인 작업을 할 수 있을 정도로 발전하지 않았기 때문이다. 현재 LHC 이벤트 데이터 분석 과정에서 자동화된 부분은 앞서 여섯 번째 글에서 소개한 바와 같이 시뮬레이션을 통해 생성된 이벤트 데이터와 실제 수집된 이벤트 데이터를 비교하여 원시 이벤트 데이터에 시뮬레이션 데이터에서 추정된 메타데이터를 덧붙이는 패턴 매칭 과정이라고 소개한 바 있다.



CMS를 비롯한 LHC의 각 검출기들이 초당 4천만 번의 횟수로 일어나는 양성자 빔 충돌로 인해 Level-1 트리거를 거치기 전에는 1TB이상의 많은 원시 데이터를 쏟아내지만, 양성자 빔 충돌 한번의 이벤트 데이터는 2MB 정도로 그렇게 큰 편이 아니다. 각각의 양성자 빔 충돌 이벤트는 서로 상호 연관이 없는 통계적으로 독립적인 이벤트들로 볼 수 있기 때문에 각 이벤트 데이터를 개별적으로 분석해도 문제가 없다. 이렇게 통계적으로 독립적인 작은 크기의 이벤트 데이터가 많은 수로 쏟아지는 형태로 데이터가 생성되기 때문에 고처리량 연산(high-throughput computing) 형태의 작업으로 분석할 수 있게 된다.

고처리량 연산(high-throughput computing) 컴퓨팅 형태의 작업은 개별 작업에서 다루는 데이터의 양은 하나의 서버나 노드에서 계산할 수 있을 만큼 작지만, 이런 개별 작업으로 다루어야 하는 데이터의 수가 매우 많아서 병렬 연산이 필요한 형태의 고성능 컴퓨팅 작업이다. 고처리량 컴퓨팅 작업과 반대되는 완전 병렬 연산(fully-parallel computing)이 필요한 작업은 데이터 자체도 하나의 서버나 노드에서 처리할 수 없을 만큼 커서 한번의 계산을 위한 데이터를 여러 대의 노드에 나누고, 여러 대의 노드에 나누어진 데이터 간에 병렬, 분산 컴퓨팅 알고리즘을 이용해 큰 계산을 수행하는 것이다.

LHC 물리학자들이 많은 수의 이벤트 데이터를 분석하려면 고처리량 연산을 손쉽게 할 수 있는 병렬 연산 소프트웨어 도구가 필요했다. 전 지구적인 슈퍼컴퓨팅 인프라인 LHC 컴퓨팅 그리드(LHC Computing Grid; LCG)에서는 많은 연산을 손쉽게 병렬로 처리할 수 있도록 Condor, OpenPBS, Platform LSF, Torque 등 당시에 고처리량 병렬 연산을 위해 개발된 작업 스케줄러들을 LCG 그리드 미들웨어가 그리드 자원 관리 기능과 연계해서 통합, 지원하였다.

당시 LCG에서 쓰였던 이런 작업 스케줄러들은 오늘날의 하둡과 같은 프레임워크의 형태가 아니었다. 프로세스 단위의 실행 파일, 실행에 필요한 관련 파일과 데이터를 하나의 샌드박스 형태로 만들고 실행할 파일을 실행하는 방법과 내용을 입력 파일 스크립트(input file) 형태로 간단하게 기술하여 쉘 프롬프트에서 작업 스케줄러 명령에 입력 파일과 샌드박스에 대한 정보를 넘기는 식으로 실행하였다.

이렇게 LCG에서 쓰였던 작업 스케줄러들은 프로세스 단위로 병렬화할 수밖에 없었기 때문에 병렬 계산을 하는 작업과 전체 분석 작업이 유기적으로 통합되지 못하고 분리되어, 작업 실행이 스케줄러의 큐(queue)에 들어온 순서대로 순차적으로 실행될 수밖에 없었다. 작업이 실행되는 동안에는 작업 내용에 대한 피드백을 받기가 어려웠고, 가장 마지막 서브작업이 끝나야 전체 작업이 끝났기 때문에 데이터 분석에 많은 시간이 소요되고 융통성을 발휘하기 어려웠다. 이런 이유로 작업 스케줄러를 이용한 이벤트 데이터 작업 병렬화는 데이터 분석 실행과정 자동화와 복잡한 빅데이터 처리 워크플로우 실행에는 한계가 있었다.

CERN에서는 LHC를 건설하기 전에 전자빔과 양전자빔을 충돌시켜 입자물리학 현상을 조사하였던 LEP(Large Electron-Positron Collider) 가속기 시절부터 PAW와 PIAF 등의 데이터 분석 소프트웨어를 만드는데 많은 노력을 기울였다. 1995년 CERN의 SPS 가속기에서 중이온 빔실험을 하던 르네 브룬(Rene Brun)과 CERN 내 휴렛패커드의 리눅스 에반겔리스트로 일하던 폰즈 라드메이커스(Fons Rademakers)가 실험 장치의 데이터 수집과정 조작(manipulation), 제어부터 고급 입자 물리학 분석에 이르는 이벤트 데이터 분석의 전 과정을 하나의 분석 환경에서 편리하게 수행할 수 있게 하려고 ROOT라고 하는 분석 소프트웨어를 만들기 시작하였다.

당시 물리학자들이 LEP나 LHC와 같은 복잡한 실험 장치를 제작, 제어하고 이벤트 시뮬레이션과 분석을 위한 복잡한 계산을 하는 과정에서 대부분 C/C++ 언어를 사용하였기 때문에, ROOT의 분석 로직을 표현하는 기본 언어도 C/C++를 사용하여 만들어졌다. 다만, R이나 MATLAB, OCTAVE와 같이 명령행 환경에서 대화식 분석이 가능하도록 C/C++ 인터프리터인 CINT를 기반으로 대화식 분석을 할 수 있도록 하였다.



LHC 가속기 건설 막바지에 다른 2003년경부터는 물리학자들이 수행하는 이벤트 분석 내용이 대부분 ROOT를 통해서 작성되고 있었기 때문에, 작업 스케줄러를 통해 여러 노드에 작업을 분산하고 그 결과를 돌려받아 후속 연산이나 작업을 하는 과정을 프로그램하는 것도 ROOT의 기반 언어인 C/C++로 작성될 수 있어야 했다.

LCG 그리드 미들웨어가 개발되던 당시에는 Condor나 Torque 등의 작업 스케줄러에서 제공되는 API가 없거나 있더라도 오늘날의 하둡과 같은 추상화된 프로그래밍 모델을 통해 제공되는 것이 아니어서 응용 프로그램과 통합이 쉽지 않았다. Open Grid Forum과 같은 오픈 소스 그리드 컴퓨팅 단체를 통해서 제정된 작업 관리 및 기술(description)에 대한 표준인 JSDL(Job Submission and Description Language)나 DRMAA(Distributed Resource Management Application API; DRMAA)와 같은 작업 및 자원 관리 메시지 표준이 제정되어 이를 작업 스케줄러에서 지원하게 된 것은 꽤 시간이 지난 후의 일이었다. JSDL이나 DRMAA를 통해 작업 스케줄러를 제어하고 상호작용 하는 방법이 여러 프로그래밍 언어 환경에서 단일화된 메시지 기반 인터페이스를 제공한다는 점에서는 바람직했지만, 개발자들이 직접 JSDL이나 DRMAA를 다루는 것은 번거로운 일이었다.
 


위와 같은 이유로 고처리량 연산을 ROOT에서 지원하기 위한 PROOF(Parallel ROOT Facility; PROOF)라는 C/C++언어 기반의 병렬 처리 프레임워크가 CERN의 ROOT 핵심 개발자들인 르네 브룬(Rene Brun)과 폰즈 라드메이커스(Fons Rademakers), MIT의 중이온 물리 연구실(Heavy Ion Group)의 마틴 발린틴(Maarten Ballintijn), 군터 롤랜드(Gunther Roland), 크리스 굴브란드슨(Kris Gulbrandsen)에 의해 개발되었다. PROOF는 ROOT의 C++ API 형태로 제공되며, 작업을 실행할 워커(worker) 노드의 정보와 작업을 분배할 내용을 C++ API를 이용해 기술해주면 ROOT C++ 분석 코드 안에서 병렬 처리를 위한 과정을 모두 제어할 수 있어서 LHC 데이터 분석의 생산성을 크게 높여주었다.

PROOF는 마스터-슬레이브 형태로 클러스터를 조직해서 작업을 병렬화하게 되며(그림 2), 마스터 노드는 여러 계층으로 계층화해서 여러 LCG Tier-1, Tier-2, Tier-3 데이터 분석 자원에 이르는 계산 자원을 통합하여 병렬 연산을 할 수 있게 한다. 실제 계산이 수행되는 워커 노드는 PROOF에서 하둡의 HDFS와 유사한 역할을 하는 병렬 파일 시스템인 SCALLA나 그리드 스토리지 시스템에 저장된 데이터에 접근해서 PROOF를 사용해 작업을 병렬화한 소스코드에 기술되어 있는 대로 작업을 병렬화하여 실행한다.



초기 버전의 PROOF에서는 ROOT의 대용량 데이터 접근 클래스인 TTree와 TChain을 이용해서 데이터 병렬(data-parallel) 방식의 병렬처리 방법을 기술하였다. ROOT의 TSelector 클래스를 이용하면 Condor, OpenPBS의 작업 기술(job description) 입력 파일(input file) 형식으로 ROOT 스크립트 외부에서 작업 병렬화를 기술하는 것이 아니라, ROOT 스크립트 내부에서 ROOT 스크립트 단위로 작업 병렬화를 기술할 수 있어 병렬화된 작업을 관리하는 것이 Condor나 OpenPBS 등의 작업 스케줄러보다 한층 일관되고 수월하다([3], 그림 2, 3).

최근 버전의 ROOT와 PROOF에서는 TExecutor 인터페이스를 만족하는 TProcessExecutor, TThreadExecutor 클래스를 이용해 병렬화할 수 있다. 이들 TProcessExecutor, TThreadExecutor 클래스는 하둡 스타일의 맵리듀스 프로그래밍 패턴도 지원한다. 최근 버전의 ROOT와 PROOF에서 지원되는 ROOT:EnableImplicitMT 함수를 이용하면 순차적인 로직을 가지는 ROOT 분석 스크립트를 자동으로 병렬화할 수도 있다[4].

요즘 많이 쓰이는 하둡이 유명해진 이유 중 하나가 데이터 블록 단위의 데이터 지역성(data locality)을 지원하는 것이다. 계산하는 작업이 계산에 필요한 해당 데이터 블록이 있는 노드에서 실행되는, 데이터 지역성을 고려한 작업 스케줄링의 개념이 바로 PROOF에서 지원되었다. PROOF에서는 데이터 뭉치 단위가 아닌 이벤트 데이터 파일 단위의 데이터 지역성(data locality)을 지원한다. 그렇지만, 하둡에서도 데이터 블록은 역시 파일 단위로 저장되기 때문에 PROOF의 데이터 지역성의 개념은 하둡의 데이터 지역성의 조상이라고도 볼 수 있다.



독자들도 잘 아시겠지만, 하둡의 작업 스케줄러는 특정 워커 노드에서 실행되는 맵이나 리듀스 작업 실행이 실패하면 자동으로 해당 작업만을 다시 실행하는 결함 포용 작업 실행(fault-tolerant job execution)을 지원한다. PROOF는 하둡과 같은 결함 포용 작업 관리(fault-tolerant job management)를 하지 않아서 워커에서 실행되는 작업이 죽으면 전체 작업이 중단된다. PROOF가 하둡과 같은 결함 포용 작업 관리를 하지는 않았지만, 각 서브작업 단위로 실시간으로 작업 상태와 내용에 대한 피드백을 제공하기 때문에 Condor나 OpenPBS 등의 작업 스케줄러에 비해서는 작업 실행의 속도와 성공률을 많이 높일 수 있었다.

하둡의 분산파일 시스템인 HDFS에서는 데이터 블록 복제(replication) 기능을 통해 데이터의 안정성을 높이지만, PROOF는 이런 데이터 복제 기능이 없다. 하둡의 HDFS는 같은 데이터 블록을 여러 개, 보통은 3개를 복제하여 다른 노드에 위치하게 하여, 특정 데이터 블록이 데이터를 저장하는 디스크나 서버의 문제로 유실되더라도 다른 복제본으로 데이터 유실을 방지하여 데이터 저장 및 관리의 신뢰성을 높인다.
하둡의 선형 확장성이 PROOF보다 좋지 않지만[5], 하둡의 데이터 지역성(data locality)을 고려한 계산과 결함 포용 작업 관리, 데이터 복제를 통한 데이터의 신뢰성 향상 등은 분명히 PROOF대비 하둡의 장점이기 때문에 최근에는 하둡을 이용한 LHC 데이터 분석 사례도 늘어나고 있다. 최근 ROOT에서 하둡이나 스파크 등의 빅데이터 기술을 이용한 병렬 연산을 지원하기 위한 연구를 고에너지 물리학자들이 연구하고 있다[6].

하둡이나 스파크와 같은 빅데이터 기술이 등장하기 전까지 PROOF는 LHC 연구자들에게 LHC 빅데이터를 분석하는 데 필요했던 병렬 연산을 손쉽게 제공해주었던 중요한 도구였다. 당시에 Condor, OpenPBS, Torque 등의 작업 스케줄러에는 없었던 고처리량 연산(high-throughput computing)을 위한 추상화된 프로그래밍 모델과 API를 제공하였다. 이 때문에 ROOT를 이용해 LHC 빅데이터를 분석했던 LHC 물리학자들이 병렬 컴퓨팅에 대한 전문적인 지식이 없이도 손쉽게 LCG 그리드 자원을 이용한 대규모 빅데이터 분석을 할 수 있었다.

비록 PROOF에서 하둡과 같은 데이터 복제 기능과 결함 포용 작업 관리(fault-tolerant job management)는 지원하지 않았지만, 하둡에서 지원되는 랙 단위 자원 인식과 이를 이용해 데이터와 작업을 스케줄링하는 랙 인식 작업 스케줄링(rack-aware job scheduling)과 함께 전 지구적인 그리드 자원의 계층과 서비스 지역을 인식해서 작업을 스케줄링할 수 있는 훨씬 큰 규모의 자원 계층 인식 스케줄링(resource hierarchy-aware scheduling)이 가능했다. 하둡이 나타나기 훨씬 전부터 빅데이터를 위한 프로그래밍 모델과 자원 관리 모델을 제시하고 빅데이터 분석을 실현했다는 점에서 PROOF는 구글의 맵리듀스나 하둡, 스파크만큼이나 빅데이터 기술 역사에 기록될 만한 소프트웨어 도구이다.


2018.03.23

김진철의 How-to-Big Data | 빅데이터 주요 기술의 조건 (1)

김진철 | CIO KR

LCG 데이터 병렬 처리 프레임워크 - PROOF
본 연재의 여섯 번째 글에서 잠시 소개했던 LHC 이벤트 데이터를 분석 과정을 잠시 되새겨 보기로 하자. LHC 이벤트 데이터 분석 과정은 먼저 검출기의 Level-1 트리거와 고수준 트리거(high-level trigger)에서 수행되는 이벤트 데이터 파편(fragment)들을 검출기 센서의 위치에 맞게 배치, 병합하고, 물리학자들이 물리학적인 분석이 가능하도록 기초적인 메타데이터를 추가하는 자동화된 데이터 분석 과정이었다. 이렇게 자동화된 데이터 분석 과정은 물리학자들이 힉스 보존과 같은 새로운 입자를 쉽게 찾게 해주거나, 입자의 특성을 더 정밀하게 분석하길 원하는 입자에서 필요한 정보를 쉽게 계산해낼 수 있도록 이벤트 데이터를 가공하는 과정이다.

위와 같이 검출기의 온라인 데이터 수집 시스템을 통해서 이벤트 데이터를 자동으로 가공한 후에는 물리학적인 분석을 위한 단계에 들어간다. 이런 추가의 물리학적인 정밀한 분석이 필요한 이유는 자동화된 분석 단계에서 쓰이는 인공지능 기술이 아직 물리학자들이 물리학적 분석을 하는 것과 같이 복잡하고 창조적인 작업을 할 수 있을 정도로 발전하지 않았기 때문이다. 현재 LHC 이벤트 데이터 분석 과정에서 자동화된 부분은 앞서 여섯 번째 글에서 소개한 바와 같이 시뮬레이션을 통해 생성된 이벤트 데이터와 실제 수집된 이벤트 데이터를 비교하여 원시 이벤트 데이터에 시뮬레이션 데이터에서 추정된 메타데이터를 덧붙이는 패턴 매칭 과정이라고 소개한 바 있다.



CMS를 비롯한 LHC의 각 검출기들이 초당 4천만 번의 횟수로 일어나는 양성자 빔 충돌로 인해 Level-1 트리거를 거치기 전에는 1TB이상의 많은 원시 데이터를 쏟아내지만, 양성자 빔 충돌 한번의 이벤트 데이터는 2MB 정도로 그렇게 큰 편이 아니다. 각각의 양성자 빔 충돌 이벤트는 서로 상호 연관이 없는 통계적으로 독립적인 이벤트들로 볼 수 있기 때문에 각 이벤트 데이터를 개별적으로 분석해도 문제가 없다. 이렇게 통계적으로 독립적인 작은 크기의 이벤트 데이터가 많은 수로 쏟아지는 형태로 데이터가 생성되기 때문에 고처리량 연산(high-throughput computing) 형태의 작업으로 분석할 수 있게 된다.

고처리량 연산(high-throughput computing) 컴퓨팅 형태의 작업은 개별 작업에서 다루는 데이터의 양은 하나의 서버나 노드에서 계산할 수 있을 만큼 작지만, 이런 개별 작업으로 다루어야 하는 데이터의 수가 매우 많아서 병렬 연산이 필요한 형태의 고성능 컴퓨팅 작업이다. 고처리량 컴퓨팅 작업과 반대되는 완전 병렬 연산(fully-parallel computing)이 필요한 작업은 데이터 자체도 하나의 서버나 노드에서 처리할 수 없을 만큼 커서 한번의 계산을 위한 데이터를 여러 대의 노드에 나누고, 여러 대의 노드에 나누어진 데이터 간에 병렬, 분산 컴퓨팅 알고리즘을 이용해 큰 계산을 수행하는 것이다.

LHC 물리학자들이 많은 수의 이벤트 데이터를 분석하려면 고처리량 연산을 손쉽게 할 수 있는 병렬 연산 소프트웨어 도구가 필요했다. 전 지구적인 슈퍼컴퓨팅 인프라인 LHC 컴퓨팅 그리드(LHC Computing Grid; LCG)에서는 많은 연산을 손쉽게 병렬로 처리할 수 있도록 Condor, OpenPBS, Platform LSF, Torque 등 당시에 고처리량 병렬 연산을 위해 개발된 작업 스케줄러들을 LCG 그리드 미들웨어가 그리드 자원 관리 기능과 연계해서 통합, 지원하였다.

당시 LCG에서 쓰였던 이런 작업 스케줄러들은 오늘날의 하둡과 같은 프레임워크의 형태가 아니었다. 프로세스 단위의 실행 파일, 실행에 필요한 관련 파일과 데이터를 하나의 샌드박스 형태로 만들고 실행할 파일을 실행하는 방법과 내용을 입력 파일 스크립트(input file) 형태로 간단하게 기술하여 쉘 프롬프트에서 작업 스케줄러 명령에 입력 파일과 샌드박스에 대한 정보를 넘기는 식으로 실행하였다.

이렇게 LCG에서 쓰였던 작업 스케줄러들은 프로세스 단위로 병렬화할 수밖에 없었기 때문에 병렬 계산을 하는 작업과 전체 분석 작업이 유기적으로 통합되지 못하고 분리되어, 작업 실행이 스케줄러의 큐(queue)에 들어온 순서대로 순차적으로 실행될 수밖에 없었다. 작업이 실행되는 동안에는 작업 내용에 대한 피드백을 받기가 어려웠고, 가장 마지막 서브작업이 끝나야 전체 작업이 끝났기 때문에 데이터 분석에 많은 시간이 소요되고 융통성을 발휘하기 어려웠다. 이런 이유로 작업 스케줄러를 이용한 이벤트 데이터 작업 병렬화는 데이터 분석 실행과정 자동화와 복잡한 빅데이터 처리 워크플로우 실행에는 한계가 있었다.

CERN에서는 LHC를 건설하기 전에 전자빔과 양전자빔을 충돌시켜 입자물리학 현상을 조사하였던 LEP(Large Electron-Positron Collider) 가속기 시절부터 PAW와 PIAF 등의 데이터 분석 소프트웨어를 만드는데 많은 노력을 기울였다. 1995년 CERN의 SPS 가속기에서 중이온 빔실험을 하던 르네 브룬(Rene Brun)과 CERN 내 휴렛패커드의 리눅스 에반겔리스트로 일하던 폰즈 라드메이커스(Fons Rademakers)가 실험 장치의 데이터 수집과정 조작(manipulation), 제어부터 고급 입자 물리학 분석에 이르는 이벤트 데이터 분석의 전 과정을 하나의 분석 환경에서 편리하게 수행할 수 있게 하려고 ROOT라고 하는 분석 소프트웨어를 만들기 시작하였다.

당시 물리학자들이 LEP나 LHC와 같은 복잡한 실험 장치를 제작, 제어하고 이벤트 시뮬레이션과 분석을 위한 복잡한 계산을 하는 과정에서 대부분 C/C++ 언어를 사용하였기 때문에, ROOT의 분석 로직을 표현하는 기본 언어도 C/C++를 사용하여 만들어졌다. 다만, R이나 MATLAB, OCTAVE와 같이 명령행 환경에서 대화식 분석이 가능하도록 C/C++ 인터프리터인 CINT를 기반으로 대화식 분석을 할 수 있도록 하였다.



LHC 가속기 건설 막바지에 다른 2003년경부터는 물리학자들이 수행하는 이벤트 분석 내용이 대부분 ROOT를 통해서 작성되고 있었기 때문에, 작업 스케줄러를 통해 여러 노드에 작업을 분산하고 그 결과를 돌려받아 후속 연산이나 작업을 하는 과정을 프로그램하는 것도 ROOT의 기반 언어인 C/C++로 작성될 수 있어야 했다.

LCG 그리드 미들웨어가 개발되던 당시에는 Condor나 Torque 등의 작업 스케줄러에서 제공되는 API가 없거나 있더라도 오늘날의 하둡과 같은 추상화된 프로그래밍 모델을 통해 제공되는 것이 아니어서 응용 프로그램과 통합이 쉽지 않았다. Open Grid Forum과 같은 오픈 소스 그리드 컴퓨팅 단체를 통해서 제정된 작업 관리 및 기술(description)에 대한 표준인 JSDL(Job Submission and Description Language)나 DRMAA(Distributed Resource Management Application API; DRMAA)와 같은 작업 및 자원 관리 메시지 표준이 제정되어 이를 작업 스케줄러에서 지원하게 된 것은 꽤 시간이 지난 후의 일이었다. JSDL이나 DRMAA를 통해 작업 스케줄러를 제어하고 상호작용 하는 방법이 여러 프로그래밍 언어 환경에서 단일화된 메시지 기반 인터페이스를 제공한다는 점에서는 바람직했지만, 개발자들이 직접 JSDL이나 DRMAA를 다루는 것은 번거로운 일이었다.
 


위와 같은 이유로 고처리량 연산을 ROOT에서 지원하기 위한 PROOF(Parallel ROOT Facility; PROOF)라는 C/C++언어 기반의 병렬 처리 프레임워크가 CERN의 ROOT 핵심 개발자들인 르네 브룬(Rene Brun)과 폰즈 라드메이커스(Fons Rademakers), MIT의 중이온 물리 연구실(Heavy Ion Group)의 마틴 발린틴(Maarten Ballintijn), 군터 롤랜드(Gunther Roland), 크리스 굴브란드슨(Kris Gulbrandsen)에 의해 개발되었다. PROOF는 ROOT의 C++ API 형태로 제공되며, 작업을 실행할 워커(worker) 노드의 정보와 작업을 분배할 내용을 C++ API를 이용해 기술해주면 ROOT C++ 분석 코드 안에서 병렬 처리를 위한 과정을 모두 제어할 수 있어서 LHC 데이터 분석의 생산성을 크게 높여주었다.

PROOF는 마스터-슬레이브 형태로 클러스터를 조직해서 작업을 병렬화하게 되며(그림 2), 마스터 노드는 여러 계층으로 계층화해서 여러 LCG Tier-1, Tier-2, Tier-3 데이터 분석 자원에 이르는 계산 자원을 통합하여 병렬 연산을 할 수 있게 한다. 실제 계산이 수행되는 워커 노드는 PROOF에서 하둡의 HDFS와 유사한 역할을 하는 병렬 파일 시스템인 SCALLA나 그리드 스토리지 시스템에 저장된 데이터에 접근해서 PROOF를 사용해 작업을 병렬화한 소스코드에 기술되어 있는 대로 작업을 병렬화하여 실행한다.



초기 버전의 PROOF에서는 ROOT의 대용량 데이터 접근 클래스인 TTree와 TChain을 이용해서 데이터 병렬(data-parallel) 방식의 병렬처리 방법을 기술하였다. ROOT의 TSelector 클래스를 이용하면 Condor, OpenPBS의 작업 기술(job description) 입력 파일(input file) 형식으로 ROOT 스크립트 외부에서 작업 병렬화를 기술하는 것이 아니라, ROOT 스크립트 내부에서 ROOT 스크립트 단위로 작업 병렬화를 기술할 수 있어 병렬화된 작업을 관리하는 것이 Condor나 OpenPBS 등의 작업 스케줄러보다 한층 일관되고 수월하다([3], 그림 2, 3).

최근 버전의 ROOT와 PROOF에서는 TExecutor 인터페이스를 만족하는 TProcessExecutor, TThreadExecutor 클래스를 이용해 병렬화할 수 있다. 이들 TProcessExecutor, TThreadExecutor 클래스는 하둡 스타일의 맵리듀스 프로그래밍 패턴도 지원한다. 최근 버전의 ROOT와 PROOF에서 지원되는 ROOT:EnableImplicitMT 함수를 이용하면 순차적인 로직을 가지는 ROOT 분석 스크립트를 자동으로 병렬화할 수도 있다[4].

요즘 많이 쓰이는 하둡이 유명해진 이유 중 하나가 데이터 블록 단위의 데이터 지역성(data locality)을 지원하는 것이다. 계산하는 작업이 계산에 필요한 해당 데이터 블록이 있는 노드에서 실행되는, 데이터 지역성을 고려한 작업 스케줄링의 개념이 바로 PROOF에서 지원되었다. PROOF에서는 데이터 뭉치 단위가 아닌 이벤트 데이터 파일 단위의 데이터 지역성(data locality)을 지원한다. 그렇지만, 하둡에서도 데이터 블록은 역시 파일 단위로 저장되기 때문에 PROOF의 데이터 지역성의 개념은 하둡의 데이터 지역성의 조상이라고도 볼 수 있다.



독자들도 잘 아시겠지만, 하둡의 작업 스케줄러는 특정 워커 노드에서 실행되는 맵이나 리듀스 작업 실행이 실패하면 자동으로 해당 작업만을 다시 실행하는 결함 포용 작업 실행(fault-tolerant job execution)을 지원한다. PROOF는 하둡과 같은 결함 포용 작업 관리(fault-tolerant job management)를 하지 않아서 워커에서 실행되는 작업이 죽으면 전체 작업이 중단된다. PROOF가 하둡과 같은 결함 포용 작업 관리를 하지는 않았지만, 각 서브작업 단위로 실시간으로 작업 상태와 내용에 대한 피드백을 제공하기 때문에 Condor나 OpenPBS 등의 작업 스케줄러에 비해서는 작업 실행의 속도와 성공률을 많이 높일 수 있었다.

하둡의 분산파일 시스템인 HDFS에서는 데이터 블록 복제(replication) 기능을 통해 데이터의 안정성을 높이지만, PROOF는 이런 데이터 복제 기능이 없다. 하둡의 HDFS는 같은 데이터 블록을 여러 개, 보통은 3개를 복제하여 다른 노드에 위치하게 하여, 특정 데이터 블록이 데이터를 저장하는 디스크나 서버의 문제로 유실되더라도 다른 복제본으로 데이터 유실을 방지하여 데이터 저장 및 관리의 신뢰성을 높인다.
하둡의 선형 확장성이 PROOF보다 좋지 않지만[5], 하둡의 데이터 지역성(data locality)을 고려한 계산과 결함 포용 작업 관리, 데이터 복제를 통한 데이터의 신뢰성 향상 등은 분명히 PROOF대비 하둡의 장점이기 때문에 최근에는 하둡을 이용한 LHC 데이터 분석 사례도 늘어나고 있다. 최근 ROOT에서 하둡이나 스파크 등의 빅데이터 기술을 이용한 병렬 연산을 지원하기 위한 연구를 고에너지 물리학자들이 연구하고 있다[6].

하둡이나 스파크와 같은 빅데이터 기술이 등장하기 전까지 PROOF는 LHC 연구자들에게 LHC 빅데이터를 분석하는 데 필요했던 병렬 연산을 손쉽게 제공해주었던 중요한 도구였다. 당시에 Condor, OpenPBS, Torque 등의 작업 스케줄러에는 없었던 고처리량 연산(high-throughput computing)을 위한 추상화된 프로그래밍 모델과 API를 제공하였다. 이 때문에 ROOT를 이용해 LHC 빅데이터를 분석했던 LHC 물리학자들이 병렬 컴퓨팅에 대한 전문적인 지식이 없이도 손쉽게 LCG 그리드 자원을 이용한 대규모 빅데이터 분석을 할 수 있었다.

비록 PROOF에서 하둡과 같은 데이터 복제 기능과 결함 포용 작업 관리(fault-tolerant job management)는 지원하지 않았지만, 하둡에서 지원되는 랙 단위 자원 인식과 이를 이용해 데이터와 작업을 스케줄링하는 랙 인식 작업 스케줄링(rack-aware job scheduling)과 함께 전 지구적인 그리드 자원의 계층과 서비스 지역을 인식해서 작업을 스케줄링할 수 있는 훨씬 큰 규모의 자원 계층 인식 스케줄링(resource hierarchy-aware scheduling)이 가능했다. 하둡이 나타나기 훨씬 전부터 빅데이터를 위한 프로그래밍 모델과 자원 관리 모델을 제시하고 빅데이터 분석을 실현했다는 점에서 PROOF는 구글의 맵리듀스나 하둡, 스파크만큼이나 빅데이터 기술 역사에 기록될 만한 소프트웨어 도구이다.


X