2020.01.07

글로벌 칼럼 | 컨테이너, 백업이 필요한가

W. Curtis Preston | Network World
컨테이너(Containers) 백업이 항상 필요한 것은 아니지만, 값 비싼 손실을 막기 위해 도커(Docker)와 기타 컨테이너를 백업해야 하는 상황이 있다. 
 
ⓒ IBM, Maersk

컨테이너가 곳곳에서 백업 관행을 깨고 있지만 데이터센터에 일어날 수 있는 최악의 상황으로부터 컨테이너 인프라의 가장 중요한 부분을 보호하기 위해 활용할 수 있는 방법이 있다. 

컨테이너는 백업할 필요가 없을 것 같지만, 자세히 살펴보면 재해급 사태는 물론 이보다 덜한 여러 사고에 대비해 보호하기 위해 컨테이너도 백업하는 것이 좋다.


컨테이너의 기본

컨테이너는 가상화의 한 유형이며, 이 가운데 도커는 가장 인기 있는 컨테이너 플랫폼이다. 컨테이너는 특정 애플리케이션을 실행할 수 있는 특수한 환경이다. 가벼운 가상 머신이라고 표현할 수도 있다. 

하이퍼바이저 서버의 각 VM에는 운영체제의 전체 사본이 포함되는 반면, 컨테이너는 기반 운영체제를 공유하며 각 컨테이너에는 해당 컨테이너에서 실행되는 애플리케이션에 필요한 라이브러리만 포함된다. 그 결과 단일 노드(OS와 컨테이너 런타임 환경을 실행하는 물리적 또는 가상 머신)에서 컨테이너가 점유하는 리소스는 같은 수의 VM에 비해 훨씬 적다.

VM과 컨테이너의 또 다른 차이점은 기업에서는 보통 하나의 VM에 다수의 애플리케이션을 동시에 실행하는 경향이 있는 반면, 컨테이너는 일반적으로 로깅, 모니터링과 같은 하나의 작업을 수행하는 하나의 애플리케이션 구성요소를 제공하도록 설계된다는 점이다. 

여러 애플리케이션 구성요소가 상호작용해야 하는 경우 각 구성요소는 일반적으로 자체 컨테이너에서 실행되면서 네트워크를 통해 통신한다. 이로써 각 애플리케이션을 개별적으로 확장하고 애플리케이션 간의 결함 및 보안 격리도 가능하다.

VM은 특정 하드웨어에서 실행되는 특정 하이퍼바이저 내에서 실행되지만 컨테이너는 훨씬 더 이식성이 높다. 컨테이너는 사실상 모든 리눅스 시스템에서 실행되며 적절한 소프트웨어만 설치하면 윈도우에서도 실행이 가능하다. 

마지막으로, 컨테이너는 태생적으로 VM에 비해 훨씬 더 일시적이다. 일반적인 VM은 몇 개월, 길게는 몇 년 동안 실행되는 반면 최근 시스디그(Sysdig)의 설문에 따르면, 컨테이너의 95%는 수명이 1주일 미만이다.

프로덕션 환경에서 다수의 컨테이너를 실행하기 위해서는 오케스트레이션(orchestration)이 필요하다. 오케스트레이션에는 쿠버네티스(보통 줄여서 K8s이라고 쓴다)가 사용된다. 쿠버네티스(Kubernetes)는 컨테이너를 포드(pod)로 그룹화한다. 

포드는 하나의 목적을 달성하는 하나 이상의 컨테이너이며 포드 안의 컨테이너는 상호 손쉽게 통신할 수 있고 공유 볼륨을 마운트하는 방법으로 스토리지를 공유할 수 있다.


컨테이너에는 백업이 필요 없다는 생각

과거에는 백업을 위해 백업해야 할 서버에 에이전트를 두는 방법이 사용됐다. 가상화가 이 모델을 무너뜨리고, 에이전트가 하이퍼바이저 수준에서 실행되면서 VM을 이미지로 백업하는 다른 모델이 만들어졌다. 컨테이너는 이 두 가지 옵션 중 어느 것도 제공하지 않는다.

