2016.08.25

리눅스 25주년 : 컨테이너와 유니커널로 입증된 '적을수록 좋다'

Serdar Yegulalp | InfoWorld

리눅스의 25년 역사를 통틀어 변치 않은 한 가지가 있다면 바로 변화다. 커널 자체도 수십 번의 개정을 거쳤고 거의 모든 사용 사례를 위한 리눅스 배포판이 만들어졌다. 가벼운 취미 프로젝트로 시작된 리눅스 문화는 이후 전세계 IT 인프라의 토대로 발전했다.

지금은 리눅스에 불어 닥칠 다음 변화의 물결이 시작되어 그 첫 번째 결과물들이 나오고 있다. 컨테이너화, 유니커널을 비롯한 여러 실험이 리눅스를 근본적으로 변화시키면서 오픈소스 운영체제로서 그 역량을 입증한 리눅스를 위한 새로운 길을 열고 있다.

리눅스의 컨테이너 혁명(또는 발전)
컨테이너는 리눅스의 재창조에서 큰 부분을 차지한다. 컨테이너는 애플리케이션, 나아가 전체 가상 시스템 간에 높은 수준의 격리를 가능하게 해주면서, 일반적으로 하이퍼바이저 스타일의 VM에 수반되는 오버헤드도 없다.

컨테이너의 놀라운 점은 소프트웨어 개발과 운영에 관한 논의를 격상시켰다는 데만 있지 않다. 컨테이너의 모든 기술은 이미 오래 전부터 리눅스에 기본적으로 존재했는데, 누군가가 상품화한 이후부터 리눅스 재창조의 동력이 되었다는 점 역시 놀라운 부분이다.

리눅스의 컨테이너 기술 중 가장 눈에 띄고 중심이 되는 기술은 도커(Docker)다. 도커는 애플리케이션을 격리 상태로 실행시키고 패키징하고 전달하고 관리하고 스케줄링하는 데 사용되는 소프트웨어 제품이다. 도커는 리눅스 커널에 이미 존재하는 기술을 가져다(주로 cgroup과 namespace) 이를 포장하기 위한 편리한 메타포, 프론트 엔드, 워크플로를 제공했다.

도커가 부상하고 얼마 지나지 않아 사람들은 급진적인 개념들을 실험하기 시작했다. 리눅스의 껍질을 다 벗겨내고 단순한 부팅 메커니즘, 시동 시스템, 그리고 컨테이너를 실행하고 관리하기 위한 수단으로 만들면 어떨까? 네트워킹과 스토리지 관리를 위한 임베디드 리눅스와 같이 컨테이너를 위한 리눅스를 만들면 좋지 않을까? 그렇게 해서 코어OS(CoreOS)가 태어났다.

코어OS는 단순히 색다른 무언가를 위해 만들어진 것이 아니다. 많은 이유가 있지만 그 중 하나는 축소판 리눅스가 관리하고 유지하기 더 쉽고, 공격으로부터 보호하기 쉽고, 하트블리드(Heartbleed) 또는 셸쇼크(Shellshock)에 직면한 경우 되살리기도 더 쉬울 것이라는 데 있다.

도커의 성공과 코어OS의 실험에 자극을 받은 다른 리눅스 배포판들도 비슷한 개념을 시도하기 시작했다. 레드햇은 제품군 전반에 대규모 컨테이너 실행 지원을 내장했고, 컨테이너 중심의 자체 리눅스인 레드햇 아토믹 호스트(Atomic Host)도 출시했다.

어떤 면에서 아토믹 호스트는 코어OS와 비슷하다. 즉, 컨테이너를 실행하는 것 외의 다른 기능은 거의 없는 간소화된 리눅스 버전이다. 그러나 레드햇의 의도는 단순히 미니멀한 시스템을 만들고 끝내는 것이 아니었다. 대신 레드햇은 아토믹 호스트를 전체 리눅스 배포판을 구축하기 위한 기반으로 삼고 컨테이너를 사용해 플랫폼에서의 소프트웨어 설치를 관리하는 방법을 택했다. 아직 전통적인 리눅스 패키지 관리의 필요성을 완전히 대체하지는 못했지만 보완적인 기능을 제공한다.

캐노니컬(Canonical)도 마찬가지로 컨테이너 기반인 스내피(Snappy) 애플리케이션 패키징 시스템을 통해 이와 유사한 방식을 도입했다. 원래 우분투 폰 OS에 업데이트를 배포하기 위한 목적으로 개발된 스내피는 컨테이너를 사용해서 데이터베이스 트랜잭션과 같은 방식으로 소프트웨어 설치를 처리한다.

