2014.11.12

리뷰|코어OS, "가볍지만 뛰어난 가상 머신"

Tom Henderson | Network World
코어OS(Core OS)는 많은 운영체제 인스턴스를 쉽게 만들 수 있는 '가벼운' 리눅스 배포판이다. 필자는 이 개념이 맘에 든다.

코어OS는 도커(Docker)를 이용해 가상 컨테이너에 애플리케이션을 배치한다. 또한 관리 커뮤니케이션 버스와 그룹 인스턴스 관리가 특징이다.

랙스페이스(Rackspace), 아마존 웹 서비스(AWS), 구글컴퓨터엔진(GCE), 브라이트박스(Brightbox) 등 클라우드 공급업체들은 코어OS와 호환이 되고, 코어OS를 전용으로 지원한다.

필자는 랙스페이스와 AWS에서 테스트를 해봤고, 잠시 로컬 환경에서도 배치했었다.

코어OS는 가볍다. 전반적으로 메모리를 적게 사용한다는 주장에 의심을 가졌었고, 결국 사용할 수 없는 한계에 다다르지 않을까 궁금했다. 그리고 일부의 경우에는 많은 메모리를 절약해주고, 아주 강력하고 특정 환경에서 유용하다는 사실을 발견했다.

코어OS는 우분투(Ubuntu)와 유사한 점이 많다. 무료이며 GPLv3 라이선스 기반이다. 우분투 14.04와 코어OS는 동일한 커널을 사용한다. 둘 모두 쉽게 맞춤화 할 수 있으며, 독자 버전을 개발할 수 있다. 그러나 코어OS는 우분투에서 해야하는 기본적인 프로세스의 약 절반 가량을 피할 수 있다.

많은 운영 시스템 인스턴스 내부에 포함된 블로트웨어(Bloatware)를 싫어한다면, 코어OS가 맘에 들 것이다. 테스트 과정에서 코어OS는 아주 효율적이었다. 리눅스 커널이고, 소속 기업이 운영체제에 정통하다면 성능과 확장성 측면에서 큰 장점을 확인할 수 있을 것이다.

문제가 될 수 있는 보안
코어OS는 통신과 SSL에 CURL을 사용한다. 필자는 인스턴스 조정에 '베스트 프랙티스' 외부 SSL 인증 권한을 표준으로 추가할 것을 권장한다.

그렇지 않을 경우, 동적인 인스턴트 간 SSL을 생성하고, 관계를 관리하느라 정신이 없을 것이다. 또한 코어OS는 서명 인증서를 이용해 업데이트를 전송한다.

이렇게 SSL 보안 제어(security control)를 추가시키면, 몇 개 스크립트를 이용해 효율적으로 확장할 수 있다. SSL 인증과 권한을 루트 인증에 투자한 효과는 바로 여기에서 누릴 수 있다. 물론 보통은 '별것 아닌' 인스턴스에 SSL을 사용하면서 비용이 추가 발생할 수 있다. 하지만 여기에서만 신속하게 통신을 보안 처리하면 된다. 그러니 이 방법을 사용해보자.

얻을 수 있는 것
코어OS는 강력한 인스턴스를 빠르게 배치할 수 있는 간소화된 리눅스 배포판이다. 인기 있는 배포판과 '생태계'에 일반적인 데몬(Daemon) 찌꺼기와 시스템 메모리를 덜어낸 배포판이다. 인기있는 배포판들이 시간이 지나면서 각종 기능으로 덤벅이 된다는 점에서 경쟁력이 있는 개념이다.

더 많은 메모리를 쓸 수 있다는 것은 더 많은 앱을 실행시킬 수 있다는 의미다. 그리고 코어OS는 이를 컨테이너에서 실행시킨다. 초기이기는 하지만 자체 통신 버스와 함께 최저 비용과 최소 관리 부담으로 많은 인스턴스(그리고 앱)를 실행시킬 수 있다.

컨테이너화된 인스턴스의 경우, 제어된 절차를 적용하고, 이를 이용해 무결성을 모니터링 할 수 있다. 코어OS 인스턴스의 수명주기 관리도 어렵지 않다. RESTful 명령어가 어려운 작업 대부분을 처리한다.

