2017.07.03

"왜 도커인가?" 도커와 리눅스 컨테이너의 이해

Chenxi Wang | InfoWorld
프리BSD 제일(FreeBSD Jail), 솔라리스 존(Solaris Zone)과 마찬가지로 리눅스 컨테이너는 별도의 CPU와 메모리, 블록 I/O, 네트워크 리소스를 갖추고 호스트 운영체제의 커널을 공유하는, 그 자체로 완전한 실행 환경이다. 일종의 가상머신처럼 느껴지지만 가상머신에 따르는 게스트 운영체제의 무거움과 시작 오버헤드가 없다.

대규모 시스템에서 VM을 실행하는 경우 보통 동일한 OS 인스턴스와 부팅 볼륨이 중복되어 여러 개가 실행된다. 컨테이너는 VM에 비해 더 능률적이고 가벼우므로 같은 하드웨어에서 VM에 비해 6~8배 더 많은 컨테이너를 실행할 수 있다.

따라서 웹 스케일 요구 사항이 있는 애플리케이션 환경에서 컨테이너는 전통적인 서버 가상화에 비해 매력적인 제안이다.

컨테이너를 이해하려면 먼저 호스트에서 실행되는 다른 프로세스와 컨테이너 사이에 벽을 치는 리눅스 커널 기능인 cgroup과 namespace부터 알아야 한다. IBM이 처음 개발한 리눅스 namespace는 시스템 리소스 집합을 래핑해서 이를 프로세스에 제공해 그 프로세서 전용 자원처럼 보이도록 한다.

구글이 개발한 리눅스의 cgroup은 프로세스 그룹의 CPU, 메모리와 같은 시스템 자원의 격리와 활용을 관장한다. 예를 들어 과학 컴퓨팅 애플리케이션과 같이 CPU 사이클과 메모리를 다량으로 소비하는 애플리케이션이 있는 경우 이를 cgroup에 배치해서 CPU 및 메모리 사용을 제한할 수 있다.

namespace가 단일 프로세스용 자원의 격리를 다룬다면, cgroup은 일군의 프로세스용 자원을 관리한다.

LXC에서 도커까지
최초의 리눅스 컨테이너 기술은 리눅스 컨테이너(Linux Container)다. 보통 줄여서 LXC라고 한다. LXC는 하나의 호스트에서 여러 개의 격리된 리눅스 시스템을 실행하기 위한 리눅스 운영체제 시스템 수준의 가상화 방법이다.

컨테이너는 운영체제에서 애플리케이션을 분리한다. 따라서 사용자는 깨끗한, 최소한의 리눅스 운영체제만을 두고 다른 모든 것은 하나 이상의 격리된 컨테이너에서 실행할 수 있다. 또한 운영체제는 컨테이너에서 추상화되므로 컨테이너 런타임 환경을 지원하는 어떤 리눅스 서버로 컨테이너를 옮길 수 있다.

단일 애플리케이션 LXC 컨테이너를 구축하기 위한 프로젝트로 시작된 도커는 LXC에 여러 가지 중요한 변화를 가미해 컨테이너의 이식성과 사용 유연성을 높였다. 도커 컨테이너를 사용하면 가상머신을 사용할 때보다 더 쉽고 빠르게 워크로드를 배포, 복제, 이동, 백업할 수 있다. 기본적으로 도커는 컨테이너를 실행할 수 있는 모든 인프라에 클라우드 수준의 유연성을 제공한다.

그래서 많은 사람들은 최근 컨테이너 인기가 급상승하는 주 요인으로 도커를 꼽는다. 이제부터 도커를 조금 더 자세히 알아보고 LXC와의 차이점에 대해 살펴보자.

도커의 내부
도커는 특수한 LXC를 빌드하기 위한 오픈소스 프로젝트로 시작됐지만, 이후 자체 컨테이너 런타임 환경으로 발전했다. 높은 수준에서 보면 도커는 효율적으로 컨테이너를 생성, 이동, 실행할 수 있는 리눅스 유틸리티다.

기본적으로 도커와 LXC 컨테이너 모두 cgroup과 namespace를 구현해서 리소스 격리를 관리하는 사용자 공간 경량 가상화 메커니즘이다. 하지만 도커 컨테이너와 LXC 간에의 몇 가지 핵심적인 차이가 있다.

단일 프로세스 대 다중 프로세스. 도커는 컨테이너가 단일 프로세스로 실행되도록 제한한다. 따라서 애플리케이션 환경이 X개의 동시 프로세스로 구성된다면, 도커에서는 각각 별도의 프로세스를 갖는 X개의 컨테이너를 실행해야 한다. 반면 LXC 컨테이너는 일반적인 init 프로세스가 있으므로 여러 프로세스를 실행할 수 있다.

