한빛출판네트워크

제공 : 한빛 네트워크
저자 : Benjamin Hindman
역자 : 김국현
원문 : Why the data center needs an operating system

 

개발자들은 오늘도 새로운 응용 프로그램의 클래스를 만들고 있습니다. 그들의 응용 프로그램은 단일 서버에 적합하지 않지만, 데이터 센터 안의 여러 서버에서 대신 돌아가고 있습니다. 예를 들어 분석 프레임워크 아파치 하둡(Apache Hadoop)과 스파크(Apache Spark)를 들 수 있으며 메시지 브로커인 아파치 카프카(Apache Kafka)와 키-값을 저장하는 아파치 카산드라(Apache Cassandra)와 또한 고객 지향 응용 프로그램으로 트위터와 넷플릭스가 있습니다.

이러한 새로운 응용 프로그램들은 배포해주는 시스템의 응용 프로그램보다도 많습니다. 단지 이것이 개발자가 하나의 머신에 대한 멀티 스레드 응용 프로그램을 개발하는 것이 일반화된 것처럼, 이제 개발자는 데이터 센터에 분산 시스템을 개발하는 것이 일반화되고 있습니다.

그러나 개발자에게 분산 시스템은 어렵고 운영자가 분산 시스템을 실행하기가 어렵습니다. 왜? 그 이유는 개발자와 운영자 모두에게 추상화의 잘못된 수준을 노출하기 때문입니다.


머신의 잘못된 추상화

머신은 잘못된 수준의 추상화를 배포하여 응용 프로그램에 개발 및 실행합니다. 개발자가 불필요한 추상화 기술로 복잡한 시스템을 노출함으로써 시스템의 각 특성에 의해 소프트웨어를 개발하는데 제약이 원인이 되며 이는 IP 주소와 지역 저장소 등을 예로 들 수 있습니다. 응용 프로그램을 이식 및 조정이 어렵고 불가능하지는 않지만, 데이터 센터의 유지 보수를 강제하는 것은 매우 복잡하고 고통스러운 과정이 될 수 있습니다.
시스템의 추상화와 같이 운영자가 배포 응용 프로그램의 시스템 손실을 예상하고, 일반적으로 시스템의 각각 하나의 응용 프로그램을 배포하기가 가장 쉽고 보수적인 접근 방식입니다. 대부분 항상 시스템의 활용도가 낮은 이용 수단을 의미하며 응용 프로그램(가상 또는 물리적)의 크기에 가깝게 시스템을 구매하지 않거나 응용 프로그램의 크기에 정확하게 시스템을 구매하지 않습니다. 컴퓨터 당 하나의 응용 프로그램을 실행함으로써, 매우 정적으로 데이터 센터를 나누고, 높은 유연한 파티션의 시스템을 각각 분산 응용 프로그램에 대해 가질 수 있습니다. 말하자면 분석을 실행하는 파티션, 데이터를 실행하는 다른 파티션, 웹 서버를 실행하는 다른 파티션, 메시지 큐를 실행하는 파티션 등등을 말합니다. 많은 파티션의 수는 기업들이 서비스 지향 구조와 함께 획일적인 구조를 교체하면서 늘어날 수밖에 없으며 또한 많은 소프트웨어를 마이크로서비스에 기반을 두어 개발할 수 있습니다.

 

정적 파티션 중 하나가 죽으면 시스템에는 무슨 일이 일어나나요? 오버 프로비저닝을 충분히(돈을 낭비하면서) 희망해보거나 다른 시스템에 빨리(노력을 낭비) 재 프로비저닝을 할 수도 있습니다. 웹 트래픽이 매일 낮게 떨어지면 어떤가요? 정적 파티션이 통신량이 가장 낮은 때의 최대 크기에 할당하면서 모든 파티션의 크기가 낭비됩니다. 이는 일반적인 데이터 센터가 8-15%의 효율로 실행하는 이유가 됩니다. 그리고 그저 바보같이 클라우드에 실행하지 마십시오: 여전히 응용 프로그램이 사용하지 않는 자원을 각 가상 머신에 충전합니다(누군가에겐 도움이 됩니다 - 당신이 아니라 클라우드 공급자들이지만요).
또 결정적으로, 시스템은 추상화되어 있으며, 조직은 수동으로 구성하면서 개별 시스템의 개별 응용 프로그램을 유지 보수하기 위해 사람들을 고용해야 합니다. 충분한 자원이 있는 경우에도 활용되지 않는 프로비저닝때문에 사람들은 새로운 응용 프로그램을 실행하려고 하면 병목 현상이 나타납니다.


