Today Keys : Unikernel, Container, Docker. specialised, single, address, space, ClickOS , Clive , Drawbridge ,HalVM , IncludeOS , Ling , MirageOS , OSv , Rumprun ,Runtime.js , UniK
오랜만에 남기는 이번 포스팅은 Unikernel이라는 기술에 대한 첫 번째 포스팅입니다.
Unikernel은 올 초에 Docker에 Join되면서 조금 더 많은 관심을 받고 있는 듯 합니다.
Rethinking Cloud Infrastructure라는 문구가 Unikernel 웹이나, Unikernel System 웹에서 나오고 있지만,
개인적으로는 Cloud보다는 IoT에 조금은 더 가깝지 않을까 생각해봅니다. ^^;
Unikernel에 관련 1차 포스팅이기 때문에 추후에 내용은 수정/보완 될 수 있을 듯 싶습니다.
Unikernel 이란?
•Unikernels are specialised, single-address-space machine images constructed by using library operating systems.
•별도의 OS Kernel을 사용하지 않고, Application을 서비스하는 데 필요한 Kernel의 특정 라이브러리만을 포함하여 Compile하여,
Hypervisor 혹은 Baremetal 등에서 바로 서비스가 가능하도록 지원.
• Haskell이나 Erlang와 같은 Type-safe 언어는 물론, C/C++/Java/Python과 같은 일반적인 언어를 사용하여 Build 가능. 즉, Application에 구현하기 위한 언어에 제약이 없이 Unikernel을 사용 가능.
※ Unikernel을 컴파일하기 위해서 사용되는 Library OS에 따라서 지원되는 개발 언어는 다름)
• 2016년 1월 21일에 Unikernel System은 Docker 에 합류
Unikernel 특징
•Application 구동에 필요한 라이브러리만 포함되기 때문에 매우 가벼움.
•불필요한 서비스가 사용되지 않기 때문에 매우 빠르게 구동(< 1ms)
•Application에 필요하지 않는 불필요한 Kernel은 배포되지 않기 때문에, 공격 노출을 줄여 보안이 강화
•General한 목적 / Multi-user 컴퓨팅에는 적합하지는 않음.
Unikernel 주요 프로젝트
• Unikernel 웹사이트(http://unikernel.org/) 에서는 Unikernel와 관련된 Open Source 프로젝트로 아래의 11개 프로젝트가 소개.
- ClickOS / Clive / Drawbridge /HalVM / IncludeOS / Ling / MirageOS / OSv / Rumprun /Runtime.js / UniK
• Unikernel과 관련된 주요 프로젝트의 내용은 아래와 같음.
Container과의 비교
•Unikernel은 Container와 동일하게 Immutable Infrastructure를 제공
•Unikernel은 Container와 유사하게 Resource 사용에 대한 Overhead가 적음.
•Container가 Host OS의 기본 Kernel을 공유하는 반면에 Unikernel은 개별 App을 구동하기 위한 일부 라이브러리에 대해서
Applicaion과 함께 컴파일하여 해당 Application에서 독립적으로 사용
•Container에서도 하나의 Kernel을 공유했을 경우에 발생하는 이슈와 보다 Container에 최적화하기 위해,
CoreOS, Atomic(Redhat 지원 프로젝트), Photon OS(VMware), Snappy(Ubuntu)와 같은 Container를 전용의 OS를 사용하여
Container별로 개별 Kernel을 사용하면서 크기를 감소시키기도 하지만, Unikernel의 경우에는 Application 구동에 필요한 최적의
Library만을 포함하기 때문에 보다 최적화 시킬 수 있음.
Library OS 특징
• single address space를 사용하기 때문에 User space와 Kernel space 간의 전환이 필요 없기 때문에, 따라서, Context switching 없이 하드웨어로 직접적인 접근이 가능하게 하여 성능을 향상
• Library OS가 구동되기 위한 특정 하드웨어의 device driver가 필요로 하는 데, 하드웨어의 변화 속도가 빨라짐에 따라서 이러한 driver를 정기적으로 다시 만들어야 하는 부분이 부담으로 작용하지만, OS 가상화로 인해서 이러한 부담은 해소될 수 있음.
•Hpyervisor에는 stable한 가상하드웨어를 제공하기 때문에 library OS가 이러한 환경에서 동작할 경우에 Hardware device driver에 대한 이슈를 해결할 수 있음.
,