도커에서 단순한 다계층 웹 애플리케이션 하나를 실행하려면 PHP 컨테이너, Nginx 컨테이너(웹 서버), MySQL 컨테이너(데이터베이스 프로세스용), 그리고 데이터베이스 테이블 및 기타 애플리케이션 데이터를 저장하기 위한 몇 가지 데이터 컨테이너가 필요하다.

이런 단일 프로세스 컨테이너의 장점은 많다. 업데이트가 더 쉽고 세분화된다는 것도 그 중 하나다. 웹 서버만 업데이트하면 되는데 데이터베이스 프로세스를 종료할 필요가 있는가? 또한 단일 프로세스 컨테이너는 마이크로서비스 기반 애플리케이션을 구축하기 위한 효율적인 아키텍처이기도 하다.

물론 단일 프로세스 컨테이너에는 제약도 있다. 예를 들어 컨테이너 내에서 에이전트, 로깅 스크립트 또는 SSH 데몬을 실행할 수 없다. 또한 작은, 애플리케이션 수준의 변경 사항을 단일 프로세스 컨테이너로 커밋하기는 쉽지 않다. 사실상 업데이트된 새 컨테이너를 시작해야 한다.

무상태 대 상태. 도커 컨테이너는 LXC에 비해 무상태(Stateless)에 맞게 만들어졌다. 첫째, 도커는 영구 스토리지를 지원하지 않는다. 도커에서 이를 처리하는 방법은 컨테이너에서 호스트 스토리지를 “도커 볼륨”으로 마운트하는 것이다. 볼륨은 마운트되므로 컨테이너 환경에 속하지 않는다.

둘째, 도커 컨테이너는 읽기 전용 계층으로 구성된다. 일단 컨테이너 이미지가 생성되면 변경되지 않는다. 런타임 중에 컨테이너의 프로세스가 내부 상태에 변경을 가할 경우 내부 상태와 컨테이너가 생성된 이미지 사이에 “diff”가 만들어진다. docker commit 명령을 실행하면 이 diff는 원래의 이미지가 아니라 새 이미지의 일부가 된다. 이 새 이미지에서 새 컨테이너를 만들 수 있다. 컨테이너를 삭제하면 diff가 사라진다.

무상태 컨테이너는 흥미로운 개체다. 컨테이너를 업데이트할 수 있지만 연속적으로 업데이트하면 그에 따라 연속적으로 새 컨테이너 이미지가 생성되므로 시스템을 롤백하기가 쉽다.

이식성. LXC에 비해 도커가 앞선 가장 중요한 부분 중 하나다. 도커는 LXC에 비해 더 많은 네트워킹, 스토리지, OS 세부 요소를 애플리케이션에서 추상화한다. 도커에서 애플리케이션은 이러한 저수준 리소스 구성으로부터 진정 독립적이다. 어느 한 도커 호스트에서 다른 도커 지원 시스템으로 도커 컨테이너를 옮기더라도 도커는 애플리케이션의 환경이 동일하게 유지되도록 보장한다.

여기서 얻는 직접적인 이점은 도커를 통해 개발자가 프로덕션 서버와 완전히 동일한 로컬 개발 환경을 구축할 수 있다는 것이다. 개발자는 코드 작성과 테스트를 완료하면 이를 컨테이너에 래핑해서 바로 AWS 서버 또는 프라이빗 클라우드로 게시할 수 있다. 환경이 동일하므로 애플리케이션은 즉각 작동한다.

LXC의 경우 개발자 시스템에서 정상 실행되더라도 서버에 배포된 후에는 제대로 실행되지 않을 수 있다. 서버 환경이 다르기 때문이다. 개발자는 그 차이를 디버깅하고 문제를 수정하기 위해 막대한 시간을 소비해야 한다.

도커는 바로 이런 복잡성을 없애준다. 도커 컨테이너가 다양한 클라우드 및 가상화 환경에서 이식성이 뛰어나고 사용하기 쉬운 이유다.

개발자 친화적인 아키텍처
기반 하드웨어에서 애플리케이션을 분리하는 것은 가상화의 바탕이 되는 기본 개념이다. 컨테이너는 여기서 한 걸음 더 나아가 기반 OS에서 애플리케이션을 분리한다. 이를 통해 이식성과 효율적인 확장을 포함한 클라우드 수준의 유연함을 얻을 수 있다. 컨테이너는 개발자에게 가상화를 뛰어넘는 새로운 차원의 효율성, 이식성, 배포 유연성을 제공한다.

컨테이너의 인기는 지금이 개발자 주도의 시대라는 사실을 반영한다. 클라우드가 인프라 혁신, 모바일이 사용성 혁신을 위한 것이었다면, 컨테이너는 개발자의 능력을 배가하는 데 있어 꼭 필요한 요소다.  editor@itworld.co.kr

