김진철의 How-to-Big Data | 빅데이터의 미래 (4)

사이버 물리 시스템을 위한 클라우드 컴퓨팅의 기술적인 요건으로서 멀티-클라우드 간 계층적 자원 조율 및 관리, 공용 클라우드(public cloud)와 사설 클라우드(private cloud)에 배치된 사이버 물리 시스템 서비스 간 자원 조율 및 관리를 위한 신뢰성 있는 하이브리드 클라우드 기술, 멀티-클라우드 및 다양한 이종(heterogeneous) 컴퓨팅 자원 간 기능 연동 과정에서 보안이 충분히 보장되면서 자원 활용과 관리를 분리할 수 있는 멀티테넌시(multi-tenancy) 지원 문제가 해결되어야 한다고 소개하였다. 사이버 물리 시스템의 사이버 자원 관리 및 조율을 위해 클라우드 컴퓨팅 시스템 자체가 사이버 물리 시스템화 되어가면서 인공지능 기술과 빅데이터를 활용한 지능형 제어의 개념이 들어오기 시작했다고 또 소개한 바 있다.

사이버 물리 시스템을 위한 미션-크리티컬한 클라우드 컴퓨팅 시스템이 발전해야 할 큰 방향으로 소개했던 위 네 가지 이슈 외에 최근 클라우드 컴퓨팅과 분산 컴퓨팅 기술 발전의 동향이 사이버 물리 시스템을 위한 클라우드 컴퓨팅 발전과 가지는 관련성을 이번 글에서 좀더 얘기해보고자 한다.
 

먼저 앞서 얘기하였던 멀티-클라우드 간, 이종 자원(heterogeneous resources) 간의 상호운용성(interoperability) 확보를 위한 표준과 인터페이스 정의 문제가 중요해지고 있다.

이런 멀티-클라우드 간, 이종 자원 간 상호연동성 문제는 그리드 컴퓨팅 기술 시절부터 논의되었던 문제이지만 아직도 분명한 해결책이 보이지 않는 문제이다. 클라우드 컴퓨팅 기술이 등장하기 전에 그리드 컴퓨팅 기술이 발전할 때에도 그리드 컴퓨팅 서비스를 제공하는 기관의 컴퓨팅 자원 관리 정책 및 환경의 차이, 그리드 컴퓨팅 미들웨어 간 인터페이스와 세부 기술의 차이로 인해 그리드 컴퓨팅 자원 간 상호호환되지 않아 다양한 기술적인 문제를 발생시켰다.

그리드 컴퓨팅 발전 당시에는 이런 문제를 “글로벌 그리드 포럼(Global Grid Forum; GGF, 현재 오픈 그리드 포럼(Open Grid Forum))”이라는 비영리 표준화 단체를 통해 해결하려고 하였고, 이를 통해 OGSA(Open Grid Services Architecture), JDSL(Job Submission Description language), DRMAA(Distributed Resource Management Application API) 등의 유명한 표준을 만들기도 하였다.

그리드 컴퓨팅 서비스들이 이런 표준을 통해 상호연동성을 높이는 것을 권고하는 한편, 그리드 미들웨어를 만들던 다양한 연구 기관들과 그리드 미들웨어를 상용화하려던 기업들은 자신들의 기술이 산업 표준이 되도록 영향력을 높이는 활동을 하거나, 아예 이해관계가 맞는 기관들끼리 컨소시엄을 이루어 표준 미들웨어를 만들고 컨소시엄이 공동 활용하는 방식으로 대응하기도 하였다. 이렇게 산업 표준 미들웨어로서 발전한 것이 그리드 컴퓨팅의 아버지인 이안 포스터 교수와 칼 케셀만 교수 연구팀이 만든 Globus 미들웨어이다. 컨소시엄을 이루어 표준 미들웨어를 만들고 발전시키려 했던 시도가, 필자가 LHC 컴퓨팅 그리드 사례에서도 자세히 소개했던 것과 같이 범유럽 그리드 컴퓨팅 인프라와 서비스를 만든 EGEE 프로젝트에서 공동 개발된 EGEE 그리드 미들웨어이다[2-7].

Globus 그리드 미들웨어는 그리드 컴퓨팅 발전 초반부터 그리드 컴퓨팅의 개념을 확립, 발전시키고 산업계에 안착시키는데 중요한 역할을 한 표준 미들웨어로서 사실상 산업 표준 그리드 미들웨어로 자리를 잡았다. Globus 그리드 미들웨어는 아직도 EGI 그리드 미들웨어를 비롯한 그리드 컴퓨팅 미들웨어의 핵심 구성 요소로 여전히 활용되고 있다.

EGEE 프로젝트의 결과물이 지속 가능하게 유지 보수되면서 활용될 수 있도록 하기 위해 EGEE 프로젝트 후에 설립된 “유럽 그리드 인프라스트럭처 재단(The EGI(European Grid Infrastructure) Foundation)” 국제기구는 EGEE 프로젝트에 참여하여 그리드 컴퓨팅 미들웨어를 만든 유럽 각 국가와 주요 연구기관이 주축이 되어 설립한 국제기구이다. “EGI 재단(The EGI Foundation)”은 EGEE 그리드 미들웨어와 범유럽 그리드 인프라스트럭처(European Grid Infrastructure)를 지속적으로 사용할 수 있게 유지보수, 발전시킬 수 있도록 EGEE 프로젝트를 위해 결성된 EGEE 그리드 미들웨어 컨소시엄이 확장, 발전된 조직이다.

EGI에서 개발, 유지보수하고 있는 EGI 그리드 미들웨어는 범유럽 그리드 컴퓨팅 인프라 서비스를 제공, 지탱하는데 아직 활용되고 있으며 그리드 컴퓨팅 기술이 실험실 기술이 아니라 유럽 사회의 실질적인 과학기술 빅데이터 문제를 해결하는 기술이 되도록 하는 데 큰 역할을 하고 있다.

위에서 언급한 Globus 미들웨어, EGEE 또는 EGI 그리드 미들웨어가 완성되기 전에는 Globus 미들웨어를 중심으로 한 몇 가지 그리드 컴퓨팅 미들웨어와 이들을 이용한 주요 그리드 컴퓨팅 서비스들이 경쟁하고 있었다. 서로 다른 그리드 컴퓨팅 서비스 간 서비스 상호연동성을 보장하기 위한 인터페이스가 “오픈 그리드 포럼(Open Grid Forum)”에서 논의되기도 하였는데 이런 노력의 결과로 “SAGA(Simple API for Grid Applications)”라는 상호연동성 표준이 제안, 채택되기도 하였다[8-17].

위와 같이 LHC 빅데이터 해결 과정에서 그리드 컴퓨팅 인프라의 상호연동성 문제가 이슈가 되었던 것과 같이 앞으로 사이버 물리 시스템의 빅데이터 처리를 위해 사용되는 다양한 클라우드 컴퓨팅 인프라 간 상호연동성 문제의 해결책을 찾는 일이 중요하게 부각될 수밖에 없다. 이런 클라우드 컴퓨팅 서비스 및 인프라 간 상호연동성을 보장할 수 있는 기술과 표준을 논의하는 과정에서 클라우드 컴퓨팅 시장에 또 하나의 비즈니스 기회가 열릴 것으로 필자는 전망한다.

오픈소스 클라우드 컴퓨팅 기술을 개발하고 전파하는 “오픈스택 재단(The OpenStack Foundation)”은 과거 “오픈 그리드 포럼(Open Grid Forum)”의 역할 Globus 미들웨어를 개발한 “Globus 얼라이언스(The Globus Alliance)”와 EGI 미들웨어를 개발하는 EGI의 역할을 겸하는 역할을 하고 있다.

“오픈 그리드 포럼(Open Grid Forum)”은 그리드 컴퓨팅 인터페이스와 아키텍처 표준을 정하고 “오픈 그리드 포럼(Open Grid Forum)”에 참여하는 다양한 이해관계자 간 표준에 대한 합의를 유도하고 이를 문서화하는 데 집중했다면, “오픈스택 재단(The OpenStack Foundation)”은 클라우드 컴퓨팅을 위한 API와 인터페이스를 “오픈스택 재단(The OpenStack Foundation)”을 후원하고 오픈스택(OpenStack) 소프트웨어 개발에 참여하는 다양한 참여기업과 소프트웨어 엔지니어들을 통해 합의하고 이를 실질적인 소프트웨어로 구현하는 역할까지 맡고 있다.

“오픈스택 재단(The OpenStack Foundation)”이 “오픈스택(OpenStack)” 개발에 참여한 기업들과 소프트웨어 엔지니어들과 함께 지금까지 정의하고 구현한 “오픈스택(OpenStack)” API와 아키텍처는 클라우드 컴퓨팅 소프트웨어의 사실상 표준으로서 역할을 하고 있다. 물론 클라우드 컴퓨팅의 강자인 “아마존 웹 서비스(Amazon Web Services; AWS)”와 마이크로소프트 “애저(Azure)”가 시장을 장악하고 있고, 이에 비해 “오픈스택(OpenStack)”으로 공용 클라우드(public cloud) 서비스를 제공하는 “랙스페이스(Rackspace)”와 같은 회사들이 시장 점유율이 많이 낮기는 하지만, 그렇다고 해서 클라우드 컴퓨팅의 산업 표준이 된 “오픈스택(OpenStack)” API의 가치가 낮아지는 것은 아니다.

