JeroCaller

쌓여만 가는 빈 캔

총 포스트 수: 368개

12 분 소요

참고하면 좋을 이전 글들

Docker를 공부하려다보니 생각보다 알아야 할 배경 지식들이 많다는 생각이 든다. 저번 시간에는 Docker의 원리를 파헤치다보니 자연스레 운영체제와 리눅스에 대한 전반적인 개요 정도는 알아야겠다는 생각이 들어 이들에 대해 각각 정리했었다. 그리고 이번에는 역시 Docker와 연관이 있다고 말할 수 있는 “가상화”에 대해 짚고 넘어가려고 한다.

물론docker image... 같은 명령어들만 안다면 바로 실전에 쓸 수는 있겠지만, 그 기저에 작동 원리, 구조 같은 걸 모르고 명령어들만 안 채로 머무르는 것은 나중에 관련하여 어떤 문제가 생기거나 했을 때 그 문제를 해결하기가 어려워질 염려가 있다. 이건 코딩을 할 때에도 매번 느끼는 것이었다. 짤 때는 좋았지만 막상 이런저런 에러들이, 그것도 하나를 해결하면 또 하나가 발생하는 연속의 상황들이 펼쳐질 때면 더더욱 당황하던 때가 많았다. 그리고 이 에러들은 대부분 눈에는 보이지 않던 기반 지식, 이론들을 알고 나면 의외로 에러가 쉽게 해결될 때도 많았다. 이뿐만 아니라, 추후 프로젝트를 진행할 시 어떤 기술들이 적합할지 결정할 때에도 기반 지식이 있다면 큰 도움이 될거라 생각한다. 아무튼 기반 지식은 없이 명령어만 아는 것만으로는 마치 “이 약이 어떤 부작용이 있는지 설명서를 읽지 않은 채 무작정 입에 넣고 보는”것과 마찬가지란 생각이다. 그래서 조금은 번거롭고 귀찮고 느리더라도 이렇게 하나씩 정리하려고 노력하고 있다1.

사설이 길었다. 어쨌든 다시 본론으로 돌아와서, 이번 시간에는 가상화에 대해 알아보도록 하겠다.

가상화

가상화(Virtualization)란, CPU, RAM, Storage 등 여러 물리적 컴퓨팅 자원들을 논리적으로 구획, 분리, 추상화하여 여러 개의 가상 환경을 만들어내는 기술이다.

일반적인 컴퓨터를 떠올려보면, 보통 하나의 컴퓨터에 단 하나의 OS만 설치되어 동작하는 걸 떠올릴텐데, 가상화를 이용하면 하나의 컴퓨터로 여러 개의 각기 다른 OS를 가지는 서로 독립적인 가상 머신(Virtual Machine, VM)을 생성할 수 있다2. 이를 이용하면 하나의 물리적 컴퓨터 내에서 윈도우 OS 환경을 사용할 수도 있고, 리눅스도 사용할 수 있게 된다.

이처럼 가상화를 진행하면 사용자 입장에서는 그것이 물리적 컴퓨터가 제공하는 것인지, 아니면 가상화로 생성된 가상 머신의 인터페이스를 보는 것인지 구별하기 힘들다.

그렇다면, 멀쩡한 물리적 컴퓨터를 왜 굳이 가상화 하는 것일까? 그 목적에는 다음과 같이 여러 개가 있을 수 있다.

  • 일반적으로는 하나의 물리적 컴퓨터에 있는 컴퓨팅 자원들을 모두 사용하지는 못한다. 이러한 유휴(Idle) 자원들까지 모두 사용하여 낭비되는 자원이 없게끔 하기 위해 가상화를 사용한다. 이렇게 하면 여러 장점들을 얻을 수 있다.
    • 하나의 물리적 컴퓨터만으로도 여러 환경의 가상 머신들을 생성하여 사용할 수 있다. 예를 들어 어떤 회사에서는 여러 용도로 인해 윈도우 OS 컴퓨터가 필요할 수도 있고, 리눅스 OS 컴퓨터가 필요할 수도 있는데, 가상화 기술을 사용하지 않았더라면 각 OS에 맞는 컴퓨터들을 별도로 구매했어야 했을 것이다. 그러나 가상화 기술을 이용하면 하나의 물리적 컴퓨터만으로도 여러 OS 환경의 서로 독립된 가상 머신들을 만들어 낼 수 있기에 효율적이면서도 다용도로 사용할 수 있게 된다.
    • 이로 인해 여러 비용들을 절감할 수 있다. 물리적 컴퓨터 추가 구매 비용을 절약할 수 있을 뿐만 아니라, 그로 인한 전기료도 아낄 수 있고, 물리적 서버를 둘 공간 수요 및 그로 인한 관리 비용도 감소시킬 수 있다.
