컨테이너화란 무엇인가요?

가상 머신(VM)보다 이식성이 뛰어나고 리소스 효율성이 뛰어난 컨테이너는 최신 클라우드 네이티브 애플리케이션의 사실상 컴퓨팅 단위로 자리 잡았습니다.

컨테이너화를 통해 개발자는 애플리케이션을 더 빠르고 안전하게 만들고 배포할 수 있습니다. 기존 방식에서는 개발자가 특정 컴퓨팅 환경에서 코드를 작성하기 때문에 새로운 위치로 옮길 때 버그와 오류가 발생하는 경우가 많습니다. 예를 들어 개발자가 데스크톱 컴퓨터에서 가상 머신으로 코드를 전송하거나 Linux® 에서 Windows 운영 체제로 코드를 전송할 때 이러한 상황이 발생할 수 있습니다. 컨테이너화는 애플리케이션 코드를 실행하는 데 필요한 관련 구성 파일, 라이브러리 및 종속성과 함께 번들로 묶어 이 문제를 해결합니다. 이 단일 소프트웨어 패키지 또는 '컨테이너'는 호스트 운영 체제에서 분리되어 있습니다. 따라서 독립형으로 사용할 수 있으며 이식성이 뛰어나 문제 없이 모든 플랫폼 또는 클라우드에서 실행할 수 있습니다.

컨테이너화와 프로세스 격리의 개념은 수십 년 전부터 존재해왔습니다. 그러나 2013년에 간단한 개발자 도구와 범용 패키징 접근 방식을 갖춘 컨테이너의 업계 표준인 오픈 소스 Docker가 등장하면서 이 기술의 채택이 가속화되었습니다. 오늘날 기업들은 새로운 애플리케이션을 만들고 기존 애플리케이션을 클라우드용으로 현대화하기 위해 컨테이너화를 점점 더 많이 사용하고 있습니다.

Forrester¹의 보고서에 따르면 미국 인프라 의사 결정권자의 74%가 온프레미스 또는 퍼블릭 클라우드 환경의 서비스형 플랫폼(PaaS) 내에서 컨테이너를 도입하고 있다고 답했습니다.

컨테이너는 '경량'이기 때문에 머신의 운영 체제 커널을 공유하며 각 애플리케이션 내에서 운영 체제를 연결해야 하는 오버헤드가 필요하지 않습니다. 컨테이너는 본질적으로 VM보다 용량이 작고 시작 시간이 짧습니다. 이 기능을 사용하면 단일 VM과 동일한 컴퓨팅 용량에서 훨씬 더 많은 컨테이너를 실행할 수 있습니다. 이 기능은 서버 효율성을 높이고 결과적으로 서버 및 라이선스 비용을 절감합니다.

가장 중요한 것은 컨테이너화를 통해 온프레미스 데이터 센터, 하이브리드 클라우드 및 멀티클라우드 환경 전반에서 애플리케이션을 '한 번 작성하면 어디서나 실행'할 수 있다는 점입니다.

이러한 이식성은 개발 속도를 높이고, 클라우드 공급업체 종속을 방지하며, 오류 격리, 관리 용이성, 보안 간소화 등과 같은 다른 주목할 만한 이점을 제공합니다.

다음 동영상에서 컨테이너화에 대한 자세한 설명을 확인할 수 있습니다.

컨테이너화 아키텍처는 네 가지 필수 구성 요소 계층으로 구성됩니다.

컨테이너는 애플리케이션을 실행하는 데 필요한 모든 관련 구성 파일, 라이브러리 및 종속성과 함께 애플리케이션 코드를 하나의 실행 가능한 소프트웨어 패키지로 묶어 캡슐화합니다.

