2018.01.29

김진철의 How-to-Big Data | 빅데이터와 클라우드 기술 (5)

김진철 | CIO KR

CMS 검출기에 영혼을 주는 CMS 온라인 소프트웨어
지난 열두번째 글에서 소개한 Level-1 트리거는 CMS를 비롯한 LHC 검출기에서 원시 데이터 처리를 위해 데이터 스트림이 가장 먼저 만나는 시스템이다. 초당 1TB 이상 검출기 센서에서 쏟아져 나오는 많은 데이터 중에서 물리학적으로 의미 있는 이벤트 데이터만 선별하는 데 필요한 빠른 데이터 처리를 위해 FPGA를 써서 연산을 가속한다고 소개하였다. 오늘 소개할 고수준 트리거(high-level trigger)는 Level-1 트리거에서 1차로 선별된 원시 데이터를 받아 물리학 분석이 가능하도록 자동으로 메타데이터를 덧붙이고 실제 사용할 수 있는 데이터로 원시 데이터를 가공하는 시스템이다.

LHC 가속기와 검출기 실험 장치의 규모가 크다 보니, LHC 모든 서브 시스템이 하나의 시스템으로 통합되어 동작하려면 필연적으로 각 모듈이 네트워크를 통해 정보를 주고받으면서 데이터를 처리하는 분산 컴퓨팅 시스템으로 개발될 수밖에 없다. 분산 컴퓨팅 시스템이 하나의 시스템으로 통합되기 위해서는 시스템내의 각 서브 시스템의 동작을 표준화된 프로그래밍 모델과 통신 방식으로 프로그램할 수 있는 소프트웨어 기술이 필요하다.



LHC 검출기별로 실험의 목적과 동작 특성, 요구 사항이 다르고, 네 대의 검출기에 필요한 요구사항을 모두 만족시킬 수 있는 소프트웨어를 만들기에는 LHC 검출기 시스템이 너무 복잡하기 때문에 LHC의 물리학자와 컴퓨터 과학자들은 검출기마다 고유의 분산 컴퓨팅 소프트웨어를 개발하여 검출기 기능을 통합하였다. 검출기 기능 통합에 사용된 분산 컴퓨팅 소프트웨어는 여러 대의 노드로 기능이 분산되어 네트워크 통신을 통해 이들 기능에서 처리된 데이터를 통합하는 미들웨어의 형태로 개발되었다.

필자가 건설에 참여하였던 CMS 검출기의 경우 XDAQ이라는 미들웨어를 사용하였다. XDAQ은 크로스 플랫폼 분산 데이터 수집, 처리 미들웨어(Cr운영체제(OS)s-platform(X) Distributed Data Acquisition and Processing middleware)의 줄인 말이다. 검출기 서브 시스템의 기반 플랫폼 종류에 상관없이 XDAQ의 핵심 API(Coretools API)를 이용해 프로그래밍하면 HTTP/1.1과 I2O 프로토콜을 통해서 고속으로 데이터를 주고받는 분산 컴퓨팅 응용 프로그램을 손쉽게 작성할 수 있도록 개발되어 있다.



그림 2에 나타난 XDAQ 미들웨어의 기본적인 구성을 같이 한번 살펴보자. XDAQ의 핵심 기능에 해당하는 Coretools 모듈에는 XDAQ 프로그래밍 모델의 가장 중요한 핵심 기능이 응용 프로그램 인터페이스(Application Programming Interface; API)로 정의되어 있다.

가장 먼저 눈에 띄는 모듈이 OS 추상화 모듈이다. XDAQ으로 통합되는 시스템을 구성하는 각 노드는 필요에 따라 다양한 하드웨어와 OS를 사용하게 된다. 이 때문에 다양한 OS의 기능을 XDAQ의 요구사항과 이에 따르는 표준 동작(operation)에 따라 추상화, 표준화할 수 있는 인터페이스와 이를 구현하는 모듈이 먼저 만들어진 것이다.

