[1부] 국제표준문서에서 컨테이너의 기능적 요구 사항 > 기술/보안

상명대학교 / 서광규 교수

최근의 클라우드 시장은 ‘멀티 클라우드’가 부상하고 있는 가운데, 컨테이너 기반 클라우드가 보편화되고 있으며, 퍼블릭 클라우드의 ‘PaaS’ 서비스가 늘어나고 있다.

컨테이너는 이미 클라우드의 가장 중요한 요소로 자리잡고 있는데, 쿠버네티스에 의한 컨테이너 오케스트레이션은 클라우드 작동의 기본이자, CSP의 필수 조건이기도 하다.

글로벌 시장에서는 AWS, MS, 구글 외에도 레드햇의 오픈시프트(OpenShift), 도커 스웜(Swarm), SUSE 랜처(Rancher) 등도 많이 사용하고 있으며 퍼블릭 클라우드의 쿠버네티스 서비스로 많이 전환하고 있는 것도 최근의 추세다.

컨테이너 및 VM(가상 머신)은 다양한 IT 요소를 결합해 시스템의 나머지 부분으로부터 격리하는 패키징된 컴퓨팅 환경으로 이 둘은 확장 방식 및 이식성에서 큰 차이가 있다.

컨테이너는 일반적으로 크기가 메가바이트 단위이다. 앱보다 크거나 실행하는 데 필수적인 모든 파일이 컨테이너에 패키징되는 것은 아니며, 특정 작업을 수행하는 단일 기능(마이크로서비스)이 컨테이너에 패키징되는 경우가 많다.

컨테이너는 경량화 속성과 공유 운영 체제(OS)로 인해 여러 환경 간에 매우 쉽게 이동할 수 있다. 반면에 VM은 일반적으로 크기가 기가바이트 단위이다.

일반적으로 VM은 자체 OS를 포함하고 있어 리소스 집약적인 기능 여러 개를 동시에 수행할 수 있다. VM에서 사용할 수 있는 리소스가 늘어남에 따라 VM은 전체 서버, OS, 데스크탑, 데이터베이스, 네트워크를 추상화, 분할, 복제, 에뮬레이션할 수 있다.

컨테이너는 특성상 작고 가벼워 퍼블릭, 프라이빗, 하이브리드 및 멀티클라우드 환경뿐 아니라 베어 메탈 시스템 간에도 쉽게 이동할 수 있다.

또한 퍼블릭, 프라이빗, 하이브리드 및 멀티클라우드 환경 전반에 걸쳐 일관된 개발 및 자동 관리 환경을 제공하기 위해 설계된 마이크로서비스 컬렉션, 즉 오늘날의 클라우드 네이티브 애플리케이션을 배포하기에 이상적인 환경이다.

클라우드 네이티브 애플리케이션을 사용하여 새 애플리케이션이 빌드 방법, 기존 애플리케이션이 최적화 방법, 이 모든 애플리케이션 연결 방법을 가속화할 수 있다. 주의할 점은 컨테이너가 기본 OS와 호환되어야 한다는 것이다.

또한 클라우드 환경에서 PaaS(Plaform as a Service)의 사용도 확산되고 있는데, PasS의 형태라고 볼 수 있는 CaaS(Container-as-a-Service)의 사용도 늘어나고 있다.

CaaS(서비스형 컨테이너)는 가상화된 애플리케이션, 클러스터 및 컨테이너를 관리하여 더 빠르고 쉽게 배포할 수 있는 방법을 조직에 제공하는 클라우드 기반 종량제 서비스이다.

CaaS 공급자는 본질적으로 조직의 컨테이너 간에 인프라를 실행하고 유지하는 컨테이너 오케스트레이션 엔진을 호스팅한다.

사용자는 컨테이너 기반 가상화, API 호출 또는 웹 포털 인터페이스를 통해 이 서비스에 액세스할 수 있다. 이 서비스는 VM(가상 시스템)이나 베어 메탈 호스트 시스템 대신 컨테이너를 통해 제공되기 때문에 조정이 더 쉽고 배포 속도도 더 빠르다.

CaaS의 각 컨테이너에는 네트워크 프로토콜 관계가 이미 정의된 자체 운영 체제와 코드 기반이 있기 때문에 특히 마이크로 애플리케이션을 배포하는 경우 CaaS가 적합한데, 이를 통해 거의 즉각적인 배포가 가능하다.

