인사이트

인사이트

새로운 관점으로 깊이 있는 통찰을 제시합니다.

오픈소스 SW

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

2020.11.06이창명
다운로드

컨테이너 기술의 발전

소프트웨어 인프라를 운영하는 기업에서 컨테이너 기술은 생산성과 효율성을 높일 수 있는 좋은 대안이다. 2008년 리눅스 컨테이너(Linux Container)가 소개되고 2013년 도커(Docker)가 등장한 이래 컨테이너(Container)는 꾸준히 개량되어 왔다. 인프라 유연성 증진, 비용 절감 그리고 개발·운영 효율 향상 등 컨테이너가 제공하는 효용성이 검증되면서 지금은 누구나 접근할 수 있는 수준에 이르렀다.

컨테이너는 응용 소프트웨어의 운영 환경을 지원하는 다양한 기능을 제공하고 있지만 이를 효과적으로 활용하기 위해서는 변화하는 기술에 대한 이해와 노력이 필요하다.

 

컨테이너 개요

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

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

그림1. 가상머신과 컨테이너의 구조_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.

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

그림2. 쿠버네티스 구조_ User interface- GUI, CU. KUBERNETES MASTER- API SERVER, SCHECULLER, CONTROLLER MANAGER, ETCD. WORKER NODE- POD(CONTAINER,CONTAINER),POD(CONTAINER,CONTAINER), DOCKER ENGINE, KUBECTL, KUBE PROXY

 

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

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

그림3. CI. CD 파이프라인_ CODE, COMMIT, CI PIPELINE(BUILD, TEST), CDPIPELINE(REVIEW, STAGING, PRODECUTCTION)

컨테이너 환경으로 전환하는 것은 자동화된 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 운영에 많은 장점을 제공한다.

그림4. 쿠버네티스와 이스티오 다이어그램_ 다음순서로 진행 CLIENT, ISTIO GATEWAY, ISIO VIRTURAL SERVICE, KUBERNETS SERVICE

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

 

마치며

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

이창명 프로

에스코어㈜ 소프트웨어사업부 컨버전스SW그룹

차세대 메일 엔진, 빅데이터 솔루션 및 실시간 분석 플랫폼을 개발하였으며 현재 오픈소스 미들웨어 솔루션 R&D를 담당하고 있습니다.