컨테이너 오케스트레이션 표준으로 자리 잡아, 관련 시장 폭발

[컴퓨터월드] 2000년대 중반, 기업들의 개발환경을 유연하고 민첩하게 만들어주는 ‘컨테이너’라는 개념이 등장한 이후 이들 컨테이너들을 관리할 수 있는 플랫폼이 주목받고 있다. 컨테이너의 오케스트레이션을 가능하게 해주는 기술은 쿠버네티스를 비롯해 ‘도커 스웜(Docker Swarm)’, ‘아파치 메소스(Apache Mesos)’ 등 다양하게 존재하지만 쿠버네티스가 이미 업계 표준으로 자리잡았다. 업계에서는 적어도 향후 10년 동안은 쿠버네티스와 관련된 시장이 크게 성장할 것으로 내다보고 있다. 컨테이너와 쿠버네티스를 중심으로 벌어지고 있는 시장상황을 살펴봤다.


컨테이너 관리의 복잡성 해결

컨테이너는 리눅스에 내장된 LXC(LinuX Container) 기술로 2000년대 중반에 처음 소개됐다. LXC는 단일 머신 상에서 여러 개의 독립된 리눅스 커널 컨테이너를 실행하기 위한 ‘OS 레벨의 가상화 기법’으로 컨테이너라는 개념이 사람들에게 인식되기 시작한 것도 이 때부터였다.

컨테이너가 최근 다시 떠오르게 된 가장 중요한 이유는 개발환경과 운영환경의 간극을 좁히기 위해서다. 일반적으로 소프트웨어(SW)는 개발자가 개발한 환경에서 가장 원활하게 구동된다. 하지만 개발 환경에서 아무 문제없이 운영되던 소프트웨어일지라도 환경이 바뀌면 문제가 생길 수 있다.

개발자의 개발 환경과 운영자의 운영 환경이 다를 경우 소프트웨어에 문제가 생길 수 있다는 것이다. 가령, 개발자는 우분투 OS 환경에서 SW를 개발했는데, 고객사에서 다른 OS를 사용하게 되면 개발 환경에서 보여줬던 기능 또는 성능에 문제가 나타날 수 있다.

특히 개발자는 SW 개발이 완료되면, 다른 OS로 마이그레이션을 하는 작업을 해야 한다. 일반적으로 특정 OS로 마이그레이션 하는데 품질 보증, 버그 수정 등을 포함해 보통 6개월이 소요된다. 개발된 소프트웨어를 특정 OS로 마이그레이션 하는 데 엄청난 인력과 시간 그리고 비용이 들어가게 된다는 것이다.

하지만 컨테이너를 활용한다면 이런 문제를 상당부분 해소할 수 있다. 컨테이너라는 그릇에 이미지화 된 ‘라이브러리(lib)’, ‘바이너리(bin)’ 등의 파일로 옮겨 넣기만 하면 된다. 이를 통해 버그 발생률을 90% 가량 감소시킬 수 있다.

이진현 맨텍 OM 사업본부 본부장은 이러한 상황을 나무를 옮겨심는 것에 비유했다. 그는 “나무를 다른 곳으로 옮겨 심을 경우 죽는 경우가 많다. 나무가 자란 환경이 아니기 때문이다. 그래서 나무를 옮겨 심을 때는 원래 나무가 있던 자리의 흙도 함께 옮긴다”며 “SW 역시 개발자의 개발환경을 SW와 함께 같은 그릇에 담아 옮겨야 하는 데 그 SW가 담긴 그릇이 바로 컨테이너다”라고 말했다.

컨테이너가 필요한 또 다른 이유는 바로 SW의 효율적인 호스팅 문제 때문이다. 물리머신에서 SW를 호스팅을 한다면, SW를 최적으로 구동할 수 있는 환경을 물리머신이 갖게 된다. OS위에 WAS(Web Application Server)를 두고 그 위에서 SW가 구동되는 형식이다. 하지만 이렇게 되면 자원(CPU, 메모리)을 격리(다수의 SW가 OS에서 잘 구동되기 위해 격리가 필요)시킬 수 없고, OS간의 호환성 문제도 발생한다.

