티스토리 뷰

[웹진] 컨테이너 기술, 가상화 그리고 Platform as a Service


가상화에서 클라우드로


IT에서 가상화 기술이 등장한지 벌써 20 가까이 되어가고 있다. 처음에는 다양한 OS환경을 경험할 없는 개발자가 단순히 자기 PC에서 다른 OS 환경의 테스트를 해보기 위해 필요한 도구 정도로 여겨졌으나 지금은 IT 인프라스트럭처에서 빠질 없는 기술이 되었으며 가상화는 서버 가상화, 데스크탑 가상화, 스토리지 가상화, 네트워크 가상화네트워크 분리, 서버 통합 수많은 용도로 활용되고 있다. 이는 곧바로 클라우드 기술의 기반이 되었으며 이제 클라우드는 인프라를 구축하는데 매우 합리적인 선택사항이 아닌 필수 고려사항이 되었다.


클라우드의 도입은 사용자가 물리적인 서버 장비, 네트워크 장비, 스토리지 등의 복잡한 고민에서 벗어날 있도록 한다도입해서 구축하는 형태가 아닌 빌려쓰는 형태는 사용자 입장에서 TCO(Total Cost of Ownership) 대한 부담을 줄일 있으며 인프라 자원을 사용한 만큼 요금을 지불하므로 불필요한 비용을 줄일 있다. 뿐만 아니라 서비스의 용량을 산정하고 이에 맞춰 장비를 구매한 다음 데이터센터에 배치하고, 전력 요건을 맞추고 OS 설치하고 네트워크를 연결하는 수많은 과정을 거치지 않으므로 도입 시간(delivery time) 줄어드는 또한 장점이다. 여기서 끝나지 않는다. 증설을 해야하는 시점에는 다시 동일한 절차를 밟아야 하는데 또한 최소화 있다. 다만 어디까지나 하드웨어나 OS 하드웨어 인프라자원에 한해서이며 실제로 서비스를 만드는데 필요한 미들웨어데이터베이스 같은 소프트웨어 자원에 대해서는 여전히 추가적인 도입 시간이 필요하다.

<물리환경이나 가상환경에 비해 IaaS나 PaaS와 같은 클라우드 환경은 인프라 구축을 위해 필요한 시간을 줄여주며 그에 따른 비용 절감 효과를 기대할 수 있다> 




클라우드의 다른 형태 Platform as a Service


클라우드를 통해 인프라스트럭처를 쉽고 빠르게 생성한다면 이미 데이터센터 운영자는 많은 시간과 노력, 그리고 비용을 줄일 있다. 소위 Infrastructure as a Service 장점이다. 여기서 한걸음 나아가 실제 서비스를 얹어야 하는 미들웨어, 데이터베이스, 메시징 시스템과 같은 소프트웨어를 클라우드로 서비스 한다면 이는 Platform as a Service(이하 PaaS) 되는 것이다.



<PaaS는 미들웨어나 DB와 같은 Runtime 플랫폼까지 클라우드에서 제공하므로 사용자는 애플리케이션에 더욱 집중할 수 있다>


PaaS
구현하기 위한 컨테이너 가상화 - 도커


기존의 가상화 기술은 하이퍼바이저를 통해 Guest OS 격리시켜 구동하는 방식으로 구조상 Guest OS 상의 시스템 콜은 하이퍼바이저를 통해 베어메탈에 있는 Host OS 시스템 콜을 호출해야 한다. Guest OS-하이퍼바이저-Host OS 연결되는 호출 구조로 인해 베어메탈에 비해 상대적으로 응답시간이나 처리성능이 떨어지게 된다. 이에 반해 컨테이너 가상화 기술은 프로세스를 격리하는 기술로 Guest OS 없고 Guest OS (?)하는 공통 라이브러리만 존재하여 마치 베어메탈의 단일 Host OS에서 프로세스를 구동하는 것과 유사한 성능을 제공한다. 





