04. 운영체제 구조(2)

안녕하세요. 이번 글은 지난 글에 못다 한 운영체제 구조 내용을 이어서 하려고 합니다. 오늘은 Monolithic kernel부터 시작해서 본격적으로 kernel design에 대해 설명하겠습니다. Design desicion과 관련해서는 저번 글을 참고해주시면 좋을 것 같습니다.

2021.11.01 - [학부공부/운영체제] - 03. 운영체제 구조(1)

03. 운영체제 구조(1)

 

04.01. Monolithic kernel

[그림 1] 커널 종류

현재 Windows와 Linux는 Monolithic kernel인데요. 이게 뭔지 왜 이것을 사용하는지 알아보도록 하겠습니다. 

 

Mono : 하나

lithic : 덩어리

 

하나의 덩어리. 즉, 커널이 사용자와 같은 주소공간에 위치하는 것을 말합니다. (한덩어리로 묶는다는 것 자체가 커널과 사용자로 구성하는 요소가 나뉠 수 있다는 것을 전제로 하는 것이죠) 다만 주소공간을 사용자와 커널 코드가 나누어 사용하긴 합니다. 같은 공간에 위치하는데 그걸 나눠서 사용한다는 거죠. 저번 글에서 언급한 System call은 application에서 kernel로 넘어갈 때 커널의 서비스를 요청하기 위해 사용한다고 보시면 되겠습니다. 

[그림 2] 모놀리식 커널에서의 주소공간 매핑

일단 장점은 같은 주소공간에 있으니까 시스템 콜과 커널 서비스 간 데이터 전달 시 오버헤드가 적습니다. 성능이 좋다는 거죠. 운영체제에서 가장 중요한 것은 결국 성능입니다. 단점은 하나의 바운더리에 있기 때문에 일부분 수정 전체에 영향을 미칩니다. 마치 EEPROM과 비슷하네요.(EEPROM은 전기적으로 Data를 썼다 지웠다 하는 비휘발성 메모리라서 조그마한 부분을 지울 수 없고 부분부분 별로 작성과 삭제가 가능합니다.) 이는 유지보수를 어렵게 합니다. 한 모듈의 버그가 시스템 전체에 영향을 끼칠 수도 있습니다. 이러면 디버깅도 좀 부담이 되겠네요. Layering과 module에 대해서 지난시간 설명했었는데요. 모놀리식 커널은 Layering하기 어렵기 때문입니다.

 

 

04.02. Micro kernel

Micro kernel은 커널 서비스를 기능에 따라 module화 한 것입니다. 독립된 주소공간에서 실행하죠. 하나의 큰 덩어리로부터 비롯되는 문제를 해결하기 위해 오랜기간 연구되어 왔습니다. 이러한 module을

 

커널 서버

 

라고 합니다. 마이크로 커널은 스케쥴링과 같은 기본적이고 공통적인 기능만 남기고 나머진 별도의 커널로 독립시켰습니다. 또한 마이크로 커널은 서버들 간의 통신(IPC)과 같은 단순한 기능만을 제공합니다. 마이크로 커널에서는 instruction 사용이 불가능해서 메시지를 주고받는데 이는 비용이 많이드는 방식입니다. 그럼 이제 한가지 질문에 답할 수 있게 되었습니다.

 

Application에서 Kernel에 접근하는 방법은 시스템 콜 말고도 있는가?

Yes. Message

그럼 장점을 알아볼까요? Layering과 module에서 설명했던 장점을 생각해보시면 됩니다. 가장 중요한 포인트는 커널 서버가 독립적으로 구현되어 있다는 것입니다. Interface와 semantics만 맞추면 되기 때문에 개발과 유지보수가 쉽죠. 또한 각각의 서버에 대해 불필요한 자원을 회수할 수 있습니다. 메모리와 CPU 사용 측면에서 유리합니다. 마지막으로 운영체제 이전 포스팅에서 "자율주행차의 안정성을 어떻게 보장할 수 있을것인가?"에 대한 답으로 OS의 수를 늘릴 수 있다고 말씀 드렸는데요. 문제가 생긴 서버를 재시작하여 해결할 수 있고 서버 코드가 protected memory에서 실행되기 때문에 안정적입니다.  

 

단점은 모놀리식 커널의 장점이 되겠죠. 성능이 낮습니다. 독립된 서버들 간 통신이 필요하기 때문이죠. 따라서 구조적으로 깔끔하긴하지만 성능때문에 실제 제품으로 사용된 경우는 거의 없다고 합니다. 성능이 모놀리식 커널의 50% 이하라고 하더군요. (사실 있는지도 잘 모르겠군요.. 있다면 알려주세요.) 다만,

 

L4 Micro kernel(Interesting topic to study)

 

이라고 독일에서 마이크로 커널이 하드웨어 서포트를 통해 리눅스와 비슷한 영역까지 성능 개선을 할 수 있다는 유의미한 결과를 논문으로 보여주었다네요. 공부해볼만한 주제인 것 같습니다. 하드웨어 서포트를 통한 성능개선은 항상 흥미로운 주제이고 참신한 아이디어를 제공하니까요.

 

Message passing

마이크로 커널은 서버간 통신이 필요하다고 하였는데요. App, VFS(파일 서버), Device driver등은 Message passing을 통해 통신합니다. 모놀리식 커널에서는 시스템 콜을 통해서 파일을 한번에 쓸 수 있지만 마이크로 커널에서는 불가능 하다는 이야기 입니다.

