컨테이너화는 어느 인프라에서나 일관적으로 실행되는 단일 경량 실행 파일(이를 컨테이너라고 부름)을 만들기 위해 소프트웨어 코드를 코드 실행에 필요한 운영 체제(OS) 라이브러리 및 종속성 항목과만 패키지화하는 것을 말합니다. 가상 머신(VM)보다 더 이동성과 리소스 효율성이 뛰어나므로 컨테이너는 사실상 최신 클라우드 네이티브 애플리케이션의 컴퓨팅 단위가 되었습니다.

컨테이너화를 통해 개발자는 애플리케이션을 보다 빠르고 안전하게 만들고 배포할 수 있습니다. 기존의 방법에서는 코드가 특정 컴퓨팅 환경에서 개발되며, 새 위치로 코드가 이전될 때 종종 버그와 오류가 발생합니다. 예를 들어 개발자가 데스크탑 컴퓨터에서 VM으로 또는 Linux에서 Windows 운영 체제로 코드를 전송하는 경우입니다. 컨테이너화는 애플리케이션 코드를 실행에 필요한 관련 구성 파일, 라이브러리 및 종속성과 함께 번들링함으로써 이 문제를 제거합니다. 이러한 단일 패키지의 소프트웨어 또는 "컨테이너"는 호스트 운영 체제에서 추상화되며, 따라서 독립형으로 작동하며 이동이 가능합니다. 즉, 문제 없이 플랫폼 또는 클라우드 간에 실행될 수 있습니다.

컨테이너화 및 프로세스 격리라는 개념은 사실 수십년이나 되었지만, 2013년에 오픈소스 Docker Engine(단순한 개발자 툴과 보편적인 패키징 접근법을 취하는, 컨테이너를 위한 업계 표준)이 등장하면서 이 기술의 도입이 가속화되었습니다. 요즘 조직들은 새로운 애플리케이션을 만들고 클라우드용으로 기존 애플리케이션을 현대화하기 위해 점점 더 많이 컨테이너화를 사용하고 있습니다. IBM의 한 설문조사(PDF, 1.4MB)에서 컨테이너 채택자의 61%는 직전 2년 동안 구축한 새 애플리케이션의 50% 이상에 컨테이너를 사용했다고 보고했으며, 채택자의 64%는 기존 애플리케이션의 50% 이상이 향후 2년간 컨테이너화될 것으로 예측했습니다.

컨테이너를 종종 "경량(lightweight)"이라고 합니다. 이는 컨테이너가 시스템의 운영 체제 커널을 공유하며 각 애플리케이션 내에서 운영 체제를 연관시키는 오버헤드가 필요하지 않음을 의미합니다. 컨테이너는 본질적으로 VM보다 용량이 작으며 더 짧은 구동 시간을 요구합니다. 따라서 단일 VM과 동일한 컴퓨팅 용량에서 훨씬 더 많은 컨테이너가 실행될 수 있습니다. 이는 보다 높은 서버 효율성을 제공하며, 향상된 서버 효율성은 서버 및 라이센스 비용을 줄입니다.

아마도 가장 중요한 점은 컨테이너화를 통해 애플리케이션을 "한 번 작성하고 어디서나 실행"할 수 있다는 것입니다. 이러한 이식성은 개발 속도를 높이고, 클라우드 벤더 종속성을 방지하며, 장애 격리, 관리 용이성, 보안 간소화 등 다른 주목할 만한 이점을 제공합니다(아래 참조).

컨테이너는 애플리케이션 코드를 실행에 필요한 관련 구성 파일, 라이브러리 및 종속성 항목과 함께 번들링하는 단일한 실행 가능 소프트웨어 패키지로서 애플리케이션을 캡슐화합니다. 컨테이너화된 애플리케이션은 운영 체제의 사본으로 번들링되지 않는다는 점에서 "격리"되어 있습니다. 그 대신에 오픈 소스 런타임 엔진(예: Docker 런타임 엔진)이 호스트의 운영 체제에 설치되어, 컨테이너가 동일 컴퓨팅 시스템의 다른 컨테이너와 운영 체제를 공유하기 위한 통로 역할을 수행합니다.

