[전문가 진단] 컨테이너 오케스트레이션

가상화 기술을 기반으로 한 가상머신(VM) 은 클라우드 확장에 큰 공을 세웠다. 컨테이너는 가상화가 아닌 격리 기술을 사용해 VM 이 가상화의 한계로 가지는 단점을 극복하고 클라우드 네이티브 환경의 마이크로서비스 구축에 최적 클라우드 컴퓨팅 기술로 부상했다.

VM은 BIOS 부터 시작해 하드웨어 체크, 커널 로딩, 데몬 시작 등의 부팅 과정을 거쳐 인스턴스 생성 속도가 느리다. 이는 인스턴스의 빠른 수평적 확장에 방해가 되는데, 컨테이너는 부팅 과정 없이 격리된 프로세스만 띄울 수 있어 인스턴스 생성이나 확장이 VM에 비해 수배에서 수 십배까지 빠르다.

VM 복제나 저장은 가상화된 디스크 이미지에 대해 이뤄지므로 이미지가 최소 수GB 단위로 크고, 버전 관리가 어렵다. 컨테이너는 이미지를 파일 단위로 관리하고 배포하기 때문에 최소한의 용량으로 보관하고 재사용 할 수 있다.

VM은 CPU부터 디스크, 네트워크 등 IO 까지 모두 가상화해 쓰기 때문에 추가적인 컴퓨팅 자원이 소모된다. 컨테이너는 호스트의 커널을 사용하고 격리된 파일시스템을 직접 사용해 호스트의 성능을 오버헤드 없이 사용 가능하다.

■왜 컨테이너인가?

1) 이식성: 종속성 및 구성을 같이 배포

기존 개발 및 운영 시스템에서는 개발 환경과 테스트 환경에서 잘 돌아가던 애플리케이션에 배포서버에만 올리면 오동작 하는 일이 잦다. 컨테이너는 OS 라이브러리, 환경 설정 등 실행에 필요한 모든 종속성을 같이 배포하므로 개발-테스트-운영 간, 온프레미스-클라우드 간 이식성이 뛰어나다.

2) CI/CD 가속화: 7배 더 자주 배포

가상머신과 달리 컨테이너 인스턴스 생성 및 삭제는 빠르고 간단하여 개발 환경이나 빌드 및 테스트 환경 구성이 쉽게 자동화된다. CI(Continuous Integration) 측면에서 기능 추가, 버그 수정 등의 이슈마다 깃(Git) 브랜치를 생성하고 해당 브랜치에 대한 개발 및 테스트 환경을 병렬 구축할 수 있다. CI측면에서도 컨테이너 이식성을 활용하면 운영 환경으로의 배포 부담이 크게 줄어든다. 이렇게 컨테이너로 구축한 데브옵스(DevOps) 운영으로 전보다 유연한 개발 사이클을 구성해 애플리케이션 비즈니스 요건 적용과 버그 수정을 신속하게 진행할 수 있다.

3) 비용 절감

물리 서버를 가상화하면서 인프라 비용이 크게 감소했지만, 컨테이너는 VM보다 더 많은 인프라 비용 절감이 가능하다. 서버 유지 자체에 필요한 커널 및 데몬 메모리를 사용하지 않기 때문에 애플리케이션에 필요한 메모리만 할당할 수 있다. 카피온라이트(Copy on write) 방식으로 공통 부분을 재활용해 이미지 저장 공간 및 컨테이어 운영에 디스크를 적게 사용한다. 호스트간 컨테이너 이동이 VM 보다 간단해 리소스에 최적화된 재배치를 쉽게 할 수 있다.

4) 마이크로서비스 아키텍처에 적합한 런타임 환경

확장성이 뛰어나고 유지보수가 쉬운 마이크로서비스 아키텍처가 기존 모노리스 아키텍처의 대안이 되고 있다. 작은 서비스를 많이 사용하고 자주 업데이트가 일어나는 마이크로 서비스의 특성상 쉽게 인스턴스를 만들고 업데이트 할 수 있는 컨테이너는 마이크로 서비스 운영에 최적인 런타임 환경이다.

■왜 쿠버네티스인가?

