도커 스터디를 진행하고 있는 겸.. 강의를 통해 배운 내용을 하나씩 정리해볼 예정이다!

1주차엔 가상화 기술이 무엇이며, 왜 사용하는지 알아보고, 가상화 기술에 있는 Hypervisor과 Container를 비교한다. 또한, Container 가상화 도구 중 하나인 Docker에 대해 알아본다.

(시작하기 전 이전 포스팅을 본다면 조금 더 이해하기 쉬울지도..?)

가상화 기술

가상이란?

실제로 존재하지 않지만 마치 존재하는 것처럼 느껴지는 거짓 현상을 의미한다.

그렇다면 가상화 기술이란 무엇인가?

컴퓨터에서 사용되는 기술이다. 실제로 존재하는 컴퓨터가 아니지만 마치 존재하는 것처럼 만들어주는 기술이다. 가상화 기술을 활용하면 하나의 컴퓨터에서 여러 대의 컴퓨터를 실행시킬 수 있다. (한 대의 컴퓨터로 여러 대를 가진 것처럼 사용 가능하다. 물론 성능이 좋아야 가능하다.) 가상화 기술은 컴퓨터 안에서 컴퓨터를 또 실행하는 기술이다. 즉, 물리적인 컴퓨팅 환경 내부에서 논리적인 컴퓨팅 환경을 만들 수 있는 기술이다.

가상화기술을 사용하는 이유

하나의 성능 좋은 컴퓨터에서 리소스 부족하지 않게 여러 대를 띄운다면 리소스 사용량에는 문제가 없다. 또한, 하나의 OS에서 프로그램이 모두 실행되고 있기에 관리하기도 편하다. 하지만 하나의 프로그램에 문제가 생길 경우 다른 프로그램에도 영향을 줄 수 있다. (하나의 프로그램의 사용량이 급증해서 리소스를 모두 소모하는 경우와 같은 상황들이 발생할 수 있다.)
→ 그래서 하나의 OS에서 여러 대의 운영을 피하는 것이 좋다.

가상화 기술을 사용해 격리된 환경에서 프로세스 실행

가상화 기술을 사용한다면 한 대의 컴퓨터에 여러 대의 격리된 논리적인 OS 환경을 만들 수 있다. 또한, 가상으로 만들어진 컴퓨터에 사용자가 리소스를 직접 분배할 수도 있다.

리소스 분배란?

→ 하나의 가상 OS가 사용할 수 있는 리소스의 최댓값을 설정하는 것이다.
→ OS가 1개에서 총 5개로 증가했기 때문에 프로그램을 4개 사용하는 것보다는 총 리소스량은 증가한다. 하지만 가상의 컴퓨터들은 논리적으로 격리되어 있기 때문에 더 안전하다.

따라서 한 대의 프로그램에서 에러가 발생해도 다른 프로그램에는 영향을 주지 않는다. 하나의 프로그램에 버그가 생겨 리소스 사용량이 급증해도 OS 한 대의 용량은 제한되어 있기 때문에 하나의 환경 문제로 마칠 수 있다.

이렇게 가상화 기술을 사용하면 각각의 소프트 웨어는 여러 대의 컴퓨터를 사용하는 것처럼 안정적으로 실행 할 수 있다. 물리적으로는 한 대의 컴퓨터를 사용해서 경제적이지만 사용자는 마치 여러 대의 컴퓨터를 사용하는 것처럼 가상 환경을 사용해서 안전하게 소프트웨어를 운영할 수 있다.

그러면 하드웨어를 여러 대 사용하면 굳이 복잡하게 가상화 기술을 사용하는가?

→ 하드웨어의 성능은 빠르게 발전하고 있다. 동시에 하드웨어를 사용하는 소프트웨어의 크기는 상대적으로 감소하는 추세이다.
→ 기업 입장에서는 낮은 사양의 컴퓨터를 여러 대 사용하는 것보다 높은 사양의 컴퓨터 한 대 사용하는 것이 가격, 설치 공간, 설치 인력, 서버 운영, 하드웨어 사이즈나 배선 같이 여러 부분에서 경제적이기 때문이다. (성능이 높다고 하드웨어 크기가 커지는 것도 아니고, 기기가 여러 대면 전기 사용량도 늘어난다.. 등) 따라서 가상화 기술을 사용해서 하나의 하드웨어를 효율적으로 활용하는 것이 엔터프라이즈 환경에서는 필수적이다.