이론적으로는 컨테이너 이미지 내에 에이전트를 둘 수 있지만 이 방법은 많은 이유에서 매우 좋지 않으므로 누구도 그렇게 하지 않는다. 또한 하이퍼바이저 수준과 비슷한 컨테이너 런타임 계층에서 에이전트를 실행할 방법도 현재는 없다. 

마지막으로, 컨테이너를 사용하는 많은 사람들이 컨테이너를 백업한다는 개념을 낯설게 받아들인다. 대부분의 컨테이너의 수명이 일주일 미만이라는 점을 감안하면 백업할 필요가 있나 싶다.


컨테이너에 백업이 필요한 이유

어떤 의미에서는 일반적인 컨테이너는 실행 상태를 백업할 필요가 없다. 백업을 정당화할 만큼의 고유성이 없기 때문이다. 게다가 대부분의 컨테이너는 상태가 없다. 즉, 컨테이너에는 데이터가 저장되지 않는다. 다른 어떤 작업을 통해 이미 저장된, 주어진 컨테이너의 또 다른 실행 인스턴스일 뿐이다.

많은 컨테이너 지지자는 컨테이너 인프라의 모든 부분에 내제된 고가용성을 강조한다. 쿠버네티스는 클러스터에서 상시 실행된다. 컨테이너는 필요에 따라 항상 생성되고 삭제된다. 그러나 많은 이가 이 고가용성을 재해 복구 역량과 혼동한다.

대화의 관점을 바꿔서, 어떤 사고로 인해 전체 클러스터, 컨테이너 노드, 관련 영구 스토리지가 마비되는 경우 쿠버네티스와 도커 환경 전체를 어떻게 복제할 것인지 질문을 해보자. 쿠버네티스, 도커, 관련 애플리케이션을 백업해야 할 이유는 여러가지다.

첫 번째는 재해 복구다. 최악의 경우가 발생한다면 어떻게 할 것인가? 두 번째, 테스트/개발 환경에서 프로덕션으로 또는 업그레이드에 앞서 프로덕션에서 스테이징으로 옮길 때와 같이 환경을 복제하기 위해서다. 세 번째 이유는 쿠버네티스 클러스터를 더 쉽게 마이그레이션하기 위해서다.


재해가 발생하는 경우 필요한 것

재해 발생 시 전체 환경을 복제하기 위해서는 다음과 같은 것이 필요하다.

- 컨테이너 이미지: 컨테이너 이미지는 컨테이너가 작동하기 위해 필요한 모든 실행 코드가 포함된 정적 파일이다. 컨테이너 이미지는 변경되지 않으며 특정 컨테이너를 실행하는 데 사용된다. 특정 컨테이너의 라이브러리와 코드를 변경해야 하는 경우 해당 컨테이너를 위한 새로운 이미지가 생성된다. 컨테이너 이미지도 보호가 필요한데, 주로 리포지토리가 사용된다. 이 리포지토리 역시 재해에 대비해 보호해야 한다.

- 연결된 스토리지, 데이터베이스: 컨테이너가 생성하는 데이터는 컨테이너의 수명이 끝난 후에도 계속 사용되는 경우가 많다. 이를 위해 NFS, 객체 저장소 또는 다른 비슷한 메커니즘을 통해 볼륨을 마운트하고 이 볼륨에 데이터를 쓴다. 데이터베이스에 연결될 수도 있다.

- 영구 볼륨: 쿠버네티스 포드에서 영구 스토리지를 사용하는 경우가 늘고 있다. 여기에 저장되는 데이터가 비즈니스에 중요하다면 스토리지 역시 백업해야 한다.

- 배포: 배포는 특정 기능을 수행하는 포드의 집합을 나타내는 쿠버네티스 개념이다. 배포는 YAML 파일로 저장되며 이 파일을 백업해야 한다.