모두 처음엔 한개의 컨테이너를 만들어 시작하지만, 곧 많은 애플리케이션과 인스턴스로 늘어나게 되며 여러 머신에서 컨테이너를 운영하게 된다. 한 두 개의 컨테이너가 아닌 엔터프라이즈 수준의 컨테이너 관리 및 운영을 위해 컨테이너 오케스트레이션 기술이 대두하게 되었고, 현재 쿠버네티스가 다음과 같은 장점과 기술을 통해 가장 선호된다.

1)허라이즌털 스케일링(Horizontal scaling)

컨테이너는 가상화가 아닌 격리를 사용하여 부팅 과정이 없고 작은 이미지를 사용하여 복제가 빠르다. 서비스에 사용자가 몰려 가용성이 더 필요할 때 쿠버네티스 커맨드라인 명령어나 설정 변경을 통해 컨테이너를 쉽게 확장할 수 있다. 이 컨테이너는 여러 물리서버 혹은 가상서버 호스트에 분산 배치된다. 또한 CPU 사용량이나 사용자 임계치에 따라 자동 확장도 가능하다.

2)서비스 디스커버리 & 로드 밸런싱(Service discovery and load balancing)

마이크로서비스 아키텍처는 물론, 일반 모던 애플리케이션에서도 각 서비스나 애플리케이션 확장 시 골고루 부하를 분산하는 로드밸런싱과 각 애플리케이션을 찾아 주는 서비스 디스커버리는 필수 요소다. 스프링 클라우드처럼 넷플릭스 OSS 플랫폼을 사용해 유레카(Eureka), 리본(Ribbon) 등을 활용할 수도 있지만 이는 애플리케이션 코드를 수정해야 하고 특정 언어에 종속된다는 단점이 있다. 쿠버네티스는 ReplicaSet 을 통해 운영 플랫폼 자체에서 서비스 디스커버리와 로드밸런싱을 기본 제공한다. 언어에 구애받지 않고 코드 수정 없이 쉽게 서비스를 확장해 스케일 아웃 가능하다.

3) 롤아웃 & 롤백(Rollout and rollback)

모던 애플리케이션은 비즈니스 요구의 빠른 적용을 위해 하루에도 수 차례 배포를 하게 된다. 이 과정에서 무중단 배포와 배포 롤백 및 특정 버전으로 돌아가는 기능은 서비스 연속성과 장애 최소화를 위해 필수적인 요구사항이다. 쿠버네티스는 배포에서 ReplicaSet 을 관리해 정책에 따른 무중단 배포, 업데이트 등을 플랫폼 차원에서 지원한다.

4) 셀프 힐링(Self-healing)

컨테이너의 메인 프로세스가 종료되어 정지된 컨테이너를 다시 시작하고, 기 정의된 API 등으로 컨테이너 상태를 파악해 정상 기능을 하지 못하는 컨테이너를 재시작 하는 작업도 쿠버네티스가 관리한다. 또한 시작된 컨테이너라도 기능을 확인해 서비스 준비가 완료된 후에 클라이언트에게 노출하게 된다.

5)Secret and configuration management

데이터베이스 접속정보나 타 시스템 인증 정보 등 안전히 관리해야 하는 비밀 정보는 어떻게 관리해야 할까? 쿠버네티스는 이러한 비밀 정보를 안전하게 보관하고 사용하는 secret 오브젝트 및 운영에 필요한 환경 변수를 저장하는 configmap 오브젝트를 지원한다. 설정 및 접속 정보를 컨테이너 이미지나 빌드 환경과 분리하여 관리하고 배포할 수 있도록 지원하여 보안과 확장, 편의성을 최대화한다.

6)오픈소스와 생태계

특정 회사가 많은 돈을 투자하여 만드는 소프트웨어 솔루션이 오픈소스보다 좋은 성능을 내고 빠른 고객 지원으로 엔터프라이즈 시장을 지배하던 시기가 있었다. 하지만 특정 회사 소유가 아닌 오픈소스 프로젝트에 개인이나 재단, 그리고 IBM 과 같은 회사들이 전폭적인 지원을 하면서 오픈소스 성능은 크게 향상되었고, 오픈소스를 잘 아는 소프트웨어 회사들이 직접 지원과 오픈소스 기여를 하면서 고객 지원 방안과 안정성도 확보되었다.