이러한 문제를 해결하기 위한 방법이 바로 가상머신(VM)이다. 기존의 서버에 하이퍼바이저를 설치하고 그 위에 가상 OS와 애플리케이션을 패키징한 VM을 만들어 실행하는 것으로 하드웨어 레벨의 가상화다. VM으로 격리 문제를 해결할 수 있는 것이다. 하지만 VM 역시 효율성을 비롯해 OS 라이선스 문제, OS의 리소스 등의 문제가 있다.

▲ VM과 컨테이너 비교표

현재의 컨테이너는 인프라 위에 OS를 구성하고 그 위에 컨테이너 엔진을 설치하며, 윗단에 컨테이너가 애플리케이션과 WAS를 포함해 올라가게 되는 구조이다. 이로써 하부 자원에 대한 종속성 없이 스스로 가동될 환경을 구축할 수 있다.

이런 이유로 버그 발생률과 개발자들의 수고를 덜 수 있을 뿐 아니라 늘어나는 개발비용에 대한 문제도 해결할 수 있다. 하지만 이러한 컨테이너가 한 개가 아닌 수천 개, 수만 개가 된다면 여전히 관리의 문제가 나타나게 된다. ‘쿠버네티스’라는 컨테이너 관리 자동화 플랫폼이 각광받는 이유이다.

▲ 베어메탈, VM과 컨테이너 구조도(출처: 레드햇)


오케스트레이션 표준으로 자리 잡아

구글에서 오픈소스로 개발한 쿠버네티스는 컨테이너의 통합 관리 필요에 의해 등장한 관리 기술이다. 하지만 컨테이너를 관리할 수 있는 기술, 즉 컨테이너 오케스트레이션 기능은 비단 쿠버네티스에만 있는 것은 아니다.

아파치 소프트웨어 재단에서 만들어진 오픈소스 프로젝트인 ‘아파치 메소스(Apache Mesos)’, 도커에서 만든 도커 엔진 그룹을 단일 가상 도커 엔진으로 묶는 클러스터링 기능을 제공하는 ‘도커 스웜(Docker Swarm)’, 코어 OS의 ‘플릿(Fleet)’, AWS의 ‘EC2’, 레드햇 ‘콕핏(Cockpit)’ 등도 컨테이너의 통합 관리에 필요한 기능을 제공하고 있다.

▲ 쿠버네티스와 메소스, 스웜의 인기도(출처: 구글 트렌드)

2016년부터 쿠버네티스는 업계 표준으로 자리 잡으면서 영향력을 더욱 확대해나가고 있다. 심지어 도커 스웜을 지원하던 도커도 쿠버네티스를 지원하겠다고 공식 발표했다. 도커 스웜이라는 자체 컨테이너 관리 플랫폼이 있는데도 쿠버네티스를 지원하겠다고 나선 것이다.

이에 대해 장민 나무기술 기술3본부장은 “도커 엔진을 통해 컨테이너를 배포하면 데스크톱 기반, 랩톱 기반의 단일 컴퓨터 환경에서는 개발 편의를 지원해 준다”며 “하지만 실제 클라우드 환경, 실제 운영 환경, 다수 물리적 호스트 등 확장성이 있는 대규모 클러스터 구현에 있어서 쿠버네티스 보다 효율성이 떨어지기 때문에 쿠버네티스를 사용하는 사람이 많다”고 말했다.

정윤진 피보탈 프린시플 테크놀로지스트는 “1대1 직접비교를 하기는 힘들지만 도커는 대단위 클러스터 환경을 위해 디자인된 건 아니다”며 “최근에는 도커를 설치하면 도커 엔진 위에 쿠버네티스를 깔아주는 형태로 발전하고 있다. 컨테이너 환경 위에 쿠버네티스 환경을 올려진 형태로 개발자에게 제공하는 추세다”라고 강조했다.