공통 바이너리 및 라이브러리 등의 기타 컨테이너 계층 역시 다중 컨테이너 중에서 공유가 가능합니다. 이는 각 애플리케이션 내에서 운영 체제를 실행하는 오버헤드를 없애고 컨테이너의 용량을 줄여주며 시동을 더 빨리 하도록 지원하여 서버 효율성을 높입니다. 또한 애플리케이션을 컨테이너로서 분리하면 한 컨테이너에 있는 악성 코드가 다른 컨테이너에 영향을 주거나 호스트 시스템을 침해할 가능성도 줄어듭니다.

호스트 운영 체제에서의 추상화를 통해 컨테이너화된 애플리케이션을 이식하고, 어떤 플랫폼이나 클라우드에서든 한결같이 일관되게 실행할 수 있습니다. 컨테이너는 데스크탑 컴퓨터에서 가상 머신(VM)으로 또는 Linux에서 Windows 운영 체제로 손쉽게 전송할 수 있으며, 가상화된 인프라에서 또는 (온프레미스 또는 클라우드의) 기존의 "베어메탈" 서버에서 일관되게 실행됩니다. 이는 소프트웨어 개발자가 자신이 가장 편하게 사용할 수 있는 툴과 프로세스를 계속 사용할 수 있도록 보장합니다.

기업들이 애플리케이션 개발과 관리에 대한 탁월한 접근 방식으로서 컨테이너화를 빠르게 채택하는 이유를 알 수 있습니다. 컨테이너화를 통해 개발자는 애플리케이션이 기존의 모놀리식(단일 계층 소프트웨어 애플리케이션)인지 또는 마이크로서비스 아키텍처 기반의 모듈형 애플리케이션인지 여부와 무관하게 애플리케이션을 보다 빠르고 안전하게 만들고 배포할 수 있습니다. 새로운 클라우드 기반 애플리케이션은 컨테이너화된 마이크로서비스로서 처음부터 다시 시작하여 구축될 수 있으며, 복잡한 애플리케이션을 일련의 보다 작은 특별하고 관리 가능한 서비스로 분할할 수 있습니다. 기존의 애플리케이션을 보다 효율적으로 컴퓨팅 리소스를 사용하는 컨테이너(또는 컨테이너화된 마이크로서비스)로 리패키징할 수 있습니다.

컨테이너화는 개발자와 개발 팀에게 상당한 이점을 제공합니다. 이점들 중 일부는 다음과 같습니다.

이식성: 컨테이너는 호스트 운영 체제에 종속되거나 의존하지 않고 이로부터 추상화된 실행 가능한 소프트웨어 패키지를 만듭니다. 따라서 컨테이너는 이식성이 있고 어떤 플랫폼이나 클라우드에서든 한결같이 일관되게 실행할 수 있습니다. 

민첩성: 컨테이너 실행을 위한 오픈 소스 Docker 엔진은 Linux 및 Windows 운영 체제 모두에서 작동하는 범용 패키징 접근 방식과 단순한 개발자 툴을 사용하여 컨테이너의 업계 표준을 시작했습니다. 컨테이너 에코시스템은 OCI(Open Container Initiative)에서 관리하는 엔진으로 전환했습니다. 소프트웨어 개발자들은 신속한 애플리케이션 개발과 개선을 위해 애자일 또는 DevOps 툴과 프로세스를 계속 사용할 수 있습니다.

속도: 컨테이너를 종종 "경량(lightweight)"이라고 합니다. 이는 컨테이너가 시스템의 운영 체제(OS) 커널을 공유하며 이러한 추가적인 오버헤드로 인해 난관에 봉착하지 않음을 의미합니다. 이는 서버 효율성을 높여줄 뿐 아니라, 부팅할 운영 체제가 없으므로 시동 시간을 단축하면서도 서버 및 라이센스 비용도 감소시킵니다.