유니커널 : 딱 필요한 만큼만
커널과 일부 컨테이너만 남길 정도로 간소화한 리눅스마저 무겁다고 생각한 사람들은 커널과 애플리케이션 하나만 남기고 그 외의 불필요한 것은 아무것도 포함하지 않는 리눅스 프로젝트를 시작했다. 이른바 "유니커널" 접근 방법이다.

유니커널은 컨테이너와 마찬가지로 새로운 개념이 아니다. 수십 년 전부터 형태를 달리하며 계속 존재해왔다. 유니커널은 작은 크기와 빠른 부팅, 최소화된 공격 표면을 대표적인 장점으로 내세우지만, 만들기는 더 복잡하다. 전통적으로 이러한 프로젝트는 리눅스를 채택하지 않고 전용으로 만든 맞춤형 커널을 사용하거나 젠 프로젝트(Xen Project)의 미니OS(MiniOS)와 같이 최소화된 커널을 기반으로 사용했다.

리눅스를 유니커널의 기반으로 사용할 수 있는 한 가지 방법은 "라이브러리 OS" 형태다. 여기서 사실상 리눅스 커널은 애플리케이션에 연결되는 거대한 코드 라이브러리가 된다. 그라핀 라이브러리 OS(Graphene Library OS)가 이 방식을 사용하는 프로젝트로, 부팅 가능한 커널 안에 "네이티브 비수정 리눅스 애플리케이션"을 내장하는 형태로 컴파일이 가능하다.

유니커널과 리눅스의 또 다른 눈에 띄는 예는 도커에서 찾아볼 수 있다. 도커는 다양한 시나리오에서 유니커널을 유니커널 시스템즈(Unikernel Systems)를 인수했고, 그 기술 일부를 맥 및 윈도우용 도커 제품에 적용했다. 원래 데스크톱에서 도커를 실행하려면 버추얼박스(VirtualBox) 기반의 온전한 리눅스 배포판을 부팅해야 했지만 이제 각 플랫폼의 네이티브 가상화 기술을 사용해 도커 엔진이 내장된 맞춤형 리눅스 커널을 부팅하면 된다.



2016.08.25

리눅스 25주년 : 컨테이너와 유니커널로 입증된 '적을수록 좋다'

Serdar Yegulalp | InfoWorld

리눅스의 25년 역사를 통틀어 변치 않은 한 가지가 있다면 바로 변화다. 커널 자체도 수십 번의 개정을 거쳤고 거의 모든 사용 사례를 위한 리눅스 배포판이 만들어졌다. 가벼운 취미 프로젝트로 시작된 리눅스 문화는 이후 전세계 IT 인프라의 토대로 발전했다.

지금은 리눅스에 불어 닥칠 다음 변화의 물결이 시작되어 그 첫 번째 결과물들이 나오고 있다. 컨테이너화, 유니커널을 비롯한 여러 실험이 리눅스를 근본적으로 변화시키면서 오픈소스 운영체제로서 그 역량을 입증한 리눅스를 위한 새로운 길을 열고 있다.

리눅스의 컨테이너 혁명(또는 발전)
컨테이너는 리눅스의 재창조에서 큰 부분을 차지한다. 컨테이너는 애플리케이션, 나아가 전체 가상 시스템 간에 높은 수준의 격리를 가능하게 해주면서, 일반적으로 하이퍼바이저 스타일의 VM에 수반되는 오버헤드도 없다.

컨테이너의 놀라운 점은 소프트웨어 개발과 운영에 관한 논의를 격상시켰다는 데만 있지 않다. 컨테이너의 모든 기술은 이미 오래 전부터 리눅스에 기본적으로 존재했는데, 누군가가 상품화한 이후부터 리눅스 재창조의 동력이 되었다는 점 역시 놀라운 부분이다.

리눅스의 컨테이너 기술 중 가장 눈에 띄고 중심이 되는 기술은 도커(Docker)다. 도커는 애플리케이션을 격리 상태로 실행시키고 패키징하고 전달하고 관리하고 스케줄링하는 데 사용되는 소프트웨어 제품이다. 도커는 리눅스 커널에 이미 존재하는 기술을 가져다(주로 cgroup과 namespace) 이를 포장하기 위한 편리한 메타포, 프론트 엔드, 워크플로를 제공했다.