image

사진 1-1. 가상화 도식. 위 그림은 하나의 물리적 서버 내에서 2개의 가상 머신 서버로 가상화하는 예시이다. 화살표 부분들은 물리적 컴퓨터에 있는 하드웨어 자원들을 가상화하여 각각의 가상 머신들에게 할당하는 것을 의미한다.

  • 보통 가상화라고 하면, 하나의 물리적 컴퓨터에서 여러 개의 가상 머신들을 만드는 “분할 방식”을 떠올리기 쉽겠지만, 여러 물리적 컴퓨터들의 자원들을 하나로 가상화하는 “통합 방식”의 가상화도 가능하다. 예를 들어 RAM 16GB를 요구하는 프로그램을 돌리고자 한다고 가정해보자. 그리고 물리적 컴퓨터가 4대나 있고, 각 컴퓨터에는 RAM 4GB씩만 남는 상황이라고 해보자. 가상화가 없었다면 아예 16GB 이상의 메모리가 탑재된 새로운 컴퓨터를 구매하지 않는 이상 해당 프로그램을 돌릴 방법이 없었겠지만, 가상화를 이용하면 물리적으로 분산된 컴퓨터들로부터 각기 RAM 4GB씩 모아 마치 하나의 컴퓨터처럼 하나로 관리하여 16GB의 프로그램을 돌릴 수 있게 된다3.
    • 이를 거꾸로 생각해보면, 만약 추후에 더 많은 컴퓨팅 자원이 필요하다면, 성능이 더 좋은 컴퓨터가 아닌 기존과 똑같은 컴퓨터를 병렬적으로 추가, 증설만 해도 된다는 것을 의미한다. 앞에 든 예를 계속 들어보면, 16GB RAM을 요구하던 프로그램이 이젠 32GB를 요구하게 된다면, 굳이 32GB 메모리가 탑재된 더 성능 좋은 컴퓨터를 사기 보단, 기존과 동일한 개당 4GB RAM이 탑재된 컴퓨터를 여러 개 사서 확장해도 된다는 것이다.
    • 즉, 가상화는 하나의 물리적 장비를 마치 여러 개의 물리적 장비인 것처럼 만들 수도 있고, 반대로 흩어져 있는 여러 물리적 장비들을 마치 하나의 물리적 장비인 것처럼 만들 수도 있는 것이다.
image

사진 1-2. 여러 물리적 컴퓨터에서 남는 하드웨어 자원(여기서는 RAM을 예로 듦)들을 하나로 모아 하나의 가상 머신으로 가상화한 예시.

AWS, Azure, GCP와 같은 클라우드 컴퓨팅 서비스 제공자 입장에서도 비싼 돈을 들여 수많은 물리적 서버들로 데이터센터를 구축했을 때, 자칫 사용되지 않고 남는 유휴 자원들이 많이 발생할 수 있기 때문에 이로 인한 운영 비용 상승을 막기 위해서라도 가상화 기술을 사용한다고 한다. 이 클라우드 서비스를 사용하는 사용자 입장에서도, 클라우드 서비스 제공자에게 충분한 돈을 지출할 수만 있다면 언제든지 더 많은 컴퓨팅 자원을 확보하여 사용할 수 있는데, 이 역시도 가상화라는 기술 덕분에 가능한 이야기이다4.

이러한 가상화 기술의 대상은 CPU(프로세서), 메모리(RAM), Storage, Network 등 다양하다.

