2019.05.10

새로운 애저 서비스의 핵심은 쿠버네티스와 코스모스 DB

Simon Bisson | InfoWorld
마이크로소프트는 스스로 세 클라우드 회사라고 지칭하기 시작했다. 엑스박스 게이밍 클라우드, 마이크로소프트 365 업무 생산성 서비스, 그리고 가장 중요한 애저가 바로 그 세 클라우드이다. 아마존 웹 서비스(AWS)에 이은 업계 2위의 애저는 초거대 규모의 클라우드로, 미처 따라잡기 힘든 속도로 서비스를 속속 출시하고 있다. 이 속도는 마이크로소프트 3대 개발자 행사에서 더욱 잘 드러나는데, 개발자라면 쏟아져 나오는 발표 내용을 철저히 살펴 봐야 핵심 요소들을 파악할 수 있다.
 
ⓒGettyImageBank

마이크로소프트가 확실히 주력하고 있는 것은 서버리스 애플리케이션 구축 플랫폼으로서의 애저이다. 이를 통해, 가상머신을 지정할 필요가 없고 초 단위 CPU 사용 시간 별로 비용을 청구하는 인프라 서비스를 제공한다. 애플리케이션에는 머신러닝, 분석, 저장, 연산 등이 가능하도록 매우 다양한 플랫폼 서비스가 자리하고 있다. 

상황이 흥미로워지는 곳은 2가지가 만나는 지점이다. 즉, 단일 애저 리전 내에서나 애저 퍼블릭 클라우드 전체에 걸쳐 코드의 확장성을 개선하기 시작하는 지점이다. 분산 애플리케이션은 수작업 구축이 쉽지 않다. 마이크로소프트는 익숙한 도구와 새로운 기능을 모두 활용하여 확장성 자동화 방식을 더 많이 제공한다.
 

쿠버네티스에서의 이벤트 주도 규모 조정 

애저는 다른 대형 퍼블릭 클라우드처럼 쿠버네티스에 크게 의존한다. 하이퍼스케일 연산 작업 시에는 분산 애플리케이션의 관리와 조율이 필수적이다. 이 때, 애플리케이션을 고립된 컨테이너로 제공하면 구축 시스템으로부터 완전한 인프라를 제공하는 절차가 단순해진다.

단, 쿠버네티스는 복잡할 수 있다. 간단한 이벤트 주도 애플리케이션용으로 사용할 때 특히 그렇다. 자바스크립트로 조율되는 쿠버네티스를 갖춘 브리게이드(Brigade)를 쓰는 방법이 있다. 단, 이벤트를 트리거시키거나 요구에 따라 새로운 서버리스 기능을 시작하기 위해 애저의 이벤트그리드(EventGrid)와 같은 도구를 사용 중이라면, 필요한 규모 조정 기능은 제공하지는 않는다.

마이크로소프트와 레드햇은 KEDA(Kubernetes-based event-driven autoscaling)를 확장성 있는 대안으로 공동 개발했다. KEDA의 목적은 워크로드를 빠르게 확장하는 것이다. 이를 위해 HTTP 이벤트 대신 자체 트리거를 사용한다. 애플리케이션은 필요에 따라 규모가 확장되기도 하고 (심지어 0까지) 축소되기도 한다. 이러한 규모 조정은 워크로드 성능 기반의 보다 일반적인 방식 대신 다른 애플리케이션과 서비스의 알림을 활용한다.

규모 조정에 KEDA를 사용함으로써 이벤트에 대응해 컨테이너를 제공해 해당 이벤트와 관련된 데이터를 처리할 준비를한다. 애저의 펑션즈(Functions)과 유사한 모델이다. 기존 애저 펑션즈 코드로 쿠버네티스 애플리케이션에 호스팅하는 방식의 일종으로, KEDA를 마이크로소프트가 제공한다는 것이 놀라운 일은 아니다. 애저 펑션즈가 컨테이너에 있고 이벤트에 의해 트리거 된다면, 쿠버네티스 클러스터를 빠르게 확장해 수요에 대처할 수 있다. 즉, 더 이상 필요하지 않은 컨테이너는 정지된다.

쿠버네티스 컨테이너에 애저 펑션즈를 넣으면 특정 클라우드에 종속되는 현상을 피하는 데 도움이 된다. KEDA를 사용한다는 것은 서버리스 애플리케이션이 애저에서, 온프레미스에서 또는 그 어떤 클라우드 상에서도 실행 가능하다는 것을 의미한다. 쿠버네티스 인프라나 자체 가상 서버에 KEDA를 지원하는 호스트만 있으면 된다. 
 

