2019.09.23

IDG 블로그 | 멀티클라우드 2.0 시대를 여는 쿠버네티스

David Linthicum | InfoWorld
슬슬 2.0이란 말에도 지치는 시절이다. 이 용어는 업계가 시장의 판도를 바꿀 수 있는 무언가를 지칭하는 용어로 사용하지만, 조금 더 혁신적이고 창의적일 필요가 있지 않을까?

멀티클라우드의 경우, 1.0 버전은 수많은 퍼블릭 클라우드 브랜드를 대부분 기업이 사용하면서 부상했다. 기업은 보통 전용 CMP(Cloud Management Platform)나 CSB(Cloud Service Broker)에 의존해 수많은 클라우드 네이티브 서비스를 관리한다. 
 
ⓒ GettyImagesBank

오늘날 대부분 멀티클라우드 배치 환경을 관리하는 방식이다. CMP나 CSB가 없다면, 각각의 클라우드 네이티브 서비스를 각 클라우드 서비스 업체가 제공하는 클라우드 네이티브 콘솔 같은 것을 사용해 다루어야 한다. 이 경우 멀티클라우드 환경에 세 곳의 퍼블릭 클라우드를 사용한다면, 서로 다른 세 개의 관리 인터페이스와 기술이 있어야 한다. 이 방식은 너무 복잡해 장기적으로 운영 가능한 환경을 만들기 어렵다.

현재 떠오르는 멀티클라우드 2.0은 다른 방식의 멀티클라우드이다. 바로 연합된 쿠버네티스를 사용해 컨테이너화된 애플리케이션과 데이터를 관리하는 것으로, 워크로드는 서로 다른 퍼블릭 클라우드 서비스 업체에서 구동하지만 서로를 인지하고 있다.

이 아키텍처는 멀티클라우드 상에서 구동하는 다중 클러스터를 다루기 쉽다. 주요 구성 요소는 두 가지로, 하나는 여러 클러스터에 걸쳐서 자원을 동기화하는 역량이다. 예상하는 것처럼 멀티클라우드 쿠버네티스 배치의 핵심 과제이다. 쿠버네티스 내의 메커니즘은 자동으로 멀티클라우드 상에서 구동하는 여러 클러스터 배치를 동기화할 수 있다. 두번째는 클러스터 내의 디스커버리이다. 이는 자동으로 DNS 서버와 로드밸런서를 구성해 수많은 퍼블릭 클라우드에 걸쳐 구동하는 모든 클러스터를 지원하는 역량이다.

멀티클라우드와 쿠버네티스를 활용하는 이점에는 고가용성도 포함되는데, 액티브/액티브 클러스터를 여러 곳의 퍼블릭 클라우드에 걸쳐 복제할 수 있기 때문이다. 따라서 하나가 장애가 나도 다른 쪽에서 박자를 놓치지 않고 작업을 이어갈 수 있다.

또한 무시무시한 업체 종속성도 피할 수 있다. 쿠버네티스는 추상화 계층으로, CSB와 CMP를 대체하며 각 퍼블릭 클라우드 서비스 업체의 네이티브 속성과 복잡성을 제거할 수 있기 때문이다. 만약 한 업체가 사업을 중단하거나 요금을 너무 올려도 걱정할 것 없다. 시장에 나와 있는 다른 클라우드 서비스 업체로 가면 된다. 퍼블릭 클라우드 서비스 업체는 범용 클러스터 처리 업체가 되는 것이다. 더구나 쿠버네티스는 오픈소스이다.

여기에 대단한 마법이 있는 것은 아니다. 실제로 쿠버네티스를 온프레미스 환경이나 클라우드에서 구축하는 것은 매우 복잡한 일이다. 그러니 연합 아키텍처를 사용해 쿠버네티스를 구축하는 것은 더욱 복잡할 것이다. 

하지만 이런 접근법을 지원하는 다수의 툴과 베스트 프랙티스가 등장하고 있다. 시장에는 더 많은 관련 기술이 나오고 있다. 확실히 이 방식은 멀티클라우드를 구현하는 더 나은 방식이다. 필자 역시 선도적인 사례 중 하나가 되어 멀티클라우드 2.0의 가능성을 확인해 볼 생각이다.  editor@itworld.co.kr