이러한 가상화에도 가상화의 대상이나 방식에 따라 여러 종류로 나뉜다.

  • 서버 가상화: 물리적 서버로부터 가상 서버들을 만들어낸다. 서버 가상화에서는 아래에 후술할 하이퍼바이저(Hypervisor)라는 소프트웨어를 통해 물리적 서버를 가상화하여 각자 고유한 OS를 가지는 가상 머신을 생성한다. 이러한 가상 머신들이 곧 가상 서버가 되는 것이다.
    • 하나의 물리적 서버(컴퓨터)가 CPU, RAM, Storage 등으로 구성되어 있듯이, 각자의 가상 머신들도 각자의 CPU, RAM, Storage를 독립적으로 보유하게 된다. 이 가상화된 자원들은 하이퍼바이저에 의해 물리적 서버에 있던 컴퓨팅 자원들의 일부를 할당받는다. 예를 들어 4 core CPU와 32GB의 RAM을 가지고 있는 하나의 물리적 서버를 각자 싱글 코어에 8GB RAM을 가지는 4개의 가상 머신들로 가상화할 수도 있는 것이다.
  • 애플리케이션 가상화: 응용 프로그램(애플리케이션)은 운영체제 환경에서 동작하는데, 응용 프로그램을 운영체제로부터 격리, 캡슐화하는 기법이다. 이를 이용하면 한 프로그램이 멈추면 다른 프로그램도 멈추는 것과 같이 각 응용 프로그램들 간의 악영향을 끼치는 것을 방지할 수 있고, 같은 응용 프로그램을 다른 컴퓨터에서 돌릴 수도 있다.
  • 데스크톱 가상화(Virtual Desktop Infrastructure, VDI): 데이터 센터 서버에서 제공하는 가상의 PC 환경으로, 가상의 컴퓨터를 사용자가 원격으로 접근하여 마치 실제 물리적 데스크톱을 사용하는 것처럼 사용할 수 있다. 이 컴퓨터를 사용하면서 저장되는 데이터들은 로컬 기기가 아닌 데이터 센터의 서버에 저장되어 데이터 저장을 위해 별도의 저장 장치를 구매할 필요가 없게 된다. 또한 데이터 센터 측에서 관리하는 것이기에 컴퓨터에 대해 사용자가 별도의 유지보수를 하지 않아도 되며, 퀄리티 좋은 보안 서비스를 보장 받을 수 있게 된다.

이 외에도 스토리지 가상화, 네트워크 가상화 등도 있다.

가상화 방식: Hypervisor VS Container

가상화를 하는 방법에는 크게 Hypervisor 방식과 Container 방식으로 나눌 수 있다.

Hypervisor 방식

앞서 언급했던 “가상 머신”은 컴퓨팅 환경을 소프트웨어적으로 구현한 것을 의미한다. 즉, 컴퓨터 동작에 필요한 여러 컴퓨팅 자원들인 CPU, RAM 등을 소프트웨어적으로 구현하여 마치 가상 머신에서 하드웨어 자원에 직접 접근할 수 있는 것처럼 보이게 만든다. 그렇기에 사용자 입장에서는 실제 물리 컴퓨터를 이용하는 것인지 가상 머신을 사용하는 것인지 구분하기 힘들다.

이러한 가상 머신은 앞서 말했던 여러 목적들을 위해 하나의 물리적 컴퓨터 위에 둘 이상 여러 개를 만들어 운용할 수도 있다. 한 편 이러한 가상 머신들을 필요에 따라 생성하거나 관리하고, 가상 머신 생성을 위해 하드웨어 자원들도 가상화하고 관리하는 역할의 무언가가 필요하다. 이를 가상머신 모니터(Virtual Machine Monitor, VMM)이라고 하는데, 이러한 중간 관리자의 대표 소프트웨어로 하이퍼바이저(Hypervisor)가 존재한다.

즉, 하이퍼바이저는 물리적 컴퓨터와 가상 머신 사이에 존재하는 중간 관리자로, 물리적인 컴퓨팅 자원들을 가상화한 후 적절히 가상머신들에게 분배하며, 가상 머신과 하드웨어 간의 입출력(I/O) 명령을 처리하기도 한다. 그래서 하이퍼바이저는 가상 머신들이 동작할 수 있게 해주는 환경과도 같다. 마치 응용 프로그램이 실행될 수 있는 환경을 제공해주는 운영체제와도 비슷한 맥락이다.