하이퍼바이저(Hypervisor) 가상화

하이퍼바이저 가상화는 전통적인 가상화 기술 방법이다.
하이퍼바이저는 컴퓨터에 설치되는 프로그램이다. 단일 물리적 머신에서 여러 가상 머신을 실행하는 데 사용할 수 있는 소프트웨어이다. OS에 설치하고 프로그램 실행해서 가상화 환경을 관리할 수 있다. 하이퍼 바이저를 통해 가상 OS를 만들 수 있고, 가상 OS를 실행시키고 종료시킬 수 도 있다. 이처럼 모든 가상 머신에는 고유한 운영 체제와 애플리케이션이 있다.
가상 OS를 만들면 사용자가 정해놓은 CPU나 메모리만큼 컴퓨터의 격리된 공간을 만들 수 있다.
가상환경은 일반적인 프로그램과 비슷하다. 가상환경을 만들 때 마다 프로그램을 설치하는 것처럼 디스크(Storage) 공간을 차지한다. 가상환경을 실행하면 프로그램을 실행시키는 것과 마찬가지로 사용자가 지정한 만큼의 CPU와 메모리를 사용한다.

여기서 호스트 OS와 게스트 OS라는 용어가 나온다.

호스트 OS란?

→ 물리적인 서버에 설치되는 OS를 말한다. 호스트 OS에서는 하이퍼바이저를 설치해서 가상환경들을 만들 수 있다. 하이퍼바이저는 호스트 OS의 자원을 격리해서 새로운 OS를 실행한다.

게스트 OS란?

→ 호스트 OS에 의해서 격리되어 만들어지고, 실행되는 OS를 말한다.

호스트 OS는 물리적인 하드웨어와 직접 연결되어 있고, 게스트 OS는 호스트 OS의 리소스를 나눈 논리적인 공간이다. 이렇게 논리적으로 격리되어 있는 게스트 OS를 일반적으로 가상 머신이라고 부른다.

그리고 이런 가상머신에서 웹서버나 WAS, DB와 같은 서버 프로그램을 프로세스로 실행해서 운영한다 . (프로세스란? : 실행 중인 프로그램)

즉, 엔터프라이즈 운영 환경에서는 서버에 호스트 OS를 설치하고, 가상화를 사용하기 위해서 하이퍼바이저를 설치한 다음에 가상 머신을 만들어서 게스트 OS를 실행한다. 이렇게 만들어진 게스트 OS에서는 실제 실행을 원하는 프로세스를 운영한다.

하이퍼바이저 원리

프로세스는 정상적으로 실행되기 위해서 CPU나 메모리(하드웨어) 같은 리소스를 사용해야 한다. 프로세스가 하드웨어를 사용하기 위해서는 OS를 통해서만 가능하다. OS는 하드웨어를 사용하기 위해 커널이라는 중요한 도구가 설치되어 있다.
일반적인 프로그램인 웹 브라우저나 문서 편집 프로그램을 실행할 때도 실행되어 있는 프로세스들은 OS의 커널에게 하드웨어 리소스를 요청한다.

커널이란?

→ 커널은 운영체제 중 항상 메모리에 올라가 있는 운영체제의 핵심 부분이다. 하드웨어와 소프트웨어 사이에서 인터페이스를 제공하며, 컴퓨터 자원들을 관리하는 역할을 한다. 커널은 인터페이스로 소프트웨어 수행에 필요한 여러가지 서비스를 제공하고, 여러 하드웨어(CPU, 메모리 등)의 리소스를 관리한다.

커널의 존재 이유?