[그림 3] 모놀리식 커널과 마이크로 커널의 모듈간 소통방식 비교

참고한 수업자료에서 성능을 한눈에 비교할 수 있는 좋은 그림이 있어 가져와 봤습니다. 모놀리식 커널에서는 모두 함수 호출로 진행 될 수 있는 부분이고요. 마이크로 커널은 주소공간, 즉 동네가 다르기 때문에 함수호출이 불가능하고 메시지 패싱을 사용합니다. 이 그림을 보안측면에서 바라보면 모놀리식 커널은 Application이 VFS, EXT3...등에 모두 접근할 수 있어야 하니까 시스템 콜의 수가 많겠군요. 이런 부분이 Attack surface를 마이크로 커널보다 넓은 하나의 이유가 될 수도 있을 것 같습니다.

(시스템 콜이 왜 attack surface가 될까요?)

register로 argument를 넘기고 register size를 넘어가면 memory stack을 사용하기 때문에

 

04.03. Hypervisor 

Hypervisor는 몇년전만 하더라도 학부생들이 접하기 어려운 내용이었는데요. Hypervisor를 통해서 가상화가 이루어집니다. 가상화라는 개념은 오래전부터 존재해왔습니다. 하지만 성능문제로 인해 크게 활용되지는 못하였는데요. 2003년 Xen의 등장으로 핵심 기술로 성장하였습니다. 가상화는 이제 너무 중요한 Topic중 하나죠. 최근 연구는 네트워크의 가상화로 이어지고 있습니다.

[그림 4] 하이퍼바이저

[그림 4]도 참고한 수업자료에서 가져온 그림입니다. 그림에서 볼 수 있듯이 하드웨어와 OS를 분리시킨건데요. 그럼 왜이렇게 하였느냐? 원래의 커널은 OS와 하드웨어가 1:1로 존재하였죠. 이 상태에서 OS가 죽으면 하드웨어는 사용하지 못하게 됩니다. 우리는 OS와 하드웨어를 분리함으로써 다수의 게스트 OS를 올릴 수 있게 된 것입니다. 우리가 흔히 접하는 Virtual box와 혼란을 느끼실 수 있는데요. 

[그림 5] Hypervisor & Virtual box

굳이 그림으로 표현해보자면 [그림 5]와 같이 표현할 수 있을 것 같습니다.

 

장점은 다수의 Guest OS가 가능해졌다. 즉, 하드웨어 cost를 낮출 수 있게 되었다는 것입니다. 아래의 표로 쉽게 이해하실 수 있습니다.

	Windows	Linux
가상화 X	100대	100대
가상화 O	필요에 따라 Virtualization Layer가 역할 최대 200대 사용 가능

또한 

 

Decoupling & Isolation

 

관점에서도 큰 장점인데요. Decoupling은 소프트웨어와 하드웨어를 분리한다는 것입니다. Isolation은 Guest OS끼리의 분리를 이야기하죠. 즉 시스템의 신뢰도를 향상시킬 수 있습니다. 하나의 Guest OS가 fail하더라도 다른 Guest OS는 살아 있으니까요. 이렇게 각 Guest OS들은 서로 다른 Virtual Machine에서 수행되기 때문에 서로의 존재를 알지 못합니다. 원래 하드웨어를 제공하는 것은 OS였는데 이제는 하이퍼바이저가 그 역할을 하게 된 것이죠. 물론 Guest OS 자기는 스스로 하드웨어를 사용하고 있다고 생각합니다. 하이퍼바이저가 시스템 자원을 분배하는 최소한의 역할만 수행하기 때문입니다. 

 

모놀리식 커널과 마이크로 커널 논쟁은 2003년 이후 하이퍼바이저가 등장하면 그러한 논의가 별 의미가 없어지게 되었습니다. 하드웨어 위에다 여러 OS를 올려놓고 제어하는 것이 훨씬 좋았기 때문이죠. 다만 하드웨어를 직접적으로 사용하는 다른 운영체제에 비해 성능이 떨어질 수 있다는 단점이 있는데요. 이를 반 가상화(Para-virtualization)로 해결할 수 있다고 합니다.

 

Para-virtualization (Interesting topic to study)

 

반가상화는 높은 기술스택이 요구된다고 합니다. 공부해볼 흥미로운 주제네요. Xen이 한 일이 반가상화인데요. [그림 4]에서 App과 Guest OS 사이의 시스템 콜과 Hypervisor call 중 Hypervisor call을 어떻게 잘 만든 것인데요.(하이퍼바이저 자체가 Hypervisor call로 인한 오버헤드가 상당합니다.) 그럼 우리는 반가상화를 하기 위해 무엇을 알아야 할까요?

바로 Guest OS의 Code입니다. 그래서 linux에 가장 먼저 도입되었죠, 또한 하드웨어 의존적인 code가 많습니다.

 

추가적으로 가상화 기술은 클라우드 기술과도 관련이 있는데요. 궁금하신 분들은 PaaS에 대해서 알아 보시면 될 것 같습니다. 

 

 

이번 글에서 기존 포스팅과 새롭게 도입된 양식이 있는데요. 바로 Interesting topic to study입니다. 해당하는 topic에 대한 자세한 이해가 없더라도 큰 맥락을 이해하는데 방해가 되진 않지만 알아볼만한 가치가 있거나 개인적으로 궁금한 topic에 대해 이러한 comment를 달아보았습니다. 나중에 시간이 되면 이 내용도 포스팅해보겠습니다.