2019.09.23

IDG 블로그 | 멀티클라우드 2.0 시대를 여는 쿠버네티스

David Linthicum | InfoWorld
슬슬 2.0이란 말에도 지치는 시절이다. 이 용어는 업계가 시장의 판도를 바꿀 수 있는 무언가를 지칭하는 용어로 사용하지만, 조금 더 혁신적이고 창의적일 필요가 있지 않을까?

멀티클라우드의 경우, 1.0 버전은 수많은 퍼블릭 클라우드 브랜드를 대부분 기업이 사용하면서 부상했다. 기업은 보통 전용 CMP(Cloud Management Platform)나 CSB(Cloud Service Broker)에 의존해 수많은 클라우드 네이티브 서비스를 관리한다. 
 
ⓒ GettyImagesBank

오늘날 대부분 멀티클라우드 배치 환경을 관리하는 방식이다. CMP나 CSB가 없다면, 각각의 클라우드 네이티브 서비스를 각 클라우드 서비스 업체가 제공하는 클라우드 네이티브 콘솔 같은 것을 사용해 다루어야 한다. 이 경우 멀티클라우드 환경에 세 곳의 퍼블릭 클라우드를 사용한다면, 서로 다른 세 개의 관리 인터페이스와 기술이 있어야 한다. 이 방식은 너무 복잡해 장기적으로 운영 가능한 환경을 만들기 어렵다.

현재 떠오르는 멀티클라우드 2.0은 다른 방식의 멀티클라우드이다. 바로 연합된 쿠버네티스를 사용해 컨테이너화된 애플리케이션과 데이터를 관리하는 것으로, 워크로드는 서로 다른 퍼블릭 클라우드 서비스 업체에서 구동하지만 서로를 인지하고 있다.

이 아키텍처는 멀티클라우드 상에서 구동하는 다중 클러스터를 다루기 쉽다. 주요 구성 요소는 두 가지로, 하나는 여러 클러스터에 걸쳐서 자원을 동기화하는 역량이다. 예상하는 것처럼 멀티클라우드 쿠버네티스 배치의 핵심 과제이다. 쿠버네티스 내의 메커니즘은 자동으로 멀티클라우드 상에서 구동하는 여러 클러스터 배치를 동기화할 수 있다. 두번째는 클러스터 내의 디스커버리이다. 이는 자동으로 DNS 서버와 로드밸런서를 구성해 수많은 퍼블릭 클라우드에 걸쳐 구동하는 모든 클러스터를 지원하는 역량이다.

멀티클라우드와 쿠버네티스를 활용하는 이점에는 고가용성도 포함되는데, 액티브/액티브 클러스터를 여러 곳의 퍼블릭 클라우드에 걸쳐 복제할 수 있기 때문이다. 따라서 하나가 장애가 나도 다른 쪽에서 박자를 놓치지 않고 작업을 이어갈 수 있다.

또한 무시무시한 업체 종속성도 피할 수 있다. 쿠버네티스는 추상화 계층으로, CSB와 CMP를 대체하며 각 퍼블릭 클라우드 서비스 업체의 네이티브 속성과 복잡성을 제거할 수 있기 때문이다. 만약 한 업체가 사업을 중단하거나 요금을 너무 올려도 걱정할 것 없다. 시장에 나와 있는 다른 클라우드 서비스 업체로 가면 된다. 퍼블릭 클라우드 서비스 업체는 범용 클러스터 처리 업체가 되는 것이다. 더구나 쿠버네티스는 오픈소스이다.

여기에 대단한 마법이 있는 것은 아니다. 실제로 쿠버네티스를 온프레미스 환경이나 클라우드에서 구축하는 것은 매우 복잡한 일이다. 그러니 연합 아키텍처를 사용해 쿠버네티스를 구축하는 것은 더욱 복잡할 것이다. 

하지만 이런 접근법을 지원하는 다수의 툴과 베스트 프랙티스가 등장하고 있다. 시장에는 더 많은 관련 기술이 나오고 있다. 확실히 이 방식은 멀티클라우드를 구현하는 더 나은 방식이다. 필자 역시 선도적인 사례 중 하나가 되어 멀티클라우드 2.0의 가능성을 확인해 볼 생각이다.  editor@itworld.co.kr


X