→ 커널이라는 중간다리를 통해 요청이 가는 이유는 하드웨어의 리소스를 사용하는 것은 아주 복잡하고 조심히 다뤄야하기 떄문이다. 그래서 커널은 하드웨어에 사용 요청을 대신 전달해주는 시스템 콜 이라는 표준을 정해놨다. 즉, 중요한 업무를 처리하는 소통 창구를 따로 만들어 놓은 것이다. 그래서 프로세스들은 커널에 시스템 콜에 보내서 하드웨어의 자원을 사용할 수 있다.

다양한 OS의 종류에서 하이퍼바이저

대표적으로 윈도우, 리눅스, 맥OS 가 있다. 각각의 OS는 다른 종류의 커널을 사용한다. 따라서 시스템 콜도 모두 다르다. (각각의 OS들은 서로 소통이 안되는 각각 다른 나라의 외국인들이라고 생각하자)

이때, 윈도우 호스트 OS에서 게스트 OS로 맥이나 리눅스 OS를 실행해야 한다고 생각해보자. 게스트 OS의 커널은 실제로 물리적인 하드웨어가 없기 때문에 리소스를 사용하려면 호스트 OS의 커널로 리소스 사용을 요청해야 한다. 하지만 호스트 OS와 게스트 OS의 종류가 다르면 호스트 OS는 게스트 OS에서 전달받은 시스템 콜을 처리할 수 없게 된다. 여기서 하이퍼바이저가 다른 커널 간의 언어를 통역해주는 통역가 역할을 수행한다.

그래서 하이퍼바이저를 사용하면 격리된 공간을 만들면서 호스트 OS와 다른 종류의 게스트 OS도 사용 가능하다.

다양한 OS의 특징과 하이퍼바이저

하이퍼바이저를 사용하는 많은 케이스가 윈도우 호스트 OS에서 게스트 OS로 리눅스를 사용하는 경우이다. 윈도우 OS는 사용성은 뛰어나지만 한 대의 성능이 무거우며, 라이선스 가격도 비싸다. 따라서 메인 OS는 윈도우로 유지하면서 실제로 프로그램을 실행시키는 서버 운영은 가벼운 리눅스 서버를 사용하는 경우가 많다. (VirtualBox라는 하이퍼바이저를 사용해 윈도우 OS에 리눅스 OS를 설치했을 것이다.)

하이퍼바이저는 특정 제품이 아닌 기술의 종류이므로, 하이퍼바이저 역할을 수행하는 VirtualBox, VMware, RHEV 등 다양한 소프트웨어들이 존재한다.

(어느정도 CPU, 메모리를 할당할지 선택 가능, OS를 설치하기 위한 설치 파일인 이미지 선택 가능, OS를 설치한 후 가상 머신을 실행하면 실제 컴퓨터에 OS를 설치한 것과 동일한 화면, 이렇게 여러 대 설치, 실행 가능하며 이렇게 만들어진 것은 게스트 OS라 할 수 있다. 이렇게 설치한 가상 머신에서 리소스 사용량을 할당하고 실제 프로그램을 실행해서 운영을 할 수 있다.)

컨테이너(Container) 가상화

컨테이너 가상화 기술은 현대 애플리케이션 운영 환경에서 하이퍼바이저 방식보다 더 선호 되는 가상화 기술이다.
이는 가볍고, 빠르다 라는 핵심 장점이 있다. (웹 서버 하나 띄우는데 각각 60초와 3초가 걸린다.)

하이퍼바이저와 컨테이너 가상화의 기술적인 차이

컨테이너 가상화는 리눅스 커널이 제공하는 LXC라는 자체 격리 기술에서 출발했다. 하이퍼바이저라는 소프트웨어는 격리된 공간을 만들어 준다. 반면 컨테이너 가상화는 커널의 자체 기능만을 사용해서 격리된 공간(컨테이너)을 만들 수 있다.

LXC 기술

커널의 네임스페이스와 Cgroups 라는 기능을 활용한다.
네임스페이스는 프로세스의 하드 드라이브, 네트워크, 사용자, 호스트 네임처럼 리소스를 나누는 기준의 역할을 한다. Cgroups는 프로세스가 사용하는 메모리, CPU, 하드디스크, 네트워크 bandwidth 처럼 리소스의 사용량을 배분하는 기술이다.
이렇게 LXC 기술을 사용해 만들어진 각각의 격리된 공간을 컨테이너라고 한다.

