Contents
1. OS에서의 커널 구조
-
Monolithic Kernel, Micro Kernel, Hypervisor
-
Hypervisor
2. Docker
-
등장 배경
-
특징
-
장점
1. OS에서의 커널 구조
1.1. Monolithic kernel, Micro kernel, Hypervisor
Monolithic Kernel
- 하나의 큰 덩어리처럼 모든 기능이 커널에 직접 포함 → 빠르지만 유지보수 어려움
Micro Kernel
- 기능을 최소한으로 줄이고 대부분의 커널 기능은 별도 서버로 분리 → 안정성/모듈성 좋음, 다만 IPC 오버헤드 존재
Hypervisor
- 커널이 아닌 가상화 계층으로, 게스트 OS를 가상 환경에서 독립적으로 실행하게 함 → 보안성 우수, 다양한 OS 동시 실행 가능
1.2. Hypervisor
- Monolithic Kernel + Micro Kernel가 아니다.
- 하드웨어 위에 위치하여, 여러 운영체제(게스트 OS)가 동시에 하나의 물리 머신을 공유할 수 있게 만드는 ==가상화 계층==이다.
특징
- 가상화된 컴퓨터 H/W 자원을 제공하기 위한 관리 계층
- 게스트 OS와 H/W 사이에 위치한다.
- 게스트 OS : Hypervisor가 제공하는 가상화된 H/W 자원을 이용하는 운영체제
- 게스트 OS와 H/W 사이에 위치한다.
- 각 게스트 OS들은 각각 서로 다른 가상 머신(Virtual Machine)에서 수행되며, 서로의 존재를 알지 못한다.
- H/W에 대한 접근은 Hypervisor에게 할당 받은 자원에 대해서만 수행한다.
- Hypervisor는 각 게스트 OS 간의 CPU, 메모리 등 시스템 자원을 분배하는 등 최소한의 역할을 수행한다.
장점
- 하나의 물리 컴퓨터에서 여러 종류의 게스트 OS 운용이 가능하다.
- 한 서버에서 다양한 서비스를 동시에 제공한다.
- 실제의 컴퓨터가 제공하는 것과 다른 형태의 명령어 집합 구조(Instruction Set Architecture)를 제공한다.
- 다른 H/W 환경으로 컴파일 된 게스트 OS 및 응용 프로그램도 실행 가능하다.
- 한 시스템이 문제(해킹)가 생겨도 다른 시스템에 영향을 못미친다.
단점
- H/W를 직접적으로 사용하는 다른 운영체제에 비해 성능이 떨어진다.(성능보다 보안성이 목적인 경우에 사용한다.)
- 게스트 OS가 H/W 자원에 직접 접근하지 못하고, 항상 Hypervisor를 경유해야 하므로 오버헤드가 발생한다.
- 반가상화(Para-Virtualization)로 성능저하 문제를 해결하려 한다.
- 단 게스트 OS의 H/W 의존적인 코드에 대한 수정이 요구된다.
- 높은 기술적인 능력이 필요하다.
- OS의 소스가 공개되지 않았다면 게스트 OS로는 수정이 불가능하다.
2. Docker
2.1. 등장 배경
2.1.1. 현대 개발 환경의 요구
오늘날의 개발 및 서비스 환경에서는 다음과 같은 요구사항이 중요해졌다:
- 하나의 서버에 여러 서비스를 동시에, 독립적으로 배포 및 실행 가능해야 한다.
- ex) 웹 서버, 데이터베이스, 백엔드 API 등
- 장애 발생 시 빠르게 재배포 및 롤백이 가능해야 한다.
- 각 서비스 간의 환경(버전, 라이브러리) 충돌 없이 실행 가능해야 한다.
- 테스트, 개발, 운영 환경 간에 일관된 실행 환경을 보장해야 한다.
이러한 요구를 충족시키기 위해 가상화 기술이 사용되어 왔지만, 기존의 Hypervisor 기반 가상화(VM)는 다음과 같은 단점이 있다:
2.1.2. 기존 VM 방식(Hypervisor 기반)의 제약
부팅 시간이 느리다
- VM은 게스트 OS 전체를 부팅해야 하므로 몇 초에서 수 분까지 시간이 소요된다.
- 예: 단순히 Spring 서버 하나 실행하려고 전체 Ubuntu OS를 부팅하는 것은 매우 비효율적이다.
리소스 소비량이 크다
- VM 하나당 CPU, 메모리, 디스크 등을 독립적으로 할당받는다.
- 각 VM은 자체 커널과 시스템 프로세스를 가지고 있기 때문에
중복된 자원 소비가 발생한다.- 예: 웹 서버만 실행하더라도 파일 시스템, 네트워크, 로그 등
OS 전반적인 자원이 필요하다.
- 예: 웹 서버만 실행하더라도 파일 시스템, 네트워크, 로그 등
서비스 단위 배포에 비효율적이다
- 새로운 서비스를 배포하기 위해 게스트 OS 설치 → 애플리케이션 설치 → 설정 → 부팅 과정을 거쳐야 한다
- VM 이미지는 수 GB 단위의 용량을 가지기 때문에 빌드, 공유, 배포 속도가 느리고 무겁다.
- 환경 간 설정 차이로 인해 일관성이 보장되지 않는 경우가 많다.
이러한 기존 VM 방식의 제약을 해결하기 위해 등장한 것이 바로 OS 수준의 경량 가상화 기술인 컨테이너, 그리고 그 대표 도구인 Docker이다.
- Docker는 리눅스 커널의 기능을 활용해, 하나의 OS 내에서 애플리케이션을 격리된 환경(컨테이너) 에서 실행하는 플랫폼이다.
- 기존 가상 머신과 달리, 호스트 OS의 커널을 공유하면서 애플리케이션을 실행한다.
- Guest OS가 없음
- 컨테이너는 독립적으로 실행되지만, 실제로는 호스트 OS의 커널을 공유한다.
2.2. 특징
2.2.1. 커널은 공유하지만, 컨테이너는 독립적으로 실행된다
- 컨테이너는 개별 애플리케이션만을 실행하도록 설계되어 있다.
- 리눅스 커널을 공유하지만, 각 컨테이너는 고유한 주소 공간, 파일 시스템, 네트워크를 가진다.
- 이로 인해 마치 독립된 OS처럼 보이지만 훨씬 가볍고 빠르다.
2.2.2. 단일 애플리케이션, 단일 환경
- 컨테이너에는 하나의 애플리케이션과 그 실행 환경(설정, 라이브러리 등)이 포함된다.
- 크기가 작고, 부팅이 빠르며, 배포가 단순하다.
- "한 번 빌드하면 어디서든 실행 가능"한 높은 이식성을 제공한다.
2.3. 장점
2.3.1. 빠른 실행 속도
- VM처럼 OS를 부팅하지 않고, 바로 애플리케이션 실행 가능
- 수 초 이내에 컨테이너 기동
2.3.2. 경량화된 이미지
- 수백 MB 수준의 가벼운 이미지로, 저장·배포·복제가 빠름
- 같은 베이스 이미지를 공유하여 저장 공간 절약
2.3.3. 환경 일관성 보장
- 개발, 테스트, 운영 환경에서 동일한 이미지 기반으로 실행 가능
- “내 컴퓨터에서는 잘 되는데?” 문제 최소화
2.3.4. 격리성과 보안성
- 컨테이너마다 독립된 환경 제공
- 한 컨테이너의 문제가 다른 컨테이너에 영향 주지 않음
2.3.5. 이식성과 확장성
- 한번 이미지로 만들면, 어디서든 실행 가능 (윈도우, 맥, 리눅스)
- Kubernetes 등 오케스트레이션 도구와 함께 사용 시 대규모 서비스 배포에 적합
그래서 도커를 왜 사용하나요?
- 도커는 가볍고 빠르며, 어디서든 일관되게 실행 가능한 애플리케이션 환경을 제공하기 때문에 사용합니다.
- 기존에도 hypervisor 기반의 가상화 기술이 있었지만, guest OS 전체를 부팅해야 해서 실행 속도가 느리고, resource를 많이 사용하는 데다, 서비스 단위로 배포하기에는 비효율적인 측면이 있었습니다.
- 도커는 이러한 한계를 해결하면서도 각 애플리케이션을 컨테이너 단위로 격리해 실행할 수 있어, 마이크로서비스 환경에 특히 적합하다고 생각합니다.
출처
- 숭실대학교 공영호 교수님 운영체제
- 스즈키 료타 (2025.02) 그림으로 배우는 도커