컨테이너화된 애플리케이션은 '격리'되어 있으므로 운영 체제의 복사본에 번들로 제공되지 않습니다. 대신, 호스트의 운영 체제에 오픈 소스 컨테이너 런타임 또는 컨테이너 엔진(예: Docker 런타임 엔진)이 설치되어 컨테이너가 동일한 컴퓨팅 시스템의 다른 컨테이너와 운영 체제를 공유하는 통로가 됩니다.

공통 바이너리(bin) 및 라이브러리와 같은 다른 컨테이너 계층은 여러 컨테이너 간에 공유할 수 있습니다. 이 기능은 각 애플리케이션 내에서 운영 체제를 실행하는 오버헤드를 제거하고 컨테이너의 용량을 VM보다 더 작게 만들고 더 빠르게 시작할 수 있도록 하여 서버 효율성을 높입니다. 애플리케이션을 컨테이너로 격리하면 한 컨테이너의 악성 코드가 다른 컨테이너에 영향을 미치거나 호스트 시스템에 침입할 가능성도 줄어듭니다.

호스트 운영 체제에서 분리된 덕분에 컨테이너화된 애플리케이션은 이동성이 뛰어나며 모든 플랫폼이나 클라우드에서 균일하고 일관되게 실행할 수 있습니다. 컨테이너는 데스크톱 컴퓨터에서 가상 머신(VM)으로 또는 Linux에서 Windows 운영 체제로 쉽게 이동할 수 있습니다. 또한 컨테이너는 온프레미스 또는 클라우드 데이터센터의 가상화된 인프라 또는 기존 베어메탈 서버에서도 일관되게 실행됩니다.

컨테이너화를 통해 소프트웨어 개발자는 애플리케이션이 기존 모놀리스(단일 계층 소프트웨어 애플리케이션)이든 마이크로서비스 아키텍처를 기반으로 구축된 모듈식 애플리케이션이든 관계없이 애플리케이션을 더 빠르고 안전하게 생성하고 배포할 수 있습니다. 개발자는 새로운 클라우드 기반 애플리케이션을 처음부터 컨테이너화된 마이크로서비스로 구축하여 복잡한 애플리케이션을 일련의 더 작고 전문화되고 관리 가능한 서비스로 나눌 수 있습니다. 또한 기존 애플리케이션을 컴퓨팅 리소스를 보다 효율적으로 사용하는 컨테이너(또는 컨테이너화된 마이크로서비스)로 다시 패키징할 수 있습니다.

컨테이너는 종종 가상 머신(VM)과 비교되는데, 두 기술 모두 여러 유형의 소프트웨어(Linux 또는 Windows 기반)를 단일 환경에서 실행할 수 있도록 하여 컴퓨팅 효율성을 크게 높여주기 때문입니다. 

가상화는 물리적 컴퓨터나 서버에 배치된 소프트웨어 계층인 하이퍼바이저를 활용하여 물리적 컴퓨터가 운영 체제와 애플리케이션을 하드웨어에서 분리할 수 있도록 합니다. 가상화 기술을 사용하면 여러 운영 체제와 소프트웨어 애플리케이션을 동시에 실행하고 단일 물리적 컴퓨터 또는 호스트 시스템의 리소스(예: CPU, 스토리지 및 메모리)를 공유할 수 있습니다. 예를 들어, IT 조직은 동일한 서버에서 다양한 애플리케이션과 함께 Windows와 Linux 또는 여러 버전의 운영 체제를 모두 실행할 수 있습니다.

각 애플리케이션과 관련 파일 시스템, 라이브러리 및 기타 종속성(운영 체제(OS) 복사본 포함)은 VM으로 함께 패키징됩니다. 단일 물리적 시스템에서 여러 VM을 실행하면 자본, 운영 및 에너지 비용을 크게 절감할 수 있습니다.