- 쿠버네티스 etcd: 쿠버네티스 중앙 데이터베이스인 etcd를 백업해야 한다. etcd는 비교적 작고, K8s는 그 내용물을 파일로 옮기기 위한 툴을 제공하므로 옮겨서 파일을 백업하면 된다.

- 프로메테우스: 프로메테우스(Prometheus)는 K8s와 도커를 모니터링하는 데 자주 사용된다. 프로메테우스 구성도 백업해야 한다.

- 쿠버네티스 리소스: 개발자가 K8s에서 리소스를 만들면 만들어진 리소스를 적절한 그룹 및 버전과 함께 백업해야 한다.


백업하지 말아야 할 것

예를 들어 다음과 같은 것은 백업할 필요가 없다.
- 실행 중인 무상태 컨테이너: 실행 중인 컨테이너는 일시적이다. 이미지(백업해야 함)에서 스폰됐지만 실행 중인 컨테이너 인스턴스를 백업할 필요는 없다. 이 컨테이너가 생성하는 데이터를 백업할 수는 있지만 컨테이너 자체를 백업해야 한다면 뭔가 잘못된 것이다. 컨테이너가 외부 볼륨에 데이터를 저장하지 않고 자체에 데이터를 포함한다면 백업해야 하지만 그런 경우는 매우 드물다.

- 포드: 포드는 단순히 실행 중인 컨테이너의 그룹이며 백업할 필요가 없다.

앞서 언급한 각 개체는 해당 개체를 로컬 또는 원격 스토리지에 백업하는 데 사용할 수 있는 기본 툴을 제공한다. 또한 다양한 방식으로 실행되는 상용 유틸리티도 등장하기 시작했다. 다음 기사에서는 쿠버네티스 및 도커 환경의 다양한 부분을 어떻게 복원하는지를 포함한 백업 방법에 대해 세부적으로 살펴보자. editor@itworld.co.kr 


2020.01.07

글로벌 칼럼 | 컨테이너, 백업이 필요한가

W. Curtis Preston | Network World
컨테이너(Containers) 백업이 항상 필요한 것은 아니지만, 값 비싼 손실을 막기 위해 도커(Docker)와 기타 컨테이너를 백업해야 하는 상황이 있다. 
 
ⓒ IBM, Maersk

컨테이너가 곳곳에서 백업 관행을 깨고 있지만 데이터센터에 일어날 수 있는 최악의 상황으로부터 컨테이너 인프라의 가장 중요한 부분을 보호하기 위해 활용할 수 있는 방법이 있다. 

컨테이너는 백업할 필요가 없을 것 같지만, 자세히 살펴보면 재해급 사태는 물론 이보다 덜한 여러 사고에 대비해 보호하기 위해 컨테이너도 백업하는 것이 좋다.


컨테이너의 기본

컨테이너는 가상화의 한 유형이며, 이 가운데 도커는 가장 인기 있는 컨테이너 플랫폼이다. 컨테이너는 특정 애플리케이션을 실행할 수 있는 특수한 환경이다. 가벼운 가상 머신이라고 표현할 수도 있다. 

하이퍼바이저 서버의 각 VM에는 운영체제의 전체 사본이 포함되는 반면, 컨테이너는 기반 운영체제를 공유하며 각 컨테이너에는 해당 컨테이너에서 실행되는 애플리케이션에 필요한 라이브러리만 포함된다. 그 결과 단일 노드(OS와 컨테이너 런타임 환경을 실행하는 물리적 또는 가상 머신)에서 컨테이너가 점유하는 리소스는 같은 수의 VM에 비해 훨씬 적다.

VM과 컨테이너의 또 다른 차이점은 기업에서는 보통 하나의 VM에 다수의 애플리케이션을 동시에 실행하는 경향이 있는 반면, 컨테이너는 일반적으로 로깅, 모니터링과 같은 하나의 작업을 수행하는 하나의 애플리케이션 구성요소를 제공하도록 설계된다는 점이다. 

