2017.09.25

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

김진철 | CIO KR
클라우드 컴퓨팅의 서막 – CERN은 왜 클라우드 컴퓨팅이 필요했나?
LHC 실험과 인공지능 기술에 대한 내용을 더 다루기 전에, 독자들의 이해를 더 쉽게 돕기 위해 클라우드 컴퓨팅과 LHC 실험과의 관계를 살펴보고 지나가려 한다. 오늘은 CERN에서 어떻게 클라우드 컴퓨팅이 시작되었는지 같이 살펴보도록 하자.

흔히 많은 클라우드 컴퓨팅은 구글이 제일 먼저 시작했다고 알고 있다. 이 말은 반은 맞고, 반은 틀리다. 클라우드 컴퓨팅의 기반이 되는 기술은 사실 구글이 클라우드 컴퓨팅이라는 말을 사용하기 전에 이미 CERN과 IBM 등의 회사들을 통해서 많이 개발되어 있었기 때문에 반은 틀린 말이라는 것이고, 클라우드 컴퓨팅이라는 용어가 처음 생겨나서 업계에 자리 잡게끔 한 것이 구글이기 때문에 반은 맞는 사실이다. 클라우드 컴퓨팅이라는 말이 처음 나왔을 때는 그 의미가 명확하지 않아서, 오라클의 회장 래리 엘리슨은 클라우드 컴퓨팅이 무엇인지 잘 모르겠다고 혹독한 비판을 하기도 했다[2-7].

1992년 CERN의 과학자들은 LHC 가속기와 네 개의 검출기의 개념 설계를 진행하면서 연간 약 1PB의 데이터가 생성될 것임을 알게 된 후, 과연 이 빅데이터를 어떻게 분석할 것인지 고민하기 시작했다. 검출기 데이터 처리를 자동화하기 위해 Level-1 트리거와 고수준 트리거(high-level trigger)에서 데이터 처리를 자동화하는 분산컴퓨팅 시스템을 만드는 것과는 별개로, 효과적인 데이터 분석을 하기 위해서는 또 다른 기술적인 난관을 해결해야 했다.

먼저, 분석하게 될 물리학자들이 CERN에 모두 모여 있지 않다는 것이다. LHC 데이터 분석을 수행할 물리학자들은 전 세계의 다양한 연구소에 소속되어 본인들이 소속된 연구기관에서 분석을 수행하게 될 것이었다. 이렇게 전 세계에 걸쳐 일하는 사람들이 어떻게 LHC 데이터를 전송받고, 전송받은 데이터를 분석하기 위한 막대한 양의 계산을 할 수 있도록 컴퓨팅 시스템을 만들어야 할 것인가?

두 번째 문제는 1PB의 데이터를 이용해 힉스 입자와 같은 중요한 물리학적 이벤트를 찾아내기 위한 분석을 하는 작업의 양이 당시의 수퍼컴퓨터로 할 수 있는 계산의 양을 훨씬 더 크게 뛰어넘었다는 것이다. 또한 당시의 서버 기술로는 CERN 데이터센터에 계산 서버를 꽉 채워도 LHC 데이터 분석을 위한 계산을 하기에는 역부족이었다. LHC 데이터 분석을 위한 계산 자원을 확보하기 위해서는 여러 개의 데이터센터에 걸친 계산 자원들이 하나의 단일한 계산 자원같이 인식되도록 하여 계산할 수 있도록 하는, 아주 극단적인 이종환경에서의 고성능 컴퓨팅을 지원하는 분산컴퓨팅 기술이 필요했다. 과연 이렇게 어려운 분산컴퓨팅 소프트웨어 기술을 LHC 실험이 시작되기 전까지 만들 수 있을 것인가?

마지막 세 번째로, LHC 실험이 아주 오랜 기간에 걸쳐서 준비되고, 단계별로 업그레이드되면서 생성되는 데이터의 양이 점차 증가한다는 것이었다. 2008년 LHC와 네 개의 검출기가 시운전을 시작하기 전에 LHC 연구원들은 1990년대부터 실험을 준비했으니 거의 20년에 걸쳐 실험을 준비한 셈이다. LHC의 개념 설계를 준비하였던 CERN의 과학자들이 그 당시 기술로는 상상도 할 수 없을 만큼 큰 데이터양인 연간 1PB의 데이터를 저장하고 분석해야 한다는 사실을 계산으로 확인하면서 맞닥뜨린 가장 어려운 문제는 연간 1PB의 데이터를 저장, 분석하기 위한 컴퓨팅 시스템이 당시 기술로서는 달성하기 어려운 수준의 확장성(scalability)을 요구한다는 것이었다.