코어OS에는 리눅스 커널, LXC 기능, etcd/ etcd 데몬 서비스 발견/ 데몬 제어, 도커, 애플리케이션 컨테이너화 시스템, 그리고 여러 배포판에서 다양한 initd(초기 데몬)을 대체한 start/ stop 프로세스 컨트롤러인 systemd가 탑재되어 있다.

fleet를 이용해 여러 인스턴스를 관리한다. fleet는 정기적으로 많은 앱/OS 인스턴스의 인스턴스와 풀을 시작할 때 도움이 된다.

우분투 및 레드햇(RedHat)과 마찬가지로 systemd 데몬을 인터페이스 관리 메커니즘으로 사용하며, 우분투 14.04와 레드햇 EL7에서 사용하는 것과 동일한 최신 커널이 들어있다. 많은 업데이트된 systemd 기반 스크립트를 변경없이 사용할 수 있다.

fleetd는 사용자 공간 명령어인 fleetctl이 제어하며, 프로세스를 인스턴스화한다. etcd 데몬은 저수준과 CLI(Command Line Interface) 스타일의 모니터링에 etcdctl을 이용하는, 통신 버스와 같은 서비스 발견 기능이다.

etcd는 간단한 동사들로 REST 명령어를 수용할 때 사용된다. 이는 RESful API 세트를 사용하며, 퍼핏(Puppet), 셰프(Chef), 또는 다른 서비스 버스 통신 버스 컨트롤러가 아닌 '린/타이트(가벼운)' 통신 기법이다. 이는 유닉스/리눅스 개발자와 관리자가 이해할 수 있도록 한다.

단점은 컨테이너와 인스턴스 스프롤(Sprawl)이 아주 쉽게 발생한다는 것이다. 많은 인스턴스를 마음대로 '배치(fire)' 할 수 있다. 자사의 회계부서가 AWS나 구글 컴퓨트 엔진(GCE)에서 날아온 청구 비용에 화가 났음을 경고해 줄 정도의 똑똑하고, 시스템 전반을 포괄하는 모니터링 메커니즘과는 거리가 멀다. 해체(Teardown)를 강제할 수 없지만, 어렵지는 않다.

각 운영체제를 동일 플랫폼에서 1GB 메모리로 설정, 우분투 14.0.4와 코어OS의 메모리 차이를 알아보는 테스트를 했다. 동일한 커널(리눅수 3.12)이었고, 기본 설정을 사용했다.

'스왑(Swap)'이 상태 머신(State Machine) 내부에서 CPU/메모리 균형을 바꾸기 전에는 코어OS 앱의 가용 메모리가 28~44% 더 많았다.

I/O나 다른 서비스를 필요로 하기까지는 앱 실행 속도가 향상되고, 메모리 요구량이 적고, 캐시도 클 수 있다는 의미다. 상태 머신의 성능이 실제 향상될 지는 앱의 호스트 사용 방식에 달려있다. 그러나 메모리 사용량 차이와 블로트의 전반적인 감소(보안 공격이 표면화될 가능성이 있음)는 테스트할 가치가 있다.

AWS, GCE, 60코어 HP DL-580 Gen8에 기반한 내부 호스팅 플랫폼 모두 테스트 결과가 유사했다. 테스트할 때 사용한 HP 서버의 경우, 도커 인스턴스를 의지하지 않고, 서버 메모리를 최대인 6TB로 확장하면 수백 개의 인스턴스를 처리할 수 있을 것이다.

많은 코어OS 인스턴스를 쉽게 가져와, 제어하고, 저마다의 ID와 IP로 컨테이너화 하고, 컨테이너를 작동시키고, 이를 폐쇄할 수 있다. 대부분은 직접 명령어가 아닌 셸 스크립트를 쓴다.