또한 CaaS에는 자동 조정 및 오케스트레이션 관리 기능이 내장되어 있어 컨테이너 성능 추적이 기본적으로 아웃소싱되어 IT 직원이 배포에 소요하는 시간이 단축된다.

CaaS가 중요한 이유는 소프트웨어 개발 팀과 IT 부서에서 수행 가능해진 작업 때문이다. 아울러 CaaS를 이용하여 수행할 필요가 사라진 작업 또한 중요한 이유 중 하나이다.

CaaS가 대두되기 전, 소프트웨어 개발에는 시장 출시 프로세스의 일부로 인프라 관리가 포함되었다. DevOps 팀은 컨테이너가 실행되는 기본 인프라에 신경 써야 했다.

이는 클라우드 시스템과 네트워크 라우팅 시스템을 감독하고 관리하는 전담 인력이 담당했다. CaaS의 등장으로 전담 인력이 이러한 작업에서 벗어났으며 컨테이너를 배포하기 전에 컨테이너 인프라를 구축하고 테스트하던 IT 인력과 DevOps의 시간 또한 절약할 수 있다.

또한 CaaS는 복잡한 클라우드 컴퓨팅과 추가 구성을 단순화해야 하는 DevOps의 부담을 덜어주게 된다.

본 고에서는 클라우드 네이티브에 대한 요구사항이 증가하고 있고 이를 위해 중요한 기술 요소인 컨테이너를 살펴보기 위해 국제 표준화 문서인 ITU-T Y.3535: Cloud computing ? Functional requirements for a container에서 제시하고 개념 및 기술적 측면을 포함한 컨테이너 개요, 클라우드 컴퓨팅의 컨테이너, 컨테이너의 기능적 요구사항 그리고 컨테이너의 사용 사례에 대하여 기술하기로 한다.

1. 컨테이너 개요

1-1. 컨테이너의 개념

컨테이너를 사용하면 소프트웨어 개발자가 컨테이너 이미지를 사용하여 애플리케이션을 신속하게 개발하고 배포할 수 있다. 컨테이너는 호스트 운영 체제(OS) 위에서 애플리케이션을 실행하며, 애플리케이션을 실행하는 데 필요한 만큼 호스트의 리소스를 사용하기 때문에 가상 머신(VM)보다 적은 리소스가 필요한다. 컨테이너는 또한 다음과 같이 애플리케이션의 가상화 처리를 위한 격리, 리소스 제어 및 이식성을 제공한다.

격리: 컨테이너는 호스트의 다른 애플리케이션과 컨테이너를 격리하는 데 사용되는 각 애플리케이션에 별도의 커널 공간과 개별 프로세서를 할당한다.
리소스 제어: 리소스를 제어하기 위해 컨테이너는 리소스를 할당하는 네임스페이스를 설정한다.

※ 참고 1 - 네임스페이스에는 네트워크 네임스페이스, 프로세서 네임스페이스, 마운트 네임스페이스 및 사용자 네임스페이스가 포함된다. 네임스페이스는 프로세스가 실행 중일 때 시스템 리소스를 격리한다. 또한 네임스페이스는 각 컨테이너에 독립적인 공간을 제공하고 커널 시스템의 다른 컨테이너와의 충돌을 방지한다.

이식성: 소프트웨어 개발자가 개발한 컨테이너 이미지는 애플리케이션 전체 또는 일부에 의해 구축된다. 컨테이너 이미지를 사용하려면 컨테이너 레지스트리에 푸시되어 다른 호스트와 공유하여 이식성을 지원한다. 컨테이너 레지스트리에 업로드된 컨테이너 이미지를 가져와서 실행한다.

그림 1은 컨테이너에 대한 애플리케이션, 컨테이너 이미지, 컨테이너 레지스트리의 사용법을 보여준다. 베어메탈 서버의 OS 또는 VM의 게스트로 OS가 호스트에 포함된다.

[그림1. 컨테이너에 대한 애플리케이션, 컨테이너 이미지 및 컨테이너 레지스트리 사용]

그림 1의 컨테이너 레지스트리는 컨테이너 엔진이 컨테이너 이미지를 저장하고 액세스하기 위한 컨테이너 이미지 저장소이다. "푸시"는 컨테이너 이미지를 컨테이너 레지스트리의 호스트에 업로드하는 것을 의미하고 "풀"은 컨테이너 레지스트리에서 컨테이너 이미지를 다운로드하는 것을 의미한다.

※ 참고 2 - 컨테이너 레지스트리에는 로컬 레지스트리, 개인 레지스트리 및 공용 레지스트리가 포함된다.