그다음에 눈에 띄는 것이 실행 환경 프레임워크(Execution Framework)이다. 다양한 OS에서 동작하는 응용 프로그램이 OS마다 의존성을 만족시키게끔 응용 프로그램 개발자가 일일이 신경을 쓴다면 CMS 검출기의 복잡한 시스템을 완성하는데 필요한 노력과 시간이 엄청나게 들어가 LHC 건설 프로젝트의 일정에 맞게 CMS 검출기 시스템을 통합하기 어려울 것이다. 이렇게 이기종(heterogeneous) 하드웨어와 OS 환경을 극복하고, XDAQ 응용 프로그램을 위한 표준 실행 환경을 제공하기 위해 응용 프로그래밍 인터페이스(API)를 제공한다.

검출기 하드웨어의 많은 장비와 부품들이 임베디드 시스템이기 때문에 하드웨어에 접근하는 데 각 장비와 부품별로 다양한 방식의 소프트웨어를 써야 한다. 각 하드웨어 자원의 특성을 감추고 표준화된 방식으로 접근, 제어하며, 원격으로 하드웨어에 접근하고 제어 파라미터를 주고받을 수 있는 추상화된 하드웨어 접근(Hardware Access) 모듈이 기본 모듈로 정의되어 있다.

마지막으로 XDAQ에서 가장 중요하게 여겨진 기능 중 하나인 네트워크 프로토콜 중립 통신(network protocol-independent communication) 방식을 지원하기 위한 통신 모듈(communication subsystem)이다. CMS 검출기의 영역별로 네트워크 요구 사항과 장비의 특성이 다르기 때문에, 장비의 데이터 처리 요구사항을 만족시키기 위해 다양한 네트워크 프로토콜이 쓰이게 된다. Level-1 트리거내 각 모듈과 장비 간의 통신을 위해서는 이더넷이 쓰이지만, 고수준 트리거의 초반부에 요구되는 매우 높은 처리량(throughput)의 요구사항을 만족하는 컴퓨팅 성능을 내기 위해서는 미리넷(Myrinet), 인피니밴드(Infiniband) 등의 고성능 네트워크 프로토콜을 써야 한다.



고성능 네트워크 장비에서 사용하는 프로토콜은 기술이 발전하면서 내용과 종류가 변화하기 때문에, LHC 실험이 수행되는 30~40여 년의 긴 시간 동안 일어나는 이런 네트워크 프로토콜의 변화에 XDAQ 응용 프로그램이 영향을 받지 않아야 한다. XDAQ으로 프로그램된 응용 프로그램들이 네트워크 프로토콜 변화에 영향을 받지 않도록 네트워크 프로토콜 수준의 통신 기능이 먼저 추상화되고 표준화될 필요가 있었다. 이런 이유로 과거에 많이 쓰였던 고성능 네트워크 프로토콜인 미리넷(Myrinet)과 최근 고성능 컴퓨팅 시스템에서 많이 쓰이고 있는 고성능 네트워크 프로토콜인 인피니밴드(Infiniband)와 같은 네트워크 프로토콜을 직접 다루는 어려움을 겪지 않고 XDAQ 응용 프로그램을 프로그램할 수 있도록 프로그래밍 모델을 정의할 필요가 있었다.

글을 읽는 독자들은 위와 같은 네트워크 프로토콜 추상화는 유닉스나 리눅스의 소켓 라이브러리와 네트워크 라이브러리 인터페이스, 인피니밴드(Infiniband) 프로토콜의 표준 동작을 정의하는 OFED 라이브러리등으로 이미 추상화되어 있지 않느냐고 생각할 수도 있다. 더군다나 비즈니스 분산 컴퓨팅 시스템 개발을 위해 훌륭한 Java 미들웨어들이 많이 있지 않느냐고 반문할 수 있다.

필자가 XDAQ 개발에 참여했던 당시의 상황은 CMS 검출기의 고성능 데이터 처리 요구사항을 만족할 만큼 Java 기술이 발전하지 않았던 때였다. 더군다나 CMS 검출기가 개발되던 1990년대에서 2000년대까지의 기간에는 미들웨어 기술이 막 태동하여 발전하던 시기였다. 현재 독자 여러분들이 사용하고 있는 많은 훌륭한 소프트웨어 기술들이 당시에는 존재하지 않았거나 충분히 성숙하지 않았다. CMS 검출기의 데이터 처리 요구사항이 당시 기술로는 극한의 요구사항이었기 때문에 가능한 모든 방법을 동원해서 컴퓨팅 하드웨어의 성능을 최대한 활용해야 했었다는 점을 염두에 두고 필자의 글을 읽을 필요가 있다.