나의 랩톱이 데이터 센터인 경우

데이터 센터에서 응용 프로그램을 실행하는 같은 방식으로 랩톱에서 응용 프로그램을 실행한 경우를 상상해보십시오. 우리는 웹 브라우저 또는 텍스트 편집기를 실행할 때마다 사용할 CPU를 지정, 메모리 모듈이 주소 접근 가능과 캐시 사용 등 추가적인 것들을 신경 써야 할 것입니다. 다행히도 우리의 노트북은 자원관리의 복잡성에서 떨어져 있는 추상화 운영체제를 가지고 있습니다.

사실 우리의 워크스테이션, 서버, 메인프레임, 슈퍼컴퓨터, 모바일 장치를 위한 운영체제가 있으며 각자 자신의 고유한 기능과 폼 팩터에 최적화되어 있습니다.

우리는 이미 하나의 거대한 창고 크기의 컴퓨터와 데이터 센터를 처리하고 있습니다. 하지만 여전히 우리가 랩톱을 사용하는 것처럼 추상화와 하드웨어 자원을 관리하는 운영체제는 없습니다.


데이터 센터를 위한 운영체제의 때

어떤 것이 데이터 센터를 위한 운영체제로 보이나요?
운영자의 관점에선 응용 프로그램이 실행될 수 있는 자원이 집결된 하나의 거대한 풀이 데이터 센터(또는 클라우드)에 모든 시스템에 걸쳐져 있습니다. 모든 응용 프로그램은 이미 시스템에서 실행 중인 다른 응용 프로그램이 있는 경우에도, 모든 시스템에서 사용 가능한 자원을 실행할 수 있기 때문에 특정 응용 프로그램에 대한 특정 시스템은 구성하지는 않을 것입니다.
개발자의 관점에선, 데이터 센터의 운영체제가 응용 프로그램과 시스템 간의 중개를 하면서 일반적인 기본적인 것을 쉽게 하는 것을 촉진해주면서 분산 응용 프로그램 개발을 쉽게 해주는 것을 바랍니다.
데이터 센터 운영체제를 위해 리눅스나 우리가 사용하는 데이터 센터에서 사용하는 다른 호스트 운영체제를 대체 할 필요는 없을 것입니다. 데이터 센터 운영체제는 호스트 운영체제 위에 소프트웨어 스택을 제공합니다. 호스트 운영체제를 지속해서 사용하기 위해선 바로 기존의 응용프로그램을 지원하는 표준 실행 환경을 지원하는 것이 중요합니다.
즉, 자원 관리와 프로세스 격리를 말하는데, 데이터 센터 운영체제는 호스트 운영체제는 단일 시스템상에 현재 제공하는 것과 유사 데이터 센터 기능을 제공하기 위한 것입니다. 다만 호스트 운영체제와 같이, 데이터 센터 운영체제는 이러한 응용 프로그램 간의 관계를 명확하게 분리하며, 공유된 자원 모음들에 걸쳐(여러 개의 프로세스로 구성) 동시에 여러 응용 프로그램을 실행하는 다수의 사용자를 활성화합니다.


데이터 센터를 위한 API

아마도 데이터 센터 운영체제 정의의 특징은 분산 응용 프로그램을 개발하기 위한 소프트웨어 인터페이스를 제공한다는 것입니다. 호스트 운영체제에 대한 시스템 호출 인터페이스와 유사하게, 데이터 센터 운영체제 API는 응용 프로그램 자원 할당 및 할당 해제, 출시, 관찰, 그리고 프로세스 파괴 기능 등이 더 있을 것입니다. API는 모든 분산 시스템이 필요로 하는 똑같은 기능을 구현하는 기본 요소를 제공합니다. 따라서 개발자는 독립적으로 기초적인 분산 시스템의 기본 요소를 다시 구현 할(그리고 필연적으로, 독립적으로 같은 버그와 성능 문제로 고통받을) 필요가 없을 것입니다.
기초적인 API 안에서 공통된 기능을 중앙 집중화를 더 쉽게, 더 안전하게, 더 빨리 새로운 분산 응용 프로그램을 개발하는 데 사용하는 것입니다. 이는 호스트 운영체제에 가상메모리가 추가될 때를 연상시킵니다. "그것은 1960년대 초에 운영체제의 설계자들이 자동 스토리지 할당이 프로그래밍을 크게 단순화할 수 있다는 것은 매우 분명했습니다." 사실, 가상 메모리 선구자 중 한 명이 썼습니다.

 