“오픈스택(OpenStack)” API와 소프트웨어의 가치는 최근 5G 이동통신의 “네트워크 기능 가상화(Network Function Virtualization; NFV)” 표준 정의와 구현, 테스트에 “오픈스택(OpenStack)”이 전면적으로 도입되어 활용되고 있는 것을 보면 할 수 있다. 5G 이동통신의 “소프트웨어 정의 네트워크(Software-Defined Network; SDN)”과 “네트워크 기능 가상화(Network Function Virtualization; NFV)” 개념이 형성되는 데에 “오픈스택(OpenStack)”이 큰 역할을 하였을 뿐만 아니라 이 개념을 개발, 테스트하고 실증하는 데에도 “오픈스택(OpenStack)”이 많이 쓰이고 있어 클라우드 컴퓨팅 기술을 활용한 새로운 5G 네트워크 기술을 개발하고 테스트하는 표준 플랫폼으로도 “오픈스택(OpenStack)”이 활용되고 있다.

이렇게 클라우드 컴퓨팅 기술을 기반으로 한 새로운 IT 기술을 개발하고 테스트하는 환경으로 “오픈스택(OpenStack)”의 역할이 확대되어 가면서, “오픈스택(OpenStack)”은 클라우드 컴퓨팅을 이용한 인프라와 서비스 간 상호운용성(interoperability)을 제공할 수 있는 표준 인터페이스의 역할을 할 수 있을 것으로 보인다.

또 하나 상호운용성(interoperability)과 관련해서 살펴보아야 할 점은 시장을 장악하고 있는 아마존 웹 서비스와 마이크로소프트 애저, 그리고 구글 클라우드와 같은 주요 공용 클라우드 서비스 업자들이 정의한 클라우드 서비스 API가 클라우드 상호운용성의 또 하나의 기준으로 활용될 수 있다는 것이다.

실례로 오픈소스 파일 시스템이나 클라우드 파일 저장 서비스에서 지원하는 인터페이스로 아마존 웹 서비스의 S3 저장소 서비스 인터페이스 지원이 유행처럼 번진 적이 있었고, 현재도 아마존 웹 서비스의 S3 저장소 API는 클라우드 파일 저장소 접근의 표준처럼 타 파일 저장소 서비스에서도 많이 지원되고 있다.

이와 같이 아마존 웹 서비스, 마이크로소프트 애저, 구글 클라우드의 주요 3대 공용 클라우드 서비스 업체들의 클라우드 컴퓨팅 API가 또 하나의 산업 표준과 상호운용성(interoperability) 지원의 기준으로 활용될 것으로 보인다.

최근 아마존 웹 서비스에서 내놓은 “아웃포스트(Outposts)”와 마이크로소프트의 “애저스택(Azure Stack)”은 아마존 웹 서비스 공용 클라우드와 마이크로소프트 애저 공용 클라우드 서비스를 이용하는 고객들이 아마존 웹 서비스, 애저의 인터페이스와 상호 호환되는 사설 클라우드 컴퓨팅 시스템을 빠르고 손쉽게 자사에 구축할 수 있도록 해주는 소프트웨어들이다. 이런 식으로 주요 공용 클라우드 컴퓨팅 서비스의 API와 아키텍처, 주요 구성 요소들이 사설 클라우드의 영역까지 진입하면서 이들 업체들의 클라우드 컴퓨팅 서비스 API와 기술들이 또 하나의 산업 표준과 상호운용성의 기준으로서 역할을 할 것으로 보인다.

사이버 물리 시스템의 일부분을 구성하는 일부 서비스들을 제공하는 기업들이 서로 다른 공용 클라우드 컴퓨팅 서비스와 사설 클라우드 컴퓨팅 소프트웨어 스택을 활용할 경우, 이렇게 서로 다른 클라우드 컴퓨팅 기술과 서비스들을 통합하여 새로운 사이버 물리 시스템으로 통합하는 기업은 복수의 클라우드 컴퓨팅 서비스들과 소프트웨어 간 상호운용성을 지원하는 클라우드 컴퓨팅 인터페이스 표준과 상호연동 기술이 필요하다. 사이버 물리 시스템의 요구 사항을 만족하고 신뢰성을 높이기 위해서는 단순히 서비스만 메시업(mesh-up)해서 되는 것이 아니라 서비스 간 자원 관리까지 같이 연동, 통합하여야 하기 때문이다.

위에서 언급한 복수의 클라우드 컴퓨팅 서비스를 활용한 사이버 물리 시스템이 어떤 모습인지를 상상해보려면 최근 붐이 일고 있는 인공지능 및 기계 학습 클라우드 API를 활용한 인지 사이버 물리 시스템 구성에 대해서 생각해보면 된다. 최근 컴퓨터 비전 및 시각 인공지능, 음성 인식 및 자연어 처리와 같은 인공지능 기능을 제공하는 클라우드 API에 공용 클라우드 컴퓨팅 기업들이 경쟁적으로 나서고 있어 점점 제공되는 API의 종류와 형태가 비슷해 지고 있기는 하지만, 각 기업이 보유한 인공지능 기술의 수준과 범위에 따라 API의 구성과 형식이 다를 수밖에 없다.

사이버 물리 시스템에서 제공하려는 서비스에 필요한 멀티 모달 인지(multi-modal perception) 및 지능형 데이터 처리를 위해 한 기업의 인공지능 클라우드 API가 모든 요구 사항을 만족시키지 못할 경우 어쩔 수 없이 복수의 클라우드 컴퓨팅 서비스를 이용해야 한다. 예를 들면 구글의 일반적인 컴퓨터 비전 및 시각 인지(visual perception), 음성 인식 및 자연어 처리 API가 아마존 웹 서비스와 마이크로소프트 애저보다 낫다는 평가를 받기 때문에 이들 API를 써서 주요 지능형 데이터 처리를 구현하더라도 아마존의 상품 검색이나 전자상거래와 연동된 서비스를 제공하려는 기업은 구글의 음성 인식 서비스 API보다는 아마존 웹 서비스에서 제공하는 알렉사 음성 인식 API를 활용하는 것이 나을 것이다.

인공지능 API분야에서 앞서가는 구글 클라우드이지만, 일반적인 가상 머신과 IT 인프라에 관련된 클라우드 컴퓨팅 서비스는 아직 아마존 웹 서비스에 뒤지는 것으로 평가받는다. 이런 경우, 인공지능 API는 구글 것을 쓰더라도 인공지능 API를 사용한 지능형 데이터 처리 후에 미션 크리티컬한 서비스 메시업과 주요 미들웨어 스택을 운영하는 용도로는 아마존 웹 서비스를 이용하는 것이 나을 수 있다. 구글의 인공지능 API를 활용하기 위해 데이터 처리에 관련된 가상 인프라 자원 일부는 구글 클라우드의 자원을 활용하더라도 서비스 인프라를 위한 주요 클라우드 컴퓨팅 자원은 아마존 웹 서비스상의 자원을 활용해야 하는 경우, 구글 클라우드 서비스와 아마존 웹 서비스의 클라우드 컴퓨팅 자원 관리 기능과 서비스가 상호 연동되어 하나의 흠 없는(seamless) 사이버 물리 시스템 서비스로 통합되도록 하는 기술이나 인터페이스가 필요하게 된다.
 

이와 같이 각 공용 클라우드 컴퓨팅 회사에서 제공하는 서비스의 종류와 수준 차이로 인해, 이들을 통합하여 새로운 종류의 사이버 물리 시스템 서비스를 제공하려는 기업은 클라우드 컴퓨팅 서비스와 인프라 간 상호운용성을 고려하지 않을 수 없게 된다. 현재 클라우드 컴퓨팅 기술과 시장을 주도하는 “오픈스택(OpenStack)”과 아마존 웹 서비스, 마이크로소프트 애저, 구글 클라우드를 중심으로 클라우드 상호운용성 표준에 클라우드 컴퓨팅 업계가 조금씩 합의를 이루어 나갈 것으로 보인다. 이런 상호운영성을 보장하는 기술과 노하우를 중심으로 사이버 물리 시스템 통합 서비스를 제공하는 기업들의 비즈니스 기회도 새롭게 창출될 것으로 보인다.

사이버 물리 시스템과 가상화 기술 – 가상 머신 VS. 컨테이너
두번째로 생각해 봐야 할 사이버 물리 시스템과 관련된 클라우드 컴퓨팅 기술 요소는 가상 머신, 컨테이너 기술과 같은 가상화 기술과 이들 자원의 관리에 관한 것이다.