CMS 검출기 부품 대부분은 임베디드 시스템이기 때문에, 하드웨어 자원의 제약이 현재보다 훨씬 더 심했다. 이렇게 자원의 제약이 심한 임베디드 컴퓨팅 시스템에서 시스템의 자원을 최대한 절약하기 위해 장비별로 다양한 바이너리 데이터 표현과 프로토콜을 사용하였는데, 이렇게 다양한 데이터 표현과 프로토콜을 직접 다루는 어려움을 줄이기 위해 XDAQ 미들웨어와 같은 표준화된 인터페이스가 꼭 필요하였다. XDAQ 표준 응용 프로그램 인터페이스(API)가 없었다면 모든 검출기 시스템 개발자들이 직접 저수준 네트워크 라이브러리를 다뤄야 했기 때문에 개발 작업의 생산성이 크게 떨어졌을 것이고, 일정에 맞추어 CMS 검출기가 건설되기 어려웠을 것이다.
 


XDAQ Coretools API에는 XDAQ 응용 프로그램의 기반이 되는 애플리케이션이라고 하는 클래스가 정의되어 있다. 이 애플리케이션 클래스는 자바 서블릿 개발의 기본이 되는 javax.servlet.http.HttpServlet과 비슷한 역할을 하는 클래스이다. 이 베이스 클래스에는 동기 전송 플러그인(Peer Transport Plugin)이라고 하는 데이터 구조가 있어 XDAQ 응용 프로그램의 특성에 따라 메시지를 전달하는 네트워크 프로토콜을 손쉽게 바꿀 수 있다. 성능이 우선시되어 네트워크 지연이 최소화되어야 할 경우 Intel이 고속 데이터 버스 통신용으로 개발한 I2O 프로토콜로 데이터를 전송하며, 일반적인 XDAQ 응용 프로그램의 제어 및 데이터베이스 접근의 경우에는 HTTP 프로토콜을 이용해 SOAP 메시지 형태로 통신하게 된다.

위와 같은 Coretools 모듈의 핵심 기능을 이용해 P2P(Peer-to-Peer) 형태로 통신하는 확장성 있는 분산 애플리케이션을 쉽게 만들 수 있다. Coretools 모듈 위에는 개발자들의 분산 응용 프로그램 개발을 돕는 도구상자인 Powerpack 모듈이 있는데, 이 Powerpack 모듈에는 분산 시스템 소프트웨어를 개발하는 데 필요한 데이터 모니터링, 오류(error)와 알람(alarm)의 분산 전파 및 통신, 웹 기반의 사용자 인터페이스 도구, 작업 제어 모듈 등이 있다. 특히 작업 제어 모듈은 요즘 빅데이터 분야에서 많이 쓰이는 하둡의 작업 스케줄러와 비슷하게 원격 XDAQ 노드에 작업을 분산하여 실행시킬 수 있으며, 조금만 응용하면 하둡과 유사한 분산 병렬 처리도 가능하다.

위와 같은 Coretools 모듈과 Powerpack 모듈을 이용해서 그림 1의 CMS 검출기 고수준 트리거를 구성하는 이벤트 빌더(Event Builder), 빌더 유닛(Builder Unit; BU), 리드아웃 유닛(Readout Unit) 등의 분산 응용 프로그램을 손쉽게 작성하고 통합할 수 있었다. XDAQ이 없었다면 CMS 검출기에서 수집되는 초당 1TB의 데이터를 적절하게 필터링하고 자동 메타데이터를 처리할 수 없었을 것이고, CMS 실험을 수행하는 물리학자들이 힉스 입자를 발견하는데 더 많은 시간과 노력이 필요했을 것이다.

 

