2019.11.29

이벤트 중심 워크로드를 위한 쿠버네티스 자동 확장

Simon Bisson | InfoWorld
쿠버네티스는 다양한 형태로 사용할 수 있는, 분산 시스템 구축을 위한 강력한 툴이다. 다만 한 가지 큰 문제는 설계상 쿠버네티스는 리소스 기반 확장만 제공한다는 점이다. 사실 쿠버네티스의 역사를 보면(AWS에 대응하기 위한 구글 내부의 보그(Borg) 서비스에서 시작됨) 이해하지 못할 것도 없다. 쿠버네티스가 목표로 한 애플리케이션과 서비스의 대부분은 리소스에 얽매이고 대량의 데이터를 다루며 메모리와 CPU에 의존했기 때문이다.
 
ⓒ GettyImagesBank

분산 애플리케이션이라고 해서 모두 그렇지는 않다. 많은 애플리케이션, 특히 IoT 시스템과 연동하는 애플리케이션은 이벤트에 신속하게 대응해야 한다. 여기서 가장 중요한 요소는 수요에 따라 프로세스를 트리거하는 이벤트와 메시지를 제공하는 I/O다. 이른바 서버리스 컴퓨팅과 잘 맞는 모델이다. 서버리스 모델의 대부분은 수요에 따라 새로운 컴퓨팅 컨테이너를 신속하게 가동하는 데 의존하는데, 이 모델은 자체 컨트롤러가 있는 전용 가상 인프라에서 잘 작동하지만 쿠버네티스의 리소스 중심 확장과의 호환성은 그다지 좋지 않다.
 

KEDA: 쿠버네티스 기반 이벤트 중심 자동 확장

마이크로소프트와 레드햇은 쿠버네티스에 이벤트 중심 확장성을 추가할 방법을 개발하기 위해 협력해왔고, 그 결과로 2019년 5월 마이크로소프트 빌드(Build) 컨퍼런스에서 오픈소스 KEDA 프로젝트를 발표했다. 이 초기 KEDA 코드는 나온 직후부터 많은 관심을 끌었는데, 최근에는 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)의 채택을 목적으로 하는 1.0 버전이 공개됐다.

KEDA는 아무 쿠버네티스 클러스터에서나 실행할 수 있으며, 확장을 이끄는 데 사용할 수 있는 새로운 메트릭스 집합을 지원한다. 이제 CPU와 메모리의 부하에만 대응하지 않고 이벤트의 수신 속도에도 대응할 수 있고, 덕분에 큐 지연과 이벤트 데이터 손실 위험이 줄어든다. 메시지 볼륨과 CPU 수요는 직접적으로 연결되지 않으므로 KEDA가 구현된 클러스터는 메시지가 도착하는 대로 새 인스턴스를 스폰할 수 있다. 일반적인 쿠버네티스 메트릭스를 사용한 대응에 비해 훨씬 더 빠르다. 또한 큐가 비어 있는 경우 클러스터를 0까지 축소해서 비용을 최소한으로 유지하고 쿠버네티스 클러스터가 애저 펑션처럼 작동하도록 한다.
 

KEDA 배치

마이크로소프트의 최근 분산 애플리케이션 툴 추세에 따라 KEDA 역시 명확한 플랫폼 무관(platform agnostic) 툴이다. 최대한 많은 플랫폼을 지원하는 쿠버네티스의 접근 방법과 배포판 간에 플랫폼 포크를 지양하자는 비공식적인 협의를 감안하면 당연한 속성이다. 마이크로소프트는 애저 펑션의 일부로 KEDA를 설치하는 방법을 제공하지만 헬름(Helm) 차트나 YAML을 사용해서 아무 쿠버네티스 설치에나 추가할 수 있다.

헬름으로 배치하는 방법이 아마 가장 좋을 것이다. 손쉽게 스크립트로 작성해서 인프라 리포지토리에 추가할 수 있기 때문이다. KEDA를 설치하려면 KEDA의 깃허브 리포지토리를 헬름 설치에 추가한다. KEDA 차트를 사용하도록 헬름 리포지토리를 업데이트하고 나면 사용 중인 헬름 버전에 맞는 적절한 설치 명령을 실행한다. 헬름 3 사용자는 차트를 실행하기에 앞서 kubectl을 사용해서 쿠버네티스 설치에 네임스페이스를 추가해야 한다.