여러 애플리케이션 구성요소가 상호작용해야 하는 경우 각 구성요소는 일반적으로 자체 컨테이너에서 실행되면서 네트워크를 통해 통신한다. 이로써 각 애플리케이션을 개별적으로 확장하고 애플리케이션 간의 결함 및 보안 격리도 가능하다.

VM은 특정 하드웨어에서 실행되는 특정 하이퍼바이저 내에서 실행되지만 컨테이너는 훨씬 더 이식성이 높다. 컨테이너는 사실상 모든 리눅스 시스템에서 실행되며 적절한 소프트웨어만 설치하면 윈도우에서도 실행이 가능하다. 

마지막으로, 컨테이너는 태생적으로 VM에 비해 훨씬 더 일시적이다. 일반적인 VM은 몇 개월, 길게는 몇 년 동안 실행되는 반면 최근 시스디그(Sysdig)의 설문에 따르면, 컨테이너의 95%는 수명이 1주일 미만이다.

프로덕션 환경에서 다수의 컨테이너를 실행하기 위해서는 오케스트레이션(orchestration)이 필요하다. 오케스트레이션에는 쿠버네티스(보통 줄여서 K8s이라고 쓴다)가 사용된다. 쿠버네티스(Kubernetes)는 컨테이너를 포드(pod)로 그룹화한다. 

포드는 하나의 목적을 달성하는 하나 이상의 컨테이너이며 포드 안의 컨테이너는 상호 손쉽게 통신할 수 있고 공유 볼륨을 마운트하는 방법으로 스토리지를 공유할 수 있다.


컨테이너에는 백업이 필요 없다는 생각

과거에는 백업을 위해 백업해야 할 서버에 에이전트를 두는 방법이 사용됐다. 가상화가 이 모델을 무너뜨리고, 에이전트가 하이퍼바이저 수준에서 실행되면서 VM을 이미지로 백업하는 다른 모델이 만들어졌다. 컨테이너는 이 두 가지 옵션 중 어느 것도 제공하지 않는다.

이론적으로는 컨테이너 이미지 내에 에이전트를 둘 수 있지만 이 방법은 많은 이유에서 매우 좋지 않으므로 누구도 그렇게 하지 않는다. 또한 하이퍼바이저 수준과 비슷한 컨테이너 런타임 계층에서 에이전트를 실행할 방법도 현재는 없다. 

마지막으로, 컨테이너를 사용하는 많은 사람들이 컨테이너를 백업한다는 개념을 낯설게 받아들인다. 대부분의 컨테이너의 수명이 일주일 미만이라는 점을 감안하면 백업할 필요가 있나 싶다.


컨테이너에 백업이 필요한 이유

어떤 의미에서는 일반적인 컨테이너는 실행 상태를 백업할 필요가 없다. 백업을 정당화할 만큼의 고유성이 없기 때문이다. 게다가 대부분의 컨테이너는 상태가 없다. 즉, 컨테이너에는 데이터가 저장되지 않는다. 다른 어떤 작업을 통해 이미 저장된, 주어진 컨테이너의 또 다른 실행 인스턴스일 뿐이다.

많은 컨테이너 지지자는 컨테이너 인프라의 모든 부분에 내제된 고가용성을 강조한다. 쿠버네티스는 클러스터에서 상시 실행된다. 컨테이너는 필요에 따라 항상 생성되고 삭제된다. 그러나 많은 이가 이 고가용성을 재해 복구 역량과 혼동한다.

대화의 관점을 바꿔서, 어떤 사고로 인해 전체 클러스터, 컨테이너 노드, 관련 영구 스토리지가 마비되는 경우 쿠버네티스와 도커 환경 전체를 어떻게 복제할 것인지 질문을 해보자. 쿠버네티스, 도커, 관련 애플리케이션을 백업해야 할 이유는 여러가지다.