반면 컨테이너화는 컴퓨팅 리소스를 훨씬 더 효율적으로 사용합니다. 컨테이너는 애플리케이션 코드를 실행하는 데 필요한 모든 종속성과 함께 번들로 묶는 하나의 실행 가능한 소프트웨어 패키지를 만듭니다. 그러나 VM과 달리 컨테이너는 OS의 복사본에 번들로 제공되지 않습니다. 대신 컨테이너 런타임 엔진은 호스트 시스템의 운영 체제, 즉 '호스트 OS'에 설치되어 컴퓨팅 시스템의 모든 컨테이너가 동일한 OS를 공유하는 통로가 됩니다.

컨테이너는 흔히 '경량'이라고 불리며, 머신의 OS 커널을 공유하므로 각 애플리케이션 내에서 OS를 연결해야 하는 오버헤드가 필요하지 않습니다(VM의 경우처럼). 다른 컨테이너 계층(공통 저장소 및 라이브러리)도 여러 컨테이너 간에 공유할 수 있으므로 컨테이너는 본질적으로 VM보다 용량이 작고 시작 속도가 빨라집니다. 여러 컨테이너를 단일 VM과 동일한 컴퓨팅 용량에서 실행할 수 있으므로 서버 효율성이 더욱 높아지고 서버 및 라이선스 비용이 절감됩니다.

다음 동영상에서는 컨테이너와 VM에 대해 자세히 설명합니다.

컨테이너화는 개발자와 개발 팀에게 특히 다음과 같은 영역에서 상당한 이점을 제공합니다.

컨테이너 기반 솔루션의 성장이 증가함에 따라 컨테이너 기술과 소프트웨어 코드 패키징에 대한 접근 방식에 대한 표준의 필요성이 대두되었습니다. 오픈 컨테이너 이니셔티브(OCI)²는 2015년 6월 Docker와 다른 업계 리더들이 설립한 Linux 프로젝트로, 컨테이너 기술에 대한 최소한의 개방형 공통 표준 및 사양을 촉진하기 위한 방법으로 등장했습니다. 그 이후로 OCI는 오픈 소스 엔진에 대한 선택의 폭을 넓혀 사용자가 특정 벤더에 종속되는 것을 방지할 수 있도록 지원했습니다. 또한 개발자는 다양한 DevOps 도구 세트를 사용하여 컨테이너화된 애플리케이션을 구축하고 원하는 인프라에서 일관되게 실행할 수 있는 OCI 인증 기술을 활용할 수 있습니다.

혼란을 없애기 위해, Docker는 Docker 컨테이너 기술을 기반으로 하는 생산성 도구를 개발하는 회사인 Docker, Inc.³를 지칭하기도 합니다. 또한 Docker, Inc. 및 기타 여러 조직과 개인이 기여하는 Docker 오픈 소스 프로젝트²와도 관련이 있습니다.

Docker는 가장 잘 알려져 있고 많이 사용되는 컨테이너 엔진 기술이지만, 더 광범위한 에코시스템은 컨테이너와 CoreOS rkt, Mesos Containerizer, LXC Linux 컨테이너, OpenVZ 및 crio-d와 같은 기타 대안을 기반으로 표준화되었습니다.

오늘날 조직에는 수백 또는 수천 개의 컨테이너가 있을 수 있으며, 이는 팀이 수동으로 관리하는 것이 거의 불가능한 양입니다. 이것이 바로 컨테이너 오케스트레이션이 필요한 이유입니다.

컨테이너 오케스트레이션 플랫폼은 컨테이너 배포, 네트워킹, 로드 밸런싱, 확장성 및 가용성과 같은 관리를 스케줄링하고 자동화합니다.

가장 널리 사용되는 컨테이너 오케스트레이션 도구인 Kubernetes는 Linux 컨테이너 기능을 자동화하는 오픈 소스 기술(원래는 Google에서 Borg라는 내부 프로젝트에 기반하여 오픈 소스화)입니다. Kubernetes는 Docker Engine과 같은 많은 컨테이너 엔진과 함께 작동합니다. 또한 컨테이너 이미지 형식 및 런타임에 대한 오픈 컨테이너 이니셔티브(OCI) 표준을 준수하는 모든 컨테이너 시스템에서 작동합니다.