2018.01.29

김진철의 How-to-Big Data | 빅데이터와 클라우드 기술 (5)

김진철 | CIO KR

CMS 검출기에 영혼을 주는 CMS 온라인 소프트웨어
지난 열두번째 글에서 소개한 Level-1 트리거는 CMS를 비롯한 LHC 검출기에서 원시 데이터 처리를 위해 데이터 스트림이 가장 먼저 만나는 시스템이다. 초당 1TB 이상 검출기 센서에서 쏟아져 나오는 많은 데이터 중에서 물리학적으로 의미 있는 이벤트 데이터만 선별하는 데 필요한 빠른 데이터 처리를 위해 FPGA를 써서 연산을 가속한다고 소개하였다. 오늘 소개할 고수준 트리거(high-level trigger)는 Level-1 트리거에서 1차로 선별된 원시 데이터를 받아 물리학 분석이 가능하도록 자동으로 메타데이터를 덧붙이고 실제 사용할 수 있는 데이터로 원시 데이터를 가공하는 시스템이다.

LHC 가속기와 검출기 실험 장치의 규모가 크다 보니, LHC 모든 서브 시스템이 하나의 시스템으로 통합되어 동작하려면 필연적으로 각 모듈이 네트워크를 통해 정보를 주고받으면서 데이터를 처리하는 분산 컴퓨팅 시스템으로 개발될 수밖에 없다. 분산 컴퓨팅 시스템이 하나의 시스템으로 통합되기 위해서는 시스템내의 각 서브 시스템의 동작을 표준화된 프로그래밍 모델과 통신 방식으로 프로그램할 수 있는 소프트웨어 기술이 필요하다.



LHC 검출기별로 실험의 목적과 동작 특성, 요구 사항이 다르고, 네 대의 검출기에 필요한 요구사항을 모두 만족시킬 수 있는 소프트웨어를 만들기에는 LHC 검출기 시스템이 너무 복잡하기 때문에 LHC의 물리학자와 컴퓨터 과학자들은 검출기마다 고유의 분산 컴퓨팅 소프트웨어를 개발하여 검출기 기능을 통합하였다. 검출기 기능 통합에 사용된 분산 컴퓨팅 소프트웨어는 여러 대의 노드로 기능이 분산되어 네트워크 통신을 통해 이들 기능에서 처리된 데이터를 통합하는 미들웨어의 형태로 개발되었다.

필자가 건설에 참여하였던 CMS 검출기의 경우 XDAQ이라는 미들웨어를 사용하였다. XDAQ은 크로스 플랫폼 분산 데이터 수집, 처리 미들웨어(Cr운영체제(OS)s-platform(X) Distributed Data Acquisition and Processing middleware)의 줄인 말이다. 검출기 서브 시스템의 기반 플랫폼 종류에 상관없이 XDAQ의 핵심 API(Coretools API)를 이용해 프로그래밍하면 HTTP/1.1과 I2O 프로토콜을 통해서 고속으로 데이터를 주고받는 분산 컴퓨팅 응용 프로그램을 손쉽게 작성할 수 있도록 개발되어 있다.



그림 2에 나타난 XDAQ 미들웨어의 기본적인 구성을 같이 한번 살펴보자. XDAQ의 핵심 기능에 해당하는 Coretools 모듈에는 XDAQ 프로그래밍 모델의 가장 중요한 핵심 기능이 응용 프로그램 인터페이스(Application Programming Interface; API)로 정의되어 있다.

가장 먼저 눈에 띄는 모듈이 OS 추상화 모듈이다. XDAQ으로 통합되는 시스템을 구성하는 각 노드는 필요에 따라 다양한 하드웨어와 OS를 사용하게 된다. 이 때문에 다양한 OS의 기능을 XDAQ의 요구사항과 이에 따르는 표준 동작(operation)에 따라 추상화, 표준화할 수 있는 인터페이스와 이를 구현하는 모듈이 먼저 만들어진 것이다.