※ 참고 3 ? 컨테이너 레지스트리는 마스터-슬레이브 아키텍처 형태로 작동한다. 마스터 레지스트리에는 슬레이브 레지스트리에 액세스하기 위한 인증 및 권한이 있다. 마스터 레지스트리는 두 레지스트리 간의 이미지 동기화 구성 및 업데이트도 지원한다.

1-2. PaaS 소개

1-2-1. 컨테이너 엔진

컨테이너 엔진은 격리된 커널 공간에 있는 컨테이너 이미지의 실행을 관리하는 커널 프로세스 그룹이다. 컨테이너 엔진은 다음과 같은 주요 기능을 제공한다.

컨테이너 이미지에서 애플리케이션 실행
격리된 커널 공간 구성 및 보안 프로세스

컨테이너 엔진은 애플리케이션별로 독립된 환경을 위해 격리된 커널 공간을 구성한다. 격리된 커널 공간은 네임스페이스로 논리적으로 구분된다. 격리된 커널 공간은 리소스 할당, 파일 시스템 마운트 또는 마운트 해제, 독립 프로세스 및 네트워크 할당을 제공한다.

컨테이너에서 애플리케이션을 실행하기 위해 컨테이너는 다음과 같이 작동한다.

컨테이너 레지스트리에서 컨테이너 이미지를 가져온다.
컨테이너 이미지를 파일 시스템으로 압축 해제한다.
파일 시스템 소유권을 설정한다.
커널 프로세스를 사용하여 애플리케이션을 실행한다.
사용자 액세스를 위해 애플리케이션의 외부 링크를 노출한다.

격리된 커널 공간의 구성에는 다음이 포함된다.

컨테이너 이미지에 대한 컨테이너 파일 시스템의 디렉터리를 설정한다.
메모리 제한, 중앙 처리 장치(CPU) 및 장치 액세스를 설정한다.
리소스에 대한 애플리케이션 고유의 네임스페이스를 생성한다.
허용되지 않는 시스템 호출을 방지하도록 구성한다.
프로세서의 보안 액세스를 설정한다.

격리된 커널 공간은 프로세스 간 독립적인 통신 경로 할당을 지원하고 독립적인 호스트 이름과 사용자를 할당한다.

1-2-2. 컨테이너 이미지

컨테이너 이미지는 컨테이너용 애플리케이션을 실행하도록 구성된 소프트웨어 패키지이다. 컨테이너 이미지에는 다음이 포함된다.

이미지 객체: 컨테이너 파일 시스템의 계층별 라이브러리, 파일 시스템, 바이너리를 포함하여 애플리케이션을 실행하기 위한 파일 그룹

※ 참고 1 ? 이미지 객체는 보관 및 압축 형식으로 제공된다.

이미지 매니페스트: 파일 시스템 및 OS에 따른 컨테이너 이미지의 계층 구조에 대한 정보

※ 참고 2 ? 이미지 매니페스트는 매니페스트의 스키마 버전, 미디어 유형, 이미지 크기 및 이미지 식별을 제공한다.

컨테이너 파일: 실행 명령, 리소스 정보, 서비스 포트, 사용자, 호스트 머신의 아키텍처 및 파일 시스템 변경과의 관계 등 컨테이너 엔진에서 사용되는 컨테이너 이미지에 대한 정보

[그림2. 컨테이너 이미지의 예]

1-2-3. 컨테이너 파일 시스템

컨테이너 파일 시스템은 컨테이너당 디렉터리와 파일로 구성된다. 컨테이너 이미지를 사용하기 위해 컨테이너 파일 시스템도 컨테이너 엔진에 의해 관리된다.

※ 참고 ? 컨테이너 파일 시스템은 메인 메모리, SSD(Solid-State Drive), 하드 디스크 드라이브와 같은 호스트의 저장 장치에 제공된다.

그림 3에서 컨테이너 파일 시스템은 디렉터리로 구성된 레이어를 제공한다. 컨테이너 이미지는 컨테이너 계층과 이미지 계층의 디렉터리에 있다. 애플리케이션은 컨테이너 계층과 이미지 계층의 단일 디렉터리에 탑재된 병합된 계층의 컨테이너 이미지를 사용한다.