Kubernetes가 업계 표준이긴 하지만, 다른 인기 있는 컨테이너 오케스트레이션 플랫폼으로는 Apache Mesos, Nomad, Docker Swarm 등이 있습니다.

컨테이너 오케스트레이션에 대해 자세히 알아보려면 Kubernetes의 작동 방식을 설명하는 다음 동영상을 확인하세요.

컨테이너화는 애플리케이션 현대화의 필수적인 부분입니다. 이 프로세스는 모놀리식(레거시) 애플리케이션을 모든 클라우드 환경에 통합되도록 설계된 마이크로서비스 아키텍처를 기반으로 구축된 클라우드 네이티브 애플리케이션으로 전환하는 것을 말합니다.

마이크로서비스는 소프트웨어 애플리케이션과 관련 사용자 인터페이스 및 기본 데이터베이스를 단일 서버 플랫폼의 단일 유닛으로 결합하는 이전의 모놀리식 모델에 비해 애플리케이션 개발 및 관리에 대한 우수한 접근 방식입니다. 마이크로서비스를 사용하면 복잡한 애플리케이션이 일련의 더 작고 전문화된 서비스로 나뉘며, 각 서비스에는 자체 데이터베이스와 자체 비즈니스 로직이 있습니다. 마이크로서비스는 공통 인터페이스(예: API)와 REST 인터페이스(예: HTTP)를 통해 통신합니다. 마이크로서비스를 사용하면 개발팀은 애플리케이션 전체에 영향을 주지 않고 특정 영역을 업데이트하는 데 집중할 수 있으므로 개발, 테스트 및 배포 속도가 빨라집니다.

마이크로서비스와 컨테이너화의 기본 개념은 비슷합니다. 두 가지 모두 기본적으로 애플리케이션을 이식 가능하고 확장 가능하며 효율적이고 관리하기 쉬운 소규모 서비스 또는 구성 요소의 모음으로 변환하는 소프트웨어 개발 방식입니다.

또한 마이크로서비스와 컨테이너화는 함께 사용할 때 잘 작동합니다. 컨테이너는 기존 모놀리스든 모듈식 마이크로서비스든 모든 애플리케이션의 경량 캡슐화를 제공합니다. 컨테이너 내에서 개발된 마이크로서비스는 이식성과 같은 컨테이너화의 모든 고유한 이점을 얻을 수 있습니다.

전반적으로 컨테이너, 마이크로서비스 및 클라우드 컴퓨팅이 통합되어 애플리케이션 개발 및 제공이 새로운 수준으로 발전했습니다. 이러한 기술은 DevOps 워크플로를 간소화하고 소프트웨어 개발 가속화를 위한 지속적 통합 및 지속적 배포(CI/CD) 파이프라인을 지원합니다. 이러한 차세대 접근 방식은 소프트웨어 개발 라이프사이클에 민첩성, 효율성 및 신뢰성을 제공하여 컨테이너화된 애플리케이션을 더 빠르게 제공하고 사용자와 시장에 향상된 기능을 제공합니다.

조직은 사용자가 애플리케이션을 빠르고 효율적으로 개발할 수 있는 클라우드로 계속 이동하고 있습니다. 컨테이너화는 온프레미스 데이터 센터에서 클라우드 기반 인프라로 또는 한 클라우드 환경에서 다른 클라우드 환경으로 데이터, 애플리케이션 및 워크로드를 이동하는 프로세스인 클라우드 마이그레이션의 중요한 비즈니스 사용 사례로 자리 잡았습니다.

클라우드 마이그레이션은 온프레미스, 퍼블릭 및 프라이빗 클라우드 서비스를 결합하여 클라우드 환경 전반에서 워크로드 관리를 지원하고 자동화하는 유연하고 비용 효율적인 단일 IT 인프라를 구축하는 조직의 하이브리드 클라우드 환경에 있어 필수적인 부분입니다.