첫 번째는 재해 복구다. 최악의 경우가 발생한다면 어떻게 할 것인가? 두 번째, 테스트/개발 환경에서 프로덕션으로 또는 업그레이드에 앞서 프로덕션에서 스테이징으로 옮길 때와 같이 환경을 복제하기 위해서다. 세 번째 이유는 쿠버네티스 클러스터를 더 쉽게 마이그레이션하기 위해서다.


재해가 발생하는 경우 필요한 것

재해 발생 시 전체 환경을 복제하기 위해서는 다음과 같은 것이 필요하다.

- 컨테이너 이미지: 컨테이너 이미지는 컨테이너가 작동하기 위해 필요한 모든 실행 코드가 포함된 정적 파일이다. 컨테이너 이미지는 변경되지 않으며 특정 컨테이너를 실행하는 데 사용된다. 특정 컨테이너의 라이브러리와 코드를 변경해야 하는 경우 해당 컨테이너를 위한 새로운 이미지가 생성된다. 컨테이너 이미지도 보호가 필요한데, 주로 리포지토리가 사용된다. 이 리포지토리 역시 재해에 대비해 보호해야 한다.

- 연결된 스토리지, 데이터베이스: 컨테이너가 생성하는 데이터는 컨테이너의 수명이 끝난 후에도 계속 사용되는 경우가 많다. 이를 위해 NFS, 객체 저장소 또는 다른 비슷한 메커니즘을 통해 볼륨을 마운트하고 이 볼륨에 데이터를 쓴다. 데이터베이스에 연결될 수도 있다.

- 영구 볼륨: 쿠버네티스 포드에서 영구 스토리지를 사용하는 경우가 늘고 있다. 여기에 저장되는 데이터가 비즈니스에 중요하다면 스토리지 역시 백업해야 한다.

- 배포: 배포는 특정 기능을 수행하는 포드의 집합을 나타내는 쿠버네티스 개념이다. 배포는 YAML 파일로 저장되며 이 파일을 백업해야 한다.

- 쿠버네티스 etcd: 쿠버네티스 중앙 데이터베이스인 etcd를 백업해야 한다. etcd는 비교적 작고, K8s는 그 내용물을 파일로 옮기기 위한 툴을 제공하므로 옮겨서 파일을 백업하면 된다.

- 프로메테우스: 프로메테우스(Prometheus)는 K8s와 도커를 모니터링하는 데 자주 사용된다. 프로메테우스 구성도 백업해야 한다.

- 쿠버네티스 리소스: 개발자가 K8s에서 리소스를 만들면 만들어진 리소스를 적절한 그룹 및 버전과 함께 백업해야 한다.


백업하지 말아야 할 것

예를 들어 다음과 같은 것은 백업할 필요가 없다.
- 실행 중인 무상태 컨테이너: 실행 중인 컨테이너는 일시적이다. 이미지(백업해야 함)에서 스폰됐지만 실행 중인 컨테이너 인스턴스를 백업할 필요는 없다. 이 컨테이너가 생성하는 데이터를 백업할 수는 있지만 컨테이너 자체를 백업해야 한다면 뭔가 잘못된 것이다. 컨테이너가 외부 볼륨에 데이터를 저장하지 않고 자체에 데이터를 포함한다면 백업해야 하지만 그런 경우는 매우 드물다.

- 포드: 포드는 단순히 실행 중인 컨테이너의 그룹이며 백업할 필요가 없다.

앞서 언급한 각 개체는 해당 개체를 로컬 또는 원격 스토리지에 백업하는 데 사용할 수 있는 기본 툴을 제공한다. 또한 다양한 방식으로 실행되는 상용 유틸리티도 등장하기 시작했다. 다음 기사에서는 쿠버네티스 및 도커 환경의 다양한 부분을 어떻게 복원하는지를 포함한 백업 방법에 대해 세부적으로 살펴보자. editor@itworld.co.kr 


X