현재 구글은 자사의 G메일, 구글 드라이브 등 애플리케이션에 CI/CD(Continuous Intergration/Continuous Deploy) 등의 기능을 위해 쿠버네티스를 활용하고 있는데 쿠버네티스를 통해 운영 중인 컨테이너는 약 30억 개이다.

▲ 오케스트레이션의 기능(출처: SPRI)

30억 개에 달하는 컨테이너를 관리하는 것은 매우 어렵다. 하지만 쿠버네티스는 오케스트레이션(Orchestration)이라는 기능으로 방대한 양의 컨테이너를 관리할 수 있다. 오케스트레이션 엔진을 통해 컨테이너의 생성과 소멸, 시작 및 중단 시점 제어, 스케줄링, 로드 밸런싱, 클러스터링 등 컨테이너로 애플리케이션을 구성하는 모든 과정을 관리할 수 있다.

컨테이너 오케스트레이션 SW는 대부분 클러스터 관리를 위한 API 서비스, 컨테이너에서 구동되는 애플리케이션 관리를 위한 서비스 디스커버리, 모니터링 서비스 등을 담당하는 콘트롤 플레인, 실제 컨테이너 들이 구동되는 서버들의 클러스터(그룹화)로 구성돼있다.

쿠버네티스의 기술적 구성은 클러스터 형태다. 쿠버네티스는 클러스터 전체를 관리하는 ‘마스터(Kubernetes Master)’와 컨테이너가 배포되는 가상 또는 물리 머신인 ‘워커노드(Worker Node)’로 나뉜다.

쿠버네티스에 의해서 배포 및 관리되는 컨테이너들은 ‘포드(Pod)’라는 단위로 묶여진다. 포드는 하나 이상의 컨테이너를 포함하며, 같은 포드에 속해있는 컨테이너들은 서로 로컬 통신이 가능하고 디스크 자원도 공유할 수 있다. 이로 인해 서비스에 따라 컴퓨팅 파워 스케일링(컴퓨팅 파워 조절)이 쉬워진다.

▲ 쿠버네티스의 아키텍처(출처: 맨텍)

먼저 ‘마스터 쿠버네티스’는 ‘Kubectl’라는 커맨드 인터페이스를 통해 세팅된다. 세팅된 마스터는 쿠버네티스의 설정 환경을 저장하고 노드로 이뤄진 클러스터 전체를 관리하는 관리자 역할을 수행한다. 또한 API 서버, 스케줄러, 컨트롤러 매니저, ETCD로 구성된다.

API 서버는 유저(UI, User Interface)로부터 요청이나, 마스터와 워커노드 간의 통신을 담당하고, ETCD는 워커노드 및 클러스터의 설정 값과 상태를 저장하는 데이터베이스 역할을 한다. 스케줄러는 포드의 배포 및 서비스에 필요한 리소스를 적절한 워커노드에 할당하며, 컨트롤러 매니저는 포드의 저장 공간 조절, 동적 추가 또는 삭제되는 포드에 대한 라벨을 할당한다. 또 여러 포드의 그룹핑 서비스 시 로드 밸런싱 등도 관리한다.

‘워커 노드’는 마스터에 의해 명령을 받고 실제 작업을 수행하는 서비스 컴포넌트로 컨테이너를 보유한 포드들이 배치된다. ‘Kubelet’은 마스터의 API 서버와 통신을 담당하며 수행할 명령을 받거나 노드의 상태를 ‘마스터 쿠버네티스’로 전달한다. ‘Kube-proxy’는 노드에 들어오는 네트워크 트래픽을 포드 내의 컨테이너에게 라우팅하고 노드와 마스터간의 네트워크 통신을 관리하는 역할을 한다.