오늘날에는 인터넷에 연결된 모든 장치에서 클라우드 기반 애플리케이션과 데이터에 액세스할 수 있으므로 팀원들이 원격으로 이동 중에도 업무를 수행할 수 있습니다. 클라우드 서비스 제공업체(CSP)(예: Amazon Web Services(AWS), Google Cloud Services, IBM Cloud 또는 Microsoft Azure)는 기본 인프라를 관리하여 조직의 서버 및 기타 장비 비용을 절감하고 자동화된 네트워크 백업을 제공하여 안정성을 높입니다. 클라우드 인프라는 온디맨드 방식으로 확장되며 부하 요구 사항이 변경됨에 따라 컴퓨팅 리소스, 용량 및 인프라를 동적으로 조정합니다. 또한 CSP는 정기적으로 제품을 업데이트하여 사용자가 생성형 AI와 같은 최신 혁신 기술에 지속적으로 액세스할 수 있도록 합니다.

최고의 클라우드 서비스 제공업체 중 다수는 서비스형 컨테이너 (CaaS)를 제공합니다. 기본적으로 서비스형 인프라(IaaS)의 하위 집합인 CaaS는 클라우드 컴퓨팅 스택에서 IaaS와 서비스형 플랫폼(PaaS) 사이에 위치하여 IaaS가 제공하는 제어 기능과 PaaS의 단순성 간의 균형을 제공합니다.

CaaS는 사용자가 컨테이너 기반 가상화 및 컨테이너 관리 프로세스를 간소화할 수 있는 클라우드 기반 플랫폼을 제공합니다. 또한 CaaS는 컨테이너 런타임, 오케스트레이션 계층 및 영구 스토리지 관리 기능을 제공합니다. 2022년 전 세계 CaaS 시장의 가치는 거의 20억 달러에 달했습니다.⁵ 

서버리스 컴퓨팅(서버리스) 은 개발자가 서버나 백엔드 인프라를 프로비저닝 또는 관리하지 않고도 애플리케이션 코드를 빌드하고 실행할 수 있는 애플리케이션 개발 및 실행 모델입니다.

서버리스 컴퓨팅에서 클라우드 서비스 제공업체는 온디맨드 방식으로 시스템 리소스를 할당하여 고객을 대신하여 서버를 유지 관리합니다. 특히 개발자와 CSP는 코드를 실행하는 데 필요한 클라우드 인프라를 프로비저닝하고 필요에 따라 인프라를 확장 및 축소하는 작업을 처리합니다. 제공업체는 종량제 요금 모델을 준수합니다.

서버리스 컴퓨팅은 팀이 인프라 관리가 아닌 코드 작성에 집중할 수 있도록 하여 개발자의 생산성을 향상시킬 수 있습니다. 반면, 컨테이너는 더 많은 제어와 유연성을 제공하여 기존 애플리케이션을 관리하고 클라우드로 마이그레이션하는 데 도움이 될 수 있습니다.

컨테이너화된 환경에 대한 보안 관행에는 개발, 테스트 및 배포를 포함한 전체 컨테이너 수명 주기에 걸친 전략이 필요합니다.

이러한 관행은 컨테이너화 플랫폼, 컨테이너 이미지, 오케스트레이션 플랫폼, 개별 컨테이너 및 애플리케이션을 포함한 모든 스택 계층을 다루어야 합니다.

무엇보다도 컨테이너 보안 정책은 제로 트러스트 프레임워크를 중심으로 이루어져야 합니다. 이 모델은 모든 사용자 연결을 검증하고 권한을 부여하며 상호 작용이 조직의 보안 정책의 조건부 요구 사항을 충족하는지 확인합니다. 또한 제로 트러스트 보안 전략은 가능한 한 많은 데이터 소스의 컨텍스트를 사용하여 동적 정책을 기반으로 모든 장치, 네트워크 흐름 및 연결을 인증하고 권한을 부여합니다.

