[OS] Operating System Structure, Kernel Designs (Monolithic, Micro, Hypervisor)

System Structure(시스템 구조)

• 운영체제는 규모가 크고 복잡한 소프트웨어이므로 설계 시 구조를 신중히 고려해야 함
• 잘 설계된 운영체제는 개발, 수정 및 디버깅, 유지 보수, 확장을 용이하게 함
• 좋은 디자인 목표는 설계하고자 하는 시스템의 목적(고객의 요구사항)과 밀접하게 관련되어 있음

 

OS Design Principle(OS 설계 원칙)

• 운영체제 설계는 Mechanism과 Policy의 분리를 통해 모듈화를 달성
• Policy(정책): 무엇을 할 것인가(What will be done)에 대한 상위 수준의 결정
  • 목표나 방향을 정하는 것과 같음 (중요한 프로그램이 먼저 CPU를 사용 같은 결정들)
• Mechanism(매커니즘): 어떻게 할 것인가(How to do something)를 다루는 구체적인 방법
  • 구체적인 알고리즘이나 자료 구조 등이 해당됨
  • ex) CPU를 공평하게 사용하기 위해 '라운드 로빈 스케줄링'을 사용, 중요한 프로그램이 먼저 사용하게 하려면 '우선순위 스케줄링' 알고리즘 사용 등
• Mechanism을 Policy에 잘 맞춰서 설계하는 것이 중요함

 

운영체제 설계를 위한 방법

• 운영체제의 복잡도를 낮추기 위해 Layering과 Modularity(모듈화) 방식이 사용됨

Layering (계층화)

• OS의 복잡도를 낮추기 위한 방안
• 각 Layer는 정의가 명확한(Well-Defined) 함수들로 이루어짐
• 하나의 Layer는 인접한 Layer와만 통신하며, 2단계 이상 건너뛴 Layer와 직접 통신 불가능

• 설계의 복잡도를 낮출 수 있지만, Overhead가 발생 (trade-off)
  • ex) OSI 7 계층 모델

• 장점
  • 독립성: Layer의 수정이 다른 Layer와 독립적이어서, 각 Layer의 함수(작업)와 서비스만 사용하도록 선택됨
  • 하위 Layer 서비스만 사용: 상위 레이어는 하위 레이어가 제공하는 서비스를 인터페이스로만 의존해 사용
    (Modularity와 Layering을 함께 고려하는 이유)
    
    • 두 개념은 상호 보완성을 띔: Layer는 추상화 수준을 가르고, 모듈화는 변경·배포·팀 작업 단위를 가름
    • 시스템의 크기에 따라 작은 시스템은 레이어 중심, 커질수록 모듈화의 기여가 더 커짐

불완전한 Layering

• ↑ Layering 원칙이 제대로 분리되지 않은 MS-DOS 예시
• 상위 Layer가 하위 Layer를 건너뛰어 직접 하드웨어에 접근하는 경우가 발생
  • 옛날 Virus의 원리
• 이는 Layering의 장점인 독립성과 유지 보수성을 저해

Kernel 내의 모듈들 (Linux)

• 리눅스(Linux)는 모듈식 구조의 좋은 예시로 다양한 기능이 모듈 형태로 구현되어 있음
• 이 모듈들은 Kernel interfaces to the hardware를 통해 하드웨어(Terminal controllers, Device controllers, Memory controllers)와 상호작용함

 

User Mode와 Kernel Mode

• CPU는 System Protection을 위해 2가지 실행 모드를 가짐
  • 실행 모드의 권한에 따라, 접근할 수 있는 메모리, 실행 가능한 명령어가 제한됨
• Kernel Mode: 모든 권한을 가진 실행 모드
  • 운영체제가 실행되는 모드
  • Privilege 명령어 실행 및 레지스터 접근이 가능 (ex. I/O 장치 제어 명령어, CR3 레지스터)
• User Mode: Kernel Mode에 비해 낮은 권한의 실행 모드
  • 애플리케이션이 실행되는 모드
    • 애플리케이션이 Kernel Mode의 권한이 필요한 서비스를 받기 위한 방법이 필요(system call)
  • Privilege 명령어 실행 불가능