하이퍼바이저에게 요구되는 3가지 요소들이 있는데, 이를 통해 하이퍼바이저의 특징을 살펴볼 수도 있을 것이다.

  • 정확성(Fidelity): 가상 머신을 위해 생성된 환경은 원래 물리적 컴퓨터의 것과 본질적으로 동일해야한다.
  • 독립성(Isolation) 및 안정성(Safety): 하이퍼바이저는 시스템 자원에 대한 완전한 제어권을 가진다.
  • 성능(Performance): 가상머신과 물리적 환경 간 성능 차이는 없어야 한다.
    • 다만 이 요소는 둘 이상의 가상 머신들이 물리적 컴퓨팅 자원을 공유해야하기 때문에 원래의 물리적 컴퓨터에 비해선 적은 리소스들을 가질 수 밖에 없어 성능이 상대적으로 떨어질 수밖에 없다.

한 편, 하이퍼바이저에도 1형(type 1)과 2형(type 2)으로 나뉘기도 한다.

사진 2-1. 하이퍼바이저 유형에 따른 구조. 왼쪽은 1형, 오른쪽은 2형 하이퍼바이저 구조이다.

사진 2-1. 하이퍼바이저 유형에 따른 구조. 왼쪽은 1형, 오른쪽은 2형 하이퍼바이저 구조이다.

1형은 베어 메탈(Bare-metal) 기반 하이퍼바이저이다. 여기서 베어 메탈이란 건, 어떠한 소프트웨어도 설치되지 않은 순정 물리적 컴퓨터를 의미한다. 그래서 여기에는 운영체제도 가상화도 존재하지 않는다. 즉, 1형 하이퍼바이저라는 건, 운영체제도 없는 아무것도 없는 물리적 컴퓨터 위에 바로 하이퍼바이저를 설치하고, 그 위에 바로 가상 머신들을 생성하는 방식이란 것이다. 원래 물리적 컴퓨터에 설치된 운영체제를 호스트 OS(Host OS), 가상화된 가상 머신에 존재하는 운영체제를 게스트 OS(Guest OS)라고 하는데, 1형에서는 호스트 OS는 존재하지 않은 채 오로지 게스트 OS만 존재하는 형태라 볼 수 있다. 중간에 호스트 OS가 없으므로 하드웨어 I/O 측면에서 상대적으로 빠른 속도를 낼 수 있다. 다만, 이러한 환경을 제공하기 위해 여러 하드웨어 드라이버를 세팅해야하고 설치가 어렵다는 단점도 존재한다. 참고로 1형 하이퍼바이저는 “하이퍼바이저형”이라고도 불린다.

2형은 호스트형이라고도 불리며, 하드웨어 위에 이미 호스트 OS가 있는 상태에서 그 위에 하이퍼바이저를 두는 형태이다. 여기서의 하이퍼바이저는 호스트 OS 위에서 동작되는 여러 응용 프로그램들과 비슷한 형태로 동작한다. 즉, 기존 컴퓨터 환경을 활용하는 것이라서 설치 및 구성이 편리하다는 장점이 있다. 다만, 게스트 OS와 하드웨어 간의 입출력을 위해 중간에 호스트 OS가 들어가므로 오버헤드5가 발생해 상대적으로 성능이 떨어진다는 단점도 존재한다.

이렇게 하이퍼바이저에 의해 생성, 구동되는 게스트 OS를 가지는 가상 머신들은 서로 독립적인 커널들을 보유하기에 서로에게 영향을 끼치지 않는다. 그래서 같은 물리적 서버 내에서 하나의 가상 머신에 이상이 발생하더라도 다른 가상 머신에 영향을 끼치지 않는다6.

참고: 전가상화와 반가상화 link

가상화 방식에도 전가상화와 반가상화로 구분된다. 이 방식들은 하드웨어 리소스의 어느 범위까지 가상화하는지, 그리고 게스트 OS가 하드웨어에 어떻게 접근하는지에 따라 구분된다고 보면 된다.

사진 2-2. 전가상화와 반가상화 구조 및 하드웨어 접근 및 제어 요청 및 수행 과정.

사진 2-2. 전가상화와 반가상화 구조 및 하드웨어 접근 및 제어 요청 및 수행 과정.

