[4] 컨테이너, 그리고 도커

지난 포스팅에서 SaaS, IaaS, PaaS 에 대해 알아보았습니다.

그리고 IaaS와 PaaS를 비교하며 IaaS는 이식성이 좋지만 운영비 효율이 낮고, PaaS는 이식성이 낮지만 비용이 절감된다고도 언급을 했습니다.

 

그렇다면, IaaS의 장점인 이식성, PaaS의 장점인 운영비를 갖출 수는 없을까요?

바로 도커를 이용하면 가능합니다 !

 

우선 어떤 서비스를 배포하는 할 때를 살표봅시다.

 

쿠버네티스의 공식 문서에는 어플리케이션 배포 방법을 3가지로 나눕니다.

 

* 배포 관련한 부분은 해당 글은 이글을 읽고 작성한 것 입니다.

 

• 전통적 배포 , Traditional Deployment
• 가상화된 배포 , Virtualized Deployment
• 컨테이너 개발 , Container Deployment

 

 

전통적 배포 , Traditional Deployment

 

전통적인 방식의 배포란 쉽게, 물리적인 컴퓨터 한대에 하나의 OS를 깔고, 여러가지 프로그램을 설치하는 방식입니다. 

 

전통적인 배포 시대에는 각 조직이 보유하고 있는 물리 서버에서 애플리케이션을 구동했어야합니다. 그렇기 때문에 간단히 물리 서버에 어플리케이션을 올려놓기만 하면 되는 방식이었습니다.

 

그러나 이에 단점도 존재합니다.

서비스 사용자에 따른 인프라의 탄력적인 확장이 불가능했고, 서로 격리되지 않은 애플리케이션들은 영향을 주고 받는 등과 같이 말이죠.

 

한 예시로, 구동 중인 어떤 어플리케이션이 리소스를 점점 많이 잡아먹더니, 서버의 한계 만큼 차지한 상황을 예로들 수 있습니다. 

서비스의 수요 증가에 대응하기 위해서 리소스를 더 할당해줘야하는 것은 맞지만, 이로 인해 리소스를 더 요구하는 다른 어플리케이션이 영향을 받게 된다면 그 서비스는 장애가 발생할 것 입니다. 그러나 수요가 늘어난다고 다른 서비스에 할당될 리소스까지는 할당해줄 수 있습니다. 따라서 각 어플리케이션이 서로 격리되어야할 필요성과 리소스 할당에 한계를 두어야할 필요성이 대두되게 됩니다.

 

후에 발전한 가상화 기술은 전통적인 배포 시대 문제점들의 해결책이 되어줍니다.

 

가상화 배포, Virtualized Deployment

 

가상화를 도입하면서 하나의 물리적인 서버를 여러대의 논리적인 서버로 나누어 사용할 수 있게 되었습니다. 이렇게 나누어진 논리적인 서버는 가상 머신(VM, Virtual Machine)이라 불리며, 이 VM들은 서로 격리되어 각각 OS를 구동합니다.

 

가상화의 도입으로 시스템의 리소스를 하드웨어 레벨에서 나누어 각 VM에 할당할 수 있고, 전통적인 배포방식보다 더 효율적으로 리소스를 사용할 수 있게 되었습니다.

 

그러나 쿠버네티스 공식 사이트의 설명에 따르면 하드웨어 레벨 가상화의 VM들은 OS를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이므로 머신의 크기가 GB 단위가 넘어가며 너무나 크다는 단점이 있습니다. 이에 대한 해결책으로, 호스트 OS를 공유하여 조금 더 가벼운 격리 속성을 가진 컨테이너 기술이 등장합니다.

 

컨테이너 개발 , Container Deployment

 

컨테이너는 가벼운 VM이라고 생각하면 편한데, VM처럼 OS를 포함한 모든 종속성을 포함하는 것이 아닌, 동작할 애플리케이션의 종속성만 포함해 묶은 것이라고 할 수 있습니다. 즉  컨테이너란 우리가 구동하려는 어플리케이션을 실행 할 수 있는 환경까지 감써서, 어디서든 쉽게 실행 할 수 있도록 해주는 기술입니다. 

 

이렇게 컨테이너를 이용함으로써 가볍고 빠르며 잘 격리된 환경에서 애플리케이션을 실행할 수 있게 되었습니다. 또한 컨테이너를 사용할 때 필요한 도구가 컨테이너 런타임입니다. 컨테이너를 쉽게 내려받거나 공유하고 구동할 수 있도록 해주는 도구인데요, 종류도 여러가지가 있습니다. 그중 가장 유명한 것이 도커입니다.

 

 

도커, docker

 

도커는 컨테이너 기반의 오픈소스 가상화 플랫폼입니다.

 

 

다양한 프로그램들과 실행 환경을 컨테이너로 규격화시켜 프로그램의 배포관리를 단순화합니다. 프로그램의 코드뿐만아니라 실행에 필요한 모든 dependency들도 컨테이너에 담기 때문에 다른 환경에서도 빠르게 애플리케이션을 실행할 수 있습니다. 

 

도커는 앞서 IaaS의 장점인 이식성, PaaS의 장점인 운영비가 저렴함을 갖춘 도구입니다. 기존의 종속적인 라이브러리 등의 설치 절차를 스크립트로 작성하기만 하고 배포 관련 사항을 도커스윔이나 쿠버네티스에 맞춰작성하기만 하면됩니다. 

 

참고로 도커는 다음과 같은 과정을 거쳐 컨테이너를 만듭니다. 

1. 도커 파일이 빌드
2. 도커 이미지 생성 및 실행
3. 도커 컨테이너 실행

이 떄 도커 파일이란 컨테이너에 설치해야하는 패키지, 환경변수설정 등을 기록한 하나의 파일이며 도커 이미지는 도커가 도커 파일의 단계에 따라 컴퓨터의 상태를 스냅샷으로 저장한 것입니다. 도커가 이미지를 불러와 실행하면 컨테이너가 생성됩니다.

 

도커 등장 이후 많은 수의 애플리케이션들이 컨테이너화되어 배포되고 있습니다. 그러나 구글의 관점에서 볼 때 너무나도 많은 수의 컨테이너들이 배포되고 교체되어 관리의 복잡성이 증가하고 있었고 컨테이너 간 네트워크 또한 이 복잡성에 크게 영향을 주고 있었습니다. 이에 쿠버네티스가 개발 되고 이를 통해 여러 컨테이너들의 스케일링, 배포 등을 종합적으로 관리하기 시작했습니다.

 

해당 내용과 관련하여 잠깐 찾아보았는데 ...

깊이가 너무 깊네요 ...

오늘은 간단한 이해만 하기로하고 ~

물러가보겠습니다 :)