[백엔드] 가상화 / 컨테이너

이전 게시글 아키텍처 / 디자인 패턴

https://hoozy.tistory.com/entry/%EB%B0%B1%EC%97%94%EB%93%9C-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4

[백엔드] 아키텍처 / 디자인 패턴

가상화

• 서버, 스토리지, 네트워크 및 기타 물리적 시스템에 대한 가상 표현을 생성하는 데 사용할 수 있는 기술이다. 가상 소프트웨어는 물리적 하드웨어 기능을 모방하여 하나의 물리적 머신에서 여러 가상 시스템을 동시에 실행한다. 기업은 가상화를 사용해 하드웨어 리소스를 효율적으로 사용하여 투자 대비 이익을 더 많이 얻을 수 있다. 또한 클라우드 컴퓨팅 서비스를 지원하여 조직의 인프라를 더욱 효율적으로 관리할 수 있다.
• 가상화를 상요하면 하드웨어 리소스와 상호 작용할 때의 유연성이 크게 높아진다. 물리적 서버는 전기를 소비하고 스토리지 공간을 차지하며 유지 관리를 필요로 한다. 물리적 서버에 액세스하려고 할 때는 물리적 근접성과 네트워크 설계로 인한 제한을 종종 경험하게 됩니다. 가상화는 물리적 하드웨어 기능을 소프트웨어로 추상화함으로써 이 모든 제한을 제거합니다. 웹의 애플리케이션을 사용하듯이 하드웨어 인프라를 관리하고 유지하며 사용할 수 있습니다.
• 장점
  1. 효율적인 리소스 사용
     • 가상화는 데이터 센터에 사용되는 하드웨어 리소스를 개선합니다. 예를 들어 하나의 컴퓨터 시스템에서 하나의 서버를 실행하는 대신 필요에 따라 서버를 사용하고 풀로 반환하여 동일한 컴퓨터 시스템에 가상 서버 풀을 생성할 수 있습니다. 기반 물리적 서버가 줄어들면 데이터 센터에 여유 공간이 늘어나고 전기, 발전기 및 냉각 장치에 들어가는 돈이 절약됩니다.
  2. 자동화된 IT 관리
     • 이제 물리적 컴퓨터가 가상화되었으니 소프트웨어 도구를 사용하여 관리할 수 있습니다. 관리자는 배포 및 구성 프로그램을 생성하여 가상 머신 템플릿을 정의합니다. 반복적이고 일관된 방식으로 인프라를 복제할 수 있으므로 오류가 많은 수동 구성이 방지됩니다.
  3. 신속한 재해 복구
     • 자연 재해나 사이버 공격과 같은 이벤트로 비즈니스 운영에 부정적인 영향이 발생할 경우 IT 인프라에 다시 액세스하고 물리적 서버를 교체하거나 고치려면 몇 시간에서 심지어 며칠이 걸릴 수 있습니다. 이와 반대로 가상화된 환경에서는 이 프로세스가 몇 분 안에 완료됩니다. 이 즉각적인 대응은 복원력을 크게 개선하고 비즈니스 연속성을 촉진하여 예정된 대로 운영을 지속할 수 있도록 합니다.

1. VM (Virtual Machine)

• '하이퍼바이저'를 이용해 하드웨어 자원을 가상화하는 방식 또는 그 결과물을 말합니다. 따라서 VM을 이해하기 위해서는 먼저 하이퍼바이저를 알야아 한다.
• 하이퍼바이저
  • 호스트 시스템에서 다수의 게스트 OS를 구동할 수 있게하는 소프트웨어이다. 하드웨어를 가상화하면서 하드웨어와 각각의 VM을 모니터링하는 중간 관리자 역할을 하는 것이 하이퍼바이저이다.

Type 1. 네이티브 or 하이퍼바이저형(native/bare-metal or Hypervisor)

출처 : 위키피디