• 각 모드 별로 접근할 수 있는 메모리 및 실행 가능한 명령어가 제한됨
• 하드웨어 지원이 필요: Intel CPU는 Ring 0~3의 4개 모드를 제공하고, 대부분의 프로세서는 2개 모드 제공

 

System Call

• Kernel에서 제공하는 Protected 서비스를 이용하기 위한 통로 (일종의 단위 연산의 모음)
  • open(): 파일 또는 장치 열기
  • write(): 파일 또는 장치에 쓰기
  • msgsnd(): 메시지 전송(MeSseGe SeND)
  • shm(): 공유 메모리 연결(SHare Memory)

User mode와 Kernel mode의 경계 역할을 하는 System Call

일반적인 Kernel의 구조

 

Kernel Designs

• 운영체제 커널의 주요 디자인 방식
• 내부 설계
  • Monolithic Kernel
  • Micro Kernel
• 가상화 추가
  • Hypervisor

3 Types of Kernel Design

 

Monolithic Kernel (하나의 거대한 돌/하나의 덩어리 커널)

• 특징
  • 하나의 주소 공간: Kernel의 모든 Service가 같은 주소 공간(Address Space)에 위치
  • 커널 코드 매핑: 애플리케이션은 커널 서비스(Mode)를 이용하고자 할 때, 자신의 메모리 공간에 커널 코드 영역을 매핑해서 접근
  • 단일한 추상화: 하드웨어에 대한 복잡한 내용을 숨기고, 애플리케이션에게는 단일하고 통일된 인터페이스 제공

• 장점 (빠른 소통)
  • 낮은 오버헤드: 애플리케이션과 모든 Kernel 서비스가 같은 주소 공간에 위치하므로, 시스템 콜 및 Kernel 서비스 간의 데이터 전달 시 Overhead가 적음
• 단점 (덩치가 너무 큼)
  • 수정의 파급 효과: 모든 서비스 모듈이 하나의 바이너리로 이루어져 있어 일부분의 수정이 전체에 영향을 미침
  • 어려운 유지 보수: 각 모듈이 유기적으로 연결되어 Kernel 크기가 커질수록 코드가 복잡해지고, 유지 보수가 어려워짐
  • 치명적인 버그: 한 모듈의 버그가 커널 전체를 망가뜨려 시스템을 다운시킬 수 있음
• Linux, Unix 계열 운영체제들이 Monolithic 커널 구조를 추구함
• 성능 면에서는 유리하지만, 복잡성과 안정성 면에서는 단점을 가짐

 

Micro Kernel (작은 Kernel)

• 특징
  • 모듈화된 서비스, 독립된 주소 공간: Kernel Service 기능에 따라 모듈화하여 각각 독립된 주소 공간에서 실행
  • 서버(Server) 개념: 이러한 모듈들을 서버(Server)라 하며, 서버들은 독립된 프로세스로 구현
    • ex) 학교란 Kernel 내에서도 수강신청은 Usaint에서, 강의는 LMS에서
  • 커널의 역할 최소화
    • 서버들 간의 통신(IPC: Inter Process Communication)과 애플리케이션의 서비스 콜 전달(메모리 관리의 기본, 하드웨어 인터럽트 처리 등)과 같은 단순한 기능만을 제공
    • 나머지 서비스들은 커널 밖의 서버들에게 맡김
      
      
• 장점 (안정성과 유연성)
  • 낮은 의존성, 쉬운 개발/유지 보수: 각 서비스가 독립적인 서버로 존재하므로, 한 서버를 수정해도 다른 서버나 커널 자체에 미치는 영향이 적음 (객체 or Function 단위로 코딩하는 거랑 유사)
    • Monolithic Kernel보다 독립적인 개발이 가능
    • Kernel의 개발 및 유지 보수가 상대적으로 용이
      
      
  • 유연한 자원 관리: 불필요한 서버는 실행하지 않거나 필요할 때만 시작/종료할 수 있어서, 메모리나 CPU 같은 시스템 자원의 효율적 확보 및 사용 가능
    
    
  • 높은 안정성(이론적): Monolithic보다 안정적
    • 특정 서버(모듈)에서 버그가 발생하더라도, 그 서버만 재시작하면 됨
    • 전체 시스템이 멈추는 일이 드뭄
    • 서버 코드가 Protected Memory에서 실행되므로 보안성이 높아 검증된 S/W 분야에 적합
      • ex) 의료 컴퓨터 분야
        
        
