2017.09.12

IDG 블로그 | 컨테이너 이식성의 진정한 의미와 호환성 계획

Scott McCarty | InfoWorld
이식성과 호환성은 같은 말이 아니다. 이식성은 비즈니스의 문제이고 호환성은 기술 문제이다.

컨테이너는 이식성(Portability)과 민첩성을 보장하겠다고 약속한다. 애플리케이션을 개발자의 노트북에서 내부 데이터센터로 옮기고, 별다른 수고없이 외부의 서로 다른 클라우드 서비스 업체로 옮길 수 있다고 한다. 컨테이너는 새로운 맞춤형 소프트웨어 버전을 구성해 얼마 전에 계약한 납품 기일을 신속하게 맞출 수 있도록 해주고, 심지어 고객에게 셀프 서비스도 제공할 수 있다. 컨테이너는 가상머신보다 더 빨리 시작하고, 더 쉽게 옮길 수 있다. 그렇지 않은가?



목표인 것은 맞지만, 이식성과 호환성은 같은 것이 아니다. 이식성은 비즈니스 문제이고, 호환성은 기술 문제이기 때문이다. 이식성은 서로 다른 환경에서 호환성을 계획해야만 구현할 수 있다. 컨테이너를 도입하는 것만으로는 애플리케이션의 호환성을 보장받지 못한다. 왜 그럴까? 컨테이너는 애플리케이션과 그 애플리케이션의 모든 운영체제 의존 요소를 패키징하는 세련된 방법일 뿐이기 때문이다.

즉 이식성을 제대로 구현하기 위해서는, 그리고 궁극적으로 비즈니스의 민첩성을 구현하기 위해서는 계획이 필요하다. 여기서는 성공적인 이식성을 구현하기 위한 즉각적인 방안을 소개한다.

1. 표준 운영 환경
이 환경에는 컨테이너 호스트, 컨테이너 이미지, 컨테이너 엔진, 컨테이너 오케스트레이션이 포함되어 있어야 한다. 이 모든 구동부는 정렬되고 표준화되어야 하며, 함께 버전을 맞추고 테스트한 것이어야 한다. 업그레이드 역시 하나의 유닛으로 함께 계획해야 하는데, 이들 요소 간의 상호 의존성이 크기 때문이다. 인프라의 정합성은 컨테이너를 구축하거나 실행하는 모든 환경에서 보장되어야 하며, 개발자의 노트북, 테스트 서버, 가상머신 역시 마찬가지이다. 표준 운영 환경에서는 항상 똑같이 테스트하고 인증 받은 요소를 모든 곳에서 사용할 것을 권장한다.

 표준 애플리케이션 정의는 여러 환경에 걸쳐 배치 자동화를 구축하는 데 필수적인 요소이다.

2. 표준 애플리케이션 정의
애플리케이션 정의에 있어서는 여러 가지 기술 선택지가 있다. 도커 컴포즈(Docker Compose), 쿠버네티스 오브젝트(Kubernetes Objects), 오픈시프트 템플릿(OpenShift Templates), 헬름 차트(Helm Charts) 등이 그것이다. 각각은 장단점이 있으니 잘 살펴보고 애플리케이션 정의 하나를 선택하자. 서로 다른 애플리케이션 정의 간에는 번역하지 않는다. 이는 한 환경의 기능이 지원되지 않거나 같은 방식으로 지원되지 않은 문제를 유발할 뿐이다.

예를 들어, 개발자가 도커 컴포즈로 구축한 애플리케이션을 프로덕션에서 쿠버네티스 오브젝트로 재구축하면 안된다. 비록 기술적으로는 가능할지 몰라도 이는 두 가지 경험, 두 가지 투자, 두 가지 버그, 두 가지 학습, 두 가지 문서화, 두 가지 문제 해결 방안 등등으로 악화된다. 최선의 방안을 한 가지 기술을 선택하고, 필요하다면 나중에 재평가해 더 나은 것으로 기술을 빨리 바꾸는 것이다.

3. 데이터 스토리지, 환경 설정, 기밀
이들 요소는 컨테이너 이미지나 애플리케이션 정의에 내장하는 것이 아니라 환경으로 제공해야 한다. 예를 들어, 개발자 노트북 상의 데이터 저장에는 신용카드 정보가 포함되지 않기를 원할 수도 있고, 프로덕션 데이터베이스 패스워드가 컨테이너 이미지에 내장되지 않기를 원할 수도 있다.