컨테이너 가상화는 하이퍼바이저 없이 커널의 자체 기술을 활용한 가상화임을 기억하면 된다. 컨테이너 가상화는 커널의 격리 기능을 활용하기 때문에 모든 컨테이너는 Host OS의 커널을 공유해서 사용한다.

하이퍼바이저는 호스트 OS와 게스트 OS의 커널이 각각 독립적으로 존재하며, 하이퍼바이저라는 소프트웨어가 중간에서 커널 간의 통신을 지원하기에 각각의 시스템 콜들이 하이퍼바이저의 통역을 거쳐가야 한다. 따라서 이렇게 요청이 거쳐가는 단계가 늘어나며 이것을 오버헤드가 크다라고 할 수 있다.

하지만 컨테이너는 호스트 OS의 커널을 사용하기 때문에 중간 단계가 따로 없어져 상대적으로 오버헤드가 적다. 즉, 하드웨어 리소스 사용 요청이 더 효율적으로 이뤄진다는 것을 의미한다.

또한, 하이퍼바이저처럼 커널이 독립적으로 있는 것은 커널을 실행하는데 있어서 더 오랜 시간이 걸린다는 것이다. 각각의 컨테이너들은 자체적 커널이 없고 호스트 OS 커널을 공유하기 때문에 커널을 실행하는 시간도 없어진다. 즉, 부팅 속도가 빨라진다.

이렇게 적은 오버헤드와 빠른 부팅이 컨테이너가 빠를 수 있는 이유이다.

하지만 커널을 독립적으로 가지고 있는 것이 보안면으로는 더 뛰어나다고 볼 수도 있다. 또한, 컨테이너는 호스트 OS의 커널을 공유하기 때문에 호스트 OS와 다른 종류의 OS는 실행할 수 없다는 것이 상대적인 단점이라고 할 수 있다.

커널이 자체적으로 제공하는 가상화 기술은 사용자가 직접 컨트롤하기는 어렵다. 따라서 도커는 이 커널의 컨테이너 가상화 기술을 편리하게 사용하기 위해 만들어진 소프트 웨어이다. 사용자는 도커를 통해 컨테이너를 만들고, 운영할 수 있다. 하이퍼바이저 방식에서는 격리된 공간을 만드는 소프트웨어가 하이퍼바이저라는 소프트웨어라면, 컨테이너 가상화에서는 실제 격리를 수행하는 주체는 도커가 아닌 커널 자체이다. 도커는 커널의 가상화 기술을 활용할 수 있도록 도와주는 보조 도구이다.

Docker

컨테이너 가상화 기술을 사용하기 위한 도구이다. 도커를 사용하면 커널의 컨테이너 가상화 기술을 사용자가 손쉽게 활용할 수 있다.

도커와 같은 컨테이너 가상화 도구를 컨테이너 플랫폼이라고 부른다. 컨테이너 플랫폼은 자체적으로 가지고 있는 컨테이너 엔진과 컨테이너 런타임으로 구성되어 있다.

컨테이너 엔진이란?

→ 말 그대로 사용자의 요청을 받아서 컨테이너를 관리해주는 역할을 한다.

컨테이너 런타임이란?

→ 직접 커널과 통신하면서 실제로 격리된 공간을 만드는 역할을 한다.

도커는 runc라는 컨테이너 런타임을 사용한다. 이 컨테이너 런타임은 OCI라는 곳에서 규정한 컨테이너 런타임 인터페이스, CRI 표준을 구현했기 때문에 무조건 runc를 사용해야하는 것은 아니다. 하지만 runc는 도커가 지원하는 기본 컨테이너 런타임이다. 이 컨테이너 플랫폼에는 Podman이나 Containerd 같은 다른 소프트웨어들도 있다. 컨테이너 가상화를 사용할 때 어떤 컨테이너 플랫폼을 사용할지 또는 어떤 컨테이너 런타임을 사용할지는 자유롭게 선택할 수 있다.
여기서 도커는 가장 점유율이 높은 컨테이너 플랫폼이다.