클라우드 컴퓨팅에서 IT 자원을 가상화하는 기술로 가상 머신이 좋으냐, 컨테이너(container), 정확하게는 리눅스 컨테이너(Linux container)가 좋으냐 하는 문제는 클라우드 컴퓨팅이 “오픈스택(OpenStack)” 기술의 발전에 힘입어 빠르게 발전하던 2014년부터 2016년까지 클라우드 컴퓨팅 업계에서 큰 화두였다[30-37]. 가상 머신이 클라우드 컴퓨팅이라는 개념이 실현될 수 있도록 큰 공헌을 하기는 했지만, 컨테이너에 비해 무겁고 관리가 어려운 점 때문에 최근 클라우드 컴퓨팅에서는 구글이 만든 “쿠버네티스(Kubernetes)”를 중심으로 컨테이너 기술이 빠르게 확산되었다[30-31, 36].

가상 머신보다 가벼운 컨테이너가 일반 사용자들에게는 쓸모가 많기 때문에 최근에는 컨테이너를 이용한 응용 프로그램과 운용, 개발 환경의 배포와 관리가 확산되는 추세지만[30-31, 36], 보안과 하드웨어 자원의 멀티테넌시(multi-tenancy) 지원과 같은 문제 때문에 가상 머신 또한 여전히 클라우드 컴퓨팅의 핵심 기술로 자리 잡고 있다. 컨테이너 기술은 가상 머신에서도 활용할 수 있기 때문에 가상 머신으로 제공된 IT 인프라 자원에서 응용 프로그램과 운영, 개발 환경 수준의 멀티테넌시(multi-tenancy)를 다시 제공하는 용도로도 활용된다.

가상 머신과 컨테이너 중에서 어떤 것을 선택해야 하는지 문제는 이제 더 이상 의미가 없어지는 듯 보이며, 가상 머신을 이용한 가상화와 IT 자원 관리가 적합한 수준에서는 가상 머신을 활용하고, 컨테이너를 이용한 응용 프로그램의 배포∙관리가 더 중요한 분야에서는 컨테이너를 활용하는 식으로 두 기술의 구현 계층과 특성에 맞게 사용하는 것에 클라우드 컴퓨팅 업계가 점차 합의를 보는 듯하다[32-35, 37]. 컨테이너 기술의 등장과 가상 머신과 컨테이너 기술의 대결을 통해 클라우드 컴퓨팅에 필요한 가상화 기술이 좀더 섬세하게 기술적인 진보가 이루어지게 된 것은 긍정적이다.

최근에는 하이퍼바이저 기반 가상 머신이 가진 멀티테넌시(multi-tenancy) 보안성과 자원 격리(isolation)의 장점을 살리면서, 컨테이너의 경량성을 제공할 수 있도록 하는 경량 하이퍼바이저 기술이 한창 주목을 받으며 개발되고 있다. 오픈스택을 만든 오픈스택 재단이, 리눅스 재단이 클라우드 컴퓨팅 및 가상화 주요 기업과 커뮤니티와 함께 공동으로 결성한 “오픈 컨테이너 이니셔티브(Open Container Initiative)” 활동의 하나로 오픈스택과는 별개의 트랙으로 관리되는 오픈소스 프로젝트인 “카타(Kata)” 컨테이너는 하이퍼바이저의 장점과 컨테이너의 장점을 모두 취한 최신 가상화 기술이다.

“카타(Kata)” 컨테이너는 도커(Docker)와 쿠버네티스(Kubernetes)와 같은 컨테이너 관리 환경에서 기존의 리눅스 컨테이너와 같이 실행, 관리될 수 있으면서 기존의 하이퍼바이저 기반 가상 머신에서 제공하는 자원 격리와 보안성을 제공할 수 있는 가벼운 하이퍼바이저이다. 이와 같이 컨테이너 기술과 하이퍼바이저 기술의 장점을 모두 살린 새로운 가상화 기술의 발전도, 앞서 설명한 하이퍼바이저와 컨테이너를 장점과 용도에 맞게 아키텍처 수준별로 사용하는 최근 흐름과 함께, 앞으로 클라우드 컴퓨팅 기술의 발전에 중요한 흐름이 될 것으로 보인다.

사이버 물리 시스템에서 활용되는 컨테이너 기술과 가상 머신 기술은 클라우드 컴퓨팅의 가상화 기술과 비슷한 양상으로 발전하면서 사이버 물리 시스템 기술 발전에 영향을 미칠 것으로 보인다. 컨테이너 기술과 가상 머신 기술이 사이버 물리 시스템에서의 활용 방향에 대해서 잠깐 생각해보기로 하자.

가상 머신 기술은 사이버 물리 시스템에 필요한 사이버 자원의 분배와 관리, 보안에 여전히 중요한 역할을 할 것으로 기대되고 있다. 가상 머신 기술은 데이터 센터를 중심으로 제공되는 공용 클라우드 자원의 멀티테넌시(multi-tenancy)와 자원 관리를 가능하게 하는 기술을 넘어, 자동차와 같이 컴퓨팅 자원의 활용이 제한된 사이버 물리 시스템 환경에서 컴퓨팅 자원을 효과적으로 분배하고 관리하는데 활용되는 미션-크리티컬 가상화 기술로 발전하고 있다.

눈에 크게 띄지는 않고 있지만 최근 자동차 업계에서 조용하게 일어나고 있는 한 변화 중의 하나는, 자동차 ECU에서 가상 머신을 이용할 수 있도록 하는 실시간 시스템용 하이퍼바이저 기술이 점차 도입되고 있는 것이다. 자동차 업계에서 하이퍼바이저 기술을 활용하려고 하는 이유는 여러 가지가 있는데, 그중에서도 가장 중요한 이유 중의 하나는 컴퓨팅 자원 활용의 효율성을 높이는 것이다.

데이터센터와 달리 자동차와 같은 사이버 물리 시스템은 시스템 내 물리적인 공간이 제약되어 있기 때문에 많은 양의 사이버 요소, 즉 컴퓨팅 자원을 탑재하기가 어렵다. 특히, 자동차와 같이 생산 원가와 가격에 민감한 사이버 물리 시스템은 임베디드 컴퓨터 하나를 넣을 때마다 원가가 상승하기 때문에 제조사 입장에서는 가능하면 적은 수의 임베디드 컴퓨터나 컴퓨팅 장비를 탑재해서 최대한의 효과를 낼 수 있어야 한다.

이를 위해 각 임베디드 컴퓨터의 성능을 최대한으로 활용하면서 남는 컴퓨팅 자원이 없도록 효과적으로 컴퓨팅 자원을 활용해야 한다. 이 때문에, 하이퍼바이저와 같이 물리적인 컴퓨팅 자원을 다양한 워크로드와 작업이 나누어 사용할 수 있도록 하는 가상화 기술이 유용하게 쓰일 수 있다.

아직은 하이퍼바이저 기술이 미션 크리티컬한 시스템에 쓰일 만큼 신뢰성과 안정성 있는 기술로 여겨지지 않았고, 지금까지 가상화 기술과 클라우드 컴퓨팅 발전의 초반에는 “젠 하이퍼바이저(Xen hypervisor)”와 KVM과 같은 오픈소스 기술에 의존하였기 때문에 하이퍼바이저 기술이 미션 크리티컬한 시스템에서 쓰일 수 있으리라고 생각한 사람이 많지 않았다. 

