운영체제 — 4강: 가상화·분산시스템·현대 OS

가상화 기술

가상화 (Virtualization):
→ 물리 자원 위에 여러 가상 환경을 만드는 기술
→ 서버 통합·자원 효율화·환경 격리·이식성 향상

하이퍼바이저 (Hypervisor):
→ 가상 머신(VM)을 생성·관리하는 소프트웨어
→ 타입 1 (Bare-metal): 하드웨어 위에 직접 실행
  VMware ESXi·Microsoft Hyper-V·KVM (Linux 커널)·Xen
  성능 우수·데이터센터·클라우드 사용
→ 타입 2 (Hosted): 호스트 OS 위에 실행
  VirtualBox·VMware Workstation
  개발·테스트·개인 사용

가상 머신 구성 요소:
→ vCPU: 물리 CPU 코어 공유·시간 분할
→ 가상 메모리: 물리 메모리 매핑
→ 가상 디스크: 파일 기반 (VMDK·QCOW2)
→ 가상 NIC: 물리 NIC 공유·소프트웨어 스위치
→ VM 이미지: 완전한 OS + 애플리케이션

KVM (Kernel-based Virtual Machine):
→ Linux 커널의 가상화 모듈
→ VT-x/AMD-V (하드웨어 가상화 지원) 필요
→ QEMU와 결합: 장치 에뮬레이션
→ 오픈소스·AWS·Google Cloud 기반 기술

하드웨어 지원 가상화:
→ Intel VT-x·AMD-V: CPU 가상화
→ SR-IOV: PCIe 장치 직접 VM에 할당
→ EPT (Extended Page Tables): 메모리 가상화 가속
→ 가상화 전·가상화 후·para-가상화 비교:
  전가상화: 게스트 수정 불필요·이진 번역 필요 (느림)
  하드웨어 보조: VT-x/AMD-V·성능 우수
  para-가상화: 게스트 OS 수정 필요·Xen Hypercall

---

컨테이너 기술

컨테이너 (Container):
→ OS 수준 가상화: 커널 공유·프로세스 격리
→ VM 대비: 가볍고 빠름 (OS 부팅 불필요)
→ 이미지 기반: 환경 재현 보장

Linux 격리 기술:
→ 네임스페이스 (Namespace): 자원 격리
  PID: 프로세스 ID 격리
  Network: 네트워크 스택 격리
  Mount: 파일 시스템 뷰 격리
  UTS: 호스트명 격리
  IPC: 프로세스 간 통신 격리
  User: UID/GID 격리 (루트리스 컨테이너)
→ cgroups (Control Groups): 자원 제한
  CPU·메모리·I/O·네트워크 대역폭 상한 설정
  자원 사용량 모니터링
→ seccomp: 시스템 콜 필터링 (보안 강화)
→ capabilities: 루트 권한 세분화

Docker:
→ 컨테이너 이미지 빌드·배포·실행 도구
→ Dockerfile: 이미지 빌드 스크립트
→ 레이어 구조: 변경된 레이어만 전송 (효율적)
→ Docker Hub: 이미지 레지스트리
→ Docker Compose: 다중 컨테이너 앱 정의·실행

컨테이너 vs VM 비교:
→ 시작 시간: 컨테이너 ms~초 / VM 분
→ 용량: 컨테이너 MB / VM GB
→ 격리 수준: 컨테이너 프로세스 / VM 완전 OS
→ 보안: VM이 더 강한 격리 (별도 커널)
→ 성능: 컨테이너 네이티브에 가까움

Kubernetes (K8s):
→ 컨테이너 오케스트레이션 플랫폼
→ 자동 배포·확장·자가 치유·로드밸런싱
→ Pod: 최소 배포 단위 (1~여러 컨테이너)
→ Service: 고정 IP·로드밸런싱 추상화
→ Deployment: Pod 복제본 관리·롤링 업데이트
→ ConfigMap·Secret: 설정·민감 정보 분리
→ HPA (Horizontal Pod Autoscaler): 자동 수평 확장

---

분산 시스템

분산 시스템 (Distributed System):
→ 네트워크로 연결된 여러 컴퓨터가 협력하여 작업 처리
→ 장점: 확장성·가용성·지리적 분산
→ 도전: 부분 장애·지연 편차·일관성 문제

RPC (원격 프로시저 호출):
→ 원격 서버의 함수를 마치 로컬처럼 호출
→ IDL (Interface Definition Language): 인터페이스 정의
→ 직렬화·역직렬화: Protocol Buffers·Thrift·JSON
→ gRPC: Google의 현대 RPC 프레임워크
  HTTP/2 기반·양방향 스트리밍·다언어 지원

CAP 정리 (Brewer):
→ 분산 시스템에서 세 가지 보장을 동시에 만족 불가
→ C (Consistency): 모든 노드가 동일 데이터
→ A (Availability): 모든 요청이 응답받음
→ P (Partition Tolerance): 네트워크 분할 시 동작
→ CP 시스템: ZooKeeper·HBase (일관성 우선)
→ AP 시스템: Cassandra·DynamoDB·CouchDB (가용성 우선)
→ 현실: P는 포기 불가 → CA 선택만 가능

