컨테이너 환경에서 미들웨어 활용하기

컨테이너 기술의 발전

소프트웨어 인프라를 운영하는 기업에서 컨테이너 기술은 생산성과 효율성을 높일 수 있는 좋은 대안입니다. 2008년 리눅스 컨테이너(Linux Container)가 소개되고 2013년 도커(Docker)가 등장한 이래 컨테이너(Container)는 꾸준히 개량되어 왔습니다. 인프라 유연성 증진, 비용 절감 그리고 개발·운영 효율 향상 등 컨테이너가 제공하는 효용성이 검증되면서 지금은 누구나 접근할 수 있는 기술이 되었습니다. 컨테이너는 응용 소프트웨어의 운영 환경을 지원하는 다양한 기능을 제공하고 있지만 이를 효과적으로 활용하기 위해서는 변화하는 기술에 대한 이해와 노력이 필요합니다.

컨테이너 개요

컨테이너는 가상화 기술의 하나로 애플리케이션 실행을 위한 바이너리와 라이브러리 등을 패키지로 묶어 배포합니다. 서로 다른 컴퓨팅 환경에서 애플리케이션을 안정적으로 실행할 수 있으며 빠른 개발이 가능합니다. 하드웨어를 가상화하는 가상머신(Virtual Machine)과 비교하면 컨테이너는 크기가 작고 가볍기 때문에, 동일한 서버 환경에서 더 많은 애플리케이션을 구동할 수 있습니다. 대표적인 컨테이너 엔진(제품)으로 리눅스 컨테이너를 지원하는 도커(Docker)를 들 수 있습니다. 도커는 컨테이너의 운영 및 배포를 자동화하는 오픈소스 프로젝트입니다.

컨테이너는 서버에 바로 배포할 수 있을 뿐 아니라, 가상머신 위에 배포할 수도 있습니다. 이 경우 대규모 시스템에서 가상머신이 제공하는 하드웨어 자원(CPU, 스토리지 등)을 가상화하여 컨테이너를 보다 효율적으로 운영할 수 있게 합니다. AWS(Amazon Web Services)와 같은 클라우드 환경에서 컨테이너를 실행·관리하는 구조와 동일하다고 볼 수 있습니다.

VM 가상머신이 제공하는 하드웨어 자원(HOST OS, CPU, 스토리지 등) 컨테이너가 제공하는 하드웨어 자원(APP1, HOST OS등) VM 가상머신위의 컨텐이너 구조

VM

app1	app2
BIN/LIB	BIN/LIB
GUEST OS	GUEST OS
HYPERVISOR
HOST OS

CONTAINER

APP1	APP2
BIN/LIB	BIN/LIB
DOCKER ENGINE
HOST OS

CONTAINER ON VM

app1	app2
BIN/LIB	BIN/LIB
DOCKER ENGINE
GUEST OS
HYPERVISOR
HOST OS

[그림 1] 가상머신(Virtual Machine)과 컨테이너(Container)의 구조

다수의 서버에 배포한 수많은 컨테이너를 관리하다 보면 다양한 이슈가 발생합니다. 개별 서버 단위로 작업을 수행해야 하고 컨테이너를 효율적으로 분배해야 함은 물론 수시로 상태를 점검하여 안정성과 고가용성을 유지해야 합니다. 이러한 불편함을 해결하기 위해 컨테이너의 오케스트레이션 및 클러스터 환경을 제공하는 도구가 나왔으며, 대표 솔루션이라고 할 수 있는 쿠버네티스(Kubernetes)로 기술이 수렴되고 있습니다. 컨테이너가 일반화되면서 널리 활용된 배경에는 쿠버네티스의 역할이 절대적이었습니다. 쿠버네티스는 전체 클러스터를 관리하는 마스터 노드와 컨테이너가 운영되는 워크 노드로 구성되어 있으며, 모든 명령은 마스트 노드의 API 서버를 통해 워크 노드로 전달됩니다.

전체 클러스터를 관리하는 마스터 노드와 컨테이너가 운영되는 워크 노드로 구성되어 있으며, 모든 명령은 마스트 노드의 API 서버를 통해 워크 노드로 전달되는 구조로 되어 있음