그다음에 눈에 띄는 것이 실행 환경 프레임워크(Execution Framework)이다. 다양한 OS에서 동작하는 응용 프로그램이 OS마다 의존성을 만족시키게끔 응용 프로그램 개발자가 일일이 신경을 쓴다면 CMS 검출기의 복잡한 시스템을 완성하는데 필요한 노력과 시간이 엄청나게 들어가 LHC 건설 프로젝트의 일정에 맞게 CMS 검출기 시스템을 통합하기 어려울 것이다. 이렇게 이기종(heterogeneous) 하드웨어와 OS 환경을 극복하고, XDAQ 응용 프로그램을 위한 표준 실행 환경을 제공하기 위해 응용 프로그래밍 인터페이스(API)를 제공한다.

검출기 하드웨어의 많은 장비와 부품들이 임베디드 시스템이기 때문에 하드웨어에 접근하는 데 각 장비와 부품별로 다양한 방식의 소프트웨어를 써야 한다. 각 하드웨어 자원의 특성을 감추고 표준화된 방식으로 접근, 제어하며, 원격으로 하드웨어에 접근하고 제어 파라미터를 주고받을 수 있는 추상화된 하드웨어 접근(Hardware Access) 모듈이 기본 모듈로 정의되어 있다.

마지막으로 XDAQ에서 가장 중요하게 여겨진 기능 중 하나인 네트워크 프로토콜 중립 통신(network protocol-independent communication) 방식을 지원하기 위한 통신 모듈(communication subsystem)이다. CMS 검출기의 영역별로 네트워크 요구 사항과 장비의 특성이 다르기 때문에, 장비의 데이터 처리 요구사항을 만족시키기 위해 다양한 네트워크 프로토콜이 쓰이게 된다. Level-1 트리거내 각 모듈과 장비 간의 통신을 위해서는 이더넷이 쓰이지만, 고수준 트리거의 초반부에 요구되는 매우 높은 처리량(throughput)의 요구사항을 만족하는 컴퓨팅 성능을 내기 위해서는 미리넷(Myrinet), 인피니밴드(Infiniband) 등의 고성능 네트워크 프로토콜을 써야 한다.



고성능 네트워크 장비에서 사용하는 프로토콜은 기술이 발전하면서 내용과 종류가 변화하기 때문에, LHC 실험이 수행되는 30~40여 년의 긴 시간 동안 일어나는 이런 네트워크 프로토콜의 변화에 XDAQ 응용 프로그램이 영향을 받지 않아야 한다. XDAQ으로 프로그램된 응용 프로그램들이 네트워크 프로토콜 변화에 영향을 받지 않도록 네트워크 프로토콜 수준의 통신 기능이 먼저 추상화되고 표준화될 필요가 있었다. 이런 이유로 과거에 많이 쓰였던 고성능 네트워크 프로토콜인 미리넷(Myrinet)과 최근 고성능 컴퓨팅 시스템에서 많이 쓰이고 있는 고성능 네트워크 프로토콜인 인피니밴드(Infiniband)와 같은 네트워크 프로토콜을 직접 다루는 어려움을 겪지 않고 XDAQ 응용 프로그램을 프로그램할 수 있도록 프로그래밍 모델을 정의할 필요가 있었다.

글을 읽는 독자들은 위와 같은 네트워크 프로토콜 추상화는 유닉스나 리눅스의 소켓 라이브러리와 네트워크 라이브러리 인터페이스, 인피니밴드(Infiniband) 프로토콜의 표준 동작을 정의하는 OFED 라이브러리등으로 이미 추상화되어 있지 않느냐고 생각할 수도 있다. 더군다나 비즈니스 분산 컴퓨팅 시스템 개발을 위해 훌륭한 Java 미들웨어들이 많이 있지 않느냐고 반문할 수 있다.

필자가 XDAQ 개발에 참여했던 당시의 상황은 CMS 검출기의 고성능 데이터 처리 요구사항을 만족할 만큼 Java 기술이 발전하지 않았던 때였다. 더군다나 CMS 검출기가 개발되던 1990년대에서 2000년대까지의 기간에는 미들웨어 기술이 막 태동하여 발전하던 시기였다. 현재 독자 여러분들이 사용하고 있는 많은 훌륭한 소프트웨어 기술들이 당시에는 존재하지 않았거나 충분히 성숙하지 않았다. CMS 검출기의 데이터 처리 요구사항이 당시 기술로는 극한의 요구사항이었기 때문에 가능한 모든 방법을 동원해서 컴퓨팅 하드웨어의 성능을 최대한 활용해야 했었다는 점을 염두에 두고 필자의 글을 읽을 필요가 있다.