다른 한편으로, 만약 두 클라우드 서비스 업체 간을 이동한다면, 데이터를 옮기면서 동기화를 유지해야 한다. 이는 세 가지 서로 다른 수준으로 구현할 수 있는데, 블록과 파일, 트랜잭션이다. 데이터 스토리지는 컨테이너에 따라 바뀌지 않으며, 대부분 컨테이너 플랫폼은 이 작업을 처리해주지 않는다.

블록 스토리지 복제는 보통 DRBD나 SRDF, 셰프 등의 기반 기술로 처리한다. 파일 복제는 보통 RSync, 글러스터 지오 리플리케이션(Gluster Geo Replication)을 사용하거나 저지연 환경에서는 GFS2나 GPFS를 사용한다. 트랜잭션 계층에서는 데이터베이스의 일부가 되어야 하며, 각 기술마다 완전히 다르다. MySQL은 자체 트랜잭션 리플리케이션(Transaction Replication)을, 몽고DB는 자체 GRRS(Geographically Redundant Replica Sets)을 사용하며, 오라클 데이터베이스는 여러 가지 옵션을 제공한다. JBoss 데이터그리드도 자체 크로스 데이터센터 리플리케이션(Cross-Datacenter Replication)을 사용한다.

애플리케이션의 이식성을 보장하는 데는 좀 더 확장된 계획이 필요하다. 컨테이너는 이식성을 약속하지만, 호환성이 낮은 수준(컨테이너 이미지, 호스트, 엔진, 오케스트레이션), 높은 수준(애플리케이션 정의), 데이터와 환경설정, 보안 관리(동기화, 역할 기반 액세스 등) 세 가지를 고려해야만 가능하다.


애플리케이션 정의는 환경 간을 옮겨 다니지만, 환경 설정과 데이터는 환경에 의해 결정된다.

단순명료한 애플리케이션으로 시작하는 것이 좋다. 컨테이너 호스트와 이미지, 엔진, 오케스트레이션, 그리고 애플리케이션 정의를 표준화하라. 데이터와 환경설정, 보안을 어떻게 관리할지 파악하라. 하나의 애플리케이션이 성공하면, 다른 워크로드로 확장하는 것이 좋다. 모든 워크로드가 쉽지는 않을 것이다. 하지만 이들 문제를 해결하고 나면, 민첩성과 이식성을 구현하고, 애플리케이션을 더 빨리 전달하고 이를 여러 클라우드 서비스 간에 더 쉽게 이전할 수 있을 것이다.  editor@itworld.co.kr


2017.09.12

IDG 블로그 | 컨테이너 이식성의 진정한 의미와 호환성 계획

Scott McCarty | InfoWorld
이식성과 호환성은 같은 말이 아니다. 이식성은 비즈니스의 문제이고 호환성은 기술 문제이다.

컨테이너는 이식성(Portability)과 민첩성을 보장하겠다고 약속한다. 애플리케이션을 개발자의 노트북에서 내부 데이터센터로 옮기고, 별다른 수고없이 외부의 서로 다른 클라우드 서비스 업체로 옮길 수 있다고 한다. 컨테이너는 새로운 맞춤형 소프트웨어 버전을 구성해 얼마 전에 계약한 납품 기일을 신속하게 맞출 수 있도록 해주고, 심지어 고객에게 셀프 서비스도 제공할 수 있다. 컨테이너는 가상머신보다 더 빨리 시작하고, 더 쉽게 옮길 수 있다. 그렇지 않은가?



목표인 것은 맞지만, 이식성과 호환성은 같은 것이 아니다. 이식성은 비즈니스 문제이고, 호환성은 기술 문제이기 때문이다. 이식성은 서로 다른 환경에서 호환성을 계획해야만 구현할 수 있다. 컨테이너를 도입하는 것만으로는 애플리케이션의 호환성을 보장받지 못한다. 왜 그럴까? 컨테이너는 애플리케이션과 그 애플리케이션의 모든 운영체제 의존 요소를 패키징하는 세련된 방법일 뿐이기 때문이다.

즉 이식성을 제대로 구현하기 위해서는, 그리고 궁극적으로 비즈니스의 민첩성을 구현하기 위해서는 계획이 필요하다. 여기서는 성공적인 이식성을 구현하기 위한 즉각적인 방안을 소개한다.

1. 표준 운영 환경
이 환경에는 컨테이너 호스트, 컨테이너 이미지, 컨테이너 엔진, 컨테이너 오케스트레이션이 포함되어 있어야 한다. 이 모든 구동부는 정렬되고 표준화되어야 하며, 함께 버전을 맞추고 테스트한 것이어야 한다. 업그레이드 역시 하나의 유닛으로 함께 계획해야 하는데, 이들 요소 간의 상호 의존성이 크기 때문이다. 인프라의 정합성은 컨테이너를 구축하거나 실행하는 모든 환경에서 보장되어야 하며, 개발자의 노트북, 테스트 서버, 가상머신 역시 마찬가지이다. 표준 운영 환경에서는 항상 똑같이 테스트하고 인증 받은 요소를 모든 곳에서 사용할 것을 권장한다.

 표준 애플리케이션 정의는 여러 환경에 걸쳐 배치 자동화를 구축하는 데 필수적인 요소이다.