쿠버네티스는 컨테이너를 유연하게 만들어주는 기능이 있다. 이로써 인프라 자원과 운영환경에 따른 능동적인 애플리케이션 관리가 가능해진다. 다이나믹 스케줄링 기능은 컨테이너를 클러스터에 배포하는 정책과 스케줄링을 쿠버네티스가 자동으로 관리해준다. 운영자는 배포하는 시점에 각각의 워커 노드의 상태를 확인할 필요가 없으며, 쿠버네티스에서 노드의 사용량에 따라 최적의 운영환경을 유지하며 컨테이너를 자동 배치한다.

오토스케일링 기능은 컨테이너 애플리케이션의 사용량 증가에 따라 컨테이너를 자동으로 복제해 배포하는 기능이다. 이 기능은 안정적인 운영을 가능하게 한다. 롤링업데이트 기능은 컨테이너의 업그레이드 혹은 패치가 필요할 경우 롤링 업데이트를 지원해 무중단에 가까운 서비스 업그레이드가 가능하다. 마지막으로 개별 컨테이너의 자원 사용량, 즉 CPU, 메모리를 제어하기 때문에 해당 컨테이너에 최적화된 리소스 사용량을 할당할 수 있다. 이를 통해 불필요한 자원 낭비를 막을 수 있다.


클라우드에서 특히 주목받아…마이그레이션 확률 높여

컨테이너와 쿠버네티스는 특히 클라우드에서 각광받고 있다. 다른 클라우드로 마이그레이션 하기 이전 애플리케이션을 개발했다면 개발한 환경의 가상머신 및 물리머신에 최적화된 상태다. 하지만 애플리케이션을 다른 클라우드로 옮길 경우 CSP 마다 사용하는 가상머신이 달라 문제가 발생할 수 있다. 한 예로 AWS에서 운영되던 것을 애저로 옮기려면 애저에 있는 가상머신에 맞게 수정하는 작업을 해야 했다.

보통 마이그레이션 과정을 거쳐 성공할 확률은 약 80%인 것으로 알려지고 있다. 확률 80%는 한 기업의 비즈니스에 큰 타격을 줄 수도 있을 정도이다. 가령, A, B, C, D라는 애플리케이션이 있다면, 이 파일들이 모두 제대로 이관돼야 애플리케이션을 구동할 수 있다. 하나라도 빠지면 운영할 수 없다. D가 이관하는 과정에서 빠지게 된다면 결국 D 때문에 마이그레이션이 실패하는 경우가 발생할 수 있는데 이는 VM 환경 및 네트워크를 다루는 방식의 차이 때문이다.

이진현 맨텍 OM 사업본부 본부장은 “컨테이너는 하부 OS, 물리머신, 하부 자원에 대한 종속성 없이 컨테이너 그 자체로 가동될 환경을 갖고 있어 어디든 옮길 수 있다. 그래서 클라우드 환경에서 급부상 하고 있다”며 “최근 클라우드 네이티브 아키텍처(CNA)가 주목받고 있는데 컨테이너는 이와 완벽하게 호환성을 갖고 있다”고 말했다.

이어 그는 “만일 내가 만든 애플리케이션이 컨테이너 기반이라면 NBP의 NCP, MS의 애저, KT의 G-클라우드 등 어디든 이식이 가능하다. AI, 블록체인 등이 최근 컨테이너 구조로 나오는 이유가 바로 클라우드 때문이다”며 “블록체인도 하이퍼바이저를 다운받으면 컨테이너 이미지로 받게 된다. 오라클의 DB도 컨테이너 이미지로 제공된다”고 말했다.

김현수 레드햇 어소시에이트 프린시플 솔루션 아키텍트 이사는 “최근 오라클이나 SAP도 자사의 솔루션을 컨테이너로 전환하려는 움직임을 보이고 있다”며 “SAP는 데이터 허브라는 기술을 컨테이너 기반으로 하려는 움직임을 보이고, 오라클은 이미 자사의 미들웨어를 컨테이너 기반으로 하겠다고 선언했다. 조만간 DB 업체들도 컨테이너로 전환하는 작업에 돌입할 것이다”고 전망했다.