결함 격리: 각각의 컨테이너화된 애플리케이션은 격리되어 있으며 서로 간에 독립적으로 작동됩니다. 한 컨테이너의 장애는 다른 컨테이너의 지속적인 운영에 영향을 주지 않습니다. 개발 팀은 다른 컨테이너의 가동 중단 없이 한 컨테이너 내의 기술적 문제를 식별하고 이를 정정할 수 있습니다. 또한 컨테이너 엔진은 OS 보안 격리 기술(예: SELinux 액세스 제어)을 활용하여 컨테이너 내의 결함을 격리할 수 있습니다.

효율성: 컨테이너화된 환경에서 실행 중인 소프트웨어는 시스템의 OS 커널을 공유하며, 컨테이너 내의 애플리케이션 계층은 컨테이너들 간에 공유가 가능합니다. 따라서 컨테이너는 본질적으로 VM보다 용량이 작으며 보다 짧은 구동 시간을 요구하므로 훨씬 더 많은 컨테이너를 단일 VM과 동일한 컴퓨팅 용량에서 실행할 수 있습니다. 이는 서버 효율성을 더 높이고 서버 및 라이센스 비용을 줄여줍니다.

관리 용이성:  컨테이너 오케스트레이션 플랫폼은 컨테이너화된 워크로드 및 서비스의 설치, 확장, 관리를 자동화합니다. 컨테이너 오케스트레이션 플랫폼은 기타 기능들 중에서도 컨테이너화된 앱의 스케일링, 새 앱 버전의 롤아웃, 그리고 모니터링, 로깅 및 디버깅 제공 등의 관리 태스크를 용이하게 합니다. 아마도 가장 인기 있는 컨테이너 오케스트레이션 시스템일 가능성이 높은 Kubernetes는 원래 Linux 컨테이너 기능을 자동화하는 오픈소스 기술(원래 Borg라는 내부 프로젝트를 기반으로 Google이 오픈소스로 공개함)입니다. Kubernetes는 Docker 등의 많은 컨테이너 엔진에서 작동되지만, 컨테이너 이미지 형식과 런타임의 OCI(Open Container Initiative) 표준을 준수하는 모든 컨테이너 시스템에서도 작동됩니다.

보안: 컨테이너로 애플리케이션을 격리시키면, 다른 컨테이너나 호스트 시스템에 악성 코드가 침투하는 것을 방지할 수 있습니다. 또한 원하지 않는 컴포넌트가 컨테이너에 진입하지 못하도록 자동으로 차단하거나 불필요한 리소스와의 통신을 제한하도록 보안 권한을 정의할 수 있습니다.

컨테이너 기반 솔루션에 대한 관심과 이러한 솔루션의 사용이 급증하면서 컨테이너 기술에 대한 표준과 소프트웨어 코드 패키지화 접근법이 필요해졌습니다. Docker 및 기타 업계 리더들이 2015년 6월에 설립한 OCI(Open Container Initiative)에서는 컨테이너 기술에 대한 공통, 최소, 개방형 표준 및 스펙을 마련하고 있습니다. 이로 인해 OCI는 오픈 소스 엔진의 선택 폭을 넓히는 데 도움을 주고 있습니다. 사용자는 더 이상 특정 벤더의 기술에 종속되지 않습니다. 오히려 사용자는 다양한 DevOps 툴 세트를 사용하여 컨테이너화된 애플리케이션을 구축하고 자신이 선택한 인프라에서 이를 지속적으로 실행할 수 있도록 해주는 OCI 인증 기술을 활용할 수 있습니다.

오늘날 Docker는 가장 잘 알려져 있고 가장 많이 사용되는 컨테이너 엔진 기술 중 하나이지만 사용 가능한 유일한 옵션은 아닙니다. 에코시스템은 컨테이너화된 기술 및 기타 대안들(예: CoreOS rkt, Mesos Containerizer, LXC Linux Containers, OpenVZ 및 crio-d)을 표준화하고 있습니다. 특성과 기본 기능들은 서로 다를 수 있지만, 이러한 기술의 진화에 따라 OCI 사양을 채택하고 활용하면 솔루션이 벤더 중립적이고 여러 운영 체제에서 실행되도록 인증을 받았으며 여러 환경에서 사용 가능하다는 것을 보장할 수 있습니다.