2018년부터 2020년에 고광도(high-luminosity) LHC 업그레이드를 위해 삽입가속기(injector)와 기반 시설을 업그레이드하게 되면 연간 현재 연산 생산되는 데이터의 30배 가까이 되는 743페타바이트, 2023년부터 2025년까지 고광도(high-luminosity) LHC 업그레이드를 진행하고 나면 2028년경에는 지금 생산되는 데이터의 3,000배인 약 3.7엑사바이트의 데이터가 생성될 것으로 예측된다. 이러한 데이터 증가량을 따라잡기 위해서는 LHC 빅데이터를 처리하는 시스템은 초기 설계부터 높은 확장성을 유지할 수 있는 아키텍처로 설계돼야 했다.

당시 컴퓨팅 기술은 무어의 법칙에 따라 프로세서의 성능이 1.5년에서 2년마다 2배가 되면서 급격한 발전을 거듭하고 있었기 때문에, LHC 실험을 시작할 즈음인 2008년경에는 1992년보다는 훨씬 더 좋은 성능의 컴퓨터를 사용할 수 있으리라는 사실은 분명했다. 하지만 그렇다고 해도, 한 대의 서버로는 저장할 수도, 계산할 수도 없는 양의 데이터라는 것은 분명했다. 무엇보다도 1992년 당시에는, 요즘은 보편화된 베오울프 클러스터 컴퓨팅 기술이 개발되기 전이었기 때문에 1PB의 데이터를 저장하고 처리하는 슈퍼컴퓨터 기술을 개발한다는 것은 요원해 보였다.

다행히도 위의 CERN 데이터 분석 컴퓨팅의 요구사항이 그리드 컴퓨팅 기술이 등장하면서 해결될 가능성이 보이기 시작했다.

그리드 컴퓨팅 기술은 1998년 당시 미국 아르곤 국립 연구소(Argonne National Laboratory)와 시카고 대학에서 일하던 이안 포스터(Ian Foster) 박사와 남가주 대학(University of Southern California)에서 일하던 칼 케셀만(Carl Kesselman) 박사가 “그리드 컴퓨팅 – 새로운 컴퓨팅 인프라의 청사진(The Grid: Blueprint for a New Computing Infrastructure)”이라는 유명한 책을 내면서 비로소 개념적으로 정립이 되기 시작했다. 그리드 컴퓨팅에 대한 자세한 소개는 앞으로 연재를 진행하면서 자세히 하기로 한다.

전기를 공급하는 파워 그리드와 같이 컴퓨팅 자원을 필요할 때 전기 플러그를 꽂아 전기를 쓰듯이 공급하자는 개념이 바로 그리드 컴퓨팅이었다. 사실 그리드 컴퓨팅은 1961년에 제안된 유틸리티 컴퓨팅, 1992년에 찰리 카트렛(Charlie Catlett)과 래리 스마(Larry Smarm) 박사에 의해 제안된 메타컴퓨팅, IBM에 의해 제안된 자율컴퓨팅(Autonomous Computing) 등의 다양한 컴퓨팅 개념의 영향을 받아 만들어진 개념이었다.


