개발자

카산드라와 쿠버네티스를 함께 실행하는 방법

Patrick McFadin | InfoWorld 2020.10.07
클라우드에서 애플리케이션을 배포하는 개발자 사이에서 컨테이너의 인기가 날로 높아진다. 이러한 새로운 애플리케이션을 관리하기 위한 컨테이너 오케스트레이션에서 쿠버네티스가 사실상 표준으로 자리잡았다. 쿠버네티스로 개발자는 수요에 따라 탄력적으로, 자동으로 확장되는 분산 애플리케이션을 구축할 수 있다.
 
쿠버네티스는 프로덕션 내의 스테이트리스(stateless) 애플리케이션 워크로드를 간단히 배포, 확장, 관리하기 위한 목적으로 개발됐다. 스테이트풀(stateful) 클라우드 네이티브 데이터에 대해서도 이와 같이 배포 및 확장이 쉬워야 한다는 요구가 예전부터 있었다.
 
분산 데이터베이스에서 향후 데이터를 수평 확장해야 하는 개발자들에게 카산드라(Cassandra)는 매력적이다. 여러 위치와 클라우드 서비스에 걸쳐 동일한 방식으로 실행 가능한, 완전한 내결함성(fault tolerant) 데이터베이스 및 데이터 관리 접근 방식을 제공하기 때문이다. 카산드라의 모든 노드는 동등하고 각 노드가 읽기 및 쓰기 요청을 처리할 수 있으므로 카산드라 모델에는 단일 실패 지점이 없다. 단일 인스턴스의 손실이 애플리케이션에 영향을 미치는 일이 없도록 실패 영역 간에 자동으로 데이터가 복제된다.
 
ⓒ Getty Images Bank
 

카산드라를 쿠버네티스에 연결하기

논리적인 다음 단계는 카산드라와 쿠버네티스를 함께 사용하는 것이다. 분산 데이터베이스를 분산 애플리케이션 환경과 함께 실행하면 데이터와 애플리케이션 작업을 상호 가까운 곳에서 처리할 수 있기 때문이다. 이렇게 하면 지연이 방지될 뿐만 아니라 대규모에서 성능을 개선하는 데도 도움이 된다.
 
그러나 이를 달성하기 위해서는 결정을 내리는 주 시스템을 알아야 한다. 카산드라에는 쿠버네티스가 제공할 수 있는 일종의 내결함성과 노드 배치가 이미 있으므로 어느 시스템이 결정을 내리는지를 아는 것이 중요하다. 이 용도로는 쿠버네티스 오퍼레이터(Kubernetes operator)를 사용하면 된다.
 
오퍼레이터는 도메인별 정보가 필요하고 외부 시스템과 상호작용해야 하는 복잡한 애플리케이션의 배포 및 관리 과정을 자동화한다. 오퍼레이터가 개발되기 전에는 데이터베이스 인스턴스와 같은 스테이트풀 애플리케이션 구성요소는 곧 데브옵스 팀에게는 더 많은 책임을 의미했다. 인스턴스를 준비하고 스테이트풀 방식으로 실행하기 위한 수작업이 필요했기 때문이다.

카산드라 커뮤니티에서 개발된 카산드라용 오퍼레이터는 여러 가지가 있다. 이 예제에서는 데이터스택스(DataStax)가 만들어 오픈소스로 공개한 cass-operator를 사용한다. 오픈소스 쿠버네티스, 구글 쿠버네티스 엔진(GKE), 아마존 일래스틱 쿠버네티스 서비스(EKS), 피보탈 컨테이너 서비스(PKS)를 지원하므로 각자의 환경에 가장 잘 맞는 쿠버네티스 서비스를 사용할 수 있다.
 
쿠버네티스 클러스터 실행에 관한 기본 지식이 있다면 쿠버네티스 클러스터에 cass-operator를 설치하는 과정은 간단하다. 쿠버네티스 클러스터 명령줄 툴인 kubectl을 사용하여 쿠버네티스 클러스터가 인증되고 쿠버네티스 클라우드 인스턴스(오픈소스 쿠버네티스, GKE, EKS 또는 PKS)가 로컬 머신에 연결되면 클러스터에 cass-operator 구성 YAML 파일을 적용할 수 있다.
 

cass-operator 정의 설정하기

다음 단계는 cass-operator 매니페스트, 스토리지 클래스 및 데이터센터를 위한 정의를 쿠버네티스 클러스터에 적용하는 것이다.
 
데이터센터의 정의에 대해 간략히 살펴보고 넘어가자. 참고로 다음은 물리적 데이터센터에 대한 참조가 아닌 카산드라에 사용되는 정의를 기반으로 한다.
 
계층 구조는 다음과 같다.

•    노드는 카산드라 인스턴스를 실행하는 컴퓨터 시스템을 가리킨다. 노드는 물리적 호스트, 클라우드의 머신 인스턴스이거나 도커 컨테이너일 수도 있다.
•    랙은 서로 근접한 카산드라 노드 집합을 가리킨다. 랙은 공통 네트워크 스위치에 연결된 노드를 포함하는 물리적 랙일 수 있다. 그러나 클라우드 환경에서 랙은 같은 가용성 영역에서 실행 중인 머신 인스턴스 집합을 나타내는 경우가 많다.
•    데이터센터는 일반적으로 동일한 건물 내에 위치하며 안정적인 네트워크로 연결된 논리적 랙 모음을 가리킨다. 클라우드 환경에서 데이터센터는 일반적으로 하나의 클라우드 지역에 매핑된다.
•    클러스터는 동일한 애플리케이션을 지원하는 데이터센터 모음을 가리킨다. 카산드라 클러스터는 단일 클라우드 환경 또는 물리적 데이터센터에서 실행되거나, 회복성을 높이고 지연을 낮추기 위해 여러 위치로 분산될 수 있다.
 