코스모스 DB에서 글로벌 데이터 분석

필자는 코스모스 DB에 여전히 매료되어 있다. 사용 요금은 싸지 않을지 몰라도, 진정한 글로벌 확장이 가능한 분산 데이터베이스를 제공한다. 이 때 데이터베이스의 복제 모델에 애플리케이션을 맞추는 것이 아니라 애플리케이션 작동 방식에 맞추기 위한 새로운 일관성 모델을 활용한다. 

지금까지는 유용한 저장소였지만 분석 기능은 제한되어 있었다. 분석 기능이 필요하다면 다른 시스템을 채울 쿼리를 사용해야 했다. 그러나 대규모 코스모스 DB 구현물 중에는 페타바이트에 달하는 데이터를 저장하는 것이 있다. 따라서 같은 규모의 부차적인 분석 시스템을 정당화하기는 어렵다.

코스모스 DB의 최신 릴리즈에는 아파치 스파크 API가 추가되어 모든 지역의 모든 코스모스 DB 파티션에 대한 쿼리를 지원한다. 쿼리는 해당 코스모스 DB 데이터의 가장 가까운 복제본에 대해 실행된다. 이를 통해 자체 데이터 형식에서 스파크의 네이티브 형식으로 변환 처리된다. 

코스모스 DB 분석 기능 개발을 돕기 위해 이제 데이터 모델 전반에 걸쳐 주피터(Jupyter) 노트북이 지원된다. 따라서, 노트북에서 쿼리를 구축, 실행한 후 동료들과 공유할 수 있다. 주피터와 관련 도구들을 활용해 머신러닝 모델들을 쉽게 실험할 수 있다. 따라서 자체 데이터를 기반으로 직접 머신러닝을 개발할 수 있다. 코스모스DB를 머신러닝 훈련에 사용하고 추론 데이터의 원천으로 사용함으로써 개발 주기가 짧아진다.
 

코스모스 DB로 쿠버네티스 규모 조정

분산 데이터베이스는 대용량 데이터 작업을 위한 도구인 것만은 아니다. 저장소의 분산 특성이 중요한 소규모 애플리케이션을 지원할 수 있다. 여기서 코스모스 DB를 애플리케이션 인프라의 일부로 만들어 애플리케이션 관리 데이터를 코드에 가장 가까운 곳에 두는 것이다. 코드 구축, 인프라 구축, 구성 정보 저장을 각각 한번씩 하고 난 후 코스모스 DB를 사용해 해당 데이터를 전 세계적으로 공유한다.

etcd는 쿠버네티스의 핵심 구성요소 중 하나로, 구성 및 상태 데이터를 보관한다. 마이크로소프트는 쿠버네티스를 애저에서 적정 규모로 실행하며, 쿠버네티스 구성 데이터를 위한 분산 저장소가 필요하다. 코스모스 DB는 애저의 데이터 인프라 중 많은 부분에서 근간 역할을 하며, 이 용도에도 적합해 한동안 이 역할을 감당해 왔다. 현재 etcd 지원은 일반인 대면 서비스로 변환되고 있다. 제대로 테스트를 거친 내부 API가 있으면, 개발자 전원을 지원하는 방향으로 가는 것이 타당하다. etcd를 사용하는 오픈소스 인프라 서비스가 점점 더 많아지고 있기 때문이다.

etcd 데이터에 코스모스 DB를 사용하면 전 세계적으로 복제되는 쿠버네티스 애플리케이션 구축이 더 쉬워진다. 모든 지역에 etcd 복사본을 두고 이를 호스팅 하기 위한 서버를 유지할 필요 없이, 장소를 막론하고 쿠버네티스 클러스터 전체에 대한 구성 데이터를 호스팅하는 코스모스 DB 인스턴스 하나만 둘 수 있다. 구성 변경은 한번만 하면 되므로 배치 및 업데이트의 실패 위험이 줄어든다.

마이크로소프트의 새로운 유행 기술 용어는 “스캐폴딩(scaffolding)”이다. 건축물의 비계처럼, 플랫폼 위에 구축되는 도구와 서비스를 지원하기 위한 프레임워크를 제공하는 것이다. 애저와의 작업 중 많은 부분은 그러한 스캐폴딩을 적정 규모로 제공하는 것이 목적이다. 코스모스 DB를 근간으로, 쿠버네티스를 스캐폴딩으로 활용한다면 이제는 자체 분산 애플리케이션 구축에 나설 공간이 많다. 애저 펑션즈부터 시작해 구축해 올라가면 된다.  editor@itworld.co.kr