도커가 부상하고 얼마 지나지 않아 사람들은 급진적인 개념들을 실험하기 시작했다. 리눅스의 껍질을 다 벗겨내고 단순한 부팅 메커니즘, 시동 시스템, 그리고 컨테이너를 실행하고 관리하기 위한 수단으로 만들면 어떨까? 네트워킹과 스토리지 관리를 위한 임베디드 리눅스와 같이 컨테이너를 위한 리눅스를 만들면 좋지 않을까? 그렇게 해서 코어OS(CoreOS)가 태어났다.

코어OS는 단순히 색다른 무언가를 위해 만들어진 것이 아니다. 많은 이유가 있지만 그 중 하나는 축소판 리눅스가 관리하고 유지하기 더 쉽고, 공격으로부터 보호하기 쉽고, 하트블리드(Heartbleed) 또는 셸쇼크(Shellshock)에 직면한 경우 되살리기도 더 쉬울 것이라는 데 있다.

도커의 성공과 코어OS의 실험에 자극을 받은 다른 리눅스 배포판들도 비슷한 개념을 시도하기 시작했다. 레드햇은 제품군 전반에 대규모 컨테이너 실행 지원을 내장했고, 컨테이너 중심의 자체 리눅스인 레드햇 아토믹 호스트(Atomic Host)도 출시했다.

어떤 면에서 아토믹 호스트는 코어OS와 비슷하다. 즉, 컨테이너를 실행하는 것 외의 다른 기능은 거의 없는 간소화된 리눅스 버전이다. 그러나 레드햇의 의도는 단순히 미니멀한 시스템을 만들고 끝내는 것이 아니었다. 대신 레드햇은 아토믹 호스트를 전체 리눅스 배포판을 구축하기 위한 기반으로 삼고 컨테이너를 사용해 플랫폼에서의 소프트웨어 설치를 관리하는 방법을 택했다. 아직 전통적인 리눅스 패키지 관리의 필요성을 완전히 대체하지는 못했지만 보완적인 기능을 제공한다.

캐노니컬(Canonical)도 마찬가지로 컨테이너 기반인 스내피(Snappy) 애플리케이션 패키징 시스템을 통해 이와 유사한 방식을 도입했다. 원래 우분투 폰 OS에 업데이트를 배포하기 위한 목적으로 개발된 스내피는 컨테이너를 사용해서 데이터베이스 트랜잭션과 같은 방식으로 소프트웨어 설치를 처리한다.

유니커널 : 딱 필요한 만큼만
커널과 일부 컨테이너만 남길 정도로 간소화한 리눅스마저 무겁다고 생각한 사람들은 커널과 애플리케이션 하나만 남기고 그 외의 불필요한 것은 아무것도 포함하지 않는 리눅스 프로젝트를 시작했다. 이른바 "유니커널" 접근 방법이다.

유니커널은 컨테이너와 마찬가지로 새로운 개념이 아니다. 수십 년 전부터 형태를 달리하며 계속 존재해왔다. 유니커널은 작은 크기와 빠른 부팅, 최소화된 공격 표면을 대표적인 장점으로 내세우지만, 만들기는 더 복잡하다. 전통적으로 이러한 프로젝트는 리눅스를 채택하지 않고 전용으로 만든 맞춤형 커널을 사용하거나 젠 프로젝트(Xen Project)의 미니OS(MiniOS)와 같이 최소화된 커널을 기반으로 사용했다.

리눅스를 유니커널의 기반으로 사용할 수 있는 한 가지 방법은 "라이브러리 OS" 형태다. 여기서 사실상 리눅스 커널은 애플리케이션에 연결되는 거대한 코드 라이브러리가 된다. 그라핀 라이브러리 OS(Graphene Library OS)가 이 방식을 사용하는 프로젝트로, 부팅 가능한 커널 안에 "네이티브 비수정 리눅스 애플리케이션"을 내장하는 형태로 컴파일이 가능하다.

유니커널과 리눅스의 또 다른 눈에 띄는 예는 도커에서 찾아볼 수 있다. 도커는 다양한 시나리오에서 유니커널을 유니커널 시스템즈(Unikernel Systems)를 인수했고, 그 기술 일부를 맥 및 윈도우용 도커 제품에 적용했다. 원래 데스크톱에서 도커를 실행하려면 버추얼박스(VirtualBox) 기반의 온전한 리눅스 배포판을 부팅해야 했지만 이제 각 플랫폼의 네이티브 가상화 기술을 사용해 도커 엔진이 내장된 맞춤형 리눅스 커널을 부팅하면 된다.



X