▲ 멀티 클라우드 상 컨테이너 배포(출처: 맨텍)

특히, 하이브리드 클라우드와 멀티 클라우드 경우 쿠버네티스의 중요성은 더욱 강조된다. 쿠버네티스는 인프라와 무과하게 OS 윗 단에 쿠버네티스 엔진을 설치함으로써 프라이빗 클라우드 환경이나 퍼블릭 클라우드 환경에서 모두 운영할 수 있도록 해준다.

그리고 여러 클라우드에 배치된 다수의 쿠버네티스 클러스터 상에 멀티 클러스터 관리 솔루션(쿠버네티스 하부 프로젝트를 위한) ‘페더레이션(federation) 프로젝트’을 통해 A사의 클라우드에서 구동되고 있는 A컨테이너를 B사의 클라우드에 구성된 B쿠버네티스 클러스터로 쉽게 배포할 수 있다.

또한 클라우드와 클라우드간 컨테이너의 확장을 통한 로드 밸런싱 또한 쉽게 구현할 수 있도록 해준다. 이러한 일이 가능한 것은 컨테이너가 마이그레이션이 필요 없는 이기종의 호스트와 하이퍼바이저간 구동이 가능하기 때문이다. 일반적으로 멀티 클라우드에서 개발과 테스트는 프라이빗에서 진행하고 서비스 배포는 퍼블릭 클라우드로 운영하는 형태를 보이고 있다.

▲ 하이브리드 클라우드 구조에서의 애플리케이션 확장(출처: 맨텍)

하이브리드 클라우드 구조에서는 주로 프라이빗 환경에서 개발/테스트와 서비스를 제공한다. 프라이빗 환경에 부하가 집중될 경우 퍼블릭 클라우드로 서비스가 자동으로 스케일 아웃 하는 방법에도 유용하다.

칵테일을 공급하고 있는 나무기술의 장민 기술 본부장은 “우리 고객 중 멀티 클라우드로 클라우드 4개를 동시에 사용하는 고객이 있다. AWS, GCP, MS 애저와 중국 고객을 타깃으로 알리바바 클라우드 등 총 4곳의 클라우드를 사용하고 있는데, 이 고객은 멀티 클라우드 환경에 각각 클라우드 서비스에 2개의 클러스터를 놓는다. 한 클러스터는 개발을 위한 클러스터이고, 다른 한 개는 운영을 위한 클러스터다”라며 멀티 클라우드 사례를 공개했다.


방대한 기능 제공, 그만큼 학습하기 어려워

쿠버네티스는 오픈소스 기술이다. 하지만 쿠버네티스 자체가 매우 방대한 기능을 제공하고 있어, 이를 제대로 학습하고 다루기는 매우 어렵다. 쿠버네티스는 여러 에코 솔루션들의 통합이 필수적이다.

예를 들어 ▲페더레이션(Federation) ▲인그레스(Ingress) ▲앱 카탈로그 ▲멀티 테넌시 구현 ▲프라이빗 컨테이너 저장소 ▲영구 볼륨 구축 ▲형상 관리 ▲네트워크 구성을 위한 CNI ▲로깅(Logging) ▲컨테이너 스케줄러 ▲CI/CD ▲모니터링 ▲알팅(Alerting) ▲배포 파이프라인 등 수십 가지의 하부 에코 솔루션과 서드파티들을 연동해야 한다.

즉 단순히 플러그 앤 플레이(Plug and Play)처럼 다운로드 받아서 설치하고 사용할 수 있는 솔루션이 아니라는 뜻이다. 구축과 구현에 수개월에서 수십 개월이 소요되며 버그 테스트, 수정, 최적화 작업 등 검증작업도 직접 해야 한다.

2018년 국내 몇몇 대기업들이 쿠버네티스 상용화에 나섰지만 실패했다는 데서도 이런 어려움을 읽을 수 있다.