규모에 상관없이 소프트웨어 회사들은 애플리케이션 개발과 관리에 대한 탁월한 접근 방식으로서 마이크로서비스를 채택하고 있으며, 이는 소프트웨어 애플리케이션 및 연관된 사용자 인터페이스와 기본 데이터베이스를 단일 서버 플랫폼의 단일 유닛으로 결합하는 이전의 모놀리식 모델과 비교됩니다. 마이크로서비스를 사용하면 복잡한 애플리케이션이 각각 자체 데이터베이스와 자체 비즈니스 로직을 지닌 일련의 보다 작고 특수화된 서비스로 분할됩니다. 그리고 마이크로서비스는 공통 인터페이스(예: API)와 REST 인터페이스(예: HTTP)를 통해 서로 간에 통신합니다. 개발 팀은 마이크로서비스를 사용하여 전체적으로 영향을 주지 않고 애플리케이션의 특정 영역에 대한 업데이트에만 집중할 수 있으므로 개발, 테스트, 배치 속도가 빨라집니다. 

마이크로서비스와 컨테이너화 모두가 기본적으로 애플리케이션을 이식 가능하고 확장 가능하며 효율적이고 손쉬운 관리가 가능한 보다 작은 서비스나 구성요소의 집합으로 변환하는 소프트웨어 개발 관행이므로, 이 두 기술의 기본 개념은 유사합니다.

또한 마이크로서비스와 컨테이너화는 함께 사용되면 더 잘 작동합니다. 컨테이너는 기존의 모노리스이거나 모듈식 마이크로서비스인지 여부와 무관하게 애플리케이션의 경량 캡슐화를 제공합니다. 그리고 컨테이너 내에서 개발된 마이크로서비스는 그 무엇보다도 개발 프로세스의 이식성 및 벤더 호환성(벤더 종속 없음)은 물론 개발자 민첩성, 결함 분리, 서버 효율성, 설치와 스케일링 및 관리의 자동화, 그리고 보안 계층이라는 컨테이너화의 모든 내재적 이점을 얻습니다.

오늘날의 통신은 사용자가 애플리케이션을 빠르고 효율적으로 개발할 수 있는 클라우드로 빠르게 이동하고 있습니다. 모든 인터넷 연결 장치에서 클라우드 기반 애플리케이션 및 데이터에 액세스할 수 있으므로 팀 구성원은 원격으로 지속해서 작업을 수행할 수 있습니다. 클라우드 서비스 제공자(CSP)는 기업의 서버 및 기타 장비 비용을 절감하고 추가적인 안정성을 위해 자동화된 네트워크 백업도 제공하는 기본 인프라를 관리합니다. 클라우드 인프라는 온디맨드로 확장이 가능하며 로드 요구사항이 변경됨에 따라 컴퓨팅 리소스, 용량 및 인프라를 동적으로 조정할 수 있습니다. 게다가 CSP는 정기적으로 오퍼링을 업데이트하므로 사용자는 최신의 혁신적 기술에 지속적으로 액세스할 수 있습니다.

컨테이너, 마이크로서비스 및 클라우드 컴퓨팅이 함께 작동하여 기존 방법론 및 환경에서는 불가능했던 새로운 수준의 애플리케이션 개발 및 배포 방법을 제공합니다. 이러한 차세대 접근 방식은 소프트웨어 개발 라이프사이클에 민첩성, 효율성, 안정성 및 보안을 추가하며, 이 모두는 일반 사용자와 시장에 애플리케이션과 개선사항을 신속하게 제공합니다.

격리된 프로세스로 실행할 수 있으며 다른 컨테이너와 독립적으로 작동할 수 있으므로 컨테이너화된 애플리케이션은 기본적으로 일정 수준의 보안을 갖추고 있습니다. 완전히 격리되어 있으므로 이는 악성 코드가 다른 컨테이너에 영향을 주거나 호스트 시스템을 침입할 수 없도록 차단합니다. 그러나 컨테이너 내의 애플리케이션 계층은 컨테이너 간에 공유되는 경우가 많습니다. 리소스 효율성의 관점에서 이는 플러스 요인이긴 하지만, 컨테이너에서 간섭 및 보안 위반의 가능성도 함께 열리게 됩니다. 다수의 컨테이너가 동일한 호스트 운영 시스템과 연관될 수 있기 때문에 공유 운영 체제에 대해서도 마찬가지일 수 있습니다. 일반 운영 체제에 대한 보안 위협은 연관된 모든 컨테이너에 영향을 미칠 수 있으며, 이와 반대로 컨테이너 침해는 잠재적으로 호스트 운영 체제에 침입할 수 있습니다.