이제는 가상화 기술과 클라우드 컴퓨팅 기술이 어느 정도 성숙했기 때문에 클라우드 컴퓨팅 기술을 미션 크리티컬한 시스템에도 사용하여 그 장점을 활용할 수 있도록 하는데 관심이 쏠리고 있다. 기존의 오픈소스 하이퍼바이저 기술인 “젠 하이퍼바이저(Xen hypervisor)”를 자동차와 같은 미션 크리티컬한 시스템에 적용할 수 있도록 임베디드 시스템용 하이퍼바이저 솔루션을 만드는 국내 스타트업인 “페르세우스(https://cyberperseus.com/)”와 같은 회사들도 생겨나고 있다.

미션 크리티컬한 시스템에 클라우드 컴퓨팅 기술을 적용해 보려는 최근 노력은 모바일 에지 컴퓨팅(Mobile Edge Computing; MEC)과 같은 영역에서도 나타나는데, 모바일 에지 컴퓨팅에 대한 얘기는 이후에 필자가 기고할 글에서 좀더 자세히 다루기로 한다.

컨테이너의 경우 미션 크리티컬한 사이버 물리 시스템을 구동하는 소프트웨어를 신뢰성 있고 안전하게 배포하고 관리하며 소프트웨어의 버그나 결함이 발견될 때마다 신속하고 신뢰성 있게 업데이트, 수정할 수 있도록 하여 사이버 물리 시스템 전체 시스템의 안전을 향상하는 데 활용이 가능하다.

컨테이너의 가장 큰 장점은 컨테이너 이미지를 원본 그대로 사용자에게 배포하여 실행시킬 수 있다는 점이다. 컨테이너 기술이 출현하기 전에는 소프트웨어를 설치, 업데이트하기 위해 소프트웨어를 배포하는 리파지토리에 소프트웨어를 설치하는 방법을 자동화한 스크립트와 설치 위치, 설정 파라미터와 같은 메타 데이터가 담긴 rpm이나 deb 등의 특정한 패키지 형식으로 소프트웨어를 패키징하여 저장, 보관해 놓고 이 패키지 형식의 소프트웨어를 다운로드, 설치하는 과정을 관리하는 설치 관리 소프트웨어를 이용해 설치, 업데이트하는 것이 일반적이었다. 현재 대부분의 운영체제에서 소프트웨어 설치, 관리에 이런 방법을 이용한다.

문제는 이렇게 소프트웨어를 설치하는 과정에서 소프트웨어를 설치하는 자동화 스크립트의 오류가 있거나, 소프트웨어가 설치되는 환경이 설치 스크립트를 작성할 때 가정했던 사항들이 충족되지 않고 문제가 있으면, 소프트웨어 설치가 실패하기 쉽다는 것이다. 설치가 온전하게 되지 않은 소프트웨어는 다시 해당 소프트웨어와 의존성이 있는 다른 소프트웨어를 설치할 때 문제가 되기 때문에, 소프트웨어 배포, 설치를 신뢰성 있게 관리하는 것은 사이버 요소의 영향을 많이 받는 사이버 물리 시스템의 안전성을 확보하기 위해서 중요한 문제이다.

컨테이너 기술은 사이버 물리 시스템 하드웨어에 배포, 설치되기 전까지 개발과 테스트를 진행한 실행 환경과 배포 구조가 동일하게 유지되어 배포, 설치되기 때문에 기존의 패키지와 자동 설치 스크립트, 소프트웨어 설치 관리자를 이용한 소프트웨어 설치, 업데이트에 비해 더 안전하고 신뢰성 있는 소프트웨어 배포와 설치가 가능하다.

컨테이너 기술의 기반이 된 리눅스 커널의 “네임스페이스(namespace)”와 “컨트롤 그룹(cgroup)”과 같은 응용 프로그램 수준의 자원 분할 및 관리 기술은 응용 프로그램 수준에서 운영체제 자원을 가상화하여 분할하고, 테넌트(tenant)별로 관리할 수 있도록 함으로써 클라우드 컴퓨팅의 기본 취지에 맞는 멀티테넌시(multi-tenancy) 관리도 가능하다. 물론 가상 머신과 같이 하드웨어 수준에서 원천적으로 자원을 분할할 수 없기 때문에 가상 머신보다 보안에 취약하지만, 응용 프로그램 소프트웨어와 실행 환경을 테스트한 그대로 오류와 결함 없이 배포할 수 있어 배포 과정에서 생길 수 있는 결함이 줄어들며, 운영체제 수준에서 자원 관리를 가상화할 수 있다는 점에서 사이버 물리 시스템의 소프트웨어 자원을 관리하고 안전성을 높이는 데 중요한 역할을 할 것으로 보인다.

필자가 이전 서른일곱 번째 글에서 5G 및 5G 이후 차세대 이동통신 네트워크도 일종의 사이버 물리 시스템으로 생각할 수 있다고 말했다.  사이버 물리 시스템으로서 미래 이동통신 네트워크 시스템의 물리 요소인 네트워크 장비에서도 위와 같은 가상 머신과 컨테이너를 이용한 멀티테넌시(multi-tenancy) 지원 및 자원 관리 개념이 실제로 상용화되어 가고 있다.

앞서 서른일곱 번째 글에서 소개한 “네트워크 기능 가상화(Network Function Virtualization; NFV)”는 가상 머신을 이용한 네트워크 장비 하드웨어 자원의 분할 및 관리를 위해 가상 머신 기반의 가상화 기술이 적용된 예이다. 이와 함께, 컨테이너를 이용한 이동통신 서비스 소프트웨어 배포 및 설치 관리를 실제로 삼성전자에서 개발하고 있는 5G 기지국 장비에 적용하고 있다. 이는 컨테이너 기술이 이동통신 네트워크 시스템의 소프트웨어 배포 및 설치, 수명주기 관리에 적용되는 좋은 예로 볼 수 있다.

이 시점에서 독자분들께서는 이들 가상 머신과 컨테이너로 대표되는 가상화 기술들이 도대체 빅데이터와 어떤 연관이 있는지 궁금해하실 것 같다. 사이버 물리 시스템에 클라우드 컴퓨팅 기술이 적용되면서 생기는 장점에 대해서는 수긍하겠지만 도대체 이런 것들이 빅데이터, 데이터 과학과 어떤 연관이 있는 건지 의문을 가질 것 같다.

사이버 물리 시스템에 클라우드 컴퓨팅이 적용되면서 생기는 문제 중 하나는 전체 시스템 구성에서 가상화 층이 추가되면서, 사이버 물리 시스템의 운영을 위해 데이터를 수집해야 하는 대상이 이들 가상화 층을 포함하도록 더 많아진다는 것이다. 이 때문에 사이버 물리 시스템의 클라우드 컴퓨팅에서 가상화 층에 해당하는 기술들의 정보를 수집, 처리, 제어하기 위한 운영 지능화(Operation Intelligence; OI) 데이터의 수집과 가공이 일어나 수집되는 데이터의 양이 더 많아지고 종류와 형태가 다양해진다.

사이버 물리 시스템의 지능 제어와 운영 자동화를 위해 물리적 요소인 하드웨어와 메카트로닉 장치들의 정보를 수집해야 할 뿐만 아니라 사이버 요소가 물리적 요소와 흠없이 통합되어 목적한 대로 동작하는지 확인하고 제어하기 위해서도 정보를 수집해야 하는데 클라우드 컴퓨팅이 도입되면서 생기는 가상화 층의 도입이 또 하나의 관리, 제어 요소가 되어 또 다른 빅데이터 원(big data source)이 되기 때문에 빅데이터와 관련이 있는 것이다.

좀더 쉽게 얘기하자면 오픈스택 기반의 클라우드 컴퓨팅 시스템을 구축하고 운영하게 되면 클라우드 컴퓨팅 자원을 위한 서버, 스토리지, 네트워크 장비 등의 하드웨어 장비들도 모니터링하면서 운영해야 하지만 이들 하드웨어 장비에서 고객들의 워크로드를 실행하는 가상 머신들의 상태와 운영 정보, 하드웨어와 가상 머신에서 실행되는 컨테이너들의 상태와 운영 정보, 그리고 이들 가상 머신과 컨테이너별로 각각 그 위에서 실행되는 프로세스와 응용 프로그램, 서비스의 상태와 정보를 다같이 모니터링하고 운영 데이터를 바탕으로 필요에 따라 적절하게 관리 및 운영 작업을 해주어야 한다.

위와 같이 가상 머신과 컨테이너, 그리고 이 가상 머신과 컨테이너를 실행하는 서버와 같은 하드웨어의 운영 데이터, 가상 머신과 컨테이너 상에서 실행되고 있는 프로세스와 응용 프로그램들에 대한 운영 데이터를 수집하고 같이 연관을 지어 처리해야 오픈스택 기반의 클라우드 컴퓨팅 시스템이 목적에 맞게 원활하게 운영될 수 있다. 이와 같은 일이 사이버 물리 시스템에서 클라우드 컴퓨팅 기술을 활용할 때에도 일어나고 사이버 물리 시스템이 정상적으로 작동하기 위해 수집, 관리, 분석해야 하는 데이터가 가상화 층에 대해서 추가로 늘어나면서 그 양과 종류가 많아지기 때문에 또 다른 운영 빅데이터 문제가 된다는 것이다.

이들 가상화 기술로 생기는 사이버 요소 아키텍처에서의 또 하나의 계층이 물리적 요소와 사이버 요소의 운영 체제, 그리고 물리적 요소를 제어하기 위한 사이버 물리 시스템의 시스템 소프트웨어 계층 사이에서 흠없이 통합되고 작동하게 하려고 가상화 층에서 수집된 빅데이터를 처리해야 한다. 이 때문에 결국 사이버 물리 시스템에 가상화 기술이 도입되는 것은 사이버 물리 시스템에서 빅데이터를 다루기 위한 기술의 중요성 또한 높아지게 하는 것이다.

사이버 물리 시스템의 자율성과 지능 제어를 위해 클라우드 컴퓨팅 기술 활용이 심화되면서 물리적 요소, 사이버 요소의 운영 데이터 수집과 컴퓨팅 자원 제어에 가상화 기술의 중요성이 높아지게 될 것이다. 사이버 물리 시스템에서 가상화 기술과 클라우드 컴퓨팅 기술의 비중이 높아지게 되면 과거에는 어려웠던 시스템 운영에서 높은 수준의 자율성(autonomy)과 장애, 결함의 자가 진단 및 치유, 사이버 물리 시스템의 동작 계획(action planning)과 스케줄링에 필요한 지능형 의사 결정 같은 것들의 실현 가능성이 높아지게 된다. 이런 이유로 사이버 물리 시스템 개발과 운영에 필요한 빅데이터 기술과 데이터 과학자들의 역할이 사이버 물리 시스템의 가상화 기술로 인해서 더 확장되는 것이다.

사이버 물리 시스템, 베어메탈(bare-metal) 컴퓨팅과 고성능 컴퓨팅
세번째로 사이버 물리 시스템과 클라우드 컴퓨팅과의 관계에서 좀더 생각해볼 것은 클라우드 컴퓨팅에서 베어메탈(bare-metal) 컴퓨팅 자원과 고성능 컴퓨팅 자원의 클라우드 컴퓨팅 서비스화 및 통합과 관련된 문제이다.

클라우드 컴퓨팅 기술이 고속 성장하던 2011년부터 2014년까지 사람들 사이에 많이 언급되었던 문제 중의 하나는 베어메탈(bare-metal) 컴퓨팅 자원의 클라우드 컴퓨팅 서비스화였다. 사실 이 문제는 클라우드 컴퓨팅의 핵심인 가상화 기술을 이용한 이종 자원의 통합 및 컴퓨팅 자원의 프로그램 가능성(programmability)과 상충되는 문제이다.

클라우드 컴퓨팅의 개념이 정립되고 발전되어 가던 2011년부터 2014년의 기간 동안 아마존 웹 서비스의 아성에 도전하고 틈새시장에서 새로운 클라우드 컴퓨팅 비즈니스 모델을 시도하는 많은 중소규모 클라우드 컴퓨팅 스타트업과 회사들이 생겨났다. 이들 중소 클라우드 컴퓨팅 기업들이 틈새시장과 차별화 요소로서 많이 고려했던 문제 중의 하나가 베어메탈(bare-metal) 자원의 클라우드 컴퓨팅 서비스화이다.

베어메탈(bare-metal) 클라우드 컴퓨팅은 가상 머신, 리눅스 컨테이너 등의 가상화 기술을 사용하지 않고 클라우드 컴퓨팅의 멀티테넌시(multi-tenancy)와 자원 활용의 신축성(elasticity), 주문형 자원 제공(on-demand computing) 등의 혜택을 제공하는 것이 목적이다. 클라우드 컴퓨팅의 멀티테넌시(multi-tenancy)와 자원 신축성을 제공하게끔 해주는 주요 핵심 기술이 바로 가상화 기술인데, 가상화 기술을 사용하지 않고 멀티테넌시(multi-tenancy)와 자원 신축성을 제공하게끔 클라우드 컴퓨팅 시스템을 디자인, 구현해야 하니 사실은 기술적으로 쉽지 않은 문제였기 때문에 기술적인 차별화로 고려할 만한 문제였다.

비즈니스 측면에서 베어메탈(bare-metal) 컴퓨팅 자원의 클라우드 컴퓨팅 서비스화가 당시 중요했던 이유 중의 하나는 가상화된 컴퓨팅 자원이 요구사항에 맞지 않는 일부 영역, 예를 들면 하드웨어 성능을 최대한 끌어내어 활용해야 하는 과학기술 및 엔지니어링 고성능 컴퓨팅, 서버 사이드 FPGA 컴퓨팅, 아직도 가상화가 쉽지 않은 GPU 컴퓨팅, 저 수준(low-level) 하드웨어 기능을 직접 활용하여 사용해야 하거나 컴퓨팅 자원이 하드웨어와 긴밀하게 통합되어 미션 크리티컬 연산을 수행해야 하는 제어용 컴퓨팅 등의 분야에 베어메탈(bare-metal) 자원의 높은 성능을 보장하면서 클라우드 컴퓨팅 서비스의 장점을 제공하면 비즈니스 가치를 제공할 수 있었기 때문이다.

요즘은 빅데이터 처리와 분석을 위한 컴퓨팅 자원을 클라우드 컴퓨팅을 통해 사용하는 것이 크게 이상하지 않고 오히려 널리 확산되는 추세지만, 2011년부터 2014년까지 빅데이터 처리를 위한 컴퓨팅 인프라는 클라우드 컴퓨팅을 통해 사용하기에는 성능상의 손실이 많다고 보아 그렇게 반기지 않았다. 당시만 해도 빅데이터 처리를 위한 컴퓨팅 인프라는 베어메탈(bare-metal) 자원을 사용하는 것을 선호하였기 때문에 IBM의 네티자(Netezza) 어플라이언스나 스마트 애널리틱스 어플라이언스, EMC가 인수한 그린플럼(GreenPlum)의 하둡 배포판을 사용한 그린플럼 데이터 컴퓨팅 어플라이언스(EMC GreenPlum DCA), 오라클의 엑살리틱스 어플라이언스(Exalytics Appliance), HP의 버티카 어플라이언스(Vertica Appliance) 등 당시 쟁쟁한 주요 IT업체들이 빅데이터를 위한 베어메탈(bare-metal) 컴퓨팅을 위해 어플라이언스 제품을 경쟁적으로 내어놓기도 하였다.

위의 빅데이터 어플라이언스 제품들은 여전히 IT회사들이 빅데이터를 위한 솔루션으로 제공하고 있는 제품들이며, 많은 기업들이 온프레미스(on-premise) 빅데이터 컴퓨팅을 위해서 사용하고 있다. 다만, 최근 클라우드 컴퓨팅이 성숙하면서 꼭 비싼 어플라이언스 제품이나 온프레미스(on-premise) 베어메탈(bare-metal) 컴퓨팅을 써야할 만큼 저지연과 높은 성능이 요구되는 빅데이터 처리가 아닌 일반적인 데이터 과학 응용 분야에서는 클라우드 컴퓨팅을 이용해 빅데이터를 다루는 것이 확산되는 추세이다.

지금까지 빅데이터 붐과 클라우드 컴퓨팅의 발전 과정을 거쳐오면서 빅데이터와 고성능 컴퓨팅을 위한 컴퓨팅 자원으로 아직까지도 베어메탈(bare-metal) 컴퓨팅 자원과 고성능의 어플라이언스 제품이 사용되고, 슈퍼컴퓨터와 고성능 컴퓨터를 이용한 과학기술과 엔지니어링 컴퓨팅이 여전히 사라지지 않고 사용되고 있는 것은 베어메탈(bare-metal) 컴퓨팅이 중요한 분야가 여전히 있고 가치를 가지고 있다는 것을 보여주는 것이다.

보통 국립 슈퍼컴퓨팅 센터와 같은 특별한 장소에 슈퍼컴퓨팅만을 위한 특별한 고성능 네트워크 장비와 인프라, 그리고 슈퍼컴퓨팅에 최적화된 하드웨어 구성과 조합을 이용해 구축하여 사용하는 슈퍼컴퓨터와 같은 장비를 보다 많은 사용자들이 편리하게 사용할 수 있도록 클라우드 컴퓨팅화를 하려는 노력이 지금까지 많이 이루어졌다. 그렇지만, 그 노력에 비해 클라우드 컴퓨팅 서비스화가 어렵고 성과가 뚜렷이 나타나지 않았다. 이런 어려움은 베어메탈(bare-metal) 컴퓨팅의 클라우드 서비스화가 비록 그 시장이 틈새시장이기는 해도 기술적인 가치와 함께 비즈니스 가치도 가지고 있다는 것을 분명하게 보여주는 것으로 볼 수 있다.

사이버 물리 시스템에서도 베어메탈(bare-metal) 컴퓨팅의 중요성은 무시할 수 없다. 사이버 물리 시스템이 활용되는 분야에 따라 특히 자율주행과 항공과 같이 사용자의 안전이 보장되어야 하거나, 국방과 기상 서비스와 같이 공공성이 강조되고 사용되는 장비가 고가이며 특정한 용도에 특화된 경우, 어쩔 수 없이 베어메탈(bare-metal) 컴퓨팅을 사용하지 않을 수 없다.

현재 클라우드 컴퓨팅이 데이터센터를 중심으로 한 서버 사이드 응용 프로그램과 서비스 산업을 중심으로 많이 활용되고 있으면서 에지 컴퓨팅 영역으로 조금씩 확산되고 있는 것과 같이, 사이버 물리 시스템 발전의 초반에도 사이버 물리 시스템에 사용되는 컴퓨팅 자원들 모두가 클라우드 컴퓨팅 시스템으로 전환되어 있지 않을 가능성이 높다. 

클라우드 컴퓨팅 기술이 사이버 물리 시스템의 자원 활용과 통합, 관리에 많은 이점과 유연성을 주기 때문에 결국은 많이 활용되겠지만 사이버 물리 시스템의 부분부분에 베어메탈(bare-metal) 컴퓨팅이 필요한 부분과 아직은 클라우드 컴퓨팅 기술이 완전하게 들어오지 않은 에지 컴퓨팅 시스템들도 사이버 물리 시스템에 통합되어야 한다. 이 때문에 클라우드 컴퓨팅이 모든 컴퓨팅 시스템의 컴퓨팅 자원 관리를 위한 기본 기술로서 사용되기 전의 과도기에는 어쩔 수 없이 베어메탈(bare-metal) 컴퓨팅 자원과 클라우드 컴퓨팅 자원의 흠 없는 통합과 관리를 위한 기술이 필요하게 된다.

위에 더해 특정한 목적으로 구축, 운영되는 사이버 물리 시스템에서는 클라우드 컴퓨팅의 활용이 당분간 아예 어려울 수도 있고 사이버 물리 시스템의 일부 구성 요소에서는 그 요구 사항에 따라 베어메탈(bare-metal) 컴퓨팅을 사용하지 않을 수 없다. 이 때문에 클라우드 컴퓨팅 시스템과 베어메탈(bare-metal) 컴퓨팅 시스템의 통합, 또는 베어메탈(bare-metal) 컴퓨팅 자원을 가상화 기술을 사용하지 않고 자원을 관리하고 클라우드 컴퓨팅 서비스화할 수 있는 기술은 어떤 식으로든 필요하고 그 수요가 꾸준히 나타나게 될 것이다.

사이버 물리 시스템에서 필요한 에지 컴퓨팅과 임베디드 실시간 분산 컴퓨팅 시스템을 위한 베어베탈 컴퓨팅 자원 관리 기술은 일반 클라우드 컴퓨팅과는 다른 특성 때문에 아직 큰 발전은 없다. 그렇지만 오픈소스 클라우드 컴퓨팅 소프트웨어인 오픈스택(OpenStack) 개발 커뮤니티에서는 하이퍼바이저, 컨테이너 논란이 뜨거워지기 시작한 2015년부터 오픈스택에서 베어메탈(bare-metal) 컴퓨팅 자원 프로비저닝 및 관리를 위한 다양한 프로젝트들이 개발되기 시작했다. 베어메탈(bare-metal) 프로비저닝과 관리를 위한 “아이어닉(Ironic)”이 대표적인 프로젝트이다. 

베어메탈(bare-metal) 컴퓨팅을 “아이어닉(Ironic)”과 같이 직접적으로 지원하지는 않지만 오픈스택에서 컨테이너 기반으로 응용 프로그램들의 베어메탈(bare-metal) 성능을 최대한 이끌어낼 수 있도록 도커(Docker)와 쿠버네티스(Kubernetes)로 관리되는 컨테이너들을 관리할 수 있는 통합 API를 제공하는 “매그넘(Magnum) 프로젝트”, 오픈스택을 컨테이너 기반의 마이크로 서비스 형태로 프로비저닝할 수 있도록 하는 “콜라(Kolla)” 프로젝트 등도 오픈스택의 가상 머신 기반의 클라우드 컴퓨팅 환경 안에서 베어메탈(bare-metal) 자원의 활용과 관리를 손쉽게 통합할 수 있도록 돕는 관련 프로젝트로 볼 수 있다.

오픈스택의 “아이어닉(Ironic)”, “매그넘(Magnum)”, “콜라(Kolla)”와 같은 종류의 기술은 앞으로 사이버 물리 시스템에서 활용되는 클라우드 컴퓨팅 기술이 베어메탈(bare-metal) 자원의 통합과 관리를 위해 어떤 방향으로 발전해 나가게 될지 엿볼 수 있게 한다.

클라우드 컴퓨팅의 성장으로 인해 인프라 엔지니어와 하드웨어를 구축하고 유지 보수하는 시스템 엔지니어들의 일자리가 사라질 것이라고 예상하는 사람들이 많아지고 있지만, 필자 생각으로는 인프라 엔지니어와 시스템 엔지니어의 역할과 임무가 달라질 뿐이지 일자리가 크게 축소되지는 않을 것 같다. 위와 같이 베어메탈(bare-metal) 컴퓨팅이 필요한 특정한 분야가 여전히 존재하고 한동안은 없어지지 않고 중요한 역할을 할 것이며, 하드웨어 기술이 발전하면서 새로운 하드웨어 기술에 맞게 클라우드 컴퓨팅 서비스와 인프라를 구축해야 하는 전문가들은 여전히 필요하기 때문에 인프라 엔지니어와 시스템 엔지니어들의 수요도 그에 맞게 유지될 것이다. 다만, 인프라와 시스템 엔지니어들이 데브옵스(DevOps) 기술과 같은 소프트웨어 마인드와 기술을 익혀야 할 필요성은 더 높아질 것으로 보인다.

가상 머신에 비해 상대적으로 베어메탈(bare-metal) 컴퓨팅 자원의 성능을 거의 그대로 활용할 수 있는 리눅스 컨테이너 기술을 활용한 클라우드 컴퓨팅의 수요는 점점 더 높아질 것으로 보인다. 특히 요즘 소프트웨어와 런타임 환경의 설치, 배치, 관리의 용도로 리눅스 컨테이너 기술이 점점 더 많이 확산되고 있고 쿠버네티스와 같이 대규모로 컨테이너 인스턴스를 관리해주는 기술이 발전하고 있기 때문에 리눅스 컨테이너 기술을 이용한 베어메탈(bare-metal) 컴퓨팅의 클라우드 컴퓨팅 서비스화는 크게 발전하고 확산될 것으로 보인다.

그렇지만 리눅스 컨테이너 기술도 네트워크 가상화 성능 문제나 멀티테넌시(multi-tenancy) 보안, 하드웨어 자원 용량 관리 및 제어 문제는 여전히 해결하지 못하고 있기 때문에 리눅스 컨테이너로 클라우드 컴퓨팅화할 수 있는 베어메탈(bare-metal) 컴퓨팅 기술은 한계가 있다. 특히 비용과 공간 제약, 발열 등의 물리적인 한계로 인해서 고성능 컴퓨팅 자원을 쓰지 못하고 적정 프로세서와 네트워크 인터페이스 기술을 사용해 가능하면 최대한 성능을 뽑아내야 하는 임베디드 시스템이나 에지 컴퓨팅 시스템의 경우 한동안 클라우드 컴퓨팅 기술을 사용하기에는 시스템 자원이 많이 부족할 것이다. 이런 이유로 사이버 물리 시스템에서 베어메탈(bare-metal) 컴퓨팅 시스템과 클라우드 컴퓨팅 시스템을 통합하는 문제, 또는 베어메탈(bare-metal) 컴퓨팅 시스템 자원을 클라우드 컴퓨팅 시스템과 동일한 인터페이스로 통합, 제어하는 문제는 한동안 중요한 기술적인 문제로 남을 것을 보인다.

반대로 클라우드 컴퓨팅에서의 이종 자원 관리 문제와 소프트웨어적 가상화 기술을 멀티테넌시(multi-tenancy)를 위해 사용하면서 생기는 별도의 시스템 부하를 줄이기 위해 하드웨어 기술 자체가 클라우드 컴퓨팅의 요구 사항에 맞게 발전하는 흐름도 나타날 것으로 보인다. 이런 흐름의 대표적인 예가 앞으로 소개하게 될 인텔의 “랙 스케일 아키텍처(Rack-scale Architecture)”인데 REST API를 통해 랙(rack) 내의 자원을 원하는 대로 조합하여 노드를 생성, 프로비저닝하고 관리하는 “팟 매니저(pod manager)”가 랙(rack) 단위 하드웨어 펌웨어에 아예 포함되어 있어서 하드웨어 수준에서 클라우드 컴퓨팅을 지원하기 용이하게 되어있다[38-53].

지금까지 언급한 다양한 가상화 기술과 베어메탈(bare-metal) 컴퓨팅 자원의 클라우드 컴퓨팅 자원과의 통합 문제로 생기는 과도기적인 문제들이 클라우드 컴퓨팅 서비스 회사나 솔루션 업체들에게는 새로운 비즈니스 기회를 만들어 주기도 할 것이다. 이런 과도기의 끝에 자원 이종성을 극복하는 하나의 가상화 솔루션이 가상화 기술을 제패하여 클라우드 컴퓨팅 아키텍처가 깔끔하게 정리될지, 아니면 프로그래머블(programmable) 하드웨어 기술의 발전으로 클라우드 컴퓨팅이 아닌 다른 이름으로 불리게 될 새로운 인프라 자원 관리 기술이 등장하게 될지 아직 분명하지 않다.

앞서 설명한 사이버 물리 시스템의 이종 자원 관리를 위한 클라우드 컴퓨팅 시스템의 상호운용성 인터페이스, 가상화 기술의 발전, 베어메탈(bare-metal) 컴퓨팅 자원의 신뢰성 있는 통합, 관리 기술은 사이버 물리 시스템을 기반으로 한 지능형 서비스 시장에서 비즈니스와 기술 발전의 계기가 될 것이다. 이는 사이버 물리 시스템 기술의 발전이 IT업계에 줄 수 있는 또 하나의 선물이 될 것으로 필자는 생각한다.

[참고문헌]
[1] 김진철, “LHC에서 배우는 빅데이터와 machine learning 활용 방안”, 2016년 9월 28일, A CIO Conversation for Technology Leadership – Breakfast Roundtable 발표 자료
[2] 김진철, “김진철의 How-to-Big Data (9) – 빅데이터와 클라우드 기술 (1)”, CIO Korea, 2017년 9월 28일자. (http://www.ciokorea.com/column/35688)
[3] 김진철, “김진철의 How-to-Big Data (10) – 빅데이터와 클라우드 기술 (2)”, CIO Korea, 2017년 9월 28일자. (http://www.ciokorea.com/column/36179)
[4] 김진철, “김진철의 How-to-Big Data (11) – 빅데이터와 클라우드 기술 (3)”, CIO Korea, 2017년 9월 28일자. (http://www.ciokorea.com/column/36540)
[5] 김진철, “김진철의 How-to-Big Data (12) – 빅데이터와 클라우드 기술 (4)”, CIO Korea, 2017년 9월 28일자. (http://www.ciokorea.com/column/36748)
[6] 김진철, “김진철의 How-to-Big Data (13) – 빅데이터와 클라우드 기술 (5)”, CIO Korea, 2017년 9월 28일자. (http://www.ciokorea.com/column/37099)
[7] 김진철, “김진철의 How-to-Big Data (14) – 빅데이터와 클라우드 기술 (6)”, CIO Korea, 2017년 9월 28일자. (http://www.ciokorea.com/column/37380)
[8] Jha, Shantenu & Kaiser, Hartmut & Merzky, Andre & Weidner, Ole. (2007). Grid Interoperability at the Application Level Using SAGA, in the Proceedings of Third International Conference on e-Science and Grid Computing, e-Science 2007, 10-13 December 2007, Bangalore, India, p. 584-591.
[9] Merzky, Andre & Weidner, Ole & Jha, Shantenu. (2015). SAGA: A standardized access layer to heterogeneous Distributed Computing Infrastructure. SoftwareX. 84. 10.1016/j.softx.2015.03.001.
[10] Goodale T, Jha S, Kaiser H, Kielmann T, Kleijer P, Merzky A, et al. A Simple API for grid applications (SAGA). In: Grid Forum Document GFD.90, Open Grid Forum, OGF Proposed Recommendation Document, 2007, open Grid Forum.
[11] Merzk A, SAGA API extension: Advert API. In: Grid Forum Document GFD.177, Open Grid Forum, OGF Proposed Recommendation Document, 2011, (http://www.ggf.org/documents/GFD.177.pdf).
[12] Merzky A, SAGA API extension: Message API. In: Grid Forum Document GFD.178, Open Grid Forum, OGF Proposed Recommendation Document, 2011, (http://www.ggf.org/documents/GFD.178.pdf).
[13] Fisher S, Wilson A, Pavnethan A, SAGA API extension: Service discovery API. In: Grid Forum Document GFD.144, Open Grid Forum, OGF Proposed Recommendation Document, 2011, (http://www.ggf.org/documents/GFD.144.pdf).
[14] Fisher S., Wilson A., SAGA API extension: Information system navigator. In: Grid Forum Document GFD.195, Open Grid Forum, OGF Proposed Recommendation Document, 2011, (http://www.ggf.org/documents/GFD.195.pdf).
[15] Merzky A, Luckow A, Simmel D, SAGA extension: Checkpoint and recovery API (CPR). In: Grid Forum Document GFD.XX, Open Grid Forum, Draft for an OGF Proposed Recommendation Document, 2008, (http://www.ogf.org/OGF27/materials/1767/saga cpr.pdf).
[16] Caryer, G. & Rings, T. & Grabowski, J. & Schulz, S. & Stokes-Rees, Ian & Kovacikova, Tatiana. (2009). Grid/cloud computing interoperability, standardization and the Next Generation Network (NGN). 10.1109/ICIN.2009.5357099.
[17] Laurence Field, Markus Schulz, Grid interoperability: the interoperations cookbook, Journal of Physics: Conference Series, V. 119, 062029, 2008.
[18] S. Andreozzi, S. Burke, L. Field, G. Galang, B. Konya, M. Litmaath, P. Millar, J. P. Navarro, “GLUE Specification v. 2.0,” In: Grid Forum Document GFD.147 Open Grid Forum, OGF Proposed Recommendation Document, 2009. (http://www.ogf.org/documents/GFD.147.pdf)
[19] S. Andreozzi, S. Burke, L. Field, B. Konya, S. Memon, D. Meredith, JP Navarro, F. Paganelli, W. Smith, “GLUE v. 2.0 – Reference Realization to XML Schema,“ In: Grid Forum Document GFD.209, Open Grid Forum, OGF Proposed Recommendation Document, 2013. (http://www.ogf.org/documents/GFD.209.pdf)
[20] W. Smith, D. Meredith, S. Memon, JP. Navarro, “GLUE v. 2.0 – Reference Realization to JSON Schema,“  In: Grid Forum Document GFD.219, Open Grid Forum, OGF Proposed Recommendation Document, 2016. (http://www.ogf.org/documents/GFD.219.pdf)
[21] S. Andreozzi, G. Galang, D. Horat, B. Konya, M. Litmaath, S. Memon, P. Millar, JP. Navarro, F. Paganelli, “GLUE v. 2.0 – Reference Realization to LDAP Schema,”  In: Grid Forum Document GFD.218, Open Grid Forum, OGF Proposed Recommendation Document, 2016. (http://www.ogf.org/documents/GFD.218.pdf)
[22] R. Nyrén, A. Edmonds, A.P. Adesso, T. Metsch, B. Parák, “Open Cloud Computing Interface – Core,” In: Grid Forum Document GFD.221, Open Grid Forum, OGF Proposed Recommendation Document, 2016. (http://www.ogf.org/documents/GFD.221.pdf)
[23] M. Drescher, B. Parák, D. Wallom, “OCCI Compute Resource Templates Profile,” In: Grid Forum Document GFD.222, Open Grid Forum, OGF Proposed Recommendation Document, 2016. (http://www.ogf.org/documents/GFD.222.pdf)
[24] R. Nyrén, A. Edmonds, T. Metsch, B. Parák, “Open Cloud Computing Interface – HTTP Protocol,”  In: Grid Forum Document GFD.223, Open Grid Forum, OGF Proposed Recommendation Document, 2016. (http://www.ogf.org/documents/GFD.223.pdf)
[25] T. Metsch, A. Edmonds, B. Parák, “Open Cloud Computing Interface – Infrastructure,” In: Grid Forum Document GFD.224, Open Grid Forum, OGF Proposed Recommendation Document, 2016. (http://www.ogf.org/documents/GFD.224.pdf)
[26] R. Nyrén, F. Feldhaus, B. Parák, Z. Šustr, “Open Cloud Computing Interface – JSON Rendering,”  In: Grid Forum Document GFD.226, Open Grid Forum, OGF Proposed Recommendation Document, 2016. (http://www.ogf.org/documents/GFD.226.pdf)
[27] T. Metsch, M. Mohamed, “Open Cloud Computing Interface – Platform,” In: Grid Forum Document GFD.227, Open Grid Forum, OGF Proposed Recommendation Document, 2016. (http://www.ogf.org/documents/GFD.227.pdf)
[28] G. Katsaros, “Open Cloud Computing Interface – Service Level Agreements,” In: Grid Forum Document GFD.228, Open Grid Forum, OGF Proposed Recommendation Document, 2016. (http://www.ogf.org/documents/GFD.228.pdf)
[29] A. Edmonds, T. Metsch, “Open Cloud Computing Interface – Text Rendering,” In: Grid Forum Document GFD.229, Open Grid Forum, OGF Proposed Recommendation Document, 2016. (http://www.ogf.org/documents/GFD.229.pdf)
[30] Timothy Prickett Morgan, “FUTURE CLOUDS COULD BE JUST CONTAINERS ON BARE METAL,” The Next Platform, September 5, 2018. (https://www.nextplatform.com/2018/09/05/future-clouds-could-be-just-containers-on-bare-metal/)
[31] Randy Bias, “Will Containers Replace Hypervisors? Almost Certainly!”, CloudScaling blog, May 17, 2016. (http://cloudscaling.com/blog/cloud-computing/will-containers-replace-hypervisors-almost-certainly/)
[32] Allison Price, “Containers and OpenStack: here’s what you need to know,” Superuser Magazine published by The OpenStack foundation, June 3, 2015. (https://superuser.openstack.org/articles/containers-and-openstack-here-s-what-you-need-to-know/)
[33] The OpenStack Foundation, “What makes OpenStack relevant in a container-driven world,” Superuser Magazine published by The OpenStack Foundation, June 22, 2017. (https://superuser.openstack.org/articles/openstack-relevant-containers/)
[34] Kathy Cacciatore, Paul Czarkowski, Steven Dake, John Garbutt, Boyd Hemphill, John Jainschigg, Andre Moruga, Adrian Otto, Craig Peters, Brian E. Whitaker, “Exploring Opportunities: Containers and OpenStack,” OpenStack White Paper, The OpenStack Foundation, 2015. (https://object-storage-ca-ymq-1.vexxhost.net/swift/v1/6e4619c416ff4bd19e1c087f27a43eea/www-assets-prod/pdf-downloads/Containers-and-OpenStack.pdf)
[35] Jaesuk Ahn, Christian Berendt, Anne Bertucio, Pete Birley, Chris Hoge, Lingxian Kong, Hongbin Lu, Daniel Mellado, Allison Price, David Rabel, Sangho Shin, Davanum Srinivas, Luis Tomás, Sam Yaple, Mikhail Fedosin, Flavio Percoco, Brian E Whitaker, “Leveraging Containers and OpenStack – A Comprehensive Review,“ The OpenStack Foundation. (https://www.openstack.org/containers/leveraging-containers-and-openstack/?lang=en_US)
[36] Fabrizio Soppelsa, “What are containers, and why do they matter to OpenStack?”, Mirantis Blog,  October 12, 2015. (https://www.mirantis.com/blog/what-are-containers-and-why-do-they-matter-to-openstack/)
[37] 안성원, “클라우드 가상화 기술의 변화 – 컨테이너 기반의 클라우드 가상화와 DevOps,” 소프트웨어정책연구소 이슈리포트 제2018-008호, 2018년 12월 10일. (file:///C:/Users/JincheolKim/Dropbox/GoodReader/Career%20management/%EA%B8%B0%EA%B3%A0/How-to-BigData/Article%2038/Hypervisor%20VS%20Container/[%EC%9D%B4%EC%8A%88%EB%A6%AC%ED%8F%AC%ED%8A%B8%202018-008]%20%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C%20%EA%B0%80%EC%83%81%ED%99%94%20%EA%B8%B0%EC%88%A0%EC%9D%98%20%EB%B3%80%ED%99%94.pdf)
[38] Intel, “Standardizing the Hyperscale Data Center.” (https://www.intel.co.kr/content/www/kr/ko/architecture-and-technology/rack-scale-design/standardizing-the-hyperscale-data-center-infographic.html)
[39] Intel, “Meeting the Challenges of Data Center Digital Transformation.” (https://www.intel.co.kr/content/www/kr/ko/architecture-and-technology/rack-scale-design/rack-scale-design-dc-transformation-brief.html)
[40] Intel, “Intel® Rack Scale Design (Intel® RSD) Architecture,” White Paper. (https://www.intel.co.kr/content/www/kr/ko/architecture-and-technology/rack-scale-design/rack-scale-design-architecture-white-paper.html)
[41] Intel, “Intel Rack Scale Design (Intel RSD) – Getting Started Guide, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/getting-started-guide-v2-5.pdf)
[42] Intel, “Intel Rack Scale Design (Intel RSD) – Architecture Specification, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/architecture-spec-v2.5.pdf)
[43] Intel, “Intel Rack Scale Design (Intel RSD) – Pod Manager (PODM) Release Notes, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/podm-release-notes-v2-5.pdf) 
[44] Intel, “Intel Rack Scale Design (Intel RSD) – Pod Manager (PODM) User Guide, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/podm-user-guide-v2-5.pdf)
[45] Intel, “Intel Rack Scale Design (Intel RSD) – Pod Manager (PODM) Representational State Transfer (REST) API Specification, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/podm-api-spec-v2.5.pdf)
[46] Intel, “Intel Rack Scale Design (Intel RSD) – Pooled System Management Engine (PSME) Release Notes, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/psme-release-notes-v2-5.pdf) 
[47] Intel, “Intel Rack Scale Design (Intel RSD) – Pooled System Management Engine (PSME) User Guide, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/psme-release-notes-v2-5.pdf)
[48] Intel, “Intel Rack Scale Design (Intel RSD) – Pooled System Management Engine (PSME) Representational State Transfer (REST) API Specification, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/psme-user-guide-v2-5.pdf)
[49] Intel, “Intel Rack Scale Design (Intel RSD) – Storage Services API Specification, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/storage-services-api-spec-v2-5.pdf)
[50] Intel, “Intel Rack Scale Design (Intel RSD) – Rack Management Module (RMM) Representational State Transfer (REST) API Specification, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/rmm-api-spec-v2-5.pdf)
[51] Intel, “Intel Rack Scale Design (Intel RSD) – Generic Assets Management Interface (GAMI) Representational State Transfer (REST) API Specification, Software v.2.5,” Revision 001, July 2019. (https://www.intel.co.kr/content/dam/www/public/us/en/documents/guides/gami-api-spec-v2-5.pdf)
[52] Mohan J. Kumar, “Look Inside Intel Rack Scale Architecture,” a contributed talk in the 9th Extremely Large Databases Conference, May 24-26, 2016. (https://www-conf.slac.stanford.edu/xldb2016/talks/published/Tues_6_Mohan-Kumar-Rack-Scale-XLDB-Updated.pdf)
[53] Scott Fulton III, “Intel Finally Releases Its Rack Scale Design to Open Source,” DataCenter Knowledge, July 29, 2016. (https://www.datacenterknowledge.com/archives/2016/07/29/intel-finally-releases-rack-scale-design-open-source)
[54] Sabina Jeschke, “Everything 4.0? – Drivers and Challenges of Cyber Physical Systems,” Forschungsdialog Rehinland – Invited Talk, Wuppertal, December 4, 2013.
[55] Insup Lee, “Cyber Physical Systems – The Next Computing Revolution,” Lecture – CIS 480, Department of Computer and Information Science, University of Pennsylvania, 2009.
[56] Insup Lee, “Cyber Physical Systems – The Next Computing Revolution,” Adream Lecture, LAAS-CNRS, June 15, 2010.
[57] 진회승, 서영희, 김원태, “CPS의 기능, 비기능적 소프트웨어 요구사항 분석”, 연구보고서 2017-008, 소프트웨어정책연구소(SPRi), 2018년 4월.
[58] Francesca Palumbo, “Introduction on Cyber-Physical Systems,” Lecture at CPS Summer School – From Concepts to Implementation, Alghero(IT), September 17 ~ 21, 2018.
[59] Teodora Sanislav, Sherali Zeadally, George Dan Mois, “A Cloud-Integrated, Multilayered, Agent-Based Cyber-Physical System Architecture,” Computer, April, 2017.
[60] Edward A. Lee, “The Past, Present and Future of Cyber-Physical Systems: A Focus on Models,” Sensors Vol. 15, pp. 4837-4869, 2015. doi:10.3390/s150304837
[61] Kyoung-Dae Kim and P. R. Kumar, “Cyber-Physical Systems: A Perspective at the Centennial,” Proceedings of the IEEE, Vol. 100, p. 1287 ~ 1308, May 13th, 2012.
[62] Soldani D, Manzalini A, “A 5G Infrastructure for ‘Anything-as-a-Service’”, J. Telecommun. Syst. Manage. 3, pp. 114, 2014. doi:10.4172/2167-0919.1000114
[63] Kyoung-Dae Kim and P. R. Kumar, “An Overview and Some Challenges in Cyber-Physical Systems,” Journal of the Indian Institute of Science, Vol. 93(3), p. 341 ~ 351, Jul.–Sep. 2013. (http://journal.library.iisc.ernet.in/index.php/iisc/article/view/1693)
[64] Alessandro D’Innocenzo, Henry Muccini, “Introduction to CPS,” 1ST DISIM WORKSHOP ON ENGINEERING CYBER-PHYSICAL SYSTEMS, TUESDAY 26, JANUARY 2016.
[65] M. Törngren, F. Asplund, S. Bensalem, J. McDermid, R. Passerone, H. Pfeifer, A. Sangiovanni-Vincentelli, B. Schätz, “Characterization, Analysis and Recommendations for Exploiting the Opportunities of Cyber-Physical Systems,” Chapter 1 in Cyber-Physical Systems – Foundations, Principles, and Applications, edited by Houbing Song, Danda B. Rawat, Sabina Jeschke, Christian Brecher, Academic Press, 2017.
[66] Krishnarajanagar GopalaIyengar Srinivasa, Gaddadevara Matt Siddesh and Kushagra Mishra, “Influence of Big Data on Cyber-Physical Systems,” in Cyber-Physical Systems – A Computational Perspective, edited by Gaddadevara Matt Siddesh, Ganesh Chandra Deka, Krishnarajanagar GopalaIyengar Srinivasa, Lalit Mohan Patnaik, CRC Press, 2016.
[67] Srinidhi Hiriyannaiah, Gaddadevara Matt Siddesh, and Krishnarajanagar Gopala Iyengar Srinivasa, “Ubiquitous Computing for Cyber-Physical Systems,” in Cyber-Physical Systems – A Computational Perspective, edited by Gaddadevara Matt Siddesh, Ganesh Chandra Deka, Krishnarajanagar GopalaIyengar Srinivasa, Lalit Mohan Patnaik, CRC Press, 2016.
[68] Houbing Song, Qinghe Du, Pinyi Ren, Wenjia Li, and Amjad Mehmood, “Cloud Computing for Transportation Cyber-Physical Systems,” in Cyber-Physical Systems – A Computational Perspective, edited by Gaddadevara Matt Siddesh, Ganesh Chandra Deka, Krishnarajanagar GopalaIyengar Srinivasa, Lalit Mohan Patnaik, CRC Press, 2016.

*김진철 박사는 1997년 한국과학기술원에서 물리학 학사, 1999년 포항공과대학교에서 인공신경망에 대한 연구로 석사 학위를, 2005년 레이저-플라즈마 가속기에 대한 연구로 박사 학위를 받았다. 2005년부터 유럽입자물리학연구소(CERN)의 LHC 데이터 그리드 구축, 개발에 참여, LHC 빅데이터 인프라를 위한 미들웨어 및 데이터 분석 기술을 연구하였다. 이후 한국과학기술정보연구원(KISTI), 포항공과대학교, 삼성SDS를 거쳐 2013년부터 SK텔레콤에서 클라우드 컴퓨팅과 인공지능 기술을 연구하고 있다. 빅데이터와 인공지능 기술의 기업 활용 방안에 대해 최근 다수의 초청 강연 및 컨설팅을 수행하였다. dl-ciokorea@foundryco.com