2019.05.10

새로운 애저 서비스의 핵심은 쿠버네티스와 코스모스 DB

Simon Bisson | InfoWorld
마이크로소프트는 스스로 세 클라우드 회사라고 지칭하기 시작했다. 엑스박스 게이밍 클라우드, 마이크로소프트 365 업무 생산성 서비스, 그리고 가장 중요한 애저가 바로 그 세 클라우드이다. 아마존 웹 서비스(AWS)에 이은 업계 2위의 애저는 초거대 규모의 클라우드로, 미처 따라잡기 힘든 속도로 서비스를 속속 출시하고 있다. 이 속도는 마이크로소프트 3대 개발자 행사에서 더욱 잘 드러나는데, 개발자라면 쏟아져 나오는 발표 내용을 철저히 살펴 봐야 핵심 요소들을 파악할 수 있다.
 
ⓒGettyImageBank

마이크로소프트가 확실히 주력하고 있는 것은 서버리스 애플리케이션 구축 플랫폼으로서의 애저이다. 이를 통해, 가상머신을 지정할 필요가 없고 초 단위 CPU 사용 시간 별로 비용을 청구하는 인프라 서비스를 제공한다. 애플리케이션에는 머신러닝, 분석, 저장, 연산 등이 가능하도록 매우 다양한 플랫폼 서비스가 자리하고 있다. 

상황이 흥미로워지는 곳은 2가지가 만나는 지점이다. 즉, 단일 애저 리전 내에서나 애저 퍼블릭 클라우드 전체에 걸쳐 코드의 확장성을 개선하기 시작하는 지점이다. 분산 애플리케이션은 수작업 구축이 쉽지 않다. 마이크로소프트는 익숙한 도구와 새로운 기능을 모두 활용하여 확장성 자동화 방식을 더 많이 제공한다.
 

쿠버네티스에서의 이벤트 주도 규모 조정 

애저는 다른 대형 퍼블릭 클라우드처럼 쿠버네티스에 크게 의존한다. 하이퍼스케일 연산 작업 시에는 분산 애플리케이션의 관리와 조율이 필수적이다. 이 때, 애플리케이션을 고립된 컨테이너로 제공하면 구축 시스템으로부터 완전한 인프라를 제공하는 절차가 단순해진다.

단, 쿠버네티스는 복잡할 수 있다. 간단한 이벤트 주도 애플리케이션용으로 사용할 때 특히 그렇다. 자바스크립트로 조율되는 쿠버네티스를 갖춘 브리게이드(Brigade)를 쓰는 방법이 있다. 단, 이벤트를 트리거시키거나 요구에 따라 새로운 서버리스 기능을 시작하기 위해 애저의 이벤트그리드(EventGrid)와 같은 도구를 사용 중이라면, 필요한 규모 조정 기능은 제공하지는 않는다.

마이크로소프트와 레드햇은 KEDA(Kubernetes-based event-driven autoscaling)를 확장성 있는 대안으로 공동 개발했다. KEDA의 목적은 워크로드를 빠르게 확장하는 것이다. 이를 위해 HTTP 이벤트 대신 자체 트리거를 사용한다. 애플리케이션은 필요에 따라 규모가 확장되기도 하고 (심지어 0까지) 축소되기도 한다. 이러한 규모 조정은 워크로드 성능 기반의 보다 일반적인 방식 대신 다른 애플리케이션과 서비스의 알림을 활용한다.

규모 조정에 KEDA를 사용함으로써 이벤트에 대응해 컨테이너를 제공해 해당 이벤트와 관련된 데이터를 처리할 준비를한다. 애저의 펑션즈(Functions)과 유사한 모델이다. 기존 애저 펑션즈 코드로 쿠버네티스 애플리케이션에 호스팅하는 방식의 일종으로, KEDA를 마이크로소프트가 제공한다는 것이 놀라운 일은 아니다. 애저 펑션즈가 컨테이너에 있고 이벤트에 의해 트리거 된다면, 쿠버네티스 클러스터를 빠르게 확장해 수요에 대처할 수 있다. 즉, 더 이상 필요하지 않은 컨테이너는 정지된다.

쿠버네티스 컨테이너에 애저 펑션즈를 넣으면 특정 클라우드에 종속되는 현상을 피하는 데 도움이 된다. KEDA를 사용한다는 것은 서버리스 애플리케이션이 애저에서, 온프레미스에서 또는 그 어떤 클라우드 상에서도 실행 가능하다는 것을 의미한다. 쿠버네티스 인프라나 자체 가상 서버에 KEDA를 지원하는 호스트만 있으면 된다. 
 