2017.07.03

"왜 도커인가?" 도커와 리눅스 컨테이너의 이해

Chenxi Wang | InfoWorld
프리BSD 제일(FreeBSD Jail), 솔라리스 존(Solaris Zone)과 마찬가지로 리눅스 컨테이너는 별도의 CPU와 메모리, 블록 I/O, 네트워크 리소스를 갖추고 호스트 운영체제의 커널을 공유하는, 그 자체로 완전한 실행 환경이다. 일종의 가상머신처럼 느껴지지만 가상머신에 따르는 게스트 운영체제의 무거움과 시작 오버헤드가 없다.

대규모 시스템에서 VM을 실행하는 경우 보통 동일한 OS 인스턴스와 부팅 볼륨이 중복되어 여러 개가 실행된다. 컨테이너는 VM에 비해 더 능률적이고 가벼우므로 같은 하드웨어에서 VM에 비해 6~8배 더 많은 컨테이너를 실행할 수 있다.

따라서 웹 스케일 요구 사항이 있는 애플리케이션 환경에서 컨테이너는 전통적인 서버 가상화에 비해 매력적인 제안이다.

컨테이너를 이해하려면 먼저 호스트에서 실행되는 다른 프로세스와 컨테이너 사이에 벽을 치는 리눅스 커널 기능인 cgroup과 namespace부터 알아야 한다. IBM이 처음 개발한 리눅스 namespace는 시스템 리소스 집합을 래핑해서 이를 프로세스에 제공해 그 프로세서 전용 자원처럼 보이도록 한다.

구글이 개발한 리눅스의 cgroup은 프로세스 그룹의 CPU, 메모리와 같은 시스템 자원의 격리와 활용을 관장한다. 예를 들어 과학 컴퓨팅 애플리케이션과 같이 CPU 사이클과 메모리를 다량으로 소비하는 애플리케이션이 있는 경우 이를 cgroup에 배치해서 CPU 및 메모리 사용을 제한할 수 있다.

namespace가 단일 프로세스용 자원의 격리를 다룬다면, cgroup은 일군의 프로세스용 자원을 관리한다.

LXC에서 도커까지
최초의 리눅스 컨테이너 기술은 리눅스 컨테이너(Linux Container)다. 보통 줄여서 LXC라고 한다. LXC는 하나의 호스트에서 여러 개의 격리된 리눅스 시스템을 실행하기 위한 리눅스 운영체제 시스템 수준의 가상화 방법이다.

컨테이너는 운영체제에서 애플리케이션을 분리한다. 따라서 사용자는 깨끗한, 최소한의 리눅스 운영체제만을 두고 다른 모든 것은 하나 이상의 격리된 컨테이너에서 실행할 수 있다. 또한 운영체제는 컨테이너에서 추상화되므로 컨테이너 런타임 환경을 지원하는 어떤 리눅스 서버로 컨테이너를 옮길 수 있다.

단일 애플리케이션 LXC 컨테이너를 구축하기 위한 프로젝트로 시작된 도커는 LXC에 여러 가지 중요한 변화를 가미해 컨테이너의 이식성과 사용 유연성을 높였다. 도커 컨테이너를 사용하면 가상머신을 사용할 때보다 더 쉽고 빠르게 워크로드를 배포, 복제, 이동, 백업할 수 있다. 기본적으로 도커는 컨테이너를 실행할 수 있는 모든 인프라에 클라우드 수준의 유연성을 제공한다.

그래서 많은 사람들은 최근 컨테이너 인기가 급상승하는 주 요인으로 도커를 꼽는다. 이제부터 도커를 조금 더 자세히 알아보고 LXC와의 차이점에 대해 살펴보자.

도커의 내부
도커는 특수한 LXC를 빌드하기 위한 오픈소스 프로젝트로 시작됐지만, 이후 자체 컨테이너 런타임 환경으로 발전했다. 높은 수준에서 보면 도커는 효율적으로 컨테이너를 생성, 이동, 실행할 수 있는 리눅스 유틸리티다.

기본적으로 도커와 LXC 컨테이너 모두 cgroup과 namespace를 구현해서 리소스 격리를 관리하는 사용자 공간 경량 가상화 메커니즘이다. 하지만 도커 컨테이너와 LXC 간에의 몇 가지 핵심적인 차이가 있다.

단일 프로세스 대 다중 프로세스. 도커는 컨테이너가 단일 프로세스로 실행되도록 제한한다. 따라서 애플리케이션 환경이 X개의 동시 프로세스로 구성된다면, 도커에서는 각각 별도의 프로세스를 갖는 X개의 컨테이너를 실행해야 한다. 반면 LXC 컨테이너는 일반적인 init 프로세스가 있으므로 여러 프로세스를 실행할 수 있다.