명칭을 알아봤으니 이제 정의를 설정할 차례다. 예제에서는 GKE를 사용하지만 다른 쿠버네티스 엔진의 경우에도 프로세스는 비슷하다. 다음과 같은 3단계로 구성된다.
 

1단계

먼저, YAML 구성 파일을 참조하는 kubectl 명령어를 실행해야 한다. 이는 cass-operator 매니페스트의 정의를 연결된 쿠버네티스 클러스터에 적용한다. 매니페스트는 API 개체 설명으로, 개체(여기서는 카산드라 오퍼레이터)의 원하는 상태를 기술한다. 버전별 매니페스트 전체는 이 깃허브 페이지에 나와 있다.
 
다음은 쿠버네티스 1.16을 실행하는 GKE 클라우드에 대한 kubectl 명령 예제다.
kubectl create -f https://raw.githubusercontent.com/datastax/cass-operator/v1.3.0/docs/user/cass-operator-manifests-v1.16.yaml

2단계


다음 kubectl 명령은 클러스터의 카산드라 노드에 사용할 스토리지 설정을 정의하는 YAML 구성에 적용된다. 쿠버네티스는 StorageClass 리소스를 지속 스토리지를 필요로 하는 팟(pod)과 특정 쿠버네티스 클러스터가 제공할 수 있는 물리적 스토리지 리소스 사이의 추상화 계층으로 사용한다. 예제에서는 SSD를 스토리지 유형으로 사용한다. 더 많은 옵션은 이 깃허브 페이지에서 볼 수 있다. 아래 스토리지 구성에 적용된 YAML은 여기서 볼 수 있다.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: server-storage
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd
  replication-type: none
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete

3단계

마지막으로, 다시 kubectl을 사용해서 카산드라 데이터센터를 정의하는 YAML을 적용한다.
# Sized to work on 3 k8s workers nodes with 1 core / 4 GB RAM
# See neighboring example-cassdc-full.yaml for docs for each parameter
apiVersion: cassandra.datastax.com/v1beta1
kind: CassandraDatacenter
metadata:
  name: dc1
spec:
  clusterName: cluster1
  serverType: cassandra
  serverVersion: "3.11.6"
  managementApiAuth:
    insecure: {}
  size: 3
  storageConfig:
    cassandraDataVolumeClaimSpec:
      storageClassName: server-storage
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 5Gi
  config:   
    cassandra-yaml:
      authenticator: org.apache.cassandra.auth.PasswordAuthenticator
      authorizer: org.apache.cassandra.auth.CassandraAuthorizer
      role_manager: org.apache.cassandra.auth.CassandraRoleManager
    jvm-options:
      initial_heap_size: "800M"
      max_heap_size: "800M"

이 예제 YAML은 오픈소스 아파치 카산드라 3.11.6 이미지용이며 쿠버네티스 클러스터에는 하나의 랙에 3개의 노드가 있다. 직접 링크는 여기다. 데이터베이스별 전체 데이터센터 구성은 이 깃허브 페이지에서 볼 수 있다.
 
지금까지 만든 리소스는 클라우드 콘솔에서 볼 수 있다. 예를 들어 구글 클라우드 콘솔에서 클러스터(Clusters) 탭을 클릭하여 실행 중인 요소와 워크로드를 볼 수 있다. 이러한 워크로드는 쿠버네티스 클러스터에서 만들고 관리할 수 있는, 배포 가능한 컴퓨팅 유닛이다.
 
배포된 카산드라 데이터베이스 자체에 연결하려면 명령줄 셀인 cqlsh를 사용해서 쿠버네티스 클러스터 내의 CQL을 사용해 카산드라를 쿼리하면 된다. 인증이 되면 DDL 명령을 제출해서 테이블 등을 만들거나 변경하고 DML 명령어로 데이터를 조작할 수 있다(예를 들어 CQL의 삽입 및 업데이트).
 

카산드라와 쿠버네티스의 다음 단계는?

아파치 카산드라에서 사용할 수 있는 오퍼레이터는 여러 가지지만 예전부터 공용 오퍼레이터에 대한 요구가 있었다. 스카이(Sky), 오렌지(Orange), 데이터스택스(DataStax), 인스터클러스터(Instaclustr) 등 카산드라 커뮤니티에서 활동하는 여러 기업이 쿠버네티스의 아파치 카산드라를 위한 공용 오퍼레이터를 구축하기 위해 협력 중이다. 이 협력은 기존 오픈소스 오퍼레이터와 함께 진행되며, 목표는 기업과 사용자에게 컴퓨팅과 데이터를 위한 일관적인 수평 확장 스택을 제공하는 것이다.
 
장기적으로 보면 클라우드 네이티브 애플리케이션으로의 전환은 클라우드 네이티브 데이터로 지원되어야 한다. 이 과정은 쿠버네티스와 같은 툴로 실현되는 자동화에 더 많이 의존하게 된다. 쿠버네티스와 카산드라를 함께 사용하면 데이터에 대한 접근 방식을 클라우드 네이티브화할 수 있다. editor@itworld.co.kr 

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.