제안한 스크립트는 탬플릿 역할을 할 수 있으며, 기능을 쉽게 복제하고 스프롤을 관리하는 더 많은 탬플릿이 출현하고 있다. 인스트루먼테이션(Instrumentation)을 찾고 있다면 다른 '화려한' UI를 선택하라. High-vocabulary 통신 인프라스트럭처도 마찬가지다.

데몬과 widgetry를 추가하기 시작한 이후에는 우분투나 레드햇으로 돌아갈 수 있다. 하지만 동일한 속도로 복구할 수 없었던 실수를 저지를 수 있다는 점을 알아야 한다. 또한 신텍스(Syntax) 검사와 많은 SSL 키 사용을 제외하고는 보안 처리가 미흡하다는 점을 상기시키고 싶다.

또 수백 개 운영체제의 인스턴스를 만들 수 있다. 각각에는 100개의 도커 컨테이너 앱이 있는데 모두 조화롭게 실행되기를 기대해야 한다. 크립트(Crypt)가 사용된다. su/root 구현을 위해 키를 준비해야 한다는 의미다. 그렇지 않다면 독자적으로 준비해야 한다.

결론
코어OS는 불필요한 부분을 덜어내고, 데몬을 사용하지 않는 가벼운 인스턴스다. 더 많은 메모리를 사용할 수 있고, 속도를 낮추는 메모리 변동(memory churn) 현상이 일어날 가능성이 낮다.

위젯과 데몬도 적기 때문에 공격 노출면이 더 적다. 블로트가 없기 때문에 엔지니어가 원하는 자원과 필요 자원을 정확히 일치시킬 수 있다.

코어OS는 크게 자가 지원(self-support), 자체 측정(your own instrumentation), 풍부한 스크립트 구축을 의미하며, 다목적의 엄청난 기능이 탑재된 범용 컴퓨팅 엔진의 화려함과 어리석음으로부터 해방된 기술이다.

한번 테스트를 해보고 싶지 않는가? 실제 인스턴스에 더 많은 메모리를 사용하기를 원하지 않는가? 조금의 번거로움은 개의치 않는가? 그렇다면 코어OS가 제격일 수 있다. editor@itworld.co.kr


2014.11.12

리뷰|코어OS, "가볍지만 뛰어난 가상 머신"

Tom Henderson | Network World
코어OS(Core OS)는 많은 운영체제 인스턴스를 쉽게 만들 수 있는 '가벼운' 리눅스 배포판이다. 필자는 이 개념이 맘에 든다.

코어OS는 도커(Docker)를 이용해 가상 컨테이너에 애플리케이션을 배치한다. 또한 관리 커뮤니케이션 버스와 그룹 인스턴스 관리가 특징이다.

랙스페이스(Rackspace), 아마존 웹 서비스(AWS), 구글컴퓨터엔진(GCE), 브라이트박스(Brightbox) 등 클라우드 공급업체들은 코어OS와 호환이 되고, 코어OS를 전용으로 지원한다.

필자는 랙스페이스와 AWS에서 테스트를 해봤고, 잠시 로컬 환경에서도 배치했었다.

코어OS는 가볍다. 전반적으로 메모리를 적게 사용한다는 주장에 의심을 가졌었고, 결국 사용할 수 없는 한계에 다다르지 않을까 궁금했다. 그리고 일부의 경우에는 많은 메모리를 절약해주고, 아주 강력하고 특정 환경에서 유용하다는 사실을 발견했다.

코어OS는 우분투(Ubuntu)와 유사한 점이 많다. 무료이며 GPLv3 라이선스 기반이다. 우분투 14.04와 코어OS는 동일한 커널을 사용한다. 둘 모두 쉽게 맞춤화 할 수 있으며, 독자 버전을 개발할 수 있다. 그러나 코어OS는 우분투에서 해야하는 기본적인 프로세스의 약 절반 가량을 피할 수 있다.

많은 운영 시스템 인스턴스 내부에 포함된 블로트웨어(Bloatware)를 싫어한다면, 코어OS가 맘에 들 것이다. 테스트 과정에서 코어OS는 아주 효율적이었다. 리눅스 커널이고, 소속 기업이 운영체제에 정통하다면 성능과 확장성 측면에서 큰 장점을 확인할 수 있을 것이다.

