[한국클라우드신문=이수현 기자] 오늘날 조직은 애플리케이션을 배포·관리해야 하는 끊임없는 도전에 직면해 있다. 컴퓨팅만큼이나 오래된 과제다. 그러나 오늘날 개발자와 비즈니스 리더가 고려해야 할 대안은 어느 때보다 많다. 새롭게 떠오르는 두 가지 대안은 '서비스형 플랫폼(PaaS)'과 '컨테이너'다. 둘 다 기본 기술과 사용 사례 측면에서 크게 다르지만, 겹치는 부분도 늘고 있다.

◇PaaS와 컨테이너의 차이점은 무엇인가?

PaaS는 조직이 특정 작업 세트를 수행하는 데 쓸 수 있는 클라우드 기반 애플리케이션 제품군이다. PaaS는 코딩, 테스트, 패키징, 배포처럼 소프트웨어 개발 작업과 가장 자주 연관된다. PaaS 공급자가 모든 소프트웨어 도구의 배포, 관리, 업데이트를 처리하기 때문에 조직은 로컬 인프라 및 지원 요소를 제거해 IT 환경을 이상적으로 단순화할 수 있다.

컨테이너는 조직이 코드를 실행할 수 있게 해주는 일종의 가상 엔터티다. 일반적으로 더 작은 응용 프로그램 또는 모듈식 소프트웨어 구성 요소 형태를 취한다. 컨테이너는 공통 OS를 공유하고 빠른 스핀업, 시작 및 중지 시간을 제공한다. 또 가상화하고 확장성이 높으며 고도로 조정된 엔터프라이즈 워크로드를 실행하는 것을 빠르고 편하게 만든다.

언뜻 보기에는 PaaS와 컨테이너 사이에 직접적인 관계가 없어 보인다. 그러나 이야기는 여기서 끝이 아니다.

◇PaaS와 컨테이너는 어떻게 사용되나?

조금 더 자세히 살펴보면 컨테이너가 PaaS에서 중요한 역할을 하는 경우가 많다는 것을 알게 된다. PaaS는 사용자가 내부에서 작업할 수 있는 소프트웨어 도구를 생성하며, 일반적으로 PaaS를 사용하면 사용자가 무엇을 생성하든 웹 애플리케이션 및 맞춤형 서비스를 배포할 수 있다.

그러나 이런 배포에는 컴퓨팅 및 스토리지 리소스를 프로비저닝·구성하기 위한 몇 가지 기본 메커니즘이 필요하다. PaaS 제공 업체는 모든 배포·확장 프로세스를 처리하기 위해 IT 직원을 사용하는 대신 효율적이고 고도로 자동화한 인프라를 선택할 것이다. 쉽게 말해 PaaS는 보통 PaaS 소프트웨어 배포를 위해 컨테이너를 사용한다.

따라서 도커 엔진에서 실행되는 것과 같은 컨테이너는 현대 PaaS의 중심 빌딩 블록 및 활성화 요소로 간주될 때가 많다. 

컨테이너는 PaaS에 국한되지 않는다. 조직은 종종 동일한 이점을 위해 로컬 데이터 센터의 컨테이너를 사용한다. 이는 사용자가 컨테이너에서 애플리케이션을 쉽게 배포하고 생성할 수 있도록 한다. 그뿐만 아니라 로컬 컨테이너는 도커, 아파치 메소스 혹은 다른 컨테이너 엔진과 같은 기존 서비스에 의존해 컨테이너를 지원하면서 쿠버네티스처럼 오케스트레이션 엔진을 사용해 컨테이너 배포·관리와 관련된 많은 작업을 자동화한다.

◇서비스형 컨테이너(CaaS)란 무엇인가?

PaaS 기술은 셀 수 없이 많은 유형의 플랫폼을 가능하게 한다. 대다수의 플랫폼은 소프트웨어 개발 같은 활동에 중점을 두며, 플랫폼에서 만든 응용 프로그램을 시작·호스팅하도록 설계된 다양한 배포 메커니즘을 포함한다. 이런 배포 메커니즘은 기본 애플리케이션 배포 인프라를 제공하기 위해 컨테이너에 의존하는 경우가 많다.