• user interface(GUI, CU)
• kubernetes master (api server, scheduler, controller manager, etcd)
• worker node(pod container container, pod container container, docker engine, kubectl, kube proxy)

[그림 2] 쿠버네티스(Kubernetes) 구조

컨테이너와 데브옵스(DevOps) 모델

컨테이너 플랫폼은 기본적으로 데브옵스 모델을 기반으로 합니다. 전통적인 IT 조직이 개발, 테스트, 운영 등의 단위로 나누어져 있었다면, 데브옵스는 하나의 조직에서 모든 업무를 수행하여 빠르고 효율적인 성과를 만들어 내는 프로세스를 추구합니다. 데브옵스는 인프라 엔지니어가 개발→빌드→배포→실행 프로세스를 자동화하는 CI(Continuous Integration)/CD(Continuous Delivery) 환경을 제공하고, 개발과 운영은 하나의 팀에서 수행하는 조직 구조이자 문화입니다. 새로운 코드 변경사항은 CI 단계에서 정기적으로 빌드 및 테스트를 거쳐 통합하며, CD 단계에서 변경사항을 자동으로 배포·실행합니다.

code, commit, ci pipeline: build, test, cd pipeline: review, staging, production [그림 3] CI·CD 파이프라인

컨테이너 환경으로 전환하는 것은 자동화된 CI/CD 파이프라인을 구축하는 것으로 기존의 조직 구성 역시 새로운 플랫폼 환경에 맞게 변화가 필요합니다. 컨테이너 환경으로 전환이 어려운 것은 기존의 조직과 프로세스에 변화가 필요하며, 모든 구성원이 컨테이너 기술 지식을 갖춰야 하기 때문입니다. 이를 극복하면 컨테이너 플랫폼이 제공하는 다음의 장점을 누릴 수 있습니다.

컨테이너의 미들웨어 지원

기업에서 사용하는 수많은 애플리케이션 중에서 컨테이너 환경과 잘 호환되면서 이식성이 우수한 애플리케이션은 무엇일까요? 대표적 미들웨어인 WAS(Web Application Server)가 이에 해당합니다. WAS는 컨테이너 기술의 얼리어답터(Early adopter)였으며, 컨테이너에 가장 많이 배포된 응용 소프트웨어 중 하나입니다. WAS는 수평 확장성, 무상태, 비공유 아키텍처(Shared-nothing Architecture) 등 컨테이너의 특성과 잘 부합하며, 컨테이너 역시 WAS가 필요로 하는 환경과 기능을 적극 지원하고 있습니다. 쿠버네티스를 살펴보면 일반적인 NFR(Non-Functional Requirement, 비기능적 요구사항) 외 WAS와 같은 미들웨어를 위한 기능이 많이 고려되었음을 알 수 있습니다. 부하 분산을 위한 로드밸런서, L7 라우팅 기능의 인그레스(Ingress), 활성 상태(Liveness)·준비 상태(Readiness) 상태 검사(Health check), 서비스 디스커버리(Service Discovery) 및 오토스케일러(Autoscaler) 등의 기능이 컨테이너 플랫폼에서 미들웨어 운영을 위해 활용됩니다.

컨테이너 환경의 소프트웨어 제약

오늘날 점점 더 많은 기업용 애플리케이션이 컨테이너 환경에 배포되고 컨테이너를 지원하는 소프트웨어 역시 증가하고 있지만 모든 애플리케이션이 컨테이너를 수용하는 것은 아닙니다. 컨테이너의 스토리지와 네트워크 인프라 관련 이슈로 전환이 어려운 레거시 애플리케이션들이 일부 존재합니다. 시스템 다운 시 컨테이너는 기본적으로 애플리케이션의 상태와 데이터가 유지되지 않습니다. 쿠버네티스에서 제공하는 임시 저장소가 있지만 컨테이너 간 공유가 되지 않으며 데이터 손실 위험이 있습니다. DBMS와 같은 상태 저장이 필수인 소프트웨어의 경우 상태 유지를 위해 별도의 NFS, iSCSI 등의 볼륨을 연결하거나 스토리지 가상화 솔루션 사용을 추가적으로 고려해야 합니다.