문제가 될 수 있는 보안
코어OS는 통신과 SSL에 CURL을 사용한다. 필자는 인스턴스 조정에 '베스트 프랙티스' 외부 SSL 인증 권한을 표준으로 추가할 것을 권장한다.

그렇지 않을 경우, 동적인 인스턴트 간 SSL을 생성하고, 관계를 관리하느라 정신이 없을 것이다. 또한 코어OS는 서명 인증서를 이용해 업데이트를 전송한다.

이렇게 SSL 보안 제어(security control)를 추가시키면, 몇 개 스크립트를 이용해 효율적으로 확장할 수 있다. SSL 인증과 권한을 루트 인증에 투자한 효과는 바로 여기에서 누릴 수 있다. 물론 보통은 '별것 아닌' 인스턴스에 SSL을 사용하면서 비용이 추가 발생할 수 있다. 하지만 여기에서만 신속하게 통신을 보안 처리하면 된다. 그러니 이 방법을 사용해보자.

얻을 수 있는 것
코어OS는 강력한 인스턴스를 빠르게 배치할 수 있는 간소화된 리눅스 배포판이다. 인기 있는 배포판과 '생태계'에 일반적인 데몬(Daemon) 찌꺼기와 시스템 메모리를 덜어낸 배포판이다. 인기있는 배포판들이 시간이 지나면서 각종 기능으로 덤벅이 된다는 점에서 경쟁력이 있는 개념이다.

더 많은 메모리를 쓸 수 있다는 것은 더 많은 앱을 실행시킬 수 있다는 의미다. 그리고 코어OS는 이를 컨테이너에서 실행시킨다. 초기이기는 하지만 자체 통신 버스와 함께 최저 비용과 최소 관리 부담으로 많은 인스턴스(그리고 앱)를 실행시킬 수 있다.

컨테이너화된 인스턴스의 경우, 제어된 절차를 적용하고, 이를 이용해 무결성을 모니터링 할 수 있다. 코어OS 인스턴스의 수명주기 관리도 어렵지 않다. RESTful 명령어가 어려운 작업 대부분을 처리한다.

코어OS에는 리눅스 커널, LXC 기능, etcd/ etcd 데몬 서비스 발견/ 데몬 제어, 도커, 애플리케이션 컨테이너화 시스템, 그리고 여러 배포판에서 다양한 initd(초기 데몬)을 대체한 start/ stop 프로세스 컨트롤러인 systemd가 탑재되어 있다.

fleet를 이용해 여러 인스턴스를 관리한다. fleet는 정기적으로 많은 앱/OS 인스턴스의 인스턴스와 풀을 시작할 때 도움이 된다.

우분투 및 레드햇(RedHat)과 마찬가지로 systemd 데몬을 인터페이스 관리 메커니즘으로 사용하며, 우분투 14.04와 레드햇 EL7에서 사용하는 것과 동일한 최신 커널이 들어있다. 많은 업데이트된 systemd 기반 스크립트를 변경없이 사용할 수 있다.

fleetd는 사용자 공간 명령어인 fleetctl이 제어하며, 프로세스를 인스턴스화한다. etcd 데몬은 저수준과 CLI(Command Line Interface) 스타일의 모니터링에 etcdctl을 이용하는, 통신 버스와 같은 서비스 발견 기능이다.

etcd는 간단한 동사들로 REST 명령어를 수용할 때 사용된다. 이는 RESful API 세트를 사용하며, 퍼핏(Puppet), 셰프(Chef), 또는 다른 서비스 버스 통신 버스 컨트롤러가 아닌 '린/타이트(가벼운)' 통신 기법이다. 이는 유닉스/리눅스 개발자와 관리자가 이해할 수 있도록 한다.

단점은 컨테이너와 인스턴스 스프롤(Sprawl)이 아주 쉽게 발생한다는 것이다. 많은 인스턴스를 마음대로 '배치(fire)' 할 수 있다. 자사의 회계부서가 AWS나 구글 컴퓨트 엔진(GCE)에서 날아온 청구 비용에 화가 났음을 경고해 줄 정도의 똑똑하고, 시스템 전반을 포괄하는 모니터링 메커니즘과는 거리가 멀다. 해체(Teardown)를 강제할 수 없지만, 어렵지는 않다.

