[Docker] 2. 가상화 기술과 컨테이너 가상화 관련 공부

2.1. 서버

2.1.1. 서버와 클라이언트

• 서버의 정의: 서버는 크게 물리적 부품과 장비로 이루어진 하드웨어(Hardware)와 그 하드웨어 위에서 실행되어 특정 서비스를 처리하고 기능을 제공하는 소프트웨어(Software)로 구성됩니다.

• 클라이언트와 서버의 역할: 클라이언트(Client)가 웹 페이지 요청이나 데이터 조회 등의 요청(Request)을 보내면, 서버(Server)는 이 요청을 받아 분석한 뒤 요청에 알맞은 결과 데이터를 가공하여 응답(Response)합니다.

• 서버-클라이언트 개념도:

  

• 결론: 모든 서버의 공통점은 클라이언트의 요청을 받아 결과를 응답하는 것입니다.

2.1.2. 서버의 종류

• 파일 서버 (File Server): 네트워크 상에서 여러 사용자가 파일을 업로드하고 다운로드하며 공유할 수 있도록 중앙에서 파일을 저장하고 관리하는 서버입니다. (예: NAS, FTP 서버, AWS S3 등)
• 데이터베이스 서버 (Database Server): 데이터를 체계적으로 저장, 수정, 삭제 및 관리하며, 클라이언트의 쿼리 요청에 따라 대량의 데이터를 빠르고 안전하게 가공해 주는 서버입니다. (예: MySQL, Oracle, PostgreSQL 등)
• 웹 서버 (Web Server): 클라이언트(웹 브라우저)로부터 HTTP/HTTPS 요청을 직접 받아 HTML, CSS, JavaScript, 이미지 등의 정적 콘텐츠를 가볍고 빠르게 응답해 주는 서버입니다. (예: Nginx, Apache 등)
• 웹 애플리케이션 서버 (WAS, Web Application Server): 단순 정적 자원 반환을 넘어 사용자의 로그인, 결제 등 복잡한 비즈니스 로직 처리 및 데이터베이스 연동과 같은 동적인 처리를 수행한 후 그 결과를 웹 서버를 통해 클라이언트에게 제공하는 서버입니다. (예: Tomcat, Express, Spring Boot 등)

2.1.3. 엔터프라이즈 환경의 서버 운영

엔터프라이즈 환경에서 기업이 서비스를 중단 없이 안정적으로 서비스하기 위해 서버를 운영하는 방식은 크게 세 가지로 분류됩니다.

1. 베어메탈 (Bare Metal): 가상화 레이어 없이 물리 하드웨어(서버 장비) 위에 운영체제(OS)를 직접 설치하고 애플리케이션을 직접 실행하는 전통적인 방식입니다.
2. 하이퍼바이저 (Hypervisor): 물리 하드웨어 위에 하이퍼바이저 소프트웨어를 올려 여러 개의 독립된 가상 머신(VM)을 나누고, 각 VM마다 별도의 게스트 운영체제(Guest OS)를 설치하여 운영하는 방식입니다.
3. 컨테이너 (Container): 별도의 게스트 OS 설치 없이, 호스트 운영체제(Host OS)의 커널을 공유하면서 네임스페이스와 cgroups 기술을 이용해 독립적이고 격리된 프로세스 공간(컨테이너)을 띄워 서비스를 운영하는 현대적인 방식입니다.

2.2. 가상화 기술

• 동작 원리 및 필요성: 가상화 기술은 단일 물리 서버의 하드웨어 리소스(CPU, 메모리, 스토리지 등)를 소프트웨어 계층을 통해 추상화하여, 여러 개의 논리적인 가상 리소스나 컴퓨팅 환경으로 쪼개서 분배하는 기술입니다. 물리 장비의 노는 리소스(유휴 자원)를 최소화하고, 여러 독립적인 개발/운영 환경을 하드웨어 증설 없이 신속하게 구축하기 위해 사용됩니다.
• 결론: 가상화 기술은 물리적인 컴퓨팅 환경 내에서 여러 개의 논리적인 컴퓨팅 환경을 만들 수 있는 기술입니다.

2.2.1. 가상화 기술과 소프트웨어