CMS 검출기 부품 대부분은 임베디드 시스템이기 때문에, 하드웨어 자원의 제약이 현재보다 훨씬 더 심했다. 이렇게 자원의 제약이 심한 임베디드 컴퓨팅 시스템에서 시스템의 자원을 최대한 절약하기 위해 장비별로 다양한 바이너리 데이터 표현과 프로토콜을 사용하였는데, 이렇게 다양한 데이터 표현과 프로토콜을 직접 다루는 어려움을 줄이기 위해 XDAQ 미들웨어와 같은 표준화된 인터페이스가 꼭 필요하였다. XDAQ 표준 응용 프로그램 인터페이스(API)가 없었다면 모든 검출기 시스템 개발자들이 직접 저수준 네트워크 라이브러리를 다뤄야 했기 때문에 개발 작업의 생산성이 크게 떨어졌을 것이고, 일정에 맞추어 CMS 검출기가 건설되기 어려웠을 것이다.
 


XDAQ Coretools API에는 XDAQ 응용 프로그램의 기반이 되는 애플리케이션이라고 하는 클래스가 정의되어 있다. 이 애플리케이션 클래스는 자바 서블릿 개발의 기본이 되는 javax.servlet.http.HttpServlet과 비슷한 역할을 하는 클래스이다. 이 베이스 클래스에는 동기 전송 플러그인(Peer Transport Plugin)이라고 하는 데이터 구조가 있어 XDAQ 응용 프로그램의 특성에 따라 메시지를 전달하는 네트워크 프로토콜을 손쉽게 바꿀 수 있다. 성능이 우선시되어 네트워크 지연이 최소화되어야 할 경우 Intel이 고속 데이터 버스 통신용으로 개발한 I2O 프로토콜로 데이터를 전송하며, 일반적인 XDAQ 응용 프로그램의 제어 및 데이터베이스 접근의 경우에는 HTTP 프로토콜을 이용해 SOAP 메시지 형태로 통신하게 된다.

위와 같은 Coretools 모듈의 핵심 기능을 이용해 P2P(Peer-to-Peer) 형태로 통신하는 확장성 있는 분산 애플리케이션을 쉽게 만들 수 있다. Coretools 모듈 위에는 개발자들의 분산 응용 프로그램 개발을 돕는 도구상자인 Powerpack 모듈이 있는데, 이 Powerpack 모듈에는 분산 시스템 소프트웨어를 개발하는 데 필요한 데이터 모니터링, 오류(error)와 알람(alarm)의 분산 전파 및 통신, 웹 기반의 사용자 인터페이스 도구, 작업 제어 모듈 등이 있다. 특히 작업 제어 모듈은 요즘 빅데이터 분야에서 많이 쓰이는 하둡의 작업 스케줄러와 비슷하게 원격 XDAQ 노드에 작업을 분산하여 실행시킬 수 있으며, 조금만 응용하면 하둡과 유사한 분산 병렬 처리도 가능하다.

위와 같은 Coretools 모듈과 Powerpack 모듈을 이용해서 그림 1의 CMS 검출기 고수준 트리거를 구성하는 이벤트 빌더(Event Builder), 빌더 유닛(Builder Unit; BU), 리드아웃 유닛(Readout Unit) 등의 분산 응용 프로그램을 손쉽게 작성하고 통합할 수 있었다. XDAQ이 없었다면 CMS 검출기에서 수집되는 초당 1TB의 데이터를 적절하게 필터링하고 자동 메타데이터를 처리할 수 없었을 것이고, CMS 실험을 수행하는 물리학자들이 힉스 입자를 발견하는데 더 많은 시간과 노력이 필요했을 것이다.

 

X