하지만 이런 사용 사례는 상대적으로 좁고, PaaS 공급자는 기본 OS와 같은 모든 컨테이너에 대한 환경을 설정한다. 오늘날 점점 더 많은 플랫폼이 서비스형 컨테이너(CaaS) 형태의 배포 메커니즘으로서 '컨테이너'에 특히 중점을 둔다. 따라서 CaaS는 컨테이너화한 소프트웨어의 자동화한 배포 및 호스팅을 처리한다. CaaS 공급자는 컨테이너와 기본 배포 환경을 배포·관리·모니터링하는 데 필요한 인프라와 엔진을 제공한다. CaaS는 이런 맥락에서 PaaS의 특정 유형이나 하위 집합으로 제공된다.

CaaS 오퍼링을 생성하는 데 사용되는 메커니즘은 다른 유형의 PaaS를 통해 컨테이너에서 소프트웨어 배포를 지원하는 데 쓰이는 메커니즘과 거의 같다. 그러나 CaaS는 사용 가능한 옵션과 컨테이터 환경의 잠재적 정교함을 확장하고, CaaS에 배포된 각 컨테이너가 다른 OS 및 기타 종속성을 캡슐화하는 마이크로서비스 애플리케이션처럼 복잡한 컨테이너 환경에 더 적합할 수 있다.

즉 목표가 소프트웨어를 개발하고 배포하는 것이라면 PaaS가 더 나은 선택일 수 있다. 반면 목표가 많은 수의 컨테이너를 복잡한 배열로 배포·관리하는 것이라면 CaaS가 더 나을 수 있다.

◇PaaS의 장단점

PaaS는 다양한 프로젝트를 빠르게 시작·지원할 수 있어 많은 조직에 매력적이다. 조직은 이런 도구, 리소스 및 기타 인프라를 만들고 유지 관리하는 데 드는 비용이나 복잡성 없이 최상위 도구 및 리소스에 뛰어들어 액세스할 수 있다. 조직은 기본 인프라를 제공하지 않고도 핵심 비즈니스와 역량에 집중할 수 있다. 따라서 PaaS의 이점은 다음과 같다.

•시간 절약: 조직은 몇 분 만에 PaaS 사용을 시작할 수 있다.

•비용 절감: 조직은 환경을 만드는 데 필요한 소프트웨어 및 하드웨어 비용을 절감한다.

•시장 출시 시간 단축: 시간·비용을 절약하면 앱과 기타 플랫폼을 더 빨리 출시해 조직에 가치를 더할 수 있다.

•유연성 : 조직은 종종 PaaS 제품을 사용자 지정하고 사용자 지정 도구를 추가, 연결할 수 있다.

•확장성: PaaS 리소스 및 인프라는 비즈니스 요구 사항에 맞게 확장될 수 있다.

•관리성 : PaaS 제공자는 인프라를 관리하고 도구·서비스를 유지 관리한다.

또 PaaS는 아래와 같이 조직이 고려해야 하는 여러 잠재적 문제 및 단점을 제시한다.

•공급 업체 로드맵: PaaS는 공급 업체가 제공하는 일련의 기능·서비스로 정의되므로 필요한 기능이 없거나, 제공 속도가 느리거나, 대안이 거의 없어 쓰이지 않을 수 있다.

•공급 업체 종속 : 조직은 PaaS와 공급자에게 의존하게 된다. 다른 PaaS 제공 업체로 마이그레이션하는 것은 어렵거나 불가능할 수 있다.

•호환성 문제 : PaaS는 다른 개발 도구 또는 플랫폼과 호환되지 않을 수 있다.

◇컨테이너의 장단점

VM과 마찬가지로 가상 컨테이너는 조직 및 애플리케이션 개발자에게 아래와 같은 다양한 이점을 제공한다.

•속도와 확장성 : 컨테이너는 작은 가상 인스턴스이며 빠르게 나타나거나 사라질 수 있다. 같은 인프라에 훨씬 더 많은 컨테이너를 허용하고, 변화하는 운영 조건에 빠르게 조정할 수 있다.

•일관성 : 컨테이너에서 실행되는 이미지 파일에는 코드를 실행하는 데 필요한 모든 구성 요소와 종속성이 포함돼 컨테이너를 어디서나 적합한 컨테이너 환경에서 운영할 수 있다.

•오토메이션 : 컨테이너는 너무 많고 일시적이기 때문에 컨테이너 환경을 효과적으로 관리하기 위해 어떤 형태의 자동화 및 오케스트레이션이 필요하다. 쿠버네티스 같은 도구는 이런 작업을 지원하기 위해 즉시 사용할 수 있다.