• 보안 및 리소스 격리의 필요성: 기존 베어메탈 환경에서는 하나의 OS 위에 여러 소프트웨어가 동시에 실행됩니다. 만약 하나의 소프트웨어가 해킹당하거나 무한 루프 등의 오류로 시스템 전체 메모리를 독점하게 되면, 같은 OS 내의 모든 소프트웨어가 함께 멈추는 보안 취약성과 자원 간섭 문제가 발생합니다.
• 가상화의 해결 방식: 가상화 기술은 애플리케이션들을 완전히 격리된 별도의 논리 공간(가상머신 또는 컨테이너)에서 실행되게 만듭니다. 이 덕분에 특정 공간이 침해당하거나 자원을 과도하게 사용하더라도 외부 환경이나 다른 격리 공간에는 전혀 악영향을 주지 않아 보안성과 시스템 안정성을 비약적으로 높일 수 있게 되었습니다.

2.2.2. 가상화 기술의 경제성

• 각 애플리케이션의 독립성과 보안을 보장하기 위해 매번 별도의 물리적 하드웨어 서버를 개별 구매하지 않는 핵심적인 이유는 경제성(TCO, 총 소유 비용) 때문입니다.
• 물리 서버의 대수가 늘어날수록 장비 구매 비용뿐만 아니라 상면(공간) 이용료, 전기 요금, 쿨링(냉방) 비용 및 시스템 관리 인력 등 운영비가 급격히 증가합니다. 가상화 기술을 사용하면 고성능 서버 1대 내부의 노는 리소스(평균 10~15% 수준인 물리 자원 사용률)를 논리적으로 잘게 쪼개어 수십 대의 가상 서버로 전환할 수 있으므로, 하드웨어 효율성을 80% 이상으로 극대화하여 막대한 인프라 비용을 절감할 수 있습니다.

---

2.3. 하이퍼바이저 가상화

• 호스트 OS (Host OS): 물리 서버 하드웨어에 직접 설치되어 구동되며, 하이퍼바이저 소프트웨어가 작동할 수 있는 뼈대와 기본 시스템 자원을 제공하는 주 운영체제입니다.
• 가상머신 (VM, Virtual Machine): 하이퍼바이저 소프트웨어를 통해 생성된 가상의 컴퓨터 본체입니다. 가상화된 CPU, 메모리, 스토리지 등을 할당받아 그 위에 독자적인 운영체제(Guest OS)를 독립적으로 부팅하고구동할 수 있습니다.
• 실행 구조: 하이퍼바이저 가상화는 물리 하드웨어 및 OS 위에 가상화 관리 계층인 하이퍼바이저(Hypervisor)가 올라갑니다. 하이퍼바이저는 물리 자원을 가상의 부품들로 나누어 개별 VM에 할당하고, 각 VM은 자체적인 게스트 OS를 기반으로 격리된 애플리케이션 실행 환경을 생성합니다.

2.3.1. 프로세스와 OS

• 프로세스, OS, 서버의 관계:
  • 프로세스(Process)는 운영체제로부터 메모리를 할당받아 실행 중인 프로그램의 인스턴스입니다.
  • OS(운영체제)는 이러한 프로세스들이 하드웨어 장치를 독점하지 못하게 중재하고 자원을 공평하게 분배/관리하는 시스템 소프트웨어입니다.
  • 서버(Server)는 이러한 OS 환경 하에서 다수의 네트워크 요청 처리 프로세스들이 항시 실행되며 서비스를 제공하는 전체 하드웨어 및 시스템 소프트웨어의 집합체입니다.

• 커널 (Kernel): 운영체제의 핵심 영역으로, 부팅 시 메모리에 상주하면서 컴퓨터의 물리 하드웨어(CPU, 메모리, 디스크 등)를 제어하고 사용자 프로세스에 자원을 할당해 주는 하드웨어 관리 총괄 관리자입니다.
• 시스템 콜 (System Call): 사용자 공간의 애플리케이션 프로세스가 디바이스 드라이버나 파일 입출력, 네트워크 통신 등 커널의 권한이 필요한 특권 명령을 실행해야 할 때, 커널에게 대행 처리를 공식적으로 요청하는 인터페이스 창구입니다.

2.3.2. 하이퍼바이저의 역할

• 하이퍼바이저는 물리 하드웨어와 가상머신(VM)들의 게스트 OS 사이에 위치하여 중간 다리 역할을 수행합니다.
• 가상머신 내부의 게스트 OS가 하드웨어 제어를 위해 시스템 콜을 보내면, 하이퍼바이저는 이를 가로채서(Intercept) 호스트의 물리 시스템 콜 및 실제 하드웨어 명령어로 변환/전달하고, 물리 자원 배분을 조율합니다.

