07. Hypervisor [Interesting topic to study]

안녕하세요. 오늘은 Hypervisor에 대해서 알아볼까 합니다.

2021.11.02 - [학부공부/운영체제] - 04. 운영체제 구조(2)

04. 운영체제 구조(2)

이 포스팅에서 모놀리식 커널, 마이크로 커널 그리고 모놀리식 커널과 마이크로 커널의 논쟁을 잠재운 하이퍼바이저에 대해서 알아 보았었는데요. 하이퍼바이저는 가상화된 컴퓨터 하드웨어 자원을 제공하기 위한 관리 계층으로 게스트 OS와 하드웨어 사이에 위치하였습니다. 오늘은 하이퍼바이저의 History와 최근 기술에 대해 알아보고자 합니다. 이 내용은 고려대학교 유혁 교수님(https://os.korea.ac.kr/) 운영체제 수업의 강의자료를 참고하였습니다.

 

07.01. History of hypervisor

[그림 1] History of Hypervisor

1세대는 별로 유용하지 않은 기술이었습니다. 2세대는 아주 low level에서 이루어졌죠. 3세대부터 반가상화가 적용되었다고 생각하시면 됩니다. Intel에서 가상화 확장을 제공하기 시작하였죠. 가상화를 소프트웨어로 제공하던 이전과 달리 하드웨어로 제공해주기 시작하여 성능도 높은 수준으로 올라왔습니다. 가상화가 보편화되기 시작하였죠.

 

07.02. 경량화된 Hypervisor : KVM & Container

[그림 2] KVM & Container

Xen이 반가상화를 통해 가상화의 획기적인 발전을 이끌었다고 말씀드린 적 있는데요. Xen은 하드웨어 위에 새로운 하이퍼바이저로써 존재한다는 것에 실질적인 어려움이 있었습니다. Guest OS를 위에 올리려면 커널과 아케텍처 등 쉽지 않은 많은 지식을 알아야 했죠. 그래서 사람들은 경량화된 하이퍼바이저를 연구하기 시작합니다. 그런 연구 끝에 나온 것에 KVM이 있습니다. KVM은 리눅스에 포함된 하이퍼바이져입니다. Intel은 VT-x라는 하드웨어 가상화 서포트를 제공하였습니다. 하지만 여전히 Physical memory를 많이 사용한다는 단점이 있어 Container를 연구하기 시작했죠.(연구자들의 연구 의도는 정확하지 않을 수 있습니다.)  참고로 여러분이 자주들어보았던 VM도 KVM이라고 생각하시면 됩니다.(아주 정확히는 KVM:Kernel-based Virtual Machine을 통해 Host OS가 Guest OS 또는 Virtual Machine과 같이 독립된 복수의 가상환경을 실행할 수 있다는 군요.)

 

즉, 경량화가

 

하이퍼바이저 > KVM > 컨테이너

 

순서로 많이 되어있다고 생각하면 됩니다. 그렇다면 왜 컨테이너가 KVM보다 더 경량화 된 것일까요?

컨테이너에서는 OS와 커널을 공유합니다. 각 컨테이너가 보는 file system이 다르죠.

여기서 Name space로 부터오는 isolation을 생각하시면 됩니다. Name space란 나중에 더 설명할 기회가 있겠지만 프로세스 또는 컨테이너가 있으면 뭘 볼 수 있는지 정의하는 것입니다. 어시장의 수조라고 생각하시면 되겠군요. 서로 다른 수조를 보는 것입니다. KVM의 Virtual Machine1가 Virtual Machine2의 file을 보지 못합니다. 컨테이너도 마찬가지이지요. 결국 차이는 World가 다르다는 것입니다. KVM은 World가 다르고 컨테이너는 World가 같아요. 컨테이너를 보시면 커널을 공유하고 있음을 알 수 있습니다. 하나의 컨테이너에 A라는 파일이 있더라도 다른 컨테이너에서 A라는 동일한 이름의 다른 파일이 있을 수 있다는 것이죠. 이것을 Container engine이 가능하게 해줍니다. 

 

요즘은 Container에 대해 더 자주 접하실 가능성이 큽니다. 컨테이너가 OS와 커널을 공유한다는 점에서 보안에 취약할 수 있지만, 보안이 아주 중요한 조건이 아니라면 컨테이너를 사용하는 추세라고 볼 수 있습니다. Xen은 하드웨어를 가상화햇다면 컨테이너는 OS를 가상화하였다고 생각해볼 수 있겠네요. Container engine만 제대로 돌아간다면 engine 밑의 커널은 다른 것이여도 상관없을 것이기 때문입니다. Container는 deploybility(배포가능성)도 아주 좋은데요. Java가 langauge 수준에서 제공하려는 것이 바로 이겁니다. 컨테이너를 만들어 놓으면 어느 서버에 던져놓아도 괜찮게 만든 것이죠.(그래서 OS 가상화라고 생각해봐도 되겠군요.) 하지만 language 수준에서 하긴 힘들죠. 아마 runtime 때문인 것 같습니다. Continer가 조금 더 궁금하신 분들은 CI, docker에 대해서 공부해보시면 좋을 것 같습니다. 저도 아직 부족한 부분이라 여러분께 당장 소개해드리긴 그렇네요... (CI가 배포판이라는 정도로만 이해하고 있습니다. runtime과 라이브러리 등을 포함해서 이것만 있으면 run anywhere라고 하더군요.)

 

마지막으로 Container는 보안이 KVM에 비해서 약점이라고 말씀드렸는데요. 이것만 짚고 마치겠습니다. 왜 KVM보다 컨테이너가 경량화된 것인지 설명한 부분이 Hint가 될 수 있을 것 같습니다. 바로 Guest OS가 없어 커널로 내려간다는 것이죠. 커널을 공유하기 때문에 커널이 fail하면 전체가 다 멈춘다고 볼 수 있습니다. 즉 OS level에서의 isolation을 기대하기 힘든 것이죠. 

 

혹시 헷갈리셨을 분들을 위해 Xen에 대한 설명도 덧붙이겠습니다. Xen은 하이퍼바이저가 존재하고 Guest os가 올라갑니다. 여기서 하이퍼바이저가 바로 Xen이라고 생각하시면 됩니다. KVM은 하이퍼바이저가 있으면 Host OS(linux)에 VM이 올라갑니다. 이렇게 보니 차이점은 하이퍼바이저가 Xen이냐 리눅스냐군요.

 

아직 제가 부족해서 공부해야 할 내용이 많은 topic입니다. 이 글을 읽어주시는 분들 중 잘못된 내용이 있으면 댓글 남겨주시면 감사하겠습니다. 질문이나 의견들은 소중하게 생각하고 언제나 환영입니다.