그러나 컨테이너는 완벽하지 않으며 컨테이너 작업을 선택하는 조직은 아래처럼 몇 가지 단점과 싸워야 한다.

•컨테이너 복잡성 : 컨테이너는 애플리케이션 코드와 종속성 배열을 포함하는 이미지 파일이다. 이 모든 것은 컨테이너 이미지를 배포하기 전에 구성 및 패키지화돼야 한다. 모든 변경 사항은 이미지를 업데이트하고, 다시 패키징해야 하며 종종 재배포된다. 이에 컨테이너 사용은 기존 VM보다 더 복잡해질 수 있다.

•운영 복잡성 : 일반적인 데이터 센터 환경에서 존재할 수 있는 컨테이너의 양은 수천개로 쉽게 셀 수 있으므로 컨테이너 관리·모니터링이 특히 중요하고 어렵다.

•보안 : 컨테이너의 핵심 문제 가운데 하나는 모든 컨테이너가 공유하는 공통 OS다. OS의 취약점·결함은 해당 시스템에서 실행되는 컨테이너를 잠재적으로 위험에 빠뜨릴 수 있다.

◇PaaS와 컨테이너 중에서 선택하는 방법

PaaS와 컨테이너 사이의 선택은 보통 의도적이 아니다. 컨테이너는 많은 PaaS 제품에 대한 일반적인 배포 수단이다. PaaS를 선택할 때 컨테이너 사용은 불가피할 수 있다. 다행히 대부분의 PaaS 제공 업체는 컨테이너 인프라를 단순화·자동화하는 데 큰 진전을 이뤘다. 컨테이너를 사용하는 PaaS는 비즈니스 사용자에게 속도와 편의성이 최우선 순위일 때 종종 가장 빠르고 쉬운 선택이다.

통제와 감독이 조직의 최우선 과제라면 PaaS를 포기하고 로컬 데이터 센터에 컨테이너 인프라를 구축하는 것이 더 합리적일 수 있다. 이를 위해서는 도커와 같은 기본 컨테이너 엔진과 쿠버네티스와 같은 자동화 및 오케스트레이션 도구를 시작으로 컨테이너 기술에 대한 상당한 전문 지식을 갖춘 IT 지원이 필요하다. 내부 컨테이너는 의심할 여지 없이 더 복잡하고 비용이 많이 들지만, 비즈니스 요구 사항과 목표에 따라 필요할 수 있다.

CaaS는 조직이 컨테이너 지원과 관련된 인프라 및 소프트웨어 플랫폼의 대부분을 제거하면서, 크고 복잡한 컨테이너 배포에 컨테이너 서비스를 사용할 수 있도록 하는 세 번째 선택을 제시한다. CaaS는 조직에 PaaS의 속도와 확장성이 필요할 때 적합한 선택이 될 수 있지만, 관건은 컨테이너 및 컨테이너 기반 애플리케이션 배포다.

늘 그렇듯 IT·비즈니스 리더는 기술, 공급자에 대해 약속하기 전 모든 대안의 요구 사항, 비용, 안정성, 가용성, 이식성, 특징 및 기능을 이해하는 것이 중요하다.

◇PaaS와 컨테이너의 미래는 무엇인가?

조직은 앞으로 몇 년 동안 컨테이너, 클라우드 및 클라우드 플랫폼 간 긴밀한 관계를 기대할 수 있다. 다음과 같은 현재 관계를 고려해야 한다.

•현재 PaaS는 일반적으로 클라우드를 통해 제공되거나 공용 클라우드로 구축된다.

•컨테이너는 최신 애플리케이션 구성 요소를 위한 빠르고 동적인 배포 메커니즘을 제공할 수 있다.

•컨테이너는 많은 PaaS 제품의 필수 요소다.

•퍼블릭 클라우드는 이미 컨테이너 배포 및 관리에 적합하다.

•퍼블릭 클라우드는 이미 컨테이너 관리 및 오케스트레이션을 서비스로 제공한다.

시간이 지나면서 더 많은 조직이 핵심 비즈니스 활동에 집중하기 위해 IT 인프라를 줄이고 비용을 관리하려고 하고 있다. 결국 이 세 기술 간 구분은 흐려지고, 훗날 구별할 수 없거나, 관련이 없게 될 것이다.