> For the complete documentation index, see [llms.txt](https://leehyokyun.gitbook.io/openbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://leehyokyun.gitbook.io/openbook/6-1.-cloud-native.md).

# 6-1. 가상화 기술 및 Cloud Native

가상화 기술, Cloud Native에 대하여

### Cloud Native, MSA를 선택하는 이유

* Cloud Native의 가치 중장기적으로 서비스가 커지고 이에 대한 트래픽 병목 관리 및 성능 향상 대응 비용이 커지는 상황에 직면한다. Cloud Native는 관리 비용 및 Scale out을 통한 성능 향상 비용을 낮추고, 고가용성을 확보할 수 있는 전략이다.
* MSA의 특징과 비용적 고려사항 도메인 별 세분화를 통해 스쿼드 운용 및 매니징이 가능하며, 이를 통한 서비스 결합도를 최소화한다. 이에 따라 단일 장애점을 제거하여 도메인 내 별도의 언어, 프로젝트, 데이터 관리, 저장 방식을 달리하고 이를 기반으로 기획, 통합, 배포 등 개별적이고 빠른 운용 방식을 확보할 수 있다. 
* 이러한 중장기적인 관리 및 성능 향상 비용의 절감 효과도 있지만, Cloud Native 환경에서 목적에 부합하고 최적화된 전략이 바로 MSA이기도 한다. 다만 도메인 별 데이터와 프로젝트 분리 등으로 인해 데이터 일관성 확보가 힘들 수 있으며, 프로세스 간 IPC 비용처럼 네트워킹 비용이 소모되어 통신 방법에 대한 고민과 통신 비용 소모 등을 고려할 필요가 있다.

### 가상화 : Hypervisor(가상머신) 기동 방식 vs 컨테이너 (Container Runtime)

#### 격리 수준 기반의 이해(VM / Docker)

* 애플리케이션 실행 환경을 격리한다는 점은 동일하지만, Host OS Kernel을 공유하면서 프로세스 기반 격리인가, Host 하드웨어를 공유하는 모든 하드웨어의 가상화인가. 
  * HyperVisor 기반의 가상화 방식 HyperVisor를 통해 하드웨어를 가상화하며, 이를 기반으로 한 가상머신은 곧 1개의 컴퓨터(Guest OS)이다. 1 VM은 1 Guest OS 구조를 가지며, 메모리, 커널, 부팅 모두 독립적으로 운용된다. 즉, 가짜 컴퓨터를 만들어 마치 하나의 컴퓨터를 새로 만들고 부팅하는 듯한 동작을 진행하는 것이다. 따라서 VM 실행은 Guest OS 부팅 및 커널 로딩, 메모리 점유 등을 동반하므로 그 자체로 엄청나게 무겁고 느리다.
  * Container 기반의 가상화 방식 Guest OS 없이, 한 개의 Host OS 커널만을 공유하여 각 프로세스를 격리 환경에서 실행하는 방식이다. 1 Container는 1 OS 환경의 효과를 내며, 컨테이너의 분리는 곧 실행할 프로세스 환경을 분리하는 것을 의미한다. 컨테이너는 하나의 컴퓨터 안에서 방을 나눈 것과 같다. 
* 가짜 컴퓨터를 놔두지 않고 Host OS에서 프로세스 실행 환경을 컨테이너로 분리 및 격리 실행한다. 하드웨어를 가상화하지 않고 namespace를 통한 격리와 cgroup을 통한 자원 제한을 이용하여 실행 환경 격리를 행한다. 게스트 운영체제를 부팅하지 않고 커널만 공유하여 격리 환경에서 프로세스 하나만 실행하므로 배포가 빠르다.
* 환경별 적합한 전략 강한 격리가 필요한 상황에서는 VM 방식을 사용하고, 빠른 배포와 마이크로서비스가 필요한 환경에서는 컨테이너 방식을 선택한다. 그래서 보통은 VM 위에 컨테이너를 올리는 구조를 활용한다.

### 컨테이너 환경에 대하여

* 컨테이너 및 런타임의 정의 Container는 실행 중인 프로세스의 집합이며 철저하게 격리된 환경이다. 컨테이너는 격리된 Linux 프로세스라고 볼 수 있다. 특정 컨테이너 간의 연결을 의미하는 네트워크 환경(Not Host Net) 및 리소스 제한 등이 붙은 실행 환경을 구성한다. Container Runtime은 이러한 Container를 생성하고 실행하는 프로그램이다.
* Docker 인터페이스 계층 구조: Docker(사용자 인터페이스) -> Docker CLI -> containerd(Docker Engine / 컨테이너 관리) -> runc(실제 컨테이너 실행) -> Linux Kernel(격리 기능 제공)의 흐름으로 이루어진다.
* Linux Kernel의 분리 메커니즘 컨테이너의 격리 환경은 Linux Kernel의 논리적 분리 및 리소스 제한(cgroup)의 원리를 기반으로 동작한다. 같은 OS이지만 컨테이너 내부 실행 환경을 논리적으로 분리한다. Host OS process list 상에서 다음과 같은 규칙으로 작동한다.
* Namespace의 역할: PID(프로세스 목록 분리), NET(네트워크 분리), MNT(파일시스템 분리), IPC(프로세스 통신 분리), UTS(hostname 분리), USER(사용자 권한 분리) 등을 통해 프로세스를 논리적으로 분리한다. 컨테이너에서는 같은 OS 내에서 container 내부 환경을 논리적으로 분리하여 PID 1, PID 2, PID 3 형태로 실행한다.
* cgroups(control groups)의 역할: 프로세스들을 Control Group으로 묶어 해당 그룹이 사용하는 리소스를 제한하고 추적한다. 예시로 CPU 1 core, RAM 512MB, Disk IO 제한 등을 수행하며 리눅스 내부적으로 /sys/fs/cgroup/ 경로에서 memory.max, cpu.max, pids.max 같은 파일로 리소스를 제한하고 관리한다. 결론적으로 Container는 namespace와 cgroup으로 격리된 프로세스이다.
* 이미지 레이어 및 실행 과정 이미지를 실행하여 컨테이너 환경에서 OS 체제와 상관없이 격리 환경에서 실행하는 과정을 거친다. 이미지 자체는 Read-only 파일 시스템 Layer의 누적 구조이다. Dockerfile의 예시로 `FROM ubuntu`, `RUN apt install openjdk-17-jdk`, `COPY app.jar /app/app.jar` 구조가 있다면, 이는 Layer 1(Ubuntu OS 파일들), Layer 2(OpenJDK 설치 파일들), Layer 3(app.jar 파일)이 순차적으로 누적된 형태를 띤다. 실행 시에는 이 Read Only 레이어들 위에 Container writable layer가 추가된다. 여러 개의 파일 시스템 레이어로 이루어진 파일 구조는 최종적으로 하나의 root system(bin, lib, app, etc 등)처럼 보이도록 Overlay FS를 활용하여 파일 시스템 및 프로젝트처럼 논리적으로 보여지도록 결합한다. 리눅스의 layer 형태로 저장될 때는 /var/lib/docker/overlay2, containers, images, volumes 등의 구조 하위에 저장되며, 최종적으로 리눅스 파일 및 프로세스 기반으로 이미지가 실행된다.

### 일반 프로그램 실행과의 비교 차이

* 일반 프로그램: OS 공유 상태에서 격리가 없으며 리소스 제한 없이 일반 실행이 이루어진다.
* 컨테이너: OS 공유 상태에서 namespace 격리가 이루어지고, cgroup 제한을 통해 리소스를 통제한다. 즉, OS를 공유하면서 논리적으로 실행 환경을 namespace 기반으로 격리하며 리소스 점유는 cgroup으로 제한하여 작동한다. 따라서 Hypervisor와는 달리 Guest OS를 부트스트랩(부팅)하지 않고 논리적으로 환경만 분리하여 실행할 수 있다. 결과적으로 HyperVisor 방식에 비해 무겁지 않고, 번거로운 OS 환경 구성 작업이 필요 없으며 그만큼 빠르다는 장점을 지닌다.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://leehyokyun.gitbook.io/openbook/6-1.-cloud-native.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.