설치한 후에는 원하는 스케일러와 작동하도록 KEDA를 구성해야 한다. KEDA 용어로 스케일러는 쿠버네티스 애플리케이션을 확장하는 데 사용되는, 이벤트 소스를 모니터링하는 툴이다. 직접 만들 수도 있지만 KEDA 커뮤니티에서 아파치 카프카부터 애저 이벤트 허브, AWS 클라우드워치와 GCP의 펍/섭(Pub/Sub) 툴에 이르기까지 대부분의 일반적인 시나리오를 포괄하는 스케일러 모음을 찾을 수 있다.
 

KEDA 자동 확장의 내부

KEDA는 두 가지 핵심 쿠버네티스 역할을 구현하며 이 역할은 쿠버네티스 클러스터에 별도의 컨테이너로 배치된다. 첫 번째인 keda-operator는 컨트롤러이며 다른 컨테이너를 관리하면서 필요에 따라 확장, 축소한다. 두 번째 역할 keda-operator-metrics-apiserver는 포드(pod)의 확장 서비스를 관리하면서 큐 길이 등의 정해진 메트릭스가 감지될 때 클러스터를 확장한다. KEDA는 이벤트 관리를 위한 툴이 아니다. 포드 코드가 이벤트를 처리해야 한다. KEDA가 하는 일은 데이터 손실 또는 심각한 시스템 지연을 방지하기 위해 클러스터가 항상 최적의 인스턴스 수를 갖도록 큐를 모니터링하는 것이 전부다.

이벤트 중심 확장을 구현하기는 어렵지 않다. 스케일러가 이벤트 소스에 연결되면 KEDA가 동일한 네임스페이스의 쿠버네티스 배치에 연결된다. 쿠버네티스의 대부분이 그렇듯이 KEDA의 동작도 맞춤 리소스 정의를 사용해서 XAML로 기술된다. 먼저 확장 동작을 위한 사양을 정의하고 대상과 폴링 간격, 쿨다운 기간을 나열하고 최소/최대 복제본 수도 지정한다. 모두 기본값이 제공되지만 적절히 조정하는 것이 좋다.

기본 폴링 간격은 30초다. 이벤트 빈도가 낮은 경우에는 적당하지만 처리할 데이터가 많은 경우 큐 백로그를 방지하려면 이 수치를 늘리는 것이 좋다. 마찬가지로 쿨다운 간격도 사용 중인 클라우드 제공업체의 컨테이너 비용 청구 정책에 따라 적절히 변경해야 한다.
 

KEDA 적절히 구성하기

KEDA를 구성할 때는 이벤트 중심 애플리케이션의 기반 패턴을 이해하는 것이 중요하다. 예를 들어 적절한 쿨다운 기간을 선택하면 활성 컨테이너의 수를 최소한으로 유지해서 비용을 낮출 수 있다. 그러나 새 컨테이너를 시작할 때 지연이 발생하고 이로 인해 시스템 속도가 저하된다. 많은 경우 최선의 방법은 신속한 응답 시간을 보장하는 데 필요한 최소한의 복제본 수를 유지하는 것이다. 이것이 애플리케이션의 경제 모델에 맞는지 여부는 각자가 판단해야 할 부분이다.

장기간 실행되는 이벤트가 있는 경우 KEDA를 사용한 배포 확장이 문제가 될 수 있다. 컨테이너가 쿠버네티스의 자체 컨트롤러에 의해 관리되므로 이벤트가 아직 처리되고 있는 중에도 리소스가 정리될 수 있기 때문이다. 대안은 이벤트가 단일 작업(생성, 실행되어 단일 메시지를 처리한 후 종료되는 작업)으로 취급되도록 KEDA를 쿠버네티스 작업과 함께 사용하는 것이다. 애저 펑션으로 컨테이너를 호스팅하는 이 접근 방법으로 서버리스 코드를 클라우드 간에 그리고 자체 인프라로 옮길 수 있다.

마이크로소프트가 KEDA와 같은 툴에서 레드햇과 협력하는 모습은 흥미롭다. 클라우드 애플리케이션은 하나의 공용 클라우드에 묶여서는 안 된다. 그런 면에서 플랫폼 무관 쿠버네티스 서비스는 공용 클라우드의 울타리를 부수고 나오기 위한 중요한 툴이다. KEDA를 사용한다는 것은 인증된 쿠버네티스 배포판, 중앙화된 하이퍼스케일 서비스, 그리고 라즈베리 파이 클러스터에서 실행되는 엣지 구현에 이르기까지, 모든 곳에서 동일한 서버리스 애플리케이션을 실행할 수 있음을 의미한다. editor@itworld.co.kr