---

2.4. 컨테이너 가상화

• LXC (Linux Containers): 리눅스 커널의 가상화 지원 기능을 기반으로, 하드웨어를 에뮬레이트하거나 별도의 OS를 구동하지 않고 단일 리눅스 호스트 시스템 내부에서 프로세스 단위의 격리된 가상 실행 환경을 만드는 컨테이너 기술의 시초 격인 오픈소스 도구입니다.
• LXC의 핵심 구성 기술:
  • 네임스페이스 (Namespace): 프로세스별로 파일 시스템(mnt), 프로세스 ID(pid), 네트워크 인터페이스(net), 사용자 ID(user) 등을 각기 다르게 매핑하여, 프로세스가 마치 자신만의 전용 OS 환경을 가진 것처럼 느끼게 환경을 물리적으로 격리하는 커널 기능입니다.
  • 컨트롤 그룹 (cgroups): 특정 네임스페이스에 묶인 격리 프로세스군이 호스트의 자원을 과도하게 소모하지 못하도록, 사용 가능한 CPU 시간, 메모리 크기, 디스크 입출력 대역폭 등을 엄격하게 할당하고 제한하는 커널 자원 관리 기능입니다.
• 커널 공유 기능: 컨테이너 가상화는 하이퍼바이저나 무거운 게스트 OS를 사용하지 않고 호스트 OS의 커널을 그대로 공유하여 명령을 수행합니다. 호스트 OS 커널 위에 컨테이너 엔진이 올라가고, 그 위에서 독립적인 프로세스(컨테이너)들이 동일한 커널 인터페이스를 타고 바로 하드웨어와 직접 통신하므로 컨테이너 기술의 핵심이자 가장 큰 특징이 됩니다.

2.4.1. 하이퍼바이저 가상화 vs 컨테이너 가상화

• 오버헤드가 적은 이유: 하이퍼바이저 가상화는 독립된 OS를 띄우기 위해 커널 이미지 로딩 및 기본 OS 실행용 리소스로 수백 MB~수 GB의 메모리를 항상 낭비해야 합니다(오버헤드가 큼). 반면 컨테이너 가상화는 게스트 OS가 없고 호스트 커널을 직접 빌려 쓰기 때문에 프로세스 구동에 필요한 만큼(수 MB)만 메모리를 소모하므로 오버헤드가 극히 적습니다.
• OS 부팅 속도가 빠른 이유: 하이퍼바이저 VM은 전원을 켜고 OS가 온전히 부팅되어 커널을 초기화하는 데 수 초에서 수 분의 기동 시간이 필요합니다. 반면 컨테이너는 이미 켜져 있는 호스트 커널 상에서 Namespace와 cgroups를 적용한 프로세스 하나를 띄우는 동작에 불과하므로, 별도의 부팅 과정 없이 밀리초(ms) 단위로 즉시 실행됩니다.

---

2.5. 도커

도커(Docker)는 리눅스 컨테이너 기술을 보다 쉽고 표준화된 방식으로 빌드, 배포, 실행할 수 있도록 통합 환경을 제공하는 대표적인 오픈소스 플랫폼입니다.

• 아키텍처 개요: 도커는 사용자가 명령어를 입력하는 도커 클라이언트(CLI)와 백그라운드에서 실질적인 컨테이너 라이프사이클을 관리하는 도커 데몬(Docker Daemon)으로 나뉩니다. 두 컴포넌트는 내부적인 REST API 규격으로 소통하며 작동하는 구조를 갖고 있습니다.

2.5.1. 도커의 아키텍처