이미지 레이어: 컨테이너 저장소의 이미지를 제공한다. 이 레이어의 이미지는 디스크 공간을 절약하기 위해 병합된 레이어와 공유된다. 애플리케이션은 읽기 전용 액세스 권한으로 이미지 계층의 컨테이너 이미지에 액세스한다.
컨테이너 계층: 각 컨테이너의 디렉터리를 제공한다. 애플리케이션은 읽기 및 쓰기 액세스 권한으로 컨테이너 계층의 컨테이너 이미지에 액세스한다.
병합된 레이어: 컨테이너 레이어와 이미지 레이어에 있는 모든 파일의 링크를 애플리케이션에 제공한다. 이 계층을 사용하면 애플리케이션별로 모든 파일에 액세스할 수 있다.

[그림3. 컨테이너용 파일 시스템의 예]

컨테이너 파일 시스템에서 컨테이너 이미지를 통합하기 위해 컨테이너 계층과 이미지 계층의 하위 디렉터리가 상위 파일 시스템 디렉터리에 병합되도록 탑재되어 애플리케이션에서 컨테이너 이미지에 논리적으로 액세스할 수 있다.

컨테이너 파일 시스템은 시스템에서 로컬로 공유되는 전체 파일 시스템에 대한 컨테이너 이미지 검색도 제공한다.

이미지 계층의 컨테이너 이미지는 컨테이너가 실행될 때 컨테이너 레지스트리에 의해 저장된다.

스토리지의 경우 애플리케이션이 컨테이너를 사용할 때 컨테이너 레지스트리의 컨테이너 이미지를 컨테이너 엔진이 로컬로 가져온다. 또한 더 나은 성능을 위해 실행 전에 컨테이너 이미지가 저장된다.

컨테이너 이미지를 가져오면 애플리케이션에서 재사용되며 이미지 계층으로 다시 가져오지 않다.

이미지 레이어의 컨테이너 이미지로 인해 파일 시스템의 용량이 초과되면 컨테이너 이미지를 다른 디스크에 저장하거나 원격으로 백업한다.

1-2-4. 컨테이너 관 시스템

컨테이너 관리 시스템(CMS)은 그림 4와 같이 단일 컨테이너는 물론 여러 컨테이너도 관리한다.

단일 컨테이너용 CMS: CMS는 컨테이너 애플리케이션 프로그래밍 인터페이스(API)를 통해 컨테이너의 실행, 버전 관리, 구성, 네트워킹 등 컨테이너 작업을 관리하는 역할을 담당한다.
다중 컨테이너용 CMS: CMS는 응용 프로그램이 여러 호스트의 컨테이너에 배포된 경우 여러 호스트 OS의 컨테이너를 관리하는 역할을 한다. CMS는 여러 컨테이너가 동시에 사용되는 경우 컨테이너를 분산 시스템 및 클러스터로 확장하는 것을 지원한다.

[그림4. 컨테이너 관리 시스템의 개념]

CMS는 다음과 같이 컨테이너 수명주기 관리, 로드 밸런싱 및 스케줄링, 컨테이너 클러스터링, 모니터링, 확장 및 컨테이너에 대한 애플리케이션 검색을 담당한다.

수명주기 관리: CMS는 생성, 일시 중지, 재개, 다시 시작, 구성 설정 등 컨테이너의 전체 수명주기를 관리한다.
로드 밸런싱 및 예약: CMS는 배포가 안정적이도록 애플리케이션에 대한 네트워크 트래픽을 분산한다. 컨테이너의 확장성과 가용성을 극대화하는 데 효과적이다.
컨테이너 클러스터링: CMS는 여러 컨테이너를 그룹화하여 클러스터를 생성한다. 클러스터는 여러 컨테이너를 논리적으로 연결하여 안정적인 응용 서비스 제공을 가능하게 한다. CMS는 클러스터 내에서 작동하지 않는 컨테이너를 교체하거나 다시 시작한다.
모니터링: CMS는 컨테이너 및 클러스터의 상태를 모니터링한다. 컨테이너의 가용성과 컨테이너의 리소스 소비(CPU, 메모리, 스토리지 등)를 모니터링한다.
확장: CMS는 서비스 워크로드에 따라 컨테이너를 클러스터로 확장하는 것을 지원한다.
애플리케이션 검색: CMS는 컨테이너에서 실행 중인 애플리케이션과 컨테이너의 위치를 찾는다.

참 고 문 헌

ITU-T Y.3535 (2022) Cloud computing ? Functional requirements for a container
ITU-T Y.3532 (2023) Cloud computing - Functional requirements of Platform as a Service for cloud native applications
ITU-T X.1601 (2015) Security framework for cloud computing

저작권 정책

기술/보안

지식정보

[1부] 국제표준문서에서 컨테이너의 기능적 요구 사항