2019.11.29

이벤트 중심 워크로드를 위한 쿠버네티스 자동 확장

Simon Bisson | InfoWorld
쿠버네티스는 다양한 형태로 사용할 수 있는, 분산 시스템 구축을 위한 강력한 툴이다. 다만 한 가지 큰 문제는 설계상 쿠버네티스는 리소스 기반 확장만 제공한다는 점이다. 사실 쿠버네티스의 역사를 보면(AWS에 대응하기 위한 구글 내부의 보그(Borg) 서비스에서 시작됨) 이해하지 못할 것도 없다. 쿠버네티스가 목표로 한 애플리케이션과 서비스의 대부분은 리소스에 얽매이고 대량의 데이터를 다루며 메모리와 CPU에 의존했기 때문이다.
 
ⓒ GettyImagesBank

분산 애플리케이션이라고 해서 모두 그렇지는 않다. 많은 애플리케이션, 특히 IoT 시스템과 연동하는 애플리케이션은 이벤트에 신속하게 대응해야 한다. 여기서 가장 중요한 요소는 수요에 따라 프로세스를 트리거하는 이벤트와 메시지를 제공하는 I/O다. 이른바 서버리스 컴퓨팅과 잘 맞는 모델이다. 서버리스 모델의 대부분은 수요에 따라 새로운 컴퓨팅 컨테이너를 신속하게 가동하는 데 의존하는데, 이 모델은 자체 컨트롤러가 있는 전용 가상 인프라에서 잘 작동하지만 쿠버네티스의 리소스 중심 확장과의 호환성은 그다지 좋지 않다.
 

KEDA: 쿠버네티스 기반 이벤트 중심 자동 확장

마이크로소프트와 레드햇은 쿠버네티스에 이벤트 중심 확장성을 추가할 방법을 개발하기 위해 협력해왔고, 그 결과로 2019년 5월 마이크로소프트 빌드(Build) 컨퍼런스에서 오픈소스 KEDA 프로젝트를 발표했다. 이 초기 KEDA 코드는 나온 직후부터 많은 관심을 끌었는데, 최근에는 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)의 채택을 목적으로 하는 1.0 버전이 공개됐다.

KEDA는 아무 쿠버네티스 클러스터에서나 실행할 수 있으며, 확장을 이끄는 데 사용할 수 있는 새로운 메트릭스 집합을 지원한다. 이제 CPU와 메모리의 부하에만 대응하지 않고 이벤트의 수신 속도에도 대응할 수 있고, 덕분에 큐 지연과 이벤트 데이터 손실 위험이 줄어든다. 메시지 볼륨과 CPU 수요는 직접적으로 연결되지 않으므로 KEDA가 구현된 클러스터는 메시지가 도착하는 대로 새 인스턴스를 스폰할 수 있다. 일반적인 쿠버네티스 메트릭스를 사용한 대응에 비해 훨씬 더 빠르다. 또한 큐가 비어 있는 경우 클러스터를 0까지 축소해서 비용을 최소한으로 유지하고 쿠버네티스 클러스터가 애저 펑션처럼 작동하도록 한다.
 

KEDA 배치

마이크로소프트의 최근 분산 애플리케이션 툴 추세에 따라 KEDA 역시 명확한 플랫폼 무관(platform agnostic) 툴이다. 최대한 많은 플랫폼을 지원하는 쿠버네티스의 접근 방법과 배포판 간에 플랫폼 포크를 지양하자는 비공식적인 협의를 감안하면 당연한 속성이다. 마이크로소프트는 애저 펑션의 일부로 KEDA를 설치하는 방법을 제공하지만 헬름(Helm) 차트나 YAML을 사용해서 아무 쿠버네티스 설치에나 추가할 수 있다.

헬름으로 배치하는 방법이 아마 가장 좋을 것이다. 손쉽게 스크립트로 작성해서 인프라 리포지토리에 추가할 수 있기 때문이다. KEDA를 설치하려면 KEDA의 깃허브 리포지토리를 헬름 설치에 추가한다. KEDA 차트를 사용하도록 헬름 리포지토리를 업데이트하고 나면 사용 중인 헬름 버전에 맞는 적절한 설치 명령을 실행한다. 헬름 3 사용자는 차트를 실행하기에 앞서 kubectl을 사용해서 쿠버네티스 설치에 네임스페이스를 추가해야 한다.