• 도커 데몬 (Docker Daemon, dockerd): 호스트 OS 백그라운드에서 상주하면서 도커 API 요청을 대기하고 수신합니다. 수신한 API 명령에 맞춰 이미지 빌드, 컨테이너 격리 및 리소스 분배, 네트워크 및 저장 볼륨 설정 등 도커의 모든 핵심 오브젝트를 통제하고 관리하는 주체입니다.
• 도커 CLI (Command Line Interface): 사용자가 커맨드 창에 docker 명령을 타이핑하여 데몬과 직접 상호작용하기 위한 도구입니다. 사용자가 입력한 커맨드는 도커 API 규격에 맞는 요청 메시지로 조립되어 도커 데몬으로 전송됩니다.
• 도커 아키텍처 실행 순서:
  1. 명령어 실행: 사용자가 터미널 환경에 docker run nginx와 같은 도커 실행 명령을 실행합니다.
  2. 사용자 명령 전달: 도커 클라이언트가 입력된 명령어를 REST API 형식으로 가공하여 도커 데몬(dockerd)에 전달합니다.
  3. 컨테이너 관리: 도커 데몬은 로컬 저장소에 nginx 이미지가 있는지 검사합니다. 이미지가 없다면 원격 도커 레지스트리(Docker Hub)에 이미지 다운로드(pull)를 요청하여 수신한 뒤, 해당 이미지를 기반으로 격리된 컨테이너를 빌드 및 생성(run)하고 자원을 할당하여 작동시킵니다.
  4. 결과 전달: 도커 데몬이 컨테이너 실행 상태 및 결과 로그를 가공해 클라이언트(CLI) 측에 API 응답으로 돌려주고, 클라이언트는 이를 터미널 화면에 정상 출력합니다.

---

2.6. 컨테이너 실행

2.6.1. 웹 서버

• docker --help 커맨드:
  도커 CLI가 지원하는 모든 옵션, 환경 변수 및 관리 명령어 목록을 요약하여 볼 수 있게 출력해 주는 명령어입니다. 특정 명령어의 철자나 사용 가능한 세부 옵션 플래그가 기억나지 않을 때 요약 매뉴얼로 유용하게 사용됩니다.

  $ docker --help
  
  Usage:  docker [OPTIONS] COMMAND
  
  A self-sufficient runtime for containers
  
  Common Commands:
    run         Create and start a new container from an image
    exec        Execute a command in a running container
    ps          List containers
    build       Build an image from a Dockerfile
    pull        Download an image from a registry
    images      List images
    ...

• 도커 명령어 구조:
  도커는 늘어나는 기능들을 논리적으로 정리하기 위해 명령어를 대분류(Management Command)와 소분류(Command) 구조로 조직화하여 지원합니다.

  • 과거 명령어 구조 (직관적인 단축형): docker [Command]
    • 예시: docker run [이미지] (컨테이너 실행), docker ps (컨테이너 목록 확인)
  • 현대적 명령어 구조 (대분류/소분류 표준형): docker [Management Command] [Command]
    • 예시: docker container run [이미지] (컨테이너 실행), docker container ls (목록 확인)
  • 과거 단축형과 현대적 표준형 모두 도커 엔진에서 호환되어 지원되므로 목적과 상황에 맞게 융통성 있게 작성하면 됩니다.

• 웹 서버(Nginx) 컨테이너 제어 명령어:
  Nginx는 가볍고 강력한 처리를 자랑하는 대중적인 웹 서버 이미지입니다. 이를 활용해 컨테이너를 기동하고 종료하는 과정은 다음과 같습니다.

  • 컨테이너 실행 (docker run):

    # Nginx 컨테이너를 백그라운드(-d)로 띄우고, 호스트 80포트를 컨테이너 80포트와 매핑(-p)하여 'my-web'이라는 이름(--name)으로 실행
    docker run -d -p 80:80 --name my-web nginx

    • -d (Detach): 컨테이너를 포그라운드가 아닌 백그라운드 프로세스로 조용히 동작시켜 터미널 창을 계속 쓸 수 있게 합니다.
    • -p [호스트포트]:[컨테이너포트] (Publish): 호스트 컴퓨터 외부에서 들어오는 포트 요청을 격리된 컨테이너 내부 포트로 포워딩해 줍니다.
    • --name: 시스템이 임의로 지정하는 긴 ID 대신, 직관적으로 알아볼 수 있는 별칭을 부여합니다.

  • 컨테이너 삭제 (docker rm):

    # 정지 상태인 my-web 컨테이너를 삭제
    docker rm my-web
    
    # 실행 중인 my-web 컨테이너를 강제(-f)로 즉시 종료하고 삭제
    docker rm -f my-web

    • -f (Force): 실행 중인 컨테이너에 리눅스 SIGKILL 시그널을 강제로 날려 즉시 정지 상태로 전환한 후 컨테이너를 완전히 영구 삭제합니다.