IBM 도 플래티늄 회원사로 가입한 클라우드네이티브컴퓨팅재단(CNCF)은 쿠버네티스를 비롯한 클라우드 컴퓨팅 기술이 특정 벤더에 종속적이지 않으면서도 빠르게 성장할 수 있도록 관리하고 후원하는 역할을 한다.

■왜 IKS인가?

쿠버네티스는 오픈소스이기 때문에 직접 VM 혹은 베어메탈에 직접 설치해 사용 가능하다. 하지만 운영 측면에서 다음과 같은 측면을 고려하고 지속적으로 관리해야 하는데, IBM 클라우드 쿠버네티스 서비스(IKS) 같은 매니지드서비스를 사용하면 전문가 관리와 수준높은 고가용성 쿠버네티스 클러스터를 저렴한 가격에 사용할 수 있다.

1)Master deployment

클러스터를 관리하기 위한 마스터 노드에는 kube-apiserver, etcd, kube-scheduler, kube-controller-manager 등이 있다. 직접 쿠버네티스를 운영하려면 각 클러스터마다 해당 컴포넌트들을 설치하고 HA 구성을 신경써야 하며 해당 인프라에 대한 비용을 지불해야 한다. IBM 클라우드 쿠버네티스 서비스는 클러스터를 배치할 때 IBM 에서 관리하는 마스터 노드가 안전하게 신규 배치되어 사용자의 워커 노드를 관리하게 된다.

2)Worker deployment

IBM 클라우드 쿠버네티스 서비스에서 클러스터를 배치할 때 워커 노드를 선택할 수 있으며, 필요에 따라 워커 노드의 추가 및 삭제가 가능하다. 배치 형태는 워크로드에 종류나 보안 요건에 따라 저렴한 shared, 다른 tenant 와 분리된 dedicated, 물리 서버에 배치하는 베어메탈 중 선택 가능하다.

워커 노드 사양도 필요에 따라 선택하고 혼합 사용할 수 있으며, 네트워크 요건에 맞춰 공용, 사설 VLAN 을 선택할 수도 있다. 높은 보안성이 요구되는 클러스터는 공용 VLAN 없이 사설 VLAN 만으로 구성하고 사무실 혹은 데이터센터와 다이렉트 링크나 VPN 으로 연결하는 구성도 가능하다.

3)베어메탈 워커노드

컨테이너의 장점중 하나는 가상화가 아닌 격리(isolation)를 통해 호스트 머신인 워커 노드의 디스크 및 네트워크를 사용하기 때문에 가상화에서 생기는 IO 손실을 피할 수 있는 것이다. 하지만 워커노드의 호스트 머신으로 VM 을 사용하는 경우 추가적인 가상화 레이어 때문에 성능 손실이 여전히 발생한다.

IBM 클라우드의 다양한 베어메탈 서버를 활용한 IBM 클라우드 쿠버네티스 서비스의 베어메탈 호스트를 사용하면 디스크 가상화 없이 컨테이너가 물리 서버의 자원을 100% 활용 가능한 이상적인 컨테이너 운영환경을 구축할 수 있다. 특히 최대한 효율적인 디스크 IOPS 를 요구하는 딥러닝, 머신러닝, 빅데이터 워크로드를 컨테이너로 구현할 때는 IBM 클라우드 쿠버네티스 서비스의 베어메탈 워커노드 호스트의 SSD 레이드 디스크를 활용하여 최대의 성능을 뽑아낼 수 있다.

4)쿠버네티스 버전 관리

많은 사용자와 기업의 참여로 쿠버네티스는 3개월마다 기능을 추가한 릴리즈를 내놓고 있고, 현재는 1.9를 거쳐 2018년 3월에 1.10 이 출시되었다. 몇 일, 혹은 몇 주 간격으로 업데이트되는 1.10.x, 1.10.y 등의 빌드 업데이트는 그나마 호환성이 좋은 편이지만, 클러스터를 직접 운영시 각 릴리즈마다 마스터 및 워커의 호환성을 확인하고 운영 환경에 적용하는 일은 쿠버네티스 운영에 큰 부담이다.