그러면, 컨테이너 이미지 자체는 어떨까요? 컨테이너 내에 패키징된 애플리케이션과 오픈 소스 컴포넌트는 보안을 어떻게 개선할 수 있을까요? Docker 등의 컨테이너 기술 제공자는 계속해서 컨테이너 보안 문제를 적극적으로 해결해야 합니다. 컨테이너화는 보안이 플랫폼에 내재되어야 하며 별도로 배치되고 구성된 솔루션이 아니어야 한다는 믿음으로 "기본적 보안" 접근 방식을 취해 왔습니다. 이를 위해 컨테이너 엔진은 기본 운영 체제에 내재된 모든 기본 격리 특성을 지원합니다. 원하지 않는 컴포넌트가 컨테이너에 진입하지 못하도록 자동으로 차단하거나 불필요한 리소스와의 통신을 제한하도록 보안 권한을 정의할 수 있습니다.

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

연구자들은 Linux 컨테이너 보안을 더욱 강화하기 위해 노력하고 있으며, 기업 전체에서 위협 감지와 대응을 자동화하고, 업계 표준과 보안 정책을 충족하도록 규제 준수를 모니터링 및 적용하며, 애플리케이션 및 엔드포인트를 통한 데이터의 안전한 흐름을 보장하고, 그 밖의 역할을 수행하기 위해 다양한 보안 솔루션이 제공되고 있습니다.

규모에 상관없이 조직 간에 컨테이너 보안을 확장하기 위한 전략에 대해 알아보세요.

컨테이너는 종종 VM(가상 머신)과 비교됩니다. 두 기술 모두 단일 환경에서 여러 유형의 소프트웨어(Linux 또는 Windows 기반)를 실행할 수 있도록 하여 상당한 컴퓨팅 효율성을 가능하게 하기 때문입니다. 그러나 컨테이너 기술은 가상화 이상의 상당한 이점을 제공하는 것으로 입증되었으며 빠르게 IT 전문가들이 선호하는 기술이 되고 있습니다.

가상화 기술을 이용하면 여러 운영 시스템 및 소프트웨어 애플리케이션을 동시에 실행하고 단일한 물리적 컴퓨터의 리소스를 공유할 수 있습니다. 예를 들어, IT 조직은 동일한 서버의 여러 애플리케이션과 함께 Windows 및 Linux 모두 또는 여러 버전의 운영 체제를 실행할 수 있습니다. 운영 체제(OS)의 사본을 포함한 각 애플리케이션 및 관련 파일, 라이브러리 및 종속성 항목은 VM으로서 함께 패키징되어 있습니다. 하나의 물리적 시스템에서 여러 VM을 실행하는 경우 자본, 운영 및 에너지 비용을 상당히 절감할 수 있습니다.

가상화에 대한 개괄적 설명은 "Virtualization in 2019" 비디오와 "Virtualization: A Complete Guide"를 확인하세요.

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

언급한 바와 같이, 컨테이너를 종종 "경량"(lightweight)이라고도 합니다. 컨테이너는 시스템의 OS 커널을 공유하며 각 애플리케이션 내에서 OS를 연관시키는 오버헤드를 요구하지 않습니다(VM의 경우에서와 같이). 기타 컨테이너 계층(일반 바이너리 및 라이브러리) 역시 여러 컨테이너 간에 공유가 가능하므로, 컨테이너는 본질적으로 VM보다 용량이 더 작고 구동 시간은 더 빠릅니다. 그리고 여러 컨테이너가 단일 VM과 동일한 컴퓨팅 용량으로 실행되므로 더 높은 서버 효율성을 제공하고 서버 및 라이센스 비용이 더욱 절감됩니다.