코스모스 DB에서 글로벌 데이터 분석

필자는 코스모스 DB에 여전히 매료되어 있다. 사용 요금은 싸지 않을지 몰라도, 진정한 글로벌 확장이 가능한 분산 데이터베이스를 제공한다. 이 때 데이터베이스의 복제 모델에 애플리케이션을 맞추는 것이 아니라 애플리케이션 작동 방식에 맞추기 위한 새로운 일관성 모델을 활용한다. 

지금까지는 유용한 저장소였지만 분석 기능은 제한되어 있었다. 분석 기능이 필요하다면 다른 시스템을 채울 쿼리를 사용해야 했다. 그러나 대규모 코스모스 DB 구현물 중에는 페타바이트에 달하는 데이터를 저장하는 것이 있다. 따라서 같은 규모의 부차적인 분석 시스템을 정당화하기는 어렵다.

코스모스 DB의 최신 릴리즈에는 아파치 스파크 API가 추가되어 모든 지역의 모든 코스모스 DB 파티션에 대한 쿼리를 지원한다. 쿼리는 해당 코스모스 DB 데이터의 가장 가까운 복제본에 대해 실행된다. 이를 통해 자체 데이터 형식에서 스파크의 네이티브 형식으로 변환 처리된다. 

코스모스 DB 분석 기능 개발을 돕기 위해 이제 데이터 모델 전반에 걸쳐 주피터(Jupyter) 노트북이 지원된다. 따라서, 노트북에서 쿼리를 구축, 실행한 후 동료들과 공유할 수 있다. 주피터와 관련 도구들을 활용해 머신러닝 모델들을 쉽게 실험할 수 있다. 따라서 자체 데이터를 기반으로 직접 머신러닝을 개발할 수 있다. 코스모스DB를 머신러닝 훈련에 사용하고 추론 데이터의 원천으로 사용함으로써 개발 주기가 짧아진다.
 

코스모스 DB로 쿠버네티스 규모 조정

분산 데이터베이스는 대용량 데이터 작업을 위한 도구인 것만은 아니다. 저장소의 분산 특성이 중요한 소규모 애플리케이션을 지원할 수 있다. 여기서 코스모스 DB를 애플리케이션 인프라의 일부로 만들어 애플리케이션 관리 데이터를 코드에 가장 가까운 곳에 두는 것이다. 코드 구축, 인프라 구축, 구성 정보 저장을 각각 한번씩 하고 난 후 코스모스 DB를 사용해 해당 데이터를 전 세계적으로 공유한다.

etcd는 쿠버네티스의 핵심 구성요소 중 하나로, 구성 및 상태 데이터를 보관한다. 마이크로소프트는 쿠버네티스를 애저에서 적정 규모로 실행하며, 쿠버네티스 구성 데이터를 위한 분산 저장소가 필요하다. 코스모스 DB는 애저의 데이터 인프라 중 많은 부분에서 근간 역할을 하며, 이 용도에도 적합해 한동안 이 역할을 감당해 왔다. 현재 etcd 지원은 일반인 대면 서비스로 변환되고 있다. 제대로 테스트를 거친 내부 API가 있으면, 개발자 전원을 지원하는 방향으로 가는 것이 타당하다. etcd를 사용하는 오픈소스 인프라 서비스가 점점 더 많아지고 있기 때문이다.

etcd 데이터에 코스모스 DB를 사용하면 전 세계적으로 복제되는 쿠버네티스 애플리케이션 구축이 더 쉬워진다. 모든 지역에 etcd 복사본을 두고 이를 호스팅 하기 위한 서버를 유지할 필요 없이, 장소를 막론하고 쿠버네티스 클러스터 전체에 대한 구성 데이터를 호스팅하는 코스모스 DB 인스턴스 하나만 둘 수 있다. 구성 변경은 한번만 하면 되므로 배치 및 업데이트의 실패 위험이 줄어든다.

마이크로소프트의 새로운 유행 기술 용어는 “스캐폴딩(scaffolding)”이다. 건축물의 비계처럼, 플랫폼 위에 구축되는 도구와 서비스를 지원하기 위한 프레임워크를 제공하는 것이다. 애저와의 작업 중 많은 부분은 그러한 스캐폴딩을 적정 규모로 제공하는 것이 목적이다. 코스모스 DB를 근간으로, 쿠버네티스를 스캐폴딩으로 활용한다면 이제는 자체 분산 애플리케이션 구축에 나설 공간이 많다. 애저 펑션즈부터 시작해 구축해 올라가면 된다.  editor@itworld.co.kr


X