네트워킹 관련해서는 컨테이너와 컨테이너 간(Container to Container) 통신이 아닌 외부 호스트와 컨테이너 간 통신(WAN)에 이슈가 발생할 수 있습니다. 쿠버네티스는 모든 컨테이너가 가상 인터페이스를 할당받아 내부 통신하도록 설계되어 있으며, 외부 통신은 게이트웨이(로드밸런서, 인그레스) 또는 클러스터IP(ClusterIP)를 통해 접근합니다. 만약 외부 네트워크에서 특정 컨테이너의 IP·PORT로 직접 연결이 필요한 경우(링 네트워크, P2P 네트워크, 그리드 컴퓨팅 등) 통신에 제약이 따를 수 있으며 이를 방지하기 위해 쿠버네티스는 다양한 네트워크 환경을 지원하는 플러그인을 솔루션으로 제공하고 있습니다.

컨테이너 모니터링

수많은 컨테이너와 다양한 서비스를 개별적으로 모니터링하고 서로 간의 의존성을 파악하는 것은 쉽지 않습니다. 모니터링은 컨테이너 인프라 구축 시 기술적으로 어려운 부분 중 하나이며 대부분은 벤더에서 제공하는 도구를 활용합니다. 쿠버네티스 대시보드가 컨테이너 리소스에 대한 모니터링은 제공하지만 애플리케이션의 성능과 로깅을 위한 모니터링 기능은 제공하지 않습니다. 효과적인 컨테이너 모니터링 예시로 이스티오(Istio) 플랫폼을 들 수 있습니다. 이스티오는 애플리케이션 간 네트워크 통신을 제어하는 서비스 메쉬(Service Mesh)로 MSA(Microservices Architecture)를 위한 관리 플랫폼입니다. 쿠버네티스와 이스티오를 결합한 컨테이너 기반의 서비스 메쉬 플랫폼은 IT 운영에 많은 장점을 제공합니다.

client, istio gateway, istio virtual service, kubernetes service [그림 4] 쿠버네티스(Kubernetes)와 이스티오(Istio) 다이어그램

이스티오의 모니터링 기능은 네트워크 트래픽을 기반으로 서비스 간 의존성, 구간별 응답시간, 처리량 등의 다양한 지표를 제공합니다. 마이크로서비스의 최소 단위 애플리케이션 배포 방식과 컨테이너 플랫폼을 결합하면 효과적인 컨테이너 개발·운영 환경을 만들 수 있습니다. 컨테이너와 마이크로서비스 환경에서는 분산된 토폴로지(Topology)의 상태를 추적하여 문제 원인을 신속하게 파악하는 것이 중요합니다. 기존 APM(Application Performance Monitoring) 도구가 단일 애플리케이션의 성능 분석을 지원했다면 분산 환경에서는 다양한 계층의 트랜잭션을 추적하기 위한 분산 추적 기술(Distributed Tracing System)이 필요합니다. 이러한 분산 추적 기술의 표준으로 CNCF(Cloud Native Computing Foundation)에서 운영하는 오픈트레이싱(OpenTracing)이 있으며 상호 호환성을 위한 분산 추적 API를 비공식 표준으로 정의하고 있습니다. 오픈트레이싱 기술을 구현하는 CNCF 예거(Jaeger), 아파치 스카이워킹(Apache SkyWalking), 엘라스틱(Elastic) APM 등의 솔루션은 마이크로서비스와 컨테이너 환경에서 APM 도구로 활용할 수 있습니다.

마치며

다양한 미들웨어 소프트웨어가 컨테이너 플랫폼으로 전환되고 개발 프로세스는 데브옵스로, 아키텍처는 마이크로서비스로, 모니터링은 클라우드 환경으로 변화하고 있습니다. 컨테이너 생태계는 사용자에게 높은 효용성을 제공하기 위해 오랜 시간 동안 기술을 발전시켜 왔으며 웹서버나 WAS 미들웨어를 위한 컨테이너 기술은 이미 완성되어 상용화 단계에 이르렀습니다. 전통적인 IT 회사뿐 아니라 디지털 기술을 활용하는 기업이라면 컨테이너의 우수한 가치에 주목하고 적극적인 활용을 검토해 볼 때가 되었습니다.



▶  해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶  해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.