전가상화(Full Virtualization)는 하드웨어 리소스의 전체를 가상화하는 방식이다. 이를 통해 가상 머신을 구동할 때 특정 CPU 제품군들에서 제공하는 가상화 지원 기술(Virtualization Technology, VT)을 이용하기도 한다. 전가상화에서는 가상 머신에서 발생한 파일 읽기, 쓰기 명령 등의 이유로 게스트 OS가 하드웨어와 상호작용을 해야할 때 중간에 있는 하이퍼바이저, 즉 VMM에게 먼저 하드웨어 접근 및 제어를 요청한다. 그러면 이 요청을 받은 VMM은 다시 호스트 OS에게 해당 요청을 전달하고, 이 요청을 받은 호스트 OS가 하드웨어 접근 및 제어를 하는 방식으로 진행된다. 이렇게 중간 단계가 많기 때문에 상대적으로 성능이 떨어지는 편이다. 이러한 전가상화를 사용하는 제품들에는 VMWare, ESX Server, 마이크로소프트사의 Hyper-V 등이 있다.

반가상화(Para Virtualization)는 하드웨어의 일부만 가상화하는 방식이다. 하이퍼바이저가 하드웨어 위에서 직접 실행되는 방식이라 네이티브 가상화라고도 불린다. 이 가상화 방식에서는 하드웨어 접근, 제어권이 호스트 OS가 아닌 하이퍼바이저가 직접 소유하고 있기에 게스트 OS와 하드웨어가 상호작용을 해야할 때 중간 단계가 전가상화에 비해 한 단계 더 줄어들어 성능이 상대적으로 유리하다고 볼 수 있다. 다만, 이 방식에서는 하이퍼바이저가 I/O 디바이스와 직접 통신하기 위한 저수준(low-level)의 커널 드라이브를 보유해야하며, 게스트 OS도 하드웨어에 직접 접근하지 못하기에 하이퍼바이저의 커널 드라이브와 통신할 수 있도록 게스트 OS 자체에 수정이 필요하다. 이를 위해선 OS를 구성하는 소스 코드를 통해 직접 수정해야해서 해당 OS가 리눅스처럼 오픈 소스가 아닌 이상 도입하기가 어려운 편이다. 반가상화의 제품군에는 Xen 등이 존재한다.

한 편, 반가상화에서 게스트 OS가 하드웨어 접근을 위해 하이퍼바이저를 호출하는 명령어를 하이퍼콜(HyperCall)이라 한다. 운영체제에서 유저 공간에서 커널 수준에서의 명령을 처리하기 위해 대신 호출하는 시스템 콜과 유사하다고 보면 된다.

Container 방식

컨테이너라 하면 일상에서는 주로 무역 관련 뉴스에서 실제 커다란 컨테이너를 떠올릴 것이다. 컨테이너는 크기가 서로 동일하지만 각 컨테이너마다 종류가 다른 물품들을 넣고 운반할 수도 있다. 가상화에 대해서도 컨테이너는 이와 비슷한 의미로 사용된다. 가상화에서의 컨테이너는, 애플리케이션과 이를 구동시킬 수 있는 환경을 제공하는 OS 간의 격리를 위한 독립적인 공간을 의미한다. 즉, 컨테이너라는 공간 안에는 애플리케이션과 이를 구동시킬 때 필요한 여러 라이브러리, 실행 파일들이 담겨져 있고, 이 공간은 외부의 OS와 격리된 구조를 가진다. 하이퍼바이저 방식의 가상화는 일종의 “컴퓨터 속의 컴퓨터”를 만들어 각 가상 머신마다 개별적인 게스트 OS를 마련하는 방법이라면, 컨테이너 방식은 각 애플리케이션마다 컨테이너로 격리하여 가상화하는 방식이다. 따라서 전자는 “하나의 독립적인 가상 머신을 만드는 방법”이라면 후자는 “하나의 애플리케이션이라는 가상 머신보다는 작은 단위로 외부 OS와 격리하여 가상화 하는 방법”으로 정리할 수 있다. 그래서 전자는 흔히 “하드웨어 수준의 가상화”라고 부르고, 후자는 “운영체제 수준에서의 가상화”라고 부르기도 한다.

이러한 컨테이너는 처음 그 개념이 등장했을 때에도 “동일한 프로그램임에도 각 컴퓨터에서 실행할 때마다 예상치 못한 오류를 만나 정상 작동하지 않아 이를 해결하기 위해 등장”했다고 하고, 지금도 컨테이너 방식의 목적이 이와 다르지 않다. 왜 Docker라는 것이 등장했는지 그 이유와 동일하다.