<서버 가상화 vs. 컨테이너 가상화>



사실, 프로세스 격리를 기반으로 하는 컨테이너 가상화의 개념은 매우 오래된 개념으로 unix chroot 명령과 유사하다. 그리고 LXC, Solaris Elastic Cloud 구현 기술이 오래전부터 이미 존재하고 있었다. 그런데 시점에서 컨테이너 가상화 기술이 부각되는 것은 도커(docker)라는 오픈소스 기술이 등장하면서이다. 과거 다양한 컨테이너 가상화 기술은 개념적인 가치를 떠나 컨테이너 생성이 쉽지 않았고 관리 메커니즘이 빈약했기 때문에 시장에서 그리 주목을 받지 못했다. 그러나 도커는 컨테이너를 생성하고 관리하는 방법이 매우 간단하고 오픈소스의 강점인 수많은 참여자의 도움으로 매우 빠르게 안정화될 있었으며 도커 허브를 통해 다양한 이미지와 풍부한 기술사례를 제공한다.

<고래 등짝에 올려진 컨테이너 박스처럼 프로그램과 실행에 필요한 것들을 컨테이너에 담아서 손쉽게 이동하고 어니서나 간단하게 실행할 수 있는 도구와 환경을 제공하는 오픈소스 플랫폼>



진정한 도커의 장점은 경량화에 있다. 도커는 리눅스 컨테이너 기술에 기반하면서 AUFS(advanced multi-layered unification filesystem)라는 파일시스템을 사용한다. 이는 도커 이미지를 계층(레이어)구조로 생성하고 이미지 파일시스템에서 변경된 부분은 새로운 레이어로 만들어 쌓아 올리는 구조이다. 구조는 도커 이미지의 크기를 작게 만들며 동일한 파일시스템 계층은 다른 이미지와 공유하여 사용할 있어 저장 공간을 최소화 있다. 작아진 이미지는 컨테이너 부팅 시간을 최소화한다.


<도커의 다층 레이어 구조 파일시스템>



만약 기존의 하이퍼바이저 기반의 가상기술을 통해 리눅스 OS위에 JBoss EAP 설치된 이미지를 생성하고 구동한다고 가정해 보자. 최소한 OS 전체 용량과 JDK, JBoss EAP 설치본을 합한 만큼의 이미지가 생성될 것이다. 또한 이들은 조그만 변경에도 완전히 새로운 한벌의 이미지가 필요할 것이다. 기동 시간은 어떨까? 거대한 이미지의 로딩 시간, OS 부팅시간, JBoss EAP 기동시간을 합한 만큼의 부팅 시간이 필요하게 된다.


반대로 도커 컨테이너 기술을 통해 동일한 기능을 수행하는 이미지를 생성한다면 OS기본 이미지(shared lib) JDK, JBoss EAP 설치본 만큼의 이미지가 생성되며 파일시스템중 일부가 변경된 다른 이미지가 필요하다면 변경된 부분만 레이어로 생성되고 다른 레이어는 다른 이미지에서 재사용되므로 전체 이미지 저장소가 필요로 하는 공간은 획기적으로 절약될 것이다. 부팅 시간 역시 이미지가 작고 OS 부팅이 없기 때문에 바로 JBoss EAP 기동되는 시간만 계산하면 된다.


이와 같은 장점을 지닌 도커는 미들웨어와 같은 플랫폼 중심의 서비스를 지향하는 PaaS 사상에 매우 어울리며 다양한 활용 방안을 제시할 있다.




도커 컨테이너 Orchestration - Kubernetes