일반적으로 상용SW의 EOL(End of Life, 단종)이 5~6년인데 반해 쿠버네티스의 EOL은 약 9개월로 비교적 짧다. 가령, 9개월 걸려 쿠버네티스 기반으로 PaaS 환경을 구축했는데, 오픈하기도 전에 해당 쿠버네티스 버전이 단종 된다면 이는 필요 없는 일을 한 셈이 된다.

게다가 일반적으로 분기별로 새로운 버전이 발행되는데, 새로운 버전에는 많은 변화가 일어나고 연동되는 하부의 수십여 가지의 오픈소스 또한 달라지기 때문에 이를 추적하고 관리하는 것도 결코 쉬운 일이 아니다.

그리고 다양한 에코 솔루션들 중 어떠한 것들을 선택해 사용할 것인지, 에코 솔루션 간의 상호 연동을 할 것인가를 사용자가 알아서 구현해야 하기 때문에 자체적으로 개발하거나 구축하는 것이 쉽지 않다. 최소한 수십 명의 전담 인원이 할당돼야 유지가 가능하다. 국내 몇몇 대기업이 쿠버네티스 상용화에 나섰다 포기한 이유이다.

이진현 맨텍 OM 사업본부 본부장은 쿠버네티스 상용화에 대해 케익을 예로 들며 “유명 프랜차이즈 점포에서 만든 케익을 살 것인가, 아니면 계란, 밀가루, 설탕 등 수많은 재료를 이용해 만들어 먹을 것인가의 문제와 같다”며 “쿠버네티스를 직접 상용화해 사용하는 것도 좋지만, 수많은 테스트, 수정 등의 공수를 들이는 것이 비효율적일 수 있다. 일반적으로 케익을 만들어 먹을 수도 있지만, 여러 케익 중 마음에 드는 것을 사먹는 것이 효율성면에서 좋을 수도 있다”고 말했다.

쿠버네티스를 직접 상용화해 사용할 경우 또 다른 어려운 점은 기술지원의 문제다. 오픈소스는 쉽게 가져다 쓸 수 있는 반면 기술지원은 뒤따르지 않는다. 쿠버네티스도 마찬가지다. 쿠버네티스는 여러 개의 오픈소스 조합, 구성 조합만 있는 것이 아니다. 모니터링을 위한 ‘프로메테우스’, 컨테이너 저장을 위한 ‘하버’ 등 수많은 요소들이 있다.

이 요소들을 직접 구성해 사용한다 해도 유지보수가 문제다. 가령, 컨테이너 저장을 위한 ‘하버’가 업그레이드 됐는데, ‘적용해야 하는 거 아니냐’라는 이슈가 생기면 그때마다 계속 업그레이드, 테스트 등을 해야 한다.

이에 대해 장민 나무기술 기술 본부장은 “상용 SW 구매에 비용 들어간다고 이를 직접 개발할 수 없는 것처럼 쿠버네티스 역시 오픈소스라는 이유로 직접 상용화에 나설 경우 구매하는 것보다 훨씬 더 많은 비용이 들어갈 수 있다”고 말했다. 그는 이어 “국산이 됐건 외산이 됐건 아직까지는 쿠버네티스를 직접 조합해 쓰기에는 어려움이 있다. 향후 버전이 4.0~5.0으로 업그레이드 되면 혹시 직접 개발하는 시대가 올지 모르겠지만 지금은 아니다”고 덧붙였다.


하둡과는 달라

업계 일각에서는 쿠버네티스의 난이도, 복잡성, 잦은 변화(릴리즈 업데이트) 등으로 인해 상용화된 시장이 활성화되지 못한 ‘하둡’과 비슷한 전철을 밟을 것이라는 시각도 있다. 하지만 대부분 전문가들은 빅데이터라는 일정 영역에 국한됐던 하둡과는 달리 컨테이너는 모든 영역에 스며들 수 있고 시장의 규모부터 차이가 있다는 점을 들어 하둡과는 다르다는 입장을 보이고 있다.

