가상화란?
가상화는 하나의 실물 컴퓨팅 자원을 마치 여러 개인 것처럼 가상으로 쪼개서 사용하거나, 여러 개의 실물 컴퓨팅 자원들을 묶어서 하나의 자원인 것처럼 사용하는 행위를 말합니다.
컴퓨팅 자원들을 실물이 아니라 개념적이고 논리적인 관점으로서 추상적으로 생각하는 것입니다.
예를 들어 저에게는 1000GB의 저장공간이 있고, 이 중 100GB만 사용합니다. 그런데 제 친구가 저장공간이 모자르다고 할 때, 저장공간은 실물로서 제 것 하나이지만, 남은 900GB를 친구에게 나눠 공유해줄 수 있는 개념입니다.
가상화 기술을 활용하면, 한 개의 물리 서버를 여러개의 가상 서버로 동작시킬 수 있습니다. 그 덕분에 더 이상 서버 리소스를 낭비하지 않고 효율적으로 사용할 수 있습니다.
VM(Virtual Machine, 가상 머신)
가상 머신(Virtual Machine, VM)은 물리적 하드웨어 시스템에 구축되어 자체 CPU, 메모리, 네트워크 인터페이스 및 스토리지를 갖추고 가상 컴퓨터 시스템으로 작동하는 가상 환경입니다.
가상 머신에 대해 알려면 가상화의 동작에 대해 이해해야 합니다.
먼저 하이퍼바이저(Hypervisor)라는 소프트웨어에 가상 서버를 생성하는 요청을 하게 됩니다. 이 요청받은 하이버파이저는 새로운 가상 서버를 생성하고, 물리 서버의 자원을 생성한 각각의 가상 서버로 전달합니다. 여기서 물리 서버의 자원이란 CPU, 메모리, 네트워크, 스토리지 등이 있습니다. 또 하이퍼바이저는 각 서버에 필요한 운영체제(OS)를 설치합니다.
이처럼 가상 서버 자체적으로 컴퓨팅 자원과 OS를 갖춘 가상 환경을 VM이라고 합니다. 이러한 과정을 통해 생성되기 때문에 VM은 같은 서버 위에 존재하더라도 별도의 시스템으로서 동작합니다.
이 때 생성된 VM을 Guest Server, VM이 작동하는 서버를 Host Server 라고 부릅니다.
VM의 장단점
기본적으로 VM은 격리된 환경을 제공합니다. 그렇기에 하나의 VM 내부의 일이 다른 VM에게 영향을 끼치지 않습니다. 즉, 보안적인 문제가 발생해도 이 문제가 전체로 번지지 않고 VM 내부에서 그칠 확률이 보다 높습니다. 또한 Host의 하드웨어 변경이나 업그레이드 등의 변화에 영향을 받지 않게 됩니다.
또한 각 VM마다 독립적인 OS (Guest OS)를 가지므로, 단일 서버에서 Linux, Windows 등 여러가지 OS를 사용할 수 있습니다. 게다가 이 독립적인 특성으로 인해 관리, 유지보수 작업에 용이합니다.
또 하나의 물리적 자원을 여러 가상 머신이 사용할 수 있기 때문에 리소스 활용의 효율성이 증가됩니다.
VM의 단점도 있습니다.
우선 VM이 점점 많아질수록 안정성이 떨어지고 성능에 따른 실행 속도 저하가 발생합니다. 서버를 여러 가상 환경으로 분리하는 것 자체가 불안정성을 내포하고 있을 수 밖에 없는데, 이 분리의 개수가 많아지면 이 특성이 두드러지게 됩니다.
또한 모든 VM마다 각각 OS를 가지고 있는 것이 용량의 부담으로서 다가갈 수도 있습니다.
또 하나의 물리적 서버보다 여러 가상 서버를 다루는 것은 기본적으로 복잡하고 어렵습니다. 리소스를 할당하고 스토리지를 관리하며 네트워크를 설정하는 과정이 어렵게 다가올 수 있습니다.
VM간 통신의 경우 Host System을 거쳐야 하는데, 이 과정에서 네트워크적으로 부담이 될 수 있습니다.
Hypervisor
하이퍼바이저는 가상화 계층을 구현하는 소프트웨어 입니다.
사실 하드웨어 스스로는 가상화된 사실을 모릅니다. 그렇기 때문에 하드웨어 위에 VM을 생성하고 자원을 할당하며 VM의 요청을 처리해주는 역할이 필요하고, 그것이 하이퍼바이저 입니다. 이러한 특성때문에 VMM(Virtual Machine Manager)라고 불리기도 합니다.
즉, 하이퍼바이저란 물리 하드웨어와 VM 간 영역을 분리하고, 그 사이에 위치하여 관리자, 즉 인터페이스 역할을 수행합니다. 그 예시로 리소스 할당, 리소스 사용 스케쥴링, VM과 하드웨어 간 I/O 명령 처리 등을 담당합니다.
이런 하이퍼바이저도 두 가지 유형으로 구분됩니다.
1. Bare-Metal Hypervisor (or Native Hypervisor)
하드웨어 위에서 직접 구동되어 Guest OS를 관리하는 하이퍼바이저를 말합니다.
이 유형은 Host OS가 별도로 존재하지 않아 Hardware와 Guest OS 사이의 간격이 짧습니다. 따라서 그 오버헤드가 적다는 장점이 있습니다. 또한 각 Guest OS가 다른 Guest OS에게 서로 영향을 주지 않습니다.
그러나 이러한 VM들을 관리할 소프트웨어가 없어 VM 관리를 위한 별도 컴퓨터나 콘솔이 필요하게 됩니다.
2. Hosted Hypervisor
Host OS를 가지는 하이퍼바이저로, 하드웨어에 이미 Host OS가 설치되어 있고 하이퍼바이저는 그 Host OS 위에서 동작합니다.
한마디로 기존 OS (시스템) 위에서 작동하므로, 쉽게 사용할 수 있는 것이 장점이지만 Guest OS와 Hardware 간 간격이 멀어지므로 오버헤드가 비교적 크고 HostOS에 문제가 발생하면 전체 Guest OS에 영향을 주게 됩니다.
우리가 흔히 윈도우 환경에서 Ubuntu를 사용할 때 Virtual Box를 설치하여 VM을 생성하는 것이 이러한 방식입니다.
Container (컨테이너)
컨테이너란 Host OS 위에서 특정 Application을 작동시키기 위해 필요한 라이브러리 또는 어플리케이션 등을 하나로 모아, 마치 별도의 서버인 것 처럼 사용할 수 있게 만든 것입니다.
위 그림에서 Docker가 곧 컨테이너를 관리하는 소프트웨어인데, 여러가지가 있지만 대표적으로 Docker가 많이 사용됩니다. 이 Docker가 컨테이너를 생성해주는 소프트웨어 입니다.
컨테이너는 VM과 마찬가지로 Application을 관련 라이브러리 및 종속 항목과 함께 패키지로 묶어 소프트웨어 서비스 구동을 위한 격리 환경을 제공합니다. 라이브러리, 시스템 도구, 코드, 런타임 등 SW를 실행하는데 필요한 모든 것들이 포함되어 있습니다.
한마디로 도커(컨테이너 가상화)는 OS에서 제공하는 자원 격리 기술을 활용하여 컨테이너라는 단위로 서비스를 분리할 수 있게 만들고, 이는 개발환경에 대한 걱정없는 배포를 가능하게 만들어줍니다.
Docker의 장단점
도커는 Application 독립성을 가져, HostOS와 다른 컨테이너와도 독립된 공간을 보장받아 충돌이 발생하지 않습니다.
컨테이너 내부 작업 후 배포 시, 도커 이미지로 생성하여 운영 서버에 전달만 하면 되기 때문에 굉장히 용이합니다.
(도커 이미지(Docker Image)란, 컨테이너를 실행할수 있는 실행 파일 및 설정 값들을 가진 것으로, 추가적으로 파일을 컴파일하거나 설치할 필요가 없는 상태의 파일을 말합니다.)
또 MSA(MicroService Architecture)로 변화하기 쉽습니다.
한마디로 Docker를 사용한다면 환경에 구애받지 않고 Application을 신속하게 배포 및 확장할 수 있습니다.
또, 각 컨테이너는 독립적이지만 Host의 커널을 공유하기 때문에 오버헤드가 적습니다. 따라서 Host 시스템의 자원을 효율적으로 사용할 수 있습니다.
도커 컨테이너는 시작하고 정지하는 시간도 짧습니다. 따라서 스케일링과 같은 동적 요구를 처리하기 용이합니다.
이런 Docker도 단점이 존재합니다.
기본적으로 Docker 컨테이너는 Host 시스템과 커널을 공유하기 때문에 보안적 취약점이 발생할 수 있어 적절한 조치가 필요합니다.
또 도커 컨테이너는 일반적으로 가볍고 휘발성이기 때문에 데이터 관리가 복잡할 수 있고, 데이터 영구 저장 및 관리를 위한 별도 DB가 필요할 수 있습니다.
VM vs Docker
구조적으로 VM은 각각의 Guest OS를 띄우는 구조이고, 컨테이너는 하나의 Host OS를 모두 공유하는 구조이기 때문에 컨테이너가 빠릅니다. 그렇지만 이러한 구조 때문에 컨테이너는 VM과 다르게 Host OS와 다른 OS를 사용하는 컨테이너를 사용할 수 없습니다.
또한 보안적인 측면에서 VM은 분리되어 있기 때문에 HostOS에 이상이 있지 않는 한 서로 피해가 가지 않지만, 컨테이너는 기본적으로 하나의 OS를 공유하기에 문제가 생길 수 있습니다.
VM | Container | |
가동 시간 | 길다 (분 단위) | 짧다 (초 단위) |
관리 소프트웨어 | 하이퍼바이저 | 도커 (대표적) |
용량 | GB 단위 (OS + 애플리케이션 + 런타임 SW) | MB 단위 (애플리케이션 + 런타임 SW) |
Guest OS | 다양한 OS 선택 가능 | Host OS와 동일한 OS만 사용 가능 |
Guest OS와의 관계 | Guest OS를 하드웨어로서 인식 | Host OS를 커널 수준으로 분리하여 OS를 가상화 형태로 사용. 필요하다면 Host와 리소스 공유 가능 |
데이터 관리 | VM 내부 or 연결된 스토리지에 저장 | 내부 데이터는 컨테이너 종료시 소멸, 필요시 추가적인 외부 스토리지 이용 |
이식성 | 가상 이미지에 대한 변환 필요 | 컨테이너 이미지 그대로 사용 가능 (추가 조치 X) |
시스템 성능 | 각 VM 별 OS가 존재하여 메모리 사용량이 많음. | 리소스를 보다 적게 사용하고 Host Memory에 가해지는 부담을 줄임. (OS를 공유하기 때문) |
유지 관리 및 업데이트 | 각 VM마다 Guest OS를 개별적으로 업데이트 해야 함 | Host OS만 업데이트 하더라도 전체 컨테이너에 적용 (유지관리 간소화) |
VM, Container 선택 상황
VM 사용
1. 레거시 방식
2. 개발 사이클 분리가 위험할 때
3. 다른 OS에서 또 다른 OS를 실행하고 싶을 때
Container 사용
1. MSA
2. DevOps 또는 CI/CD
3. 동일한 OS를 공유하는 다양한 IT 설치 공간에서 확장 가능한 프로젝트 전
'DevOps' 카테고리의 다른 글
SonarQube란? (0) | 2024.05.02 |
---|
개발자가 되고 싶어요.