2. 표준 애플리케이션 정의
애플리케이션 정의에 있어서는 여러 가지 기술 선택지가 있다. 도커 컴포즈(Docker Compose), 쿠버네티스 오브젝트(Kubernetes Objects), 오픈시프트 템플릿(OpenShift Templates), 헬름 차트(Helm Charts) 등이 그것이다. 각각은 장단점이 있으니 잘 살펴보고 애플리케이션 정의 하나를 선택하자. 서로 다른 애플리케이션 정의 간에는 번역하지 않는다. 이는 한 환경의 기능이 지원되지 않거나 같은 방식으로 지원되지 않은 문제를 유발할 뿐이다.

예를 들어, 개발자가 도커 컴포즈로 구축한 애플리케이션을 프로덕션에서 쿠버네티스 오브젝트로 재구축하면 안된다. 비록 기술적으로는 가능할지 몰라도 이는 두 가지 경험, 두 가지 투자, 두 가지 버그, 두 가지 학습, 두 가지 문서화, 두 가지 문제 해결 방안 등등으로 악화된다. 최선의 방안을 한 가지 기술을 선택하고, 필요하다면 나중에 재평가해 더 나은 것으로 기술을 빨리 바꾸는 것이다.

3. 데이터 스토리지, 환경 설정, 기밀
이들 요소는 컨테이너 이미지나 애플리케이션 정의에 내장하는 것이 아니라 환경으로 제공해야 한다. 예를 들어, 개발자 노트북 상의 데이터 저장에는 신용카드 정보가 포함되지 않기를 원할 수도 있고, 프로덕션 데이터베이스 패스워드가 컨테이너 이미지에 내장되지 않기를 원할 수도 있다.

다른 한편으로, 만약 두 클라우드 서비스 업체 간을 이동한다면, 데이터를 옮기면서 동기화를 유지해야 한다. 이는 세 가지 서로 다른 수준으로 구현할 수 있는데, 블록과 파일, 트랜잭션이다. 데이터 스토리지는 컨테이너에 따라 바뀌지 않으며, 대부분 컨테이너 플랫폼은 이 작업을 처리해주지 않는다.

블록 스토리지 복제는 보통 DRBD나 SRDF, 셰프 등의 기반 기술로 처리한다. 파일 복제는 보통 RSync, 글러스터 지오 리플리케이션(Gluster Geo Replication)을 사용하거나 저지연 환경에서는 GFS2나 GPFS를 사용한다. 트랜잭션 계층에서는 데이터베이스의 일부가 되어야 하며, 각 기술마다 완전히 다르다. MySQL은 자체 트랜잭션 리플리케이션(Transaction Replication)을, 몽고DB는 자체 GRRS(Geographically Redundant Replica Sets)을 사용하며, 오라클 데이터베이스는 여러 가지 옵션을 제공한다. JBoss 데이터그리드도 자체 크로스 데이터센터 리플리케이션(Cross-Datacenter Replication)을 사용한다.

애플리케이션의 이식성을 보장하는 데는 좀 더 확장된 계획이 필요하다. 컨테이너는 이식성을 약속하지만, 호환성이 낮은 수준(컨테이너 이미지, 호스트, 엔진, 오케스트레이션), 높은 수준(애플리케이션 정의), 데이터와 환경설정, 보안 관리(동기화, 역할 기반 액세스 등) 세 가지를 고려해야만 가능하다.


애플리케이션 정의는 환경 간을 옮겨 다니지만, 환경 설정과 데이터는 환경에 의해 결정된다.

단순명료한 애플리케이션으로 시작하는 것이 좋다. 컨테이너 호스트와 이미지, 엔진, 오케스트레이션, 그리고 애플리케이션 정의를 표준화하라. 데이터와 환경설정, 보안을 어떻게 관리할지 파악하라. 하나의 애플리케이션이 성공하면, 다른 워크로드로 확장하는 것이 좋다. 모든 워크로드가 쉽지는 않을 것이다. 하지만 이들 문제를 해결하고 나면, 민첩성과 이식성을 구현하고, 애플리케이션을 더 빨리 전달하고 이를 여러 클라우드 서비스 간에 더 쉽게 이전할 수 있을 것이다.  editor@itworld.co.kr


X