IBM 클라우드 쿠버네티스 서비스는 쿠버네티스의 모든 릴리즈를 확인하고 테스트 후 클릭만으로 업그레이드할 수 있게 매니지드 서비스를 제공하며, 이 서비스는 CNCF 의 공식 인증을 통해 제공된다.

5)Component management

쿠버네티스 자체로도 강력한 기능을 제공하지만, 쿠버네티스의 또다른 장점은 다양한 컴포넌트를 쿠버네티스와 함께 사용할 수 있다는 점이다. 이러한 패키지를 직접 선택하고 설치하고 관리하는 것도 적지 않은 일이다. IBM 클라우드 쿠버네티스 서비스를 사용하면 다음과 같은 중요하고 필요한 컴포넌트를 선정하여 쿠버네티스와 연동하고 해당 컴포넌트를 최신 버전으로 유지하고 패치하기 때문에 사용자는 개발 및 배포에 집중할 수 있다.

쿠버네티스는 내부 포드(Pod) 통신용 네트워크를 별도로 만들어 관리하지만, 노드간 통신에는 별도의 SDN 구성이 필요하다. IBM 클라우드 쿠버네티스 서비스는 이 중 Calico 를 사용해 노드간 BGP 로 리눅스 커널의 L3 라우팅을 활용하는 빠르고 안정적인 네트워크 통신을 제공한다.

간단한 앱은 Deployment 를 통해 배포하고 관리할 수 있지만, 여러 Deployment와 서비스가 연동돼 서비스를 구성하는 앱은 다른 방식의 패키지 관리가 필요하다. IBM 클라우드 쿠버네티스 서비스 는 쿠버네티스에서 가장 널리 사용되는 Helm 패키지 관리자를 쉽게 사용할 수 있도록 표준 쿠버네티스 Helm 차트 및 IBM 에서 제공하는 차트를 목록 형태로 제공한다.

6)보안(Security)

컨테이너에서는 VM 수준의 보안 뿐 아니라 컨테이너에 맞는 보안 정책 및 기술을 적용해야 한다. IBM 클라우드 쿠버네티스 서비스 에서는 쿠버네티스에 다음과 같은 보안 요소를 적용하여 클러스터를 안전하게 유지한다.

방화벽은 포드(Pod) 간, 혹은 외부에서 들어오거나 외부로 나가는 트래픽에 대해서는 위에 서술한 Calico 의 네트워크 정책을 사용하여 보안 설정이 가능하다. 보다 다양한 방화벽 정책이 필요하다면 IBM 클라우드 인프라의 어플라이언스 및 하드웨어 방화벽을 주문하여 IBM 클라우드 쿠버네티스 서비스 에서 사용할 수 있다.

보안이 중요한 서비스의 경우에는 베어메탈 기반의 IBM 클라우드 쿠버네티스 서비스 워커 노드를 주문하여 하드웨어 TPM 보안을 사용할 수 있다. TPM 을 사용하면 바이오스와 커널 수준에서 디스크 암호화, 키 보안, 커널 및 시스템 정합성 확인 등을 수행하여 컨테이너의 보안성을 한층 높일 수 있다.

컨테이너 이미지가 배포되면 VM 과 달리 컨테이너 내부에서 진행되는 작업이 적기 때문에, 이미지 안에 들어가는 라이브러리의 보안 버그나 컨테이너 설정에서 생기는 보안 취약점을 찾기 어렵다. IBM 클라우드 컨테이너 레지스트리는 취약점어드바이저(VA) 기능을 제공한다.

리눅스 배포판으로 만들어진 이미지의 알려진 취약점을 자동으로 스캔해 관리자에게 알려주고, 해당 취약점을 해결할 방안을 제시하여 컨테이너 이미지의 보안을 유지한다.

컨테이너 레지스트리에 악의적인 사용자가 작성한 컨테이너 이미지가 업로드된다면 해당 레지스트리를 사용하는 모든 클러스터는 크게 위험해진다. IBM Helm 차트를 통해 제공되는 IBM 컨테이너 이미지 시큐리티 인포스먼트(IBM Container Image Security Enforcement) 패키지를 설치하면 Docker content trust 를 통해 서명되지 않은 비인증 이미지나, 위의 VA 에서 취약점이 있다고 판단하는 이미지를 설치하거나 업데이트하지 못하게 막아 클러스터를 안전하게 보호한다.