사진 3-1. 하이퍼바이저 방식과 컨테이너 방식의 구조 차이. 오른쪽이 컨테이너 방식의 구조이다.

사진 3-1. 하이퍼바이저 방식과 컨테이너 방식의 구조 차이. 오른쪽이 컨테이너 방식의 구조이다.

컨테이너 가상화 방식의 구조는 다음과 같다. 하나의 물리적 컴퓨터 위에 있는 호스트 OS 위에 컨테이너 엔진을 동작시킨다7. 이 엔진 위에서 각각의 컨테이너들이 동작하는 방식이다. 이 때, 하이퍼바이저 방식에서는 각각의 가상 머신들이 각자의 게스트 OS와 커널을 소유하여 서로 독립적인 특성을 지닌 반면, 컨테이너 방식에서는 모든 컨테이너가 동일한 호스트 OS의 커널을 사용한다는 것이 차이점이다. 이는 각자의 컨테이너들이 운영체제 중 사용자 공간(user space, user land)에 해당하는 공간을 각자 독립적으로 소유할 수 있다는 뜻이기도 하다. 컨테이너에 존재하는 사용자 공간과, 호스트 OS에 있는 커널과 맞물리며 마치 두 퍼즐이 맞춰지는 것처럼 맞물려서 작동하는 방식이다. 이로 인해, 겉보기엔 똑같아 보이는 사용자 공간 구조더라도 두 컨테이너 내에서 각자 서로 다른 환경 설정을 독립적으로 수행할 수 있다. 이러한 컨테이너 방식의 고유한 구조와 그 원리는 컨테이너 방식 특유의 장단점으로도 이어진다.

image

사진 3-2. 컨테이너 방식에서의 운영체제 구조. 컨테이너 방식에서는 여러 컨테이너들이 동일한 Host OS 커널을 공유하여 사용하며, 대신 각 컨테이너마다 독립적인 사용자 공간(user space)을 가진다. 위 그림은 운영체제를 구성하는 두 부분인 커널과 사용자 공간이 마치 퍼즐처럼 맞물려 작동한다는 것을 표현하기 위해 일부러 위와 같이 퍼즐 모양으로 묘사하였다.

하이퍼바이저에 비해 컨테이너 방식의 장점은 컨테이너 구동이 가볍다는 것이다. 하이퍼바이저 방식에서는 가상 머신 단위로 가상화를 했기에 각자 가지고 있는 게스트 OS도 부팅해야하고, 하드웨어 간의 I/O 입출력 상황에서도 중간에 거쳐야하는 단계가 많아 성능 및 속도가 상대적으로 떨어진다. 반면, 컨테이너 방식에서는 별도의 게스트 OS가 필요한 것이 아니기에 바로 호스트 OS 커널과 상호작용할 수 있어 성능, 속도 측면에서는 더 유리하다. 이러한 이유로, 애플리케이션을 구동 환경과 격리시키고자 하는 것이 목적이라면 굳이 가상 머신을 만드는 방식보다는 컨테이너 방식을 사용하는 것이 더 경량화되어 있어 좋다.

또한, 하이퍼바이저 방식에서는 하나의 가상 머신을 만들고 그 위에 게스트 OS를 구동시키기 위해 수 GB에 달하는 저장 공간을 최소로 요구하기도 하고, 마치 하나의 또 다른 가상 컴퓨터처럼 작동하기 위해 CPU, RAM 등 모든 하드웨어 자원들을 가상화해야해서 적지 않은 컴퓨팅 자원을 소모한다. 반면 컨테이너 방식에서는 하나의 애플리케이션을 작동시키기 위해 필요한 컴퓨팅 자원만을 필요8로 하기에 상대적으로 필요한 컴퓨팅 자원이 적어 이 점도 장점이 된다.

반면, 컨테이너 방식에서는 모두 같은 커널을 공유하기 때문에, 호스트 OS의 커널에 이상이 생길 경우 모든 컨테이너에도 영향이 간다는 것이 단점이다. 하이퍼바이저 방식에서는 아예 물리적 컴퓨터 자체에 문제가 생긴다면 모를까, 하나의 가상 머신에서 생긴 문제가 다른 가상 머신에까지 영향을 끼치지는 않는 것이 차이점 중 하나이다.