• 하이퍼바이저가 하드웨어 바로 위에서 실행되는 방식이다.
• 하이버바이저가 하드웨어를 직접 제어하기 때문에 자원을 효율적으로 사용할 수 있고, 별도의 호스트OS가 없으므로 오버헤드가 적지만 여러 하드웨어 드라이버를 세팅해야 하므로 설치가 어렵습니다.
• 이 타입에서 하이퍼바이저는 Xen, 마이크로소프트 Hyper-V, KVM이 네이티브 하이퍼바이저에 속한다.
  • 네이티브형 하이퍼바이저는 전가상화, 반가상화 방식으로 세분화할 수 있다.
  • 하이퍼바이저를 통해 가상 머신 내의 게스트 OS가 호스트 시스템을 활용한다는 점은 같지만, 하드웨어와 인터랙션하는 방식에 차이가 있다.

출처 : https://library.gabia.com/contents/infrahosting/7426/

1-1. 전 가상화 (Full Virtualization)

• 게스트 OS를 호스트 시스템과 완전히 분리하여 실행
• 게스트 OS는 하드웨어 자원을 요청하기 위해, 반드시 하이퍼바이저가 중재 해야 함
• 전 가상화는 하드웨어를 모두 가상화하는 방식이다.
• 게스트 OS가 하이퍼바이저에게 하드웨어 시스템 제어를 요구하면, 하이퍼바이저는 하드웨어에게 해당 요구 사항을 전달한다.

출처 : https://library.gabia.com/contents/infrahosting/7426/

- 각 게스트 OS는 ‘DOM 0’라는 관리 머신을 거쳐 하이퍼바이저와 통신하므로, CPU와 RAM처럼 I/O가 잦은 자원을 컨트롤 하기에는 번거롭습니다. 이런 한계를 개선하기 위해 반가상화 방식이 출현하게 되었습니다.

1-2. 반 가상화 (Para Virtualization)

• 게스트 OS를 일부 수정하여 필요한 하드웨어 자원을 직접 요구할 수 있음
• 반 가상화 방식은 하드웨어를 완전히 가상화하지 않습니다.
• 대신 게스트 OS의 커널을 일부 수정해 하드웨어와 인터랙션할 수 있도록 합니다.
• OS를 수정해야 하므로 게스트 OS가 윈도우일 경우 별도의 Tool을 이용해야 해서 번거로움이 있습니다.
• 대표적인 반가상화 방식 소프트웨어인 Xen에서 게스트 OS는 Hyper Call이라는 명령어를 통해 하드웨어에 필요한 자원을 바로 하이퍼바이저에 전달하고, 하이퍼바이저는 바로 하드웨어를 제어합니다.

출처 : https://library.gabia.com/contents/infrahosting/7426/

• 즉, 각각의 게스트 OS는 필요한 자원을 직접 요청할 수 있는 능력이 있으므로 모든 요청을 ‘DOM 0’ 가 한꺼번에 처리하여 하드웨어를 제어하는 전가상화 방식에 비해 성능이 좋습니다.

Type 2. 호스트형(hosted)

출처 : 위키피디

• 호스트형 하이퍼바이저는 일반적인 소프트웨어처럼 호스트 OS 위에서 실행됩니다.
• 하드웨어 자원을 VM 내부의 게스트 OS에 에뮬레이트 하는 방식이기 때문에 네이티브 방식에 비해 오버헤드가 크지만, 게스트 OS 종류에 대한 제약이 없고 데스크톱뿐 아니라 노트북에서도 운영할 수 있습니다.
• 대표적으로는 VMware server, VMware Workstation, Virtual box가 있습니다.
• 하이퍼바이저에 의해 구동되는 VM은 각 VM별로 독립된 가상의 자원을 할당받습니다. VM은 논리적으로 분리되어 있어서 한 VM에 오류가 발생해도 다른 VM으로 확산되지 않는다는 장점이 있습니다.

출처 : https://library.gabia.com/contents/infrahosting/7426/

2. 컨테이너

2. 컨테이너