그림 1. (왼쪽 위) 그리드 컴퓨팅과 Globus 프로젝트의 창시자 이안 포스터 박사. (왼쪽 중간) 그리드 컴퓨팅과 Globus 프로젝트의 공동 창시자 칼 케셀만 박사. (왼쪽 아래) 이안 포스터 박사와 칼 케셀만 박사가 지은 “그리드 컴퓨팅 – 새로운 컴퓨팅 인프라의 청사진(The Grid: Blueprint for a New Computing Infrastructure)” 책. 그리드 컴퓨팅의 개념을 정립하고 세계적으로 주목을 받았다. (오른 쪽) 그리드 컴퓨팅 기술을 미들웨어로 구현한 Globus Toolkit 소프트웨어의 구성. (그림 소스: (왼쪽 위) https://www.ci.uchicago.edu/profile/191 (왼쪽 중간) https://www.isi.edu/~carl/ (왼쪽 아래) https://goo.gl/s5NVGH (오른쪽) http://toolkit.globus.org/toolkit/about.html )

그리드 컴퓨팅 기술이 이안 포스터 박사와 칼 케셀만 박사에 의해 주도되어 개발된 Globus 미들웨어를 통해 가시화되면서 CERN의 과학자들은 이들의 그리드 컴퓨팅 기술과 개념을 LHC 실험 데이터 분석에 활용하기 있는 방법을 모색하기 시작하였다. 당시 초기 Globus 미들웨어는 CPU와 같은 계산 자원을 통합하는 데에 집중하고 있었기 때문에, Globus 미들웨어만으로는 LHC 실험의 요구사항을 모두 충족할 수 없었다. 특히 저장 장치와 데이터 전송에 대한 요구사항을 Globus 미들웨어가 적절하게 충족시키지 못했기 때문에 Globus 미들웨어를 코어로 하고, LHC 실험의 요구 사항을 위한 추가의 미들웨어 기술을 개발하는 LHC 컴퓨팅 그리드(LHC Computing Grid; 이하 LCG) 프로젝트를 출범시키게 된다.

전 지구적인 계산 자원을 Globus 미들웨어로 통합하기 위한 LHC 연구원들의 노력은 많은 어려움에 부딪히게 된다. 그 중에서 가장 어려운 문제는 전세계에 퍼져 있는 컴퓨팅 자원들의 극단적인 이종성(heterogeneity) 문제다. 이런 계산 자원의 극단적인 이종성 문제는, 단순히 컴퓨팅 자원을 제공하는 데이터센터에서 사용하는 하드웨어 기종의 차이뿐만이 아니라, 각 데이터센터의 보안 정책, 노드 별로 설치되어 운영되는 운영체제와 소프트웨어의 차이와 같은 다양한 수준과 영역에 걸쳐서 일어났다. 아무리 Globus 미들웨어에서 표준 인터페이스를 정의해 미들웨어 수준의 상호작용을 표준화한다고 해도, 이러한 표준 인터페이스를 구현하기 위한 수준에서의 이종성이 너무 다양해서 모든 경우를 다 살펴 포용하기가 매우 어려웠다.


그림 2. 미국의 그리드 사이트와 유럽의 그리드 사이트간에 데이터가 교환되고 있는 모습을 표현한 WLCG 대시보드 모니터링. (Google Earth로 가시화함. http://wlcg.web.cern.ch/wlcg-google-earth-dashboard)

2017.09.25

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

김진철 | CIO KR
클라우드 컴퓨팅의 서막 – CERN은 왜 클라우드 컴퓨팅이 필요했나?
LHC 실험과 인공지능 기술에 대한 내용을 더 다루기 전에, 독자들의 이해를 더 쉽게 돕기 위해 클라우드 컴퓨팅과 LHC 실험과의 관계를 살펴보고 지나가려 한다. 오늘은 CERN에서 어떻게 클라우드 컴퓨팅이 시작되었는지 같이 살펴보도록 하자.

흔히 많은 클라우드 컴퓨팅은 구글이 제일 먼저 시작했다고 알고 있다. 이 말은 반은 맞고, 반은 틀리다. 클라우드 컴퓨팅의 기반이 되는 기술은 사실 구글이 클라우드 컴퓨팅이라는 말을 사용하기 전에 이미 CERN과 IBM 등의 회사들을 통해서 많이 개발되어 있었기 때문에 반은 틀린 말이라는 것이고, 클라우드 컴퓨팅이라는 용어가 처음 생겨나서 업계에 자리 잡게끔 한 것이 구글이기 때문에 반은 맞는 사실이다. 클라우드 컴퓨팅이라는 말이 처음 나왔을 때는 그 의미가 명확하지 않아서, 오라클의 회장 래리 엘리슨은 클라우드 컴퓨팅이 무엇인지 잘 모르겠다고 혹독한 비판을 하기도 했다[2-7].

1992년 CERN의 과학자들은 LHC 가속기와 네 개의 검출기의 개념 설계를 진행하면서 연간 약 1PB의 데이터가 생성될 것임을 알게 된 후, 과연 이 빅데이터를 어떻게 분석할 것인지 고민하기 시작했다. 검출기 데이터 처리를 자동화하기 위해 Level-1 트리거와 고수준 트리거(high-level trigger)에서 데이터 처리를 자동화하는 분산컴퓨팅 시스템을 만드는 것과는 별개로, 효과적인 데이터 분석을 하기 위해서는 또 다른 기술적인 난관을 해결해야 했다.

먼저, 분석하게 될 물리학자들이 CERN에 모두 모여 있지 않다는 것이다. LHC 데이터 분석을 수행할 물리학자들은 전 세계의 다양한 연구소에 소속되어 본인들이 소속된 연구기관에서 분석을 수행하게 될 것이었다. 이렇게 전 세계에 걸쳐 일하는 사람들이 어떻게 LHC 데이터를 전송받고, 전송받은 데이터를 분석하기 위한 막대한 양의 계산을 할 수 있도록 컴퓨팅 시스템을 만들어야 할 것인가?

두 번째 문제는 1PB의 데이터를 이용해 힉스 입자와 같은 중요한 물리학적 이벤트를 찾아내기 위한 분석을 하는 작업의 양이 당시의 수퍼컴퓨터로 할 수 있는 계산의 양을 훨씬 더 크게 뛰어넘었다는 것이다. 또한 당시의 서버 기술로는 CERN 데이터센터에 계산 서버를 꽉 채워도 LHC 데이터 분석을 위한 계산을 하기에는 역부족이었다. LHC 데이터 분석을 위한 계산 자원을 확보하기 위해서는 여러 개의 데이터센터에 걸친 계산 자원들이 하나의 단일한 계산 자원같이 인식되도록 하여 계산할 수 있도록 하는, 아주 극단적인 이종환경에서의 고성능 컴퓨팅을 지원하는 분산컴퓨팅 기술이 필요했다. 과연 이렇게 어려운 분산컴퓨팅 소프트웨어 기술을 LHC 실험이 시작되기 전까지 만들 수 있을 것인가?

마지막 세 번째로, LHC 실험이 아주 오랜 기간에 걸쳐서 준비되고, 단계별로 업그레이드되면서 생성되는 데이터의 양이 점차 증가한다는 것이었다. 2008년 LHC와 네 개의 검출기가 시운전을 시작하기 전에 LHC 연구원들은 1990년대부터 실험을 준비했으니 거의 20년에 걸쳐 실험을 준비한 셈이다. LHC의 개념 설계를 준비하였던 CERN의 과학자들이 그 당시 기술로는 상상도 할 수 없을 만큼 큰 데이터양인 연간 1PB의 데이터를 저장하고 분석해야 한다는 사실을 계산으로 확인하면서 맞닥뜨린 가장 어려운 문제는 연간 1PB의 데이터를 저장, 분석하기 위한 컴퓨팅 시스템이 당시 기술로서는 달성하기 어려운 수준의 확장성(scalability)을 요구한다는 것이었다.

2018년부터 2020년에 고광도(high-luminosity) LHC 업그레이드를 위해 삽입가속기(injector)와 기반 시설을 업그레이드하게 되면 연간 현재 연산 생산되는 데이터의 30배 가까이 되는 743페타바이트, 2023년부터 2025년까지 고광도(high-luminosity) LHC 업그레이드를 진행하고 나면 2028년경에는 지금 생산되는 데이터의 3,000배인 약 3.7엑사바이트의 데이터가 생성될 것으로 예측된다. 이러한 데이터 증가량을 따라잡기 위해서는 LHC 빅데이터를 처리하는 시스템은 초기 설계부터 높은 확장성을 유지할 수 있는 아키텍처로 설계돼야 했다.

당시 컴퓨팅 기술은 무어의 법칙에 따라 프로세서의 성능이 1.5년에서 2년마다 2배가 되면서 급격한 발전을 거듭하고 있었기 때문에, LHC 실험을 시작할 즈음인 2008년경에는 1992년보다는 훨씬 더 좋은 성능의 컴퓨터를 사용할 수 있으리라는 사실은 분명했다. 하지만 그렇다고 해도, 한 대의 서버로는 저장할 수도, 계산할 수도 없는 양의 데이터라는 것은 분명했다. 무엇보다도 1992년 당시에는, 요즘은 보편화된 베오울프 클러스터 컴퓨팅 기술이 개발되기 전이었기 때문에 1PB의 데이터를 저장하고 처리하는 슈퍼컴퓨터 기술을 개발한다는 것은 요원해 보였다.

다행히도 위의 CERN 데이터 분석 컴퓨팅의 요구사항이 그리드 컴퓨팅 기술이 등장하면서 해결될 가능성이 보이기 시작했다.

그리드 컴퓨팅 기술은 1998년 당시 미국 아르곤 국립 연구소(Argonne National Laboratory)와 시카고 대학에서 일하던 이안 포스터(Ian Foster) 박사와 남가주 대학(University of Southern California)에서 일하던 칼 케셀만(Carl Kesselman) 박사가 “그리드 컴퓨팅 – 새로운 컴퓨팅 인프라의 청사진(The Grid: Blueprint for a New Computing Infrastructure)”이라는 유명한 책을 내면서 비로소 개념적으로 정립이 되기 시작했다. 그리드 컴퓨팅에 대한 자세한 소개는 앞으로 연재를 진행하면서 자세히 하기로 한다.

전기를 공급하는 파워 그리드와 같이 컴퓨팅 자원을 필요할 때 전기 플러그를 꽂아 전기를 쓰듯이 공급하자는 개념이 바로 그리드 컴퓨팅이었다. 사실 그리드 컴퓨팅은 1961년에 제안된 유틸리티 컴퓨팅, 1992년에 찰리 카트렛(Charlie Catlett)과 래리 스마(Larry Smarm) 박사에 의해 제안된 메타컴퓨팅, IBM에 의해 제안된 자율컴퓨팅(Autonomous Computing) 등의 다양한 컴퓨팅 개념의 영향을 받아 만들어진 개념이었다.


그림 1. (왼쪽 위) 그리드 컴퓨팅과 Globus 프로젝트의 창시자 이안 포스터 박사. (왼쪽 중간) 그리드 컴퓨팅과 Globus 프로젝트의 공동 창시자 칼 케셀만 박사. (왼쪽 아래) 이안 포스터 박사와 칼 케셀만 박사가 지은 “그리드 컴퓨팅 – 새로운 컴퓨팅 인프라의 청사진(The Grid: Blueprint for a New Computing Infrastructure)” 책. 그리드 컴퓨팅의 개념을 정립하고 세계적으로 주목을 받았다. (오른 쪽) 그리드 컴퓨팅 기술을 미들웨어로 구현한 Globus Toolkit 소프트웨어의 구성. (그림 소스: (왼쪽 위) https://www.ci.uchicago.edu/profile/191 (왼쪽 중간) https://www.isi.edu/~carl/ (왼쪽 아래) https://goo.gl/s5NVGH (오른쪽) http://toolkit.globus.org/toolkit/about.html )

그리드 컴퓨팅 기술이 이안 포스터 박사와 칼 케셀만 박사에 의해 주도되어 개발된 Globus 미들웨어를 통해 가시화되면서 CERN의 과학자들은 이들의 그리드 컴퓨팅 기술과 개념을 LHC 실험 데이터 분석에 활용하기 있는 방법을 모색하기 시작하였다. 당시 초기 Globus 미들웨어는 CPU와 같은 계산 자원을 통합하는 데에 집중하고 있었기 때문에, Globus 미들웨어만으로는 LHC 실험의 요구사항을 모두 충족할 수 없었다. 특히 저장 장치와 데이터 전송에 대한 요구사항을 Globus 미들웨어가 적절하게 충족시키지 못했기 때문에 Globus 미들웨어를 코어로 하고, LHC 실험의 요구 사항을 위한 추가의 미들웨어 기술을 개발하는 LHC 컴퓨팅 그리드(LHC Computing Grid; 이하 LCG) 프로젝트를 출범시키게 된다.

전 지구적인 계산 자원을 Globus 미들웨어로 통합하기 위한 LHC 연구원들의 노력은 많은 어려움에 부딪히게 된다. 그 중에서 가장 어려운 문제는 전세계에 퍼져 있는 컴퓨팅 자원들의 극단적인 이종성(heterogeneity) 문제다. 이런 계산 자원의 극단적인 이종성 문제는, 단순히 컴퓨팅 자원을 제공하는 데이터센터에서 사용하는 하드웨어 기종의 차이뿐만이 아니라, 각 데이터센터의 보안 정책, 노드 별로 설치되어 운영되는 운영체제와 소프트웨어의 차이와 같은 다양한 수준과 영역에 걸쳐서 일어났다. 아무리 Globus 미들웨어에서 표준 인터페이스를 정의해 미들웨어 수준의 상호작용을 표준화한다고 해도, 이러한 표준 인터페이스를 구현하기 위한 수준에서의 이종성이 너무 다양해서 모든 경우를 다 살펴 포용하기가 매우 어려웠다.


그림 2. 미국의 그리드 사이트와 유럽의 그리드 사이트간에 데이터가 교환되고 있는 모습을 표현한 WLCG 대시보드 모니터링. (Google Earth로 가시화함. http://wlcg.web.cern.ch/wlcg-google-earth-dashboard)

X