7)클라우드 서비스 & 왓슨(Cloud service & Watson)

애플리케이션을 컨테이너화하여 클라우드에 올린다면 IBM Cloud 에서 제공되는 다양한 서비스를 쉽게 연동하여 비즈니스 요건을 만족하고 애플리케이션의 품질을 향상할 수 있다.

쿠버네티스 자체에서도 Kube-proxy 를 활용한 로드밸런싱이 가능하지만, IBM 클라우드 쿠버네티스 서비스 에서는 IBM Cloud 인프라에서 제공하는 로드밸런서도 간단히 쿠버네티스 와 연동되어 대용량 트래픽에 대비할 수 있다.

챗봇, 음성, 자연어 처리, 이미지 처리 등 왓슨 서비스를 사용하는 애플리케이션을 빠르고 효율적으로 개발해야 한다면 어떤 아키텍처가 가장 좋을까? ICCS 문서의 기본 튜토리얼을 통해 ICCS 에서 Watson 서비스를 사용하는 예제를 체험해본다면 Watson 서비스를 얼마나 쉽게 컨테이너 환경에서 사용하고 개발할 수 있는지 확인할 수 있다.

컨테이너에 기본 할당되는 디스크가 휘발성이기 때문에 쿠버네티스 는 퍼시스턴트볼륨(PV), 퍼시스턴트볼륨클레인(PVC) 개념을 사용해 퍼시스턴트 스토리지를 제공한다. 컨테이너를 직접 운영하려면 글러스터FS, 셰프 등 네트워크 기반 스토리지를 별도로 생성하고 관리해야 하지만, ICCS 에서는 IBM 클라우드에서 제공하는 신뢰성 높은 블록 스토리지가 클러스터 PV 로 기본 제공되어 높은 안정성과 확장성을 가진 스토리지를 쉽게 사용할 수 있다.

컨테이너 클러스터를 운영하게 되면 기존 모니터링과 다른 메트릭을 통해 deployment, pod, node 를 관리해야 한다. IBM 클라우드 모니터링 서비스는 전 세계에 배포되는 컨테이너 클러스터의 지표를 Graphite 시계열 데이터베이스로 취합하고 Grafana 로 필요한 지표를 사용자화 할 수 있는 통합 모니터링 대시보드를 기본 제공한다.

마이크로서비스로 분리되고 컨테이너로 분산된 로그는 한군데로 취합하고 모니터링하여 애플리케이션의 정상 여부 및 상황을 파악해야 한다. IBM 클라우드 로깅 서비스를 사용하면 클릭 몇 번으로 IBM 클라우드 쿠버네티스 서비스 클러스터의 로그를 ELK 로 취합하여 확인할 수 있다.

■컨테이너와 쿠버네티스 적용

컨테이너와 쿠버네티스가 충분히 좋지만, 레거시 앱을 클라우드 기반 컨테이너 환경으로 옮기는 것은 간단하지 않다. 다음과 같은 업무에서 쿠버네티스를 고려해본다.

새로운 클라우드 앱을 개발해야 한다면 당연히 컨테이너 환경을 먼저 고려해야 한다. 12 팩터(Factor)를 적용해 배포 쉽고 확장 용이하며 유연성 있게 개발하는 클라우드 네이티브 앱은 쿠버네티스와 잘 맞는다.

컨테이너에 익숙하지 않다면 한 개의 컨테이너로 시작하고, 이를 Deployment 로 쿠버네티스 클러스터에 올려 서비스로 노출해보며 쿠버네티스에 익숙해지면 된다. 실제 코드로 이루어진 예제를 실행해보며 기술을 습득할 수 있는 IBM 코드를 참조하면 좋다.

이미 IaaS 에서 앱을 운영하고 있지만 위에서 언급한 컨테이너나 쿠버네티스 장점이 너무나 누리고 싶다면, 기존 앱을 컨테이너화 하는 것도 가능하다. 어느 정도 마이그레이션을 준비할 수 있다면 클라우드 네이티브 앱이 아니더라도 Dockerfile 을 작성하여 이미지를 만들고, 기존 파일시스템을 사용하는 부분이 있다면 PVC 에 마운트하여 컨테이너 환경에서 운영할 수 있다.