• 최근 가상화 기술의 축은 하이퍼바이저 기반의 가상화에서 컨테이너 기반 가상화로 이동하고 있습니다.
• 컨테이너 기술은 LXC(Linux Container)에서부터 출발합니다. LXC는 호스트 OS에서 프로세스 간 벽을 만드는 기술로, 네임 스페이스와 cgroup을 조합한 형태입니다.
  • 네임 스페이스: 리눅스 시스템 자원을 묶어 프로세스에 할당하는 방식으로, 하나의 프로세스 자원을 관리하는 기능. IBM에서 개발.
  • cgroup: CPU, 메모리 등 프로세스 그룹의 시스템 자원 사용량을 관리하여 특정 애플리케이션이 자원을 과다하게 사용하는 것을 제한. Google에서 개발.
• 이처럼 격리된 고유 영역에서 애플리케이션을 실행하는 것을 의미하는 컨테이너는 애플리케이션의 실행에 필요한 라이브러리와 바이너리, 기타 구성 파일을 ‘이미지’ 단위로 빌드하여 패키지로 배포합니다.
• 실행에 필요한 모든 환경이 준비되어 있으므로 어떤 환경에서도 애플리케이션을 오류 없이 동작시킬 수 있는 것이 가장 큰 특징입니다.

출처 : https://library.gabia.com/contents/infrahosting/7426/

• 그림처럼 컨테이너는 하이퍼바이저와 게스트 OS가 필요하지 않으므로 더 가벼운 것이 두번째 특징입니다. 일반적으로 컨테이너에는 OS가 포함되지 않아 크기가 수십 MB에 불과하고, 운영체제 부팅이 필요 없으므로 서비스를 시작하는 시간도 짧습니다. 크기가 작기 때문에 컨테이너 복제와 배포에도 용이합니다.
• 애플리케이션을 실행할 때에도 물리 서버에서 애플리케이션 하나를 실행하는 것과 마찬가지로, 호스트 OS 위에 애플리케이션의 실행 패키지인 ‘이미지’를 배포하기만 하면 됩니다.
• 반면, VM은 항상 게스트 OS가 포함되므로 보통 수 GB에 해당하고, 애플리케이션을 실행할 때에도 먼저 VM을 띄우고 자원을 할당한 다음, 게스트 OS를 부팅하여 애플리케이션을 실행시켜야 합니다.
• 이처럼 VM에 비해 컨테이너는 애플리케이션을 실행, 배포하는 과정이 가볍기 때문에 하나의 물리 서버에서 더 많은 애플리케이션을 구동시킬 수 있습니다.

Kubernetes

• 구글 엔지니어들이 개발하고 설계한 플랫폼이다. 구글은 초창기에 Linux 컨테이너 기술에 기여하였으며 구글 제품이 컨테이너에서 어떻게 작동하는지 대중에게 공개하였습니다. 이는 구글의 클라우드 서비스를 구동하는 기술이기도 합니다. 구글은 내부 플랫폼인 Borg를 통해 일주일에 20억 개 이상의 컨테이너 배포를 생성하고 있습니다. Borg는 쿠버네티스의 전신이었으며 수년 동안 Borg를 개발하는 과정에서 축적된 경험은 쿠버네티스 기술의 주요 원동력이 되었습니다.
• 컨테이너의 계층 구조

출처 : https://www.codestates.com/blog/content/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4

• 기능
  • 실제 프로덕션 환경에서의 애플리케이션들은 여러 컨테이너에 걸쳐 있으며 이러한 컨테이너는 여러 서버 호스트에 배포되어야 합니다. 이 때문에 컨테이너를 위한 보안은 멀티 레이어 구조로 되어 있고 복잡할 수 있습니다. 바로 여기에 쿠버네티스가 사용됩니다. 쿠버네티스는 이러한 워크로드를 위해 규모에 맞는 컨테이너를 배포하는 데 필요한 오케스트레이션 및 관리 기능을 제공합니다.
    • 오케스트레이션 : 오케스트라를 지휘한다는 의미로, 여러 개의 컨테이너를 관리하는 의미이다.
• 장점
  • 쿠버네티스 오케스트레이션을 사용하면 여러 컨테이너에 걸쳐 애플리케이션 서비스를 구축하고 클러스터 전체에서 컨테이너의 일정을 계획하고 이러한 컨테이너를 확장하여 컨테이너의 상태를 지속적으로 관리할 수 있습니다. 또한 IT 보안을 한층 강화할 수 있습니다.