도커의 아키텍처

도커는 클라이언트-서버 모델로 실행된다. (서버-클라와 동일한 관계이다.) 도커에도 사용자의 명령을 전달해주는 클라이언트와 실제로 컨테이너를 관리해주는 도커데몬 이라는 서버가 존재한다.

클라이언트는 사용자의 명령을 도커 데몬에게 전달하고, 도커 데몬은 컨테이너를 관리하는 기능을 제공해주고 도커 D라고도 부른다.
(보통 데몬이라고 이름 붙은 소프트웨어는 서버에서 지속적으로 실행이 되는 소프트웨어를 의미한다. )

도커 데몬도 호스트 OS에서 지속적으로 실행되면서 클라이언트의 요청에 따라서 컨테이너를 관리한다. 그리고 도커 데몬은 클라이언트가 이런 기능들을 사용할 수 있도록 API를 제공한다.

API란?

→ 상호 간의 약속을 의미한다.
→ API는 혼인신고서, 전입신고서 와 같이 상호간의 주고받는 데이터의 약속된 양식이다.

그래서 도커 데몬을 컨테이너 마을에서 컨테이너를 관리해주는 주민센터 직원이라고 생각하면 된다. 도커 데몬은 컨테이너를 관리하기 위해 API 명세서를 제공해준다. 컨테이너를 생성하려면 컨테이너 생성 API 요청을 보내야 하고, 삭제하려면 삭제 API.. 와같이 양식에 맞게 보내면 실행 된다.

https://docs.docker.com/engine/api/v1.45/ 다음 링크는 Docker 엔진이 제공하는 API에 대한 공식 문서이다. Docker 엔진한테 어떤 요청을 보낼 때는 이 API 양식에 맞춰 보내야 한다. 일반 API와 비슷하게 각각의 메서드로 컨테이너스에 json으로 요청을 보낼 수 있다. 요청 보냈을 때 받는 응답은 json의 포맷으로 돌아온다. 이외에도 쿼리 파라미터에 대한 정보도 볼 수 있다.
이런 형식에 맞춰 요청을 보내는 것도, 응답을 제대로 읽는 것도 어렵다. 또한, 작업마다 API를 파악하고 전달하려면 시간이 오래 걸린다. 따라서 사용자가 직접 API를 사용하기는 어렵다.

그래서 Docker에서는 Command Line 도구인 Docker CLI(Command Line Interface) 가 클라이언트 툴로 제공된다. 이 CLI는 클라이언트가 명령어를 입력하면 이 명령어를 서버의 API 형식에 맞게 만들어서 대신 전달해주는 역할을 한다.

따라서 사용자는 Docker CLI를 통해 도커 데몬의 API와 쉽게 통신할 수 있다.

위 사진과 같이 중간다리 역할을 해준다고 생각하면 된다.
(원리 예시: Docker가 제공하는 클라이언트 툴을 사용하면 명령어 한 줄로 API와 통신할 수 있으며, 그의 예시로는 CLI에서 Docker PS를 입력하면 컨테이너 목록을 볼 수 있다. 실제로는 CLI가 대신 get메서드로 container list API를 형식에 맞춰 도커데몬에게 보내준다. 도커 데몬에선 이러한 요청을 분석해서 컨테이너 리스트를 불러온 뒤 json 형태로 응답을 보내준다. CLI는 json 형태의 요청을 보기 편리한 테이블의 형태로 만들어서 우리에게 보여준다.)

도커의 아키텍처 정리

→ 도커는 클라이언트 - 서버 모델로 실행된다. 클라이언트는 CLI, 서버는 도커 데몬으로 구성된다. 사용자는 CLI를 통해 간단한 명령어를 사용해서 컨테이너를 관리할 수 있으며, 명령어를 실행하면 CLI는 API에 맞게 요청을 만들어서 Docker 데몬으로 전달하고, Docker 데몬은 컨테이너 런타임을 통해서 컨테이너를 조작하고 그 결과를 다시 CLI로 보내준다.

레퍼런스

• [2024 NEW] 개발자를 위한 쉬운 도커