[Docker 이론] 가상화와 컨테이너의 등장배경
Updated:
목차
- VM vs Container
- What is swarms
- What is volume
- What is docker compose
1. Docker란?
컨테이너 기반 가상화 도구이다.
가상화란?
1-1. 가상화개념 등장배경
인터넷 강의 사이트를 운영하기 위해 거금 5000만원을 들여 좋은 서버를 샀다고 생각해보자.
개발한 인강 사이트를 해당 서버에서 돌리기로 하였다. 이때 고정 사용자가 고작 1000명 정도에 불과하다면 기껏 비싼 서버를 사놓고 성능의 반도 사용하지 못하고 있게된다.
이대로는 서버 유지가 힘들거 같아서 다른 서비스도 만들어서 이 서버에서 돌리기로 하였다.
열심히 쇼핑몰 플랫폼을 개발하고 적용하려고 하니 인강 사이트에서 사용되고 있는 기술들과 충돌이 일어나서 결국 쇼핑몰 사이트를 구동하지 못하였다.
이러한 하나의 서버에서 기존 플랫폼이 사용하는 기술과 새로 개발한 플랫폼의 기술이 충돌하는 것을 막기위해 서버의 성능을 나눠서 사용하는 것이 고안되었고 이 개념이 바로 “가상화” 개념이다.
하나의 서버 자원을 나눠서 가지며 성능을 분산시키고 분산된 서버들은 각기 다른 서비스를 수행할 수 있게 하였다.
가상화를 통해 사용자가 많은 서비스에는 서버 자원을 더 많이 할당해주고, 적은 서비스에는 적게 할당해 줘서 서버를 더 효율적으로 관리할 수 있게 됩니다.
1-2. 가상화의 종류
- 서버 가상화 : 하나의 물리적 서버 호스트에서 여러 개의 서버 운영체제를 게스트로 실행할 수 있게 해주는 소프트웨어 아키텍쳐.
이미지 출처 - https://thinkground.studio/%ED%98%B8%EC%8A%A4%ED%8A%B8%ED%98%95-%EC%84%9C%EB%B2%84-%EA%B0%80%EC%83%81%ED%99%94hosted-virtualization-architecture/
위의 그림을 보면 하나의 Host OS에 여러개의 Guest OS가 할당된 것을 볼 수 있다.
이러한 서버 가상화를 가능하게 하는것이 바로 Virtual Machine Monitor $($VMM) 기술이다. $($VMM은 하이퍼바이저라고도 부른다.)
1-3. Virtual Machine Monitor
VMM은 가상화 기술을 통해 하나의 Host OS에서 여러개의 Guest OS를 생성해서 사용할 수 있게 해주는 소프트웨어다.
이렇게 생성된 여러개의 Guest OS는 가상머신 단위로 구분되고 각 가상머신에는 여러 운영체제가 설치되어 사용된다. 또한 각 Guest OS는 다른 Guest OS와 완전히 독립된 공간과 시스템 자원을 지원받게 된다.
1-4. 서버가상화의 단점
서버 가상화에서 각종 시스템 자원을 가상화 하고 독립된 공간을 매번 할당해주는 가상화 작업은 반드시 VMM을 거쳐서 이루어 져야 한다. 때문에 일반 호스트에 비해 성능 손실이 발생한다.
게다가 가상머신에는 Guest OS를 사용하기 위한 라이브러리와 커널을 모두 포함하고 있기 때문에 배포를 위한 이미지로 만들었을때 이미지 크기가 너무 커지는 단점이 존재한다.
총 정리 - 가상머신 Tradeoff:
Pros
- 완벽히 독립된 운영체제를 생성할 수 있다.
Cons
- 성능이 느리다, 용량이 크다.
2. 컨테이너란?
컨테이너는 가상화 공간을 만들기 위해 리눅스 자체 기능인 “chroot, namespace, cgroup”을 사용함으로써 프로세스 단위의 독립된 공간을 만든다.
이미지 출처 - https://www.netapp.com/blog/containers-vs-vms/
컨테이너 엔진 $($Docker engine)위에 컨테이너들이 할당 되었으며 별도의 Guest OS가 사용되지 않은것을 확인 할 수 있다.
이러한 컨테이너는 어플리케이션 구동에 필요한 라이브러리와 실행 파일만이 존재한다.
때문에 배포를 위한 이미지로 만들었을 때 이미지의 용량 또한 가상머신에 비해 크게 줄어들며 배포 시간이 빨라지고 가상화된 공간을 사용했을 때의 성능 손실도 거의 없다는 장점이 있다.
$($컨테이너 엔진 기술은 Docker만의 기술이 아니라 다른 회사도 존재한다.)
컨테이너의 기술적 의미를 조금 더 알아보자면 이미지의 목적에 따라 생성되는 프로세스 단위의 격리 환경을 제공하며 각 프로세스의 생명 주기를 관리하는 역할을 한다.
SpringBoot 1개와 nginx 1개를 컨테이너에서 실행하는 경우를 예로 들어보자.
Springboot와 nginx가 독립된 가상공간에 할당된 것을 확인할 수 있다.
컨테이너가 실행되면 프로세스가 실행되는데 필요한 자원들을 커널을 통해 가져오고 프로세스를 실행하게 된다.
이때 프로세스는 OS 위에서 실행되며 OS는 이때 컨테이너를 프로세스로 바라보게 된다.
때문에 Springboot 어플리케이션 프로세스를 직접 실행하나, 컨테이너로 실행하나 Host OS 입장에서는 똑같은 프로세스로 취급하게 된다.
덕분에 컨테이너는 프로세스를 Host OS와 격리된 환경에서 관리하며 독립된 개발 환경을 보장해 준다. 뿐만 아니라 프로세스를 컨테이너 단위로 바라볼 수 있게 되고 프로세스의 관리, 확장이 편리해진다.
그렇다면 컨테이너는 어떻게 관리할 수 있을까?
앞에서 지나쳤던 그림에 컨테이너 엔진이 포함되어 있었습니다.
컨테이너 엔진, 혹은 도커엔진은 유저가 컨테이너를 쉽게 관리할 수 있게 해주는 주체이다.
3. Container Engine 이란?
컨테이너 엔진의 역할로는
-
컨테이너 관리
-
이미지 관리
-
불륨 관리
-
네트워크 관리
등이 있으며 컨테이너의 라이프 사이클을 관리하며 컨테이너를 생성하기 위한 이미지 관리, 컨테이너의 데이터를 저장하기 위한 저장소 역할을 하는 볼륨의 관리, 컨테이너의 접속을 관리하기 위한 네트워크 관리 등의 기능을 제공한다.
사용자가 터미널에 도커 명령어 ex) docker run -it...
를 입력하게 되면 명령어는 도커엔진으로 전달되고 도커엔진 안의 도커 클라이언트는 /var/run/docker.sock
에 위치한 유닉스 소켓을 통해 도커 데몬의 API를 호출한다.
도커 데몬은 명령어에 해당하는 작업을 수행하고 수행 결과를 도커 클라이언트에게 반환하며 사용자에게 결과를 출력한다.
도커 프로세스가 실행되어 입력을 받을 준비가 된 상태를 도커 데몬이라고 부른다.
도커 데몬에게 명령어를 직접 전달하는 경우
사용자는 url 요청을 통해 도커 데몬에 명령어를 직접 전달하는 것과 같은 동작을 수행할 수 있다.
Leave a comment