PACELC 정리 (확장):
→ CAP에 지연(Latency) 추가
→ 파티션 시: C vs A / 정상 시: L(지연) vs C

분산 합의 알고리즘:
→ Paxos: 고전적 합의 알고리즘·이해 어려움
→ Raft: Paxos 단순화 버전·리더 선출·로그 복제
  etcd·CockroachDB·TiKV 활용
→ BFT (Byzantine Fault Tolerance): 악의적 노드도 허용

분산 파일 시스템:
→ GFS (Google File System):
  청크(64MB) 분산 저장·체크섬·자동 복제
  마스터-청크서버 구조
→ HDFS (Hadoop Distributed File System):
  GFS 오픈소스 구현
  NameNode(메타데이터)·DataNode(데이터)
→ Ceph: 오픈소스 분산 스토리지 (오브젝트·블록·파일)

분산 데이터베이스:
→ 수평 파티셔닝 (Sharding): 행 기준 노드 분산
→ 복제 (Replication): 고가용성·읽기 확장
→ 2PC (2단계 커밋): 분산 트랜잭션 원자성 보장
  코디네이터 장애 시 블록킹 문제
→ Saga 패턴: 마이크로서비스 분산 트랜잭션 (보상 트랜잭션)

---

현대 OS 동향

마이크로커널 vs 모놀리식 커널:
→ 모놀리식 커널 (Linux·Windows):
  모든 기능이 커널 공간 → 빠름
  드라이버 버그가 커널 크래시 유발 가능
→ 마이크로커널 (MINIX·seL4):
  최소 기능만 커널 (IPC·스케줄링·메모리)
  나머지는 사용자 공간 서버
  안정성·보안 우수·성능은 낮음
→ 하이브리드 (Windows NT·macOS XNU):
  두 방식 혼합

실시간 운영체제 (RTOS):
→ 결정론적 응답 시간 보장
→ 경성 실시간: 데드라인 절대 준수 (제어 시스템·항공)
→ 연성 실시간: 데드라인 최선 준수 (멀티미디어)
→ FreeRTOS·VxWorks·QNX·RTEMS

임베디드 OS:
→ 자원 제약 환경: 소형 메모리·저전력
→ RTOS·Linux (임베디드)·Zephyr·Mbed OS
→ IoT: TinyOS·Contiki·RIOT

현대 OS 보안 기능:
→ ASLR (Address Space Layout Randomization):
  프로세스마다 스택·힙·라이브러리 주소 무작위화
  버퍼 오버플로우 익스플로잇 어렵게
→ DEP/NX (Data Execution Prevention):
  데이터 세그먼트 실행 금지
  셸코드 실행 방지
→ SMEP·SMAP: 사용자 공간 코드/데이터 커널 접근 금지
→ CFI (Control Flow Integrity): 함수 포인터 조작 방지
→ Secure Boot: 부팅 과정 무결성 검증

eBPF (Extended Berkeley Packet Filter):
→ 커널 수정 없이 커널 내 프로그램 실행
→ 관찰성·네트워킹·보안 동적 삽입
→ Cilium (K8s 네트워킹)·Falco (보안)·Pixie (관찰성)

---

자주 묻는 질문

Q. VM과 컨테이너 중 어떤 것을 선택해야 하나요? A. 선택 기준은 격리 요구 수준과 자원 효율 간의 균형입니다. 강한 보안 격리가 필요하거나 게스트 OS가 호스트와 다른 OS여야 할 경우(예: Linux 서버에서 Windows VM)에는 VM이 적합합니다. 데이터센터 물리 서버를 여러 팀이 공유할 때도 VM의 완전 격리가 유리합니다. 반면 동일 OS를 기반으로 빠른 배포·확장·이식성이 필요한 마이크로서비스 애플리케이션이라면 컨테이너가 적합합니다. 컨테이너는 시작 시간이 밀리초 수준이고, CI/CD와의 통합이 쉬우며, 수백~수천 개를 동시에 실행할 수 있습니다. 실제로 클라우드 환경에서는 두 기술을 함께 사용합니다. VM으로 멀티테넌트 격리를 보장하면서 그 위에서 컨테이너를 운영하는 구조(AWS EC2 + EKS 등)가 일반적입니다.

Q. CAP 정리가 실제 데이터베이스 선택에 어떻게 영향을 주나요? A. CAP 정리는 분산 시스템 설계의 핵심 지침입니다. 금융·결제 시스템처럼 데이터 일관성이 절대적으로 중요한 경우 CP 시스템을 선택합니다. ZooKeeper나 관계형 데이터베이스(Postgres·MySQL)의 동기 복제가 여기 해당합니다. 네트워크가 분할되면 서비스를 일시 중단하더라도 잘못된 데이터를 반환하지 않겠다는 선택입니다. 반면 소셜 미디어 좋아요 수나 사용자 활동 로그처럼 약간의 일관성 지연을 허용할 수 있는 서비스는 AP 시스템(Cassandra·DynamoDB)을 선택합니다. 높은 가용성과 낮은 지연을 우선시하되, 결국 데이터는 일치(최종 일관성)됩니다. 다만 CAP는 이분법이 아닌 연속체이며, 실제는 일관성과 가용성의 정도를 세밀히 조정하는 설계를 많이 사용합니다.