▲ 쿠버네티스의 해외 시장규모 그래프(단위: 억 원)

특히 쿠버네티스를 쉽게 사용하고 관리할 수 있는 다양한 상용화 솔루션들이 출시되고 있어 쿠버네티스가 클라우드 네이티브 아키텍처(CNA), 마이크로 서비스 아키텍처(MSA)의 기반 플랫폼의 표준이 될 것으로 전망되기도 한다.

업계에서는 앞으로 중소기업들은 쿠버네티스를 클라우드 서비스의 매니지드 형태로 제공받을 것으로 예측한다. 사용자 입장에서 쿠버네티스를 직접 개발하는 것보다는 상용화된 제품을 도입하는 것이 효율성과 비용 등의 면에서 훨씬 유리하다는 것이다. 향후 쿠버네티스가 어떻게 발전해 나갈지는 당분간 지켜봐야 할 것으로 보인다.

쿠버네티스 도입 사례

신한금융
아코디언으로 AI/블록체인 인프라 구축

신한금융은 쿠버네티스를 도입하기 이전에는 도커를 이용해 블록체인과 AI를 운영했다. 도커는 베어 메탈기반의 서버에서 운영됐고, 향후 클라우드에 대한 이전을 고려했다. 또한, 지속적인 서비스 요구 사항과 수정사항이 꾸준히 증가했고, 운영자가 수작업으로 관리해 컨테이너 이미지와 애플리케이션이 늘어남에 따라 운영의 어려움이 발생했다.

이로 인해 신한금융은 맨텍에 클라우드까지 확충 가능한 유연한 시스템을 요구했고, 계속적으로 추가되는 서비스에 맞춰 반복적인 애플리케이션 빌드와 배포를 자동화하기를 원했다. 또한 GUI 기반으로 운영자가 쉽게 애플리케이션을 유지 보수하기를 원했으며, 애플리케이션(컨테이너) 모니터링 서비스도 원했다.

맨텍의 아코디언을 도입함으로써 H/W, 가상화, 클라우드 종속성을 탈피할 수 있었고, 원-스톱 구조로 애플리케이션 빌드부터 배포까지 수행할 수 있게 됐다. 또한 웹 UI를 제공해 운영자가 쉽게 노드와 애플리케이션을 관리할 수 있고, 애플리케이션(컨테이너) 모니터링 대시보드도 제공받을 수 있게 됐다.

 

▲ 신한금융, 도입 이전 상황과 아코디언 도입 이후(출처: 맨텍)

 

 

성균관대학교
컨테이너 기반 개발 및 실습환경 구축

성균관대학교는 아코디언 도입 이전에는 주어진 시간 및 장소에서만 개발 리소스를 활용할 수 있는 상황이었다. 또한, 수업 시 개발 환경 구축에 시간을 낭비할 수밖에 없었고, 공유 PC를 사용하기 때문에 수업마다 다시금 개발 환경을 새롭게 구축해야만 했다.

이에 성균관대학교는 외부에서도 접근할 수 있는 환경을 원했으며 H/W, OS 종속성 탈피 및 향후 외부 클라우드 이식하는 등 다양한 요구사항을 제시했다. 또 다양한 개발 환경 및 SW 이미지의 제공, 실습에 참여하는 학생들에게 개별적으로 개발 환경을 제공하고자 맨텍의 아코디언을 도입했다.

도입 결과 개발 환경 구축 시간이 2일간 소요되던 것을 5분으로 단축시켰고, 외부 클라우드로 이식할 때에는 마이그레이션을 별도로 할 필요가 없어졌다. 특히, 멀티 테넌시 지원으로 개별 학생들에게 맞춤형 서비스를 제공할 수 있게 됐고, 중앙 집중환경으로 자원 할당과 회수, VM 대비 직접도가 40배가량 향상됐다.

 

▲ 성균관대학교 도입 이전 상황과 아코디언 도입 이후(출처: 맨텍)
저작권자 © 컴퓨터월드 무단전재 및 재배포 금지