구성 요소

1. 클러스터

• 컨트롤 플레인 및 하나 이상의 컴퓨팅 머신 또는 노드로 구성된 클러스터는 최소 하나 이상의 제어판(Control Plane) 컴포넌트와, 이것과 연결된 몇 개의 워커노드로 구성되어 있습니다.

2. 컨트롤 플레인 (제어판)

• 쿠버네티스 노드를 제어하는 프로세스들이 모여있는 곳입니다. 여기에서 모든 태스크 할당이 시작되고 제어판 컴포넌트는 클러스터가 잘 작동할 수 있게 돕습니다. 제어판의 구성 요소도 자세히 알아보겠습니다.

1. etcd
   • 쿠버네티스 클러스터의 모든 데이터를 담고 있는 key-value 저장소입니다.
   • 인프라를 원하는 상태로 만들기 위해 정상 상태에 대한 snapshot 및 관리에 필요한 메타데이터를 저장합니다.
2. kube-api-server
   • 쿠버네티스 클러스터의 허브로서 클라이언트와 etcd에 저장된 데이터 사이의 상호작용을 중개합니다.
   • 사용자 (운영자), 클러스터 내 구성요소, 그리고 외부 컴포넌트가 서로 통신 할 수 있도록 HTTP API를 제공합니다.
   • 작동 원리

출처 : https://www.codestates.com/blog/content/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4

1. kube-scheduler
   • 새로운 POD를 감지하여 어떤 워커노드에 실행시킬지를 선택하는 역할을 합니다.
   • 노드의 현재 상태와 Pod의 요구사항을 체크합니다. 노드에 라벨을 부여합니다.
2. kube-conroller-manager
   • API 서버를 통해 클러스터의 다양한 컴포넌트들의 상태를 감지하고, 원하는 상태로 만드는 역할을 합니다.
   • 다양한 컨트롤러가 하나로 패키징되어 단일 프로세스 내에서 실행되게 합니다.

3. 워커노드

• kubelet이라는 프로세스가 돌아가고 있는데, 이 kubelet은 다른 노드와 서로 통신하거나 컨테이너를 실행하는 등의 태스크를 실행할 수 있게 합니다. 한 개 이상의 컨테이너가 자리 잡고 있으며, 워커 노드는 실제로 애플리케이션이 실행되고 있는 곳이라고 할 수 있습니다. 그럼 워커 노드의 구성요소도 자세히 알아보도록 하겠습니다.

1. kubelet
   • 각 노드에서 실행되는 기본 노드 에이전트 입니다. 일종의 데몬이라고 생각하면 이해가 빠를 겁니다.
   • 컨테이너를 생성, 삭제하고 상태를 모니터링하며 마스터 노드와 통신을 담당 역할을 합니다.
   • 큐베렛이 작동하는 원리는 PodSpec 측면에서 작동합니다. 파일로 명시된 PodSpec 부분에 그 코드에 설명된 컨테이너가 실행되고 정상적으로 작동하는 지를 확인합니다.
   • 큐베렛은 쿠버네티스에서 생성되지 않은 컨테이너는 관리하지 않습니다.
2. kube-proxy
   • 모든 워커 노드마다 실행되는 네트워크 프록시입니다.
   • 다른 Pod간의 네트워크 통신과 클러스터 바깥에서 Pod로 네트워크 통신을 할 수 있게 해줍니다.
   • 성능 상의 이유로 별도의 프록시 프로그램 대신 iptable 또는 IPVS를 사용합니다. 즉 설정만 관리한다는 뜻이지요.

출처 : https://www.alibabacloud.com

3. kube-proxy
   • 단일 노드에 배포된 하나 이상의 컨테이너 그룹입니다. 포드에 있는 모든 컨테이너는 IP 주소, IPC, 호스트 이름, 기타 리소스를 공유합니다.

아래에서는 대표적인 컨테이너 엔진인 도커(Docker)의 정의와 사용법을 알아보겠습니다.

Docker (컨테이너 엔진)

도커란