References

[1] 지은이: 오가사와라 시게타카, 옮긴이: 심효섭, “그림과 실습으로 배우는 도커 & 쿠버네티스“, 위키북스

[2] M1-1 가상화

[3] 2.1. WSL 2의 구조

[4] Docker 베이스 이미지 이해하기: 컨테이너 속 Ubuntu는 진짜 Ubuntu가 아님 | GeekNews

[5] Base images

[6] 가상화란 무엇인가요? - 클라우드 컴퓨팅 가상화 설명 - AWS

[7] 안성원, “클라우드 가상화 기술의 변화 - 컨테이너 기반의 클라우드 가상화와 DevOps”, SPRi 소프트웨어 정책연구소, 2018.12.10, 제2018-008호.

[8] 베어 메탈의 뜻과 베어 메탈 서버

Bare Metal Server | 카카오클라우드

[9] 베어 메탈의 뜻과 베어 메탈 서버

오직 나만을 위한 고성능 물리 서버를 클라우드에서 사용할 수 있습니다! - 베어 메탈 서버(Bare Metal Server)

[10] 가상화 개념

가상화

[11] 참고 - Resource pooling

What Is Virtual Resource Pooling?

[12] 참고 - Resource pooling

What is Resource Pooling in Cloud Computing? - StarAgile

[13] 참고 - Resource pooling

Resource Pooling Architecture in Cloud Computing - GeeksforGeeks

  1. 솔직히 말하자면, 바로 실전으로 들어가 Docker 사용 방법 및 실습 과정으로 바로 넘어가 정리하고 싶은 마음이 굴뚝같긴 하다. ↩

  2. 쉽게 말해 가상의 컴퓨터가 생성된다고 보면 된다. 컴퓨터 안의 컴퓨터. ↩

  3. 여기서는 “여러 물리적 자원들을 하나로 모아 통합하는 방식의 가상화”를 쉽게 설명하기 위해 RAM을 예시로 들었다. 좀 더 엄밀하고 자세한 사항은 “Resource pooling”이란 개념을 참고. ↩

  4. 단순히 클라우드 컴퓨팅 서비스에 가상화가 사용된다, 수준이 아니라, 애초에 클라우드 컴퓨팅 서비스를 구현하기 위해선 가상화 기술이 필수라고 한다. 물론 간혹 고성능 컴퓨팅 등의 특수 목적을 위해 가상화가 전혀 되지 않은 베어 메탈(Bare-metal) 서버를 제공하는 경우도 있긴 하다. ↩

  5. Overhead. 집에서 어딘가까지 간다고 칠 때, 자동차나 대중교통을 타는 시간 뿐만 아니라 중간에 버스 정류장까지 걸어가고 기다리는 시간, 중간에 신호등에 걸려 기다리는 시간 등이 모두 오버헤드라 할 수 있다. 즉, 오버헤드라는 것은 명령어를 처리하기 위해 추가적으로 필요한 컴퓨팅 자원 및 추가 소요 시간을 의미한다. ↩

  6. 물론 물리적 서버 자체에 문제가 발생한다면 그 위에 구동하던 가상 머신들 모두가 영향을 받긴 할 것이다. ↩

  7. 여기에는 Docker 등의 여러 종류의 엔진들이 있다. 필자가 앞으로 다룰 기술도 Docker라서 여기서는 그냥 편하게 Docker engine이라고 봐도 될 것이다. ↩

  8. Docker image들의 경우 대부분 수 MB ~ 수백 MB 정도의 저장 공간을 차지한다. 물론 GB 단위로 차지하는 image들도 있지만 평균이 MB 단위 정도라서 가상 머신 방식에 비해선 꽤 경량적이라고 할 수 있다. ↩

This content is licensed under CC BY-NC 4.0

댓글남기기

참고

[OS] 리눅스 개요

17 분 소요

Docker에 대해 공부하다보니, Docker가 리눅스 운영체제를 기반으로 돌아가기도 하고, 각각의 d...

[OS] 운영체제의 구조

11 분 소요

Docker를 공부하다보니 아무래도 운영체제에 대한 기본적인 지식은 있어야겠다는 필요성을 느끼게되었다....