• 단점 (성능 저하)
  • 낮은 성능: 독립된 서버들 간의 통신 및 Context Switching 때문에 오버헤드 발생
    • Monolithic Kernel보다 낮은 성능을 보임
• Mach(macOS의 기반), QNX, L4 등이 마이크로 커널 구조 사용
• 안정성과 유연성 면에서 Monolithic Kernel보다 뛰어나지만, 성능 면에서는 불리한 trade-off를 가지고 있음

블록 I/O 처리(시스템 콜) 비교

 

Hypervisor(가상 세계의 지휘자)

• 특징
  • 가상화 관리 계층: 실제 하드웨어와 그 위에서 돌아가는 운영체제(Guest OS: Window or Linux) 사이에 존재
    • 하드웨어 자원을 가상화하여 각 게스트 OS에 할당하고 관리하는 역할
  • 독립적인 가상 머신: 각 게스트 OS들은 자기만의 독립적인 가상 머신 안에서 실행되며 서로의 존재를 알지 못함
  • 할당된 자원만 접근: 각 게스트 OS들의 H/W에 대한 접근은 Hypervisor에게 할당 받은 자원에 대해서만 수행
  • 최소한의 자원 분배 역할: Hypervisor 자체는 CPU, 메모리, 스토리지 등 물리적 자원을 각 VM에 효율적으로 나눠주는 최소한의 역할만 수행
    
    
• 장점 (유연성과 효율성)
  • 다양한 OS 운용: 하나의 물리 컴퓨터에서 여러 종류의 게스트 OS 운용이 가능
    • ex) 전기차 서버에 주행 OS, 온도 관리 OS, 기타 OS가 동시에 존재
  • ISA(Instruction Set Architecture) 추상화: 실제 하드웨어의 명령어 집합 구조와 다른 형태의 가상 ISA를 제공
    • 다른 H/W 환경을 위해 컴파일 된 게스트 OS 및 애플리케이션도 가상 머신에서 실행 가능
      
      
• 단점 (성능 저하와 복잡성): 게스트 OS가 Hypervisor를 거쳐야 하므로 H/W를 직접적으로 사용하는 다른 OS에 비해 성능이 떨어짐
  • 이를 위해 반가상화 기법을 사용하기도 함 
  • 반가상화(Para-Virtualization): 게스트 OS가 Hypervisor의 존재를 인지하고, H/W에 직접 접근하는 대신 Hypervisor가 제공하는 특수 인터페이스를 통해 효율적으로 통신하는 방식
    • 게스트 OS의 H/W 의존적인 코드 수정이 요구되며, 높은 기술적 능력이 필요하고 OS 소스가 공개되지 않았다면 수정이 불가능함
• VMware, KVM, VirtualBox, Hyper-V 등이 있음

클라우드 컴퓨팅과 서버 가상화의 핵심 기술로, 자원 활용도를 극대화하고 유연한 서비스 제공을 가능하게 하지만, 성능 오버헤드와 구현의 복잡성을 동반함

3 Types of Kernel Design

구분	Monolithic Kernel	Micro Kernel	Hypervisor
구성	모든 커널 서비스가 하나의 커널 내에 존재	최소한의 커널 + 대부분의 서비스는 사용자 영역 서버로 분리	하드웨어와 게스트 OS 사이에 위치하는 관리 계층
실행 위치	Kernel area (단일 주소 공간)	Kernel area (최소한) + User area (대부분의 서버)	Hardware와 GuestOS 사이
통신 방식	시스템 콜 후 직접 함수 호출	시스템 콜 후 IPC (프로세스 간 통신)	Guest OS는 Hypervisor를 통해 H/W 접근 (시스템 콜 or 특수 인터페이스)
장점	높은 성능, 낮은 오버헤드	높은 안정성, 유연한 개발/유지 보수, 자원 효율성	여러 OS 동시 운용, 하드웨어 추상화, 강력한 격리
단점	낮은 안정성, 어려운 유지 보수, 버그 시 시스템 전체 영향	낮은 성능 (IPC 오버헤드), 복잡한 통신	성능 저하 (가상화 오버헤드), 반가상화 시 OS 수정 필요
예시	Linux	Mach, QNX	VMware ESXi, KVM