애플리케이션을 배포하고 확장하는 데 오케스트레이션 플랫폼을 비롯한 컨테이너화 기술에 의존하는 조직이 늘어나면서 컨테이너 보안은 더욱 중요한 관심사가 되었습니다. Red Hat⁶의 보고서에 따르면 컨테이너 및 Kubernetes 환경에서 가장 큰 보안 문제는 취약점 및 잘못된 구성입니다.

앞서 언급했듯이 컨테이너화된 애플리케이션은 격리된 프로세스로 실행되고 다른 컨테이너와 독립적으로 작동할 수 있기 때문에 본질적으로 보안 수준이 높습니다. 진정으로 격리된 이 기능은 악성 코드가 다른 컨테이너에 영향을 미치거나 호스트 시스템에 침입하는 것을 방지할 수 있습니다. 그러나 컨테이너 내의 애플리케이션 계층은 컨테이너 간에 공유되는 경우가 많습니다. 리소스 효율성 측면에서는 이점이 있지만, 컨테이너 간 간섭과 보안 침해를 유발할 가능성도 있습니다. 공유 운영 체제의 경우에도 마찬가지인데, 여러 컨테이너가 동일한 호스트 운영 체제와 연결될 수 있기 때문입니다. 공통 운영 체제에 대한 보안 위협은 관련된 모든 컨테이너에 영향을 미칠 수 있으며, 반대로 컨테이너 침해는 잠재적으로 호스트 운영 체제를 침범할 수 있습니다.

그렇다면 컨테이너 이미지 자체와 관련된 위험과 취약성은 어떨까요? 강력한 컨테이너화 전략에는 '기본 보안' 접근 방식이 포함되는데, 이는 보안이 별도로 배포 및 구성된 솔루션이 아니라 플랫폼에 내재되어 있어야 한다는 의미입니다. 이를 위해 컨테이너 엔진은 기본 운영 체제에 내재된 모든 기본 격리 속성을 지원합니다. 원치 않는 구성 요소가 컨테이너에 들어가는 것을 자동으로 차단하거나 불필요한 리소스와의 통신을 제한하도록 보안 권한을 정의할 수 있습니다.

예를 들어, Linux 네임스페이스는 각 컨테이너에 시스템의 격리된 보기를 제공하는 데 도움이 됩니다. 여기에는 네트워킹, 마운트 지점, 프로세스 ID, 사용자 ID, 프로세스 간 통신 및 호스트 이름 설정이 포함됩니다. 네임스페이스는 각 컨테이너 내의 프로세스를 통해 이러한 리소스에 대한 액세스를 제한할 수 있습니다. 일반적으로 네임스페이스를 지원하지 않는 하위 시스템은 컨테이너 내에서 액세스할 수 없습니다. 관리자는 간단한 사용자 인터페이스를 통해 컨테이너화된 각 애플리케이션에서 이러한 '격리 제약 조건'을 쉽게 생성하고 관리할 수 있습니다.

또한 기업 전반의 위협 탐지 및 대응을 자동화하는 다양한 컨테이너 보안 솔루션을 사용할 수 있습니다. 이러한 툴은 보안 정책을 모니터링 및 시행하고 업계 표준을 충족하여 데이터의 안전한 흐름을 보장하는 데 도움이 됩니다. 예를 들어, 보안 관리 소프트웨어 툴은 CI/CD 파이프라인을 자동화하고, 프로덕션 전에 취약성을 차단하며, 실시간 가시성을 통해 의심스러운 활동을 조사하는 데 도움이 될 수 있습니다. 이러한 접근 방식은 소프트웨어 개발 라이프사이클의 모든 수준에서 보안 관행의 통합을 자동화하는 애플리케이션 및 개발 프로세스인 DevSecOps에 속합니다.