물론 도커 컨테이너 기술이 PaaS 적합한 기반 기술이기는 하나 도커만으로는 부족한 부분이 분명이 존재한다. 만약 도커만 가지고 웹서버나 WAS 서비스를 구현해 보신 분들이 있다면 분명 재미있는 기술이라는 점은 인정하면서도 실제 적용하는데는 부정적일 것이다. 도커 컨테이너를 관리하고 자동화하는 기능이 필요한 것이다. 다행스럽게도 오픈소스의 강점중 하나인 참여자의 도움으로 이러한 공백을 메울수 있는 솔루션이 개발되었는데 이것이 바로 Google에서 주도한 Kubernetes 프로젝트이다. Kubernetes 그리스어로 항해자라는 뜻을 지니며 도커 컨테이너를 관리하기 위해 Google에서 자체적으로 개발하다가 오픈소스 프로젝트로 외부에 공개되었으며 다음과 같은 기능을 제공한다.


API서버 제공 - Kubernetes는 모든 기능을 API서버를 통해 Rest API로 제공한다.

컨테이너 배포  관리 - Kubernetes는 컨테이너 집합을 Pod로 묶어서 생성하고 관리한다. 또한 자원 사용량이나  node selector 등 기준으로 통해 pod를 어떤 노드에서 구동할지를 결정한다.

도커 이미지 관리 - 도커 이미지를 버전별로 관리할 수 있는 관리 방안을 제공한다.

네트워크 관리 - SDN을 통해 클러스터 네트워크를 생성하고 pod 등 object에 네트워크 IP를 할당한다. 또한 외부 클라이언트가 접속할 수 있도록 proxy를 제공한다.

스토리지 연계 - Persistent Volume을 생성하고 관리하며  pod에서 이를 사용할 수 있도록 연계한다.

리소스 관리 - pod의 자원 사용량을 관리한다.

빌드 - 애플리케이션을 빌드하고 이를 도커 이미지화 할 수 있는 메커니즘을 제공한다.

자동 확장 - pod 자원 사용량에 따라 자동으로 pod를 scale-out 하거나 scale-in 한다.


<Kubernetes Architecture>



RedHat OpenShift Container Platform


레드햇은 도커와 Kubernetes 오픈소스를 묶어  OpenShift Container Platform이라는 PaaS 플랫폼을 만들었으며 이들 외에  관리 콘솔, 사용자 관리, 인증, Source-To-Image 빌드, 그리고 레드햇의 미들웨어 플랫폼을 xPaaS라는 패키지로 묶어 종합 미들웨어 플랫폼으로 제공하고 있다. xPaaS에는 JBoss EAP6.4, 7.0 뿐만 아니라 Apache Tomcat7, 8, BPM, BRM suite, ActiveMQ 애플리케이션의 기반이 되는 미들웨어를 포함하며 여기에 사용자가 개발한 애플리케이션을 바로 적용할 있도록 Source-To-Image 빌드 기능을 적용하였다. 따라서 별도의 커스터마이징이 없이도 레드햇의 다양한 미들웨어 소프트웨어를 적용할 있으며 Jenkins 파이프라인을 포함하여 DevOps 기능을 강화하였다. 외에도 데이터베이스로는 postgresql, mysql, mongodb 이미지 뿐만 아니라 nodejs, python, ruby, perl 거의 대부분 언어의 플랫폼을 이미지와 템플릿으로 제공한다.  


웹 관리 콘솔 제공

사용자 인증 - ID/PW기본 인증, LDAP 인증, Keystone 인증, Github 인증 등 다양한 인증 방법 제공 

xPaaS 플랫폼 제공 - JBoss EAP, Tomcat 및 BRM, BPM, JDG 등 미들웨어 제품군 템플릿 제공

Source-To-Image 빌드 - 애플리케이션 소스코드를 연계하여 빌드 및 배포 자동화 제공

CI/CD - Jenkins pipeline을 생성하고 DevOps를 위한 기반 제공

DB 및 다양한 애플리케이션 플랫폼 - PostgreSQL, MySQL, MongoDB 등 DB 템플릿를 제공하며 JBoss EAP와 연계 생성 기능 제공. Ruby, NodeJS, Perl 등 애플리케이션 플랫폼 템플릿 제공 




<OpenShift Container Platform>




<OpenShift Application Service>

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함