설치한 후에는 원하는 스케일러와 작동하도록 KEDA를 구성해야 한다. KEDA 용어로 스케일러는 쿠버네티스 애플리케이션을 확장하는 데 사용되는, 이벤트 소스를 모니터링하는 툴이다. 직접 만들 수도 있지만 KEDA 커뮤니티에서 아파치 카프카부터 애저 이벤트 허브, AWS 클라우드워치와 GCP의 펍/섭(Pub/Sub) 툴에 이르기까지 대부분의 일반적인 시나리오를 포괄하는 스케일러 모음을 찾을 수 있다.
 

KEDA 자동 확장의 내부

KEDA는 두 가지 핵심 쿠버네티스 역할을 구현하며 이 역할은 쿠버네티스 클러스터에 별도의 컨테이너로 배치된다. 첫 번째인 keda-operator는 컨트롤러이며 다른 컨테이너를 관리하면서 필요에 따라 확장, 축소한다. 두 번째 역할 keda-operator-metrics-apiserver는 포드(pod)의 확장 서비스를 관리하면서 큐 길이 등의 정해진 메트릭스가 감지될 때 클러스터를 확장한다. KEDA는 이벤트 관리를 위한 툴이 아니다. 포드 코드가 이벤트를 처리해야 한다. KEDA가 하는 일은 데이터 손실 또는 심각한 시스템 지연을 방지하기 위해 클러스터가 항상 최적의 인스턴스 수를 갖도록 큐를 모니터링하는 것이 전부다.

이벤트 중심 확장을 구현하기는 어렵지 않다. 스케일러가 이벤트 소스에 연결되면 KEDA가 동일한 네임스페이스의 쿠버네티스 배치에 연결된다. 쿠버네티스의 대부분이 그렇듯이 KEDA의 동작도 맞춤 리소스 정의를 사용해서 XAML로 기술된다. 먼저 확장 동작을 위한 사양을 정의하고 대상과 폴링 간격, 쿨다운 기간을 나열하고 최소/최대 복제본 수도 지정한다. 모두 기본값이 제공되지만 적절히 조정하는 것이 좋다.

기본 폴링 간격은 30초다. 이벤트 빈도가 낮은 경우에는 적당하지만 처리할 데이터가 많은 경우 큐 백로그를 방지하려면 이 수치를 늘리는 것이 좋다. 마찬가지로 쿨다운 간격도 사용 중인 클라우드 제공업체의 컨테이너 비용 청구 정책에 따라 적절히 변경해야 한다.
 

KEDA 적절히 구성하기

KEDA를 구성할 때는 이벤트 중심 애플리케이션의 기반 패턴을 이해하는 것이 중요하다. 예를 들어 적절한 쿨다운 기간을 선택하면 활성 컨테이너의 수를 최소한으로 유지해서 비용을 낮출 수 있다. 그러나 새 컨테이너를 시작할 때 지연이 발생하고 이로 인해 시스템 속도가 저하된다. 많은 경우 최선의 방법은 신속한 응답 시간을 보장하는 데 필요한 최소한의 복제본 수를 유지하는 것이다. 이것이 애플리케이션의 경제 모델에 맞는지 여부는 각자가 판단해야 할 부분이다.

장기간 실행되는 이벤트가 있는 경우 KEDA를 사용한 배포 확장이 문제가 될 수 있다. 컨테이너가 쿠버네티스의 자체 컨트롤러에 의해 관리되므로 이벤트가 아직 처리되고 있는 중에도 리소스가 정리될 수 있기 때문이다. 대안은 이벤트가 단일 작업(생성, 실행되어 단일 메시지를 처리한 후 종료되는 작업)으로 취급되도록 KEDA를 쿠버네티스 작업과 함께 사용하는 것이다. 애저 펑션으로 컨테이너를 호스팅하는 이 접근 방법으로 서버리스 코드를 클라우드 간에 그리고 자체 인프라로 옮길 수 있다.

마이크로소프트가 KEDA와 같은 툴에서 레드햇과 협력하는 모습은 흥미롭다. 클라우드 애플리케이션은 하나의 공용 클라우드에 묶여서는 안 된다. 그런 면에서 플랫폼 무관 쿠버네티스 서비스는 공용 클라우드의 울타리를 부수고 나오기 위한 중요한 툴이다. KEDA를 사용한다는 것은 인증된 쿠버네티스 배포판, 중앙화된 하이퍼스케일 서비스, 그리고 라즈베리 파이 클러스터에서 실행되는 엣지 구현에 이르기까지, 모든 곳에서 동일한 서버리스 애플리케이션을 실행할 수 있음을 의미한다. editor@itworld.co.kr


X