도커에서 단순한 다계층 웹 애플리케이션 하나를 실행하려면 PHP 컨테이너, Nginx 컨테이너(웹 서버), MySQL 컨테이너(데이터베이스 프로세스용), 그리고 데이터베이스 테이블 및 기타 애플리케이션 데이터를 저장하기 위한 몇 가지 데이터 컨테이너가 필요하다.

이런 단일 프로세스 컨테이너의 장점은 많다. 업데이트가 더 쉽고 세분화된다는 것도 그 중 하나다. 웹 서버만 업데이트하면 되는데 데이터베이스 프로세스를 종료할 필요가 있는가? 또한 단일 프로세스 컨테이너는 마이크로서비스 기반 애플리케이션을 구축하기 위한 효율적인 아키텍처이기도 하다.

물론 단일 프로세스 컨테이너에는 제약도 있다. 예를 들어 컨테이너 내에서 에이전트, 로깅 스크립트 또는 SSH 데몬을 실행할 수 없다. 또한 작은, 애플리케이션 수준의 변경 사항을 단일 프로세스 컨테이너로 커밋하기는 쉽지 않다. 사실상 업데이트된 새 컨테이너를 시작해야 한다.

무상태 대 상태. 도커 컨테이너는 LXC에 비해 무상태(Stateless)에 맞게 만들어졌다. 첫째, 도커는 영구 스토리지를 지원하지 않는다. 도커에서 이를 처리하는 방법은 컨테이너에서 호스트 스토리지를 “도커 볼륨”으로 마운트하는 것이다. 볼륨은 마운트되므로 컨테이너 환경에 속하지 않는다.

둘째, 도커 컨테이너는 읽기 전용 계층으로 구성된다. 일단 컨테이너 이미지가 생성되면 변경되지 않는다. 런타임 중에 컨테이너의 프로세스가 내부 상태에 변경을 가할 경우 내부 상태와 컨테이너가 생성된 이미지 사이에 “diff”가 만들어진다. docker commit 명령을 실행하면 이 diff는 원래의 이미지가 아니라 새 이미지의 일부가 된다. 이 새 이미지에서 새 컨테이너를 만들 수 있다. 컨테이너를 삭제하면 diff가 사라진다.

무상태 컨테이너는 흥미로운 개체다. 컨테이너를 업데이트할 수 있지만 연속적으로 업데이트하면 그에 따라 연속적으로 새 컨테이너 이미지가 생성되므로 시스템을 롤백하기가 쉽다.

이식성. LXC에 비해 도커가 앞선 가장 중요한 부분 중 하나다. 도커는 LXC에 비해 더 많은 네트워킹, 스토리지, OS 세부 요소를 애플리케이션에서 추상화한다. 도커에서 애플리케이션은 이러한 저수준 리소스 구성으로부터 진정 독립적이다. 어느 한 도커 호스트에서 다른 도커 지원 시스템으로 도커 컨테이너를 옮기더라도 도커는 애플리케이션의 환경이 동일하게 유지되도록 보장한다.

여기서 얻는 직접적인 이점은 도커를 통해 개발자가 프로덕션 서버와 완전히 동일한 로컬 개발 환경을 구축할 수 있다는 것이다. 개발자는 코드 작성과 테스트를 완료하면 이를 컨테이너에 래핑해서 바로 AWS 서버 또는 프라이빗 클라우드로 게시할 수 있다. 환경이 동일하므로 애플리케이션은 즉각 작동한다.

LXC의 경우 개발자 시스템에서 정상 실행되더라도 서버에 배포된 후에는 제대로 실행되지 않을 수 있다. 서버 환경이 다르기 때문이다. 개발자는 그 차이를 디버깅하고 문제를 수정하기 위해 막대한 시간을 소비해야 한다.

도커는 바로 이런 복잡성을 없애준다. 도커 컨테이너가 다양한 클라우드 및 가상화 환경에서 이식성이 뛰어나고 사용하기 쉬운 이유다.

개발자 친화적인 아키텍처
기반 하드웨어에서 애플리케이션을 분리하는 것은 가상화의 바탕이 되는 기본 개념이다. 컨테이너는 여기서 한 걸음 더 나아가 기반 OS에서 애플리케이션을 분리한다. 이를 통해 이식성과 효율적인 확장을 포함한 클라우드 수준의 유연함을 얻을 수 있다. 컨테이너는 개발자에게 가상화를 뛰어넘는 새로운 차원의 효율성, 이식성, 배포 유연성을 제공한다.

컨테이너의 인기는 지금이 개발자 주도의 시대라는 사실을 반영한다. 클라우드가 인프라 혁신, 모바일이 사용성 혁신을 위한 것이었다면, 컨테이너는 개발자의 능력을 배가하는 데 있어 꼭 필요한 요소다.  editor@itworld.co.kr

X