기초적인 사례 

 

데이터 센터 운영체제의 특징 두 개는 그 즉시 분산 응용 프로그램은 서비스 검색 및 조정이 간단하다는 것입니다. 응용 프로그램이 다른 응용 프로그램에 발견될 필요가 거의 없는 단일 호스트와는 달리 발견은 분산 응용 프로그램을 위한 표준입니다. 마찬가지로, 대부분의 분산 응용 프로그램은 조정 및 합의의 몇 가지 방법을 통해 높은 가용성 및 내결함성을 이루고 있지만, 이를 정확하고 효율적으로 구현하는 것은 몹시 어렵습니다. 개발자들은 현재 서비스 검색 및 조정을 위해 아파치 ZooKeeper와 Core OS 같은 등등의 기존의 도구들을 사용하도록 강요하고 있습니다. 이 때문에 서로 다른 응용 프로그램에 대해 여러 도구를 배포할 수 있도록 해주며 운영의 복잡성과 유지 보수성을 매우 증가 시킬 수 있습니다. 

개발을 단순화하면서 데이터 센터 운영체제가 발견과 조정을 위하여 기본적인 것을 제공하는 것 뿐만 아니라 응용 프로그램 편의성도 제공합니다. 많은 사용자가 현재 호스트 운영체제에 다른 파일 시스템 구현을 선택할 수 있으며, 조직에선 응용 프로그램을 다시 작성하지 않고 기본적인 구현을 변경할 수 있습니다. 

 

응용 프로그램을 배포하는 새로운 방법

현재 데이터 센터의 운영체제, 소프트웨어 인터페이스는 개발자가 일반적인 응용 프로그램을 배포하고자 할 때 개발자가 사람에게 물어 제공하는 상호작용을 대체하는 자신의 응용프로그램을 실행하는 시스템을 구성하거나 개발자는 (예를 들면 CLI 또는 GUI를 통해) 데이터 센터 운영체제를 사용하는 응용 프로그램을 실행하고 응용 프로그램은 데이터 센터 운영체제의 API를 사용하여 실행하는 것을 휴먼 인터페이스라 말합니다.
운영자는 각 사용자에게 할당 가능한 자원의 양을 지정하고, 사용자는 그들에게 사용할 수 있는 어떤 자원을 사용하여, 그들이 원하는 응용 프로그램을 실행하는데 이 기능을 이용하면 사용자 간의 우려를 깨끗하게 없앨 수 있습니다. 왜냐하면 운영자가 현재 어느 특정 자원, 데이터 센터 운영체제 및 상부에서 실행되는 분산 응용 프로그램을 사용할 수 있지만 자원을 더욱 어떻게, 어떤 유형의 자원의 양을 지정하며 자원 사용에 대한 추가적인 인텔리전트를 보다 효율적으로 실행하면서 실패 핸들을 좋게 합니다. 대부분의 분산 응용 프로그램은 복잡한 스케줄링 요구 사항을 가지고 있기 때문에 실패 복구를 위한 특정 요구(데이터베이스를 생각하십시오), 소프트웨어 의사 결정 대신에 인간이 데이터 센터 규모를 운영을 효율적으로 하는 것을 힘을 실어줘야 합니다(아파치 하둡을 생각하십시오).


"클라우드"는 운영체제가 아닙니다