각 운영체제를 동일 플랫폼에서 1GB 메모리로 설정, 우분투 14.0.4와 코어OS의 메모리 차이를 알아보는 테스트를 했다. 동일한 커널(리눅수 3.12)이었고, 기본 설정을 사용했다.

'스왑(Swap)'이 상태 머신(State Machine) 내부에서 CPU/메모리 균형을 바꾸기 전에는 코어OS 앱의 가용 메모리가 28~44% 더 많았다.

I/O나 다른 서비스를 필요로 하기까지는 앱 실행 속도가 향상되고, 메모리 요구량이 적고, 캐시도 클 수 있다는 의미다. 상태 머신의 성능이 실제 향상될 지는 앱의 호스트 사용 방식에 달려있다. 그러나 메모리 사용량 차이와 블로트의 전반적인 감소(보안 공격이 표면화될 가능성이 있음)는 테스트할 가치가 있다.

AWS, GCE, 60코어 HP DL-580 Gen8에 기반한 내부 호스팅 플랫폼 모두 테스트 결과가 유사했다. 테스트할 때 사용한 HP 서버의 경우, 도커 인스턴스를 의지하지 않고, 서버 메모리를 최대인 6TB로 확장하면 수백 개의 인스턴스를 처리할 수 있을 것이다.

많은 코어OS 인스턴스를 쉽게 가져와, 제어하고, 저마다의 ID와 IP로 컨테이너화 하고, 컨테이너를 작동시키고, 이를 폐쇄할 수 있다. 대부분은 직접 명령어가 아닌 셸 스크립트를 쓴다.

제안한 스크립트는 탬플릿 역할을 할 수 있으며, 기능을 쉽게 복제하고 스프롤을 관리하는 더 많은 탬플릿이 출현하고 있다. 인스트루먼테이션(Instrumentation)을 찾고 있다면 다른 '화려한' UI를 선택하라. High-vocabulary 통신 인프라스트럭처도 마찬가지다.

데몬과 widgetry를 추가하기 시작한 이후에는 우분투나 레드햇으로 돌아갈 수 있다. 하지만 동일한 속도로 복구할 수 없었던 실수를 저지를 수 있다는 점을 알아야 한다. 또한 신텍스(Syntax) 검사와 많은 SSL 키 사용을 제외하고는 보안 처리가 미흡하다는 점을 상기시키고 싶다.

또 수백 개 운영체제의 인스턴스를 만들 수 있다. 각각에는 100개의 도커 컨테이너 앱이 있는데 모두 조화롭게 실행되기를 기대해야 한다. 크립트(Crypt)가 사용된다. su/root 구현을 위해 키를 준비해야 한다는 의미다. 그렇지 않다면 독자적으로 준비해야 한다.

결론
코어OS는 불필요한 부분을 덜어내고, 데몬을 사용하지 않는 가벼운 인스턴스다. 더 많은 메모리를 사용할 수 있고, 속도를 낮추는 메모리 변동(memory churn) 현상이 일어날 가능성이 낮다.

위젯과 데몬도 적기 때문에 공격 노출면이 더 적다. 블로트가 없기 때문에 엔지니어가 원하는 자원과 필요 자원을 정확히 일치시킬 수 있다.

코어OS는 크게 자가 지원(self-support), 자체 측정(your own instrumentation), 풍부한 스크립트 구축을 의미하며, 다목적의 엄청난 기능이 탑재된 범용 컴퓨팅 엔진의 화려함과 어리석음으로부터 해방된 기술이다.

한번 테스트를 해보고 싶지 않는가? 실제 인스턴스에 더 많은 메모리를 사용하기를 원하지 않는가? 조금의 번거로움은 개의치 않는가? 그렇다면 코어OS가 제격일 수 있다. editor@itworld.co.kr


X