• 리눅스 컨테이너에 리눅스 어플리케이션을 프로세스 격리기술을 사용하여 더 쉽게 컨테이너로 실행하고 관리할 수 있게 해주는 오픈소스 프로젝트이다. 도커는 일반적으로 도커 엔진 혹은 도커에 관련된 모든 프로젝트를 말한다.
  • 도커 엔진은 컨테이너를 생성하고 관리하는 주체로서 이 자체로도 컨테이너를 제어할 수 있고 다양한 기능을 제공하는 도커의 프로젝트이다. 도커의 생태계에 있는 여러 프로젝트들은 도커 엔진을 좀 더 효율적으로 사용하기 위한 것에 불과하기 때문에 도커의 핵심은 도커 엔진이라고 할 수 있다.

도커 컨테이너

• 가상화된 공간을 생성하기 위해 리눅스 자체 기능인 chroot, 네임스페이스(namespace), cgroup을 사용함으로써 프로세스 단위의 격리 환경을 만들기 때문에 성능 손실이 거의 없다. 컨테이너에 필요한 커널을 공유해서 사용하고, 컨테이너 안에는 어플리케이션을 구동하는 데 필요한 라이브러리 및 실행 파일만 존재하기 때문에 컨테이너를 이미지로 만들었을 때 이미지의 용량 또한 가상 머신에 비해 대폭 줄어든다. 따라서 컨테이너를 이미지로 만들어 배포하는 시간이 가상 머신에 비해 빠르며, 가상화된 공간을 사용할 때의 성능 손실도 거의 없다는 장점이 있다.
• 정리하면,
  • 도커 컨테이너는 가상화된 공간을 생성할 때 리눅스 자체 기능을 사용하여 프로세스 단위의 격리 환경을 만드므로
    • -> 성능 손실 없음
  • 가상머신과 달리 커널을 공유해서 사용하므로, 컨테이너에는 라이브러리 및 실행파일만 있으므로
    • -> 용량이 작음 ↓
  • 위의 이유로 -> 컨테이너를 이미지로 만들었을 때
    • -> 배포하는 시간이 가상 머신에 비해 빠르며 ↑, 사용할 때의 성능 손실 또한 거의 없음 ↓

도커 구성 요소

• Docker Client -> 도커를 설치하면 그것이 Client며 build, pull, run 등의 도커 명령어를 수행한다.
• DOCKER_HOST -> 도커가 띄워져있는 서버를 의미한다. DOCKER_HOST에서 컨테이너와 이미지를 관리하게 된다.
• Docker daemon -> 도커 엔진이다.
• Registry -> 외부(remote) 이미지 저장소이다. 다른 사람들이 공유한 이미지를 내부(local) 도커 호스트에 pull할 수 있다. 이렇게 가져온 이미지를 run하면 컨테이너가 된다.
  • public 저장소: Docker Hub, QUAY
  • private 저장소: AWS ECR 혹은 Docker Registry를 직접 띄워서 비공개로 사용하는 방법등이 존재한다.

도커 이미지 / 도커 컨테이너

• 도커 엔진에서 사용하는 기본 단위는 이미지와 컨테이너이며 도커 엔진의 핵심이다.
• 도커 이미지와 컨테이너와 관계는 운영 체제에서의 프로그램 <-> 프로세스, 객체지향 프로그래밍에서의 클래스 <-> 인스턴스의 관계 와 비슷하다고 보면 된다.
• Docker File -> Docker Image: Docker File은 도커 이미지를 만들때 사용하는 파일. docker build 명령어를 실행시키면 도커 이미지를 만들 수 있습니다.
• Docker Image -> Docker Container: Docker Image를 docker run 명령어를 실행시키면 Docker Container를 만들 수 있습니다.

스프링부트 프로젝트를 도커 이미지로 만들어보기

 

다음 게시글 클라우드

https://hoozy.tistory.com/entry/%EB%B0%B1%EC%97%94%EB%93%9C-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C

[백엔드] 클라우드

참고 자료

https://aws.amazon.com/ko/what-is/virtualization/
https://library.gabia.com/contents/infrahosting/7426/
https://www.codestates.com/blog/content/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4
https://seosh817.tistory.com/345