우리는 왜 새로운 운영체제를 필요로 할까요? laaS 와 PaaS는 이미 이러한 문제를 해결하지 않았을까요?
laaS 는 여전히 시스템에 초점을 맞추고 있기 때문에 우리의 문제를 해결하지 않습니다. 이는 응용프로그램이 실행하기 위해 사용을 위한 소프트웨어 인터페이스로 설계되지 않습니다. laaS는 (가상)머신으로 머신을 켰지만 머신의 상단에 개발자가 쉽게 분산 응용 프로그램을 개발할 수 있도록 하는 기본 요소는 제공하지 않고 준비된 가상 머신에 다른 사람의 애플리케이션을 배포하기 위해 설계되어있습니다.
PaaS는 다른 한편으로, 머신은 추상화와는 멀어있으며 사람이 소비하도록 설계되어있습니다. 대부분의 PaaS 솔루션은 쉽게 분산 응용 프로그램을 개발하기 위해 다수의 접선 서비스와 통합을 포함하게 하지만 다른 PaaS 솔루션 이식의 방법은 없습니다.

 

 

아파치 메소스 : 분산 시스템 커널

분산 컴퓨팅은 이제 예외가 아니라 표준이며, 추상화 계층 분산 응용 프로그램을 위한 이식성 높은 API를 제공하는 데이터 센터 운영체제가 필요합니다. 우리의 산업을 방해하는 것은 아닙니다. 개발자는 똑같은 기능을 다시 구현하지 않고도 분산 응용 프로그램을 개발할 수 있어야 합니다. 하나의 조직에 내장되어있는 분산 응용 프로그램을 다른 조직에서 쉽게 실행할 수 있어야 합니다.
기존의 클라우드 컴퓨팅 솔루션 및 API는 충분하지 않습니다. 또한, 데이터 센터 운영체제 API는 리눅스와 비슷하게 개방과 협력 방식으로 개발해야 합니다. 독점 API로 강제한다면 건강하고 혁신적인 시스템 성장을 억제할 수 있습니다. 데이터 센터 또는 클라우드에서 실행될 수 있는 이식성 있는 API를 위해 분산 컴퓨팅에 대한 POSIX를 작성할 때입니다.
저는 아파치 메소스(Apache Mesos) 오픈소스 프로젝트 공동 제작자 겸 의장이며 아파치 메소스는 그 방향의 한 단계입니다. 아파치 메소스는 내장하고 실행할 수 있는 분산 응용프로그램에 이식성 높은 API를 제공하는 분산 시스템 커널이 되는 것을 목표로 하고 있습니다.
유명한 분산 시스템은 이미 메소스 위에서 직접 개발되었습니다. 아파치 스파크(Apache Aurora), 아파치 오로라(Apache Aurora), 에어비엔비(Airbnb)의 크로노스(Chronos)와 메소스페어(Mesosphere)의 마라톤(Marathon)도 포함됩니다. 메소스 위에 실행 및 이식된 다른 인기 분산 시스템은 아파치 하둡(Hadoop)을 포함하여 아파치 스톰(Storm), 구글의 쿠버네테스(Kubernetes)가 있습니다.
크로노스는 메소스 위에 개발된 매력적인 예시입니다. 크로노스는 코드 몇만 줄의 메소스 위에 네트워크 통신을 위한 명시적인 소켓 프로그래밍을 하지 않고도 개발된 높은 가용성과 내결함성 크론을 제공하는 분산 시스템입니다.
구글과 같은 기업들이 거의 십 년 전에 만들어진 사내 솔루션을 사용하고 있는 동안 트위터와 에어비엔비 같은 회사는 이미 자신의 데이터 센터를 실행할 수 있도록 메소스를 사용하고 있습니다. 사실, 단지 구글의 맵리듀스는 하둡과 관련된 사업에 박차를 가했으며, 구글의 자체 데이터 센터 솔루션은 메소스의 발전과 밀접한 관련이 있습니다.

완전한 데이터 센터 운영체제가 아닌, 메소스에서 동작하는 분산 응용 프로그램 일부와 함께 전체 데이터 센터 운영체제가 내장될 수 있는 필수적인 개발 블록의 일부인 커널(메소스), 분산된 init.d(마라톤 / 오로라), 크론 (크로노스) 등을 제공하는 것입니다.
메소스를 공부하고 싶거나 기여에 관심이 있으신가요? mesos.apache.org를 확인하고 트위터 @ApacheMesos를 팔로우 하십시오. 우리는 트위터, 에어비엔비, 허브스팟, 오픈테이블, 이베이/페이팔, 넷플릭스, 그루폰 등과 같은 회사와 같이 성장하는 커뮤니티이며 더 늘어날 것입니다.