Cassandra 인터페이스

프리뷰 — Cassandra interface

이 기능에는 서비스별 약관의 일반 서비스 약관 항에 있는 'GA 이전 제공 서비스 약관'이 적용됩니다. GA 이전 기능은 '있는 그대로' 제공되며 지원이 제한될 수 있습니다. 자세한 내용은 출시 단계 설명을 참조하세요.

이 페이지에서는 Apache Cassandra와 Spanner 아키텍처를 비교하고 Spanner의 Cassandra 인터페이스 기능과 제한사항을 설명합니다. 이 문서는 Cassandra에 익숙하며 Spanner를 데이터베이스로 사용하면서 기존 애플리케이션을 마이그레이션하거나 새 애플리케이션을 설계하려는 개발자를 대상으로 합니다.

Cassandra와 Spanner 모두 높은 확장성과 짧은 지연 시간이 필요한 애플리케이션을 위해 빌드된 대규모 분산 데이터베이스입니다. 두 데이터베이스 모두 까다로운 NoSQL 워크로드를 지원할 수 있지만 Spanner는 데이터 모델링, 쿼리, 트랜잭션 작업에 사용되는 고급 기능을 제공합니다. Spanner가 NoSQL 데이터베이스 기준을 충족하는 방법에 대한 자세한 내용은 비관계형 워크로드용 Spanner를 참조하세요.

핵심 개념

이 섹션에서는 주요 Cassandra 및 Spanner 개념을 비교합니다.

용어

Cassandra	Spanner
클러스터	인스턴스 Cassandra 클러스터는 서버 및 스토리지 리소스 모음인 Spanner 인스턴스와 같습니다. Spanner는 관리형 서비스이므로 기본 하드웨어나 소프트웨어를 구성할 필요가 없습니다. 인스턴스에 예약할 노드 수를 지정하거나 인스턴스가 자동을 확장되도록 자동 확장을 사용하기만 하면 됩니다. 인스턴스는 데이터베이스용 컨테이너처럼 작동합니다. 또한 인스턴스 수준에서 데이터 복제 토폴로지(리전, 이중 리전 또는 멀티 리전)를 선택합니다.
키스페이스	데이터베이스 Cassandra 키스페이스는 테이블과 기타 스키마 요소(예: 색인 및 역할)의 모음인 Spanner 데이터베이스와 같습니다. 키스페이스와 달리 복제 위치를 구성할 필요가 없습니다. Spanner는 데이터를 자동으로 인스턴스에 지정된 리전에 복제합니다.
표	테이블 Cassandra와 Spanner 모두에서 테이블은 테이블 스키마에 지정된 기본 키로 식별되는 행의 모음입니다.
파티션	분할 Cassandra와 Spanner 모두 데이터 샤딩을 통해 확장됩니다. Cassandra에서는 각 샤드를 파티션이라고 하며 Spanner에서는 각 샤드를 분할이라고 합니다. Cassandra는 해시 파티셔닝을 사용합니다. 즉, 각 행은 기본 키의 해시를 기준으로 스토리지 노드에 독립적으로 할당됩니다. Spanner는 범위로 샤딩됩니다. 즉, 기본 키 키스페이스에서 연속된 행은 스토리지에서도 연속됩니다(분할 경계 제외). Spanner는 부하와 스토리지를 기준으로 분할과 병합을 처리하며 이는 애플리케이션에 투명합니다. 중요한 의미는 Cassandra와 달리 기본 키의 프리픽스를 통한 범위 스캔이 Spanner에서 효율적인 작업이라는 점입니다.
행	행 Cassandra와 Spanner 모두에서 행은 기본 키로 고유하게 식별되는 열의 모음입니다. Cassandra와 마찬가지로 Spanner는 복합 기본 키를 지원합니다. Cassandra와 달리 데이터가 범위로 샤딩되므로 Spanner는 파티션 키와 정렬 키를 구분하지 않습니다. Spanner는 정렬 키만 있고 파티셔닝은 백그라운드에서 관리된다고 생각하면 됩니다.
열	열 Cassandra와 Spanner 모두에서 열은 같은 유형의 데이터 값 집합입니다. 테이블의 각 행에는 값 하나가 있습니다. Cassandra 열 유형을 Spanner와 비교하는 방법에 대한 자세한 내용은 데이터 유형을 참조하세요.

아키텍처

Cassandra 클러스터는 서버와 이러한 서버와 함께 배치된 스토리지의 집합으로 구성됩니다. 해시 함수는 파티션 키스페이스의 행을 가상 노드(vnode)에 매핑합니다. 그런 다음 클러스터 키스페이스의 일부를 처리하기 위해 일련의 vnode가 각 서버에 무작위로 할당됩니다. vnode의 스토리지는 서빙 노드에 로컬로 연결됩니다. 클라이언트 드라이버는 서빙 노드에 직접 연결되고 부하 분산과 쿼리 라우팅을 처리합니다.

Spanner 인스턴스는 복제 토폴로지의 서버 집합으로 구성됩니다. Spanner는 CPU 및 디스크 사용량을 기준으로 동적으로 각 테이블을 행 범위로 샤딩합니다. 샤드는 서빙을 위해 컴퓨팅 노드에 할당됩니다. 데이터는 컴퓨팅 노드와는 별개로 Google의 분산 파일 시스템인 Colossus에 물리적으로 저장됩니다. 클라이언트 드라이버는 요청 라우팅과 부하 분산을 수행하는 Spanner의 프런트엔드 서버에 연결됩니다. 자세한 내용은 Spanner 읽기 및 쓰기 수명 백서를 참조하세요.

대략적으로 두 아키텍처 모두 리소스가 기본 클러스터에 추가될 때 확장됩니다. Spanner의 컴퓨팅 및 스토리지 분리를 통해 워크로드 변경에 따라 컴퓨팅 노드 간의 로드가 더 빠르게 다시 분산됩니다. Cassandra와 달리 데이터가 Colossus에 유지되므로 샤드가 이동할 때 데이터가 이동하지 않습니다. 또한 데이터가 파티션 키로 정렬될 것으로 예상되는 애플리케이션에는 Spanner의 범위 기반 파티셔닝이 더 자연스러울 수 있습니다. 범위 기반 파티셔닝의 단점은 키스페이스의 한쪽 끝에 쓰는 워크로드(예: 현재 타임스탬프로 키가 지정된 테이블)는 추가 스키마 설계를 고려하지 않으면 부하 집중이 발생할 수 있다는 점입니다. 부하 집중을 해결하는 기법에 대한 자세한 내용은 스키마 설계 권장사항을 참조하세요.

일관성

Cassandra에서는 작업마다 일관성 수준을 지정해야 합니다. 쿼럼 일관성 수준을 사용하는 경우 복제본 노드 대다수가 작업의 조정자 노드에 응답해야 성공한 것으로 간주됩니다. 일관성 수준 1을 사용하는 경우 Cassandra에서 작업이 성공한 것으로 간주되려면 단일 복제본 노드가 응답해야 합니다.

Spanner는 strong consistency를 제공합니다. Spanner API는 복제본을 클라이언트에 노출하지 않습니다. Spanner 클라이언트는 Spanner가 단일 머신 데이터베이스인 것처럼 Spanner와 상호작용합니다. 쓰기는 항상 Spanner가 사용자에게 성공을 보고하기 전에 대부분의 복제본에 작성됩니다. 이후의 읽기는 새로 작성된 데이터를 반영합니다. 애플리케이션은 과거 특정 시점의 데이터베이스 스냅샷을 읽을 수 있으며 이는 강력한 읽기에 비해 성능 이점을 가질 수 있습니다. Spanner의 일관성 속성에 대한 자세한 내용은 트랜잭션 개요를 참조하세요.

Spanner는 대규모 애플리케이션에 필요한 일관성과 가용성을 지원하도록 빌드되었습니다. Spanner는 대규모로 고성능 strong consistency를 제공합니다. 필요한 사용 사례의 경우 Spanner는 최신 요구사항을 완화하는 스냅샷(비활성) 읽기를 지원합니다.

Cassandra 인터페이스

Cassandra 인터페이스를 사용하면 익숙한 Cassandra 도구와 문법을 사용하여 Spanner의 확장 가능하고 가용성이 높은 완전 관리형 인프라를 활용할 수 있습니다. 이 페이지는 Cassandra 인터페이스의 기능과 제한사항을 이해하는 데 도움이 됩니다.

Cassandra 인터페이스 이점

• 이식성: Cassandra 인터페이스는 Cassandra와 호환되는 스키마, 쿼리, 클라이언트를 사용하여 다양한 Spanner 기능에 대한 액세스 권한을 제공합니다. 이를 통해 Spanner에서 빌드된 애플리케이션을 다른 Cassandra 환경으로 또는 그 반대로 이동하는 과정이 간소화됩니다. 이러한 이식성은 배포 유연성을 제공하고 비상시 출구 전략과 같은 재해 복구 시나리오를 지원합니다.
• 기본 지식: 이미 Cassandra를 사용하고 있으면 같은 CQL 문과 유형을 여러 개 사용하여 Spanner를 빠르게 시작할 수 있습니다.
• 타협하지 않는 Spanner: Cassandra 인터페이스는 Spanner의 기존 기반을 기반으로 하므로 보완적인 GoogleSQL 생태계에서 제공되는 기능을 저하시키지 않고도 Spanner의 기존 가용성, 일관성, 가격 대비 성능 이점을 모두 제공합니다.

CQL 호환성

• CQL 언어 지원: Spanner는 데이터 쿼리 언어(DQL), 데이터 조작 언어(DML), 경량 트랜잭션(LWT), 집계 및 날짜 시간 함수를 비롯한 CQL 언어의 하위 집합을 제공합니다.

• 지원되는 Cassandra 기능: Cassandra 인터페이스는 가장 흔히 사용되는 많은 Cassandra 기능을 지원합니다. 여기에는 스키마 및 유형 시스템의 핵심 부분, 여러 일반적인 쿼리 형태, 다양한 함수 및 연산자, Cassandra 시스템 카탈로그의 주요 측면이 포함됩니다. 애플리케이션은 Spanner의 Cassandra 유선 프로토콜 구현을 통해 연결하여 여러 Cassandra 클라이언트나 드라이버를 사용할 수 있습니다.

• 클라이언트 및 유선 프로토콜 지원: Spanner는 애플리케이션과 함께 실행되는 간단한 클라이언트인 Cassandra 어댑터를 사용하여 Cassandra 유선 프로토콜 v4의 핵심 쿼리 기능을 지원합니다. 이를 통해 많은 Spanner의 전역 엔드포인트 및 연결 관리와 IAM 인증을 활용하여 Cassandra 클라이언트가 Spanner Cassandra 인터페이스 데이터베이스를 있는 그대로 사용할 수 있습니다.

지원되는 Cassandra 데이터 유형

다음 표에서는 지원되는 Cassandra 데이터 유형을 보여주며 각 데이터 유형을 해당 Spanner GoogleSQL 데이터 유형에 매핑합니다.

	지원되는 Cassandra 데이터 유형	Spanner GoogleSQL 데이터 유형
숫자 유형	tinyint(부호 있는 8비트 정수)	INT64(부호 있는 64비트 정수) Spanner는 부호 있는 정수의 단일 64비트 전체 데이터 유형을 지원합니다.
	smallint(부호 있는 16비트 정수)
	int(부호 있는 32비트 정수)
	bigint(부호 있는 64비트 정수)
	float(32비트 IEEE-754 부동 소수점)	FLOAT32(32비트 IEEE-754 부동 소수점)
	double(64비트 IEEE-754 부동 소수점)	FLOAT64(64비트 IEEE-754 부동 소수점)
	decimal	고정 정밀도 십진수의 경우 NUMERIC 데이터 유형(정밀도 38, 비율 9)을 사용합니다.
	varint(변수 정밀도 정수)
문자열 유형	text	STRING(MAX) text 및 varchar 모두 UTF-8 문자열을 저장하고 검증합니다. Spanner에서는 STRING 열의 최대 길이를 지정해야 합니다. 스토리지에는 영향을 미치지 않으며 이는 검증을 위한 것입니다.
	varchar
	ascii	STRING(MAX)
	uuid	STRING(MAX)
	inet	STRING(MAX)
	blob	BYTES(MAX) 바이너리 데이터를 저장하려면 BYTES 데이터 유형을 사용합니다.
날짜 및 시간 유형	date	DATE
	time	INT64 Spanner에서는 전용 기간 데이터 유형을 지원하지 않습니다. INT64를 사용하여 나노초 기간을 저장합니다.
	timestamp	TIMESTAMP
컨테이너 유형	set	ARRAY Spanner에서는 전용 set 데이터 유형을 지원하지 않습니다. ARRAY 열을 사용하여 set를 나타냅니다.
	list	ARRAY ARRAY를 사용하여 유형이 지정된 객체 목록을 저장합니다.
	map	JSON Spanner에서는 전용 지도 유형을 지원하지 않습니다. JSON 열을 사용하여 지도를 나타냅니다.
기타 유형	boolean	BOOL
	counter	INT64

데이터 유형 주석

cassandra_type 열 옵션을 사용하면 Cassandra 및 Spanner 데이터 유형 간의 매핑을 정의할 수 있습니다. Spanner에서 Cassandra 호환 쿼리를 사용하여 상호작용할 테이블을 만들 때 cassandra_type 옵션을 사용하여 각 열에 해당하는 Cassandra 데이터 유형을 지정할 수 있습니다. 그런 다음 Spanner는 이 매핑을 사용하여 두 데이터베이스 시스템 간에 데이터를 전송할 때 데이터를 올바르게 해석하고 변환합니다.

예를 들어 Cassandra에 다음과 같은 스키마가 있는 테이블이 있다고 가정해 보겠습니다.

CREATE TABLE Albums (
  albumId uuid,
  title varchar,
  artists set<varchar>,
  tags  map<varchar, varchar>,
  numberOfSongs tinyint,
  releaseDate date,
  copiesSold bigint,
  ....
  PRIMARY KEY(albumId)
)

Spanner에서는 다음과 같이 유형 주석을 사용하여 Cassandra 데이터 유형에 매핑합니다.

CREATE TABLE Albums (
  albumId       STRING(MAX) OPTIONS (cassandra_type = 'uuid'),
  title         STRING(MAX) OPTIONS (cassandra_type = 'varchar'),
  artists       ARRAY<STRING(max)> OPTIONS (cassandra_type = 'set<varchar>'),
  tags          JSON OPTIONS (cassandra_type = 'map<varchar, varchar>'),
  numberOfSongs INT64 OPTIONS (cassandra_type = 'tinyint'),
  releaseDate   DATE OPTIONS (cassandra_type = 'date'),
  copiesSold    INT64 OPTIONS (cassandra_type = 'bigint')
  ...
) PRIMARY KEY (albumId);

참고: cassandra_type 주석이 있는 Spanner 테이블을 만든 후에는 주석을 변경할 수 없습니다. 기존 주석을 변경하거나 해당 테이블의 열에 새 cassandra_type 주석을 추가할 수는 없습니다. cassandra_type 주석을 변경하려면 특정 열 자체를 삭제한 후 다시 만들어야 합니다.

이전 예시에서 OPTIONS 절은 열의 Spanner 데이터 유형을 해당 Cassandra 데이터 유형에 매핑합니다.

• albumId(Spanner STRING(MAX))는 Cassandra에서 uuid에 매핑됩니다.
• title(Spanner STRING(MAX))는 Cassandra에서 varchar에 매핑됩니다.
• artists(Spanner ARRAY<STRING(MAX)>)는 Cassandra에서 set<varchar>에 매핑됩니다.
• tags(Spanner JSON)는 Cassandra에서 map<varchar,varchar>에 매핑됩니다.
• numberOfSongs(Spanner INT64)는 Cassandra에서 tinyint에 매핑됩니다.
• releaseDate(Spanner DATE)는 Cassandra에서 date에 매핑됩니다.
• copiesSold(Spanner INT64)는 Cassandra에서 bigint에 매핑됩니다.

직접적이고 세밀한 매핑

대부분의 경우 Spanner 및 Cassandra 데이터 유형 간의 매핑은 간단합니다. 예를 들어 Spanner STRING(MAX)은 Cassandra varchar에 매핑되고 Spanner INT64는 Cassandra bigint에 매핑됩니다.

그러나 매핑을 더 많이 고려하고 조정해야 하는 경우도 있습니다. 예를 들어 Cassandra smallint를 Spanner INT64에 매핑해야 할 수 있습니다.

지원되는 Cassandra 함수

이 섹션에는 Spanner에서 지원되는 Cassandra 함수가 나와 있습니다.

다음 목록에서는 Cassandra 함수에 대한 Spanner 지원을 보여줍니다.

• 모든 집계 함수
• currentTimeUUID를 제외한 모든 날짜/시간 함수
• 다음 쿼리 함수 중 어느 것도 사용하지 않습니다.
  • WRITETIME
  • TTL
  • TOKEN
  • CAST
• BATCH 조건을 제외한 모든 경량 트랜잭션(LWT) 함수

Spanner에서 지원되지 않는 Cassandra 기능

Cassandra 인터페이스는 Cassandra와 호환되는 스키마, 유형, 쿼리, 클라이언트를 통해 Spanner의 기능을 제공한다는 점을 이해하는 것이 중요합니다. Cassandra의 일부 기능은 지원되지 않습니다. 기존 Cassandra 애플리케이션을 Spanner로 마이그레이션하려면 Cassandra 인터페이스를 사용하더라도 지원되지 않는 Cassandra 기능이나 동작의 차이(예: 쿼리 최적화 또는 기본 키 설계)를 수용하기 위해 약간의 재작업이 필요할 수 있습니다. 하지만 일단 마이그레이션되면 워크로드에서 Spanner의 안정성과 고유한 다중 모델 기능을 활용할 수 있습니다.

다음 목록에는 지원되지 않는 Cassandra 기능에 대한 자세한 내용이 나와 있습니다.

• 지원되지 않는 일부 CQL 언어 기능: 사용자 정의 유형 및 함수, TimeUUID, TTL, 쓰기-타임스탬프
• Spanner 및 Spanner 컨트롤 플레인: Cassandra 인터페이스가 있는 데이터베이스는 Spanner 및 Google Cloud도구를 사용하여 인스턴스를 프로비저닝, 보호, 모니터링, 최적화합니다. Spanner는 관리 활동을 위한 nodetool과 같은 도구를 지원하지 않습니다.

DDL 지원

CQL DDL 문은 Cassandra 인터페이스를 통해 직접 지원되지 않습니다. DDL 변경의 경우 Spanner Google Cloud 콘솔, gcloud 명령어 또는 클라이언트 라이브러리를 사용해야 합니다.

연결

• Cassandra 클라이언트 지원

  Spanner를 사용하면 다양한 클라이언트에서 데이터베이스에 연결할 수 있습니다.

  • Cassandra 어댑터는 처리 중 도우미로 사용하거나 사이드카 프록시로 사용하여 Cassandra 애플리케이션을 Cassandra 인터페이스에 연결할 수 있습니다. 자세한 내용은 Cassandra 어댑터를 사용하여 Spanner에 연결을 참조하세요.
  • Cassandra 어댑터를 로컬에서 독립형 프로세스로 시작하고 CQLSH를 사용하여 연결할 수 있습니다. 자세한 내용은 Cassandra 어댑터를 애플리케이션에 연결을 참조하세요.

Identity and Access Management(IAM)로 액세스 제어

Cassandra 엔드포인트에 대해 읽기 및 쓰기 작업을 수행하려면 spanner.databases.adapt, spanner.databases.select, spanner.databases.write 권한이 있어야 합니다. 자세한 내용은 IAM 개요를 참조하세요.

Spanner IAM 권한을 부여하는 방법에 관한 자세한 내용은 IAM 역할 적용을 참조하세요.

모니터링

Spanner는 Cassandra 어댑터를 모니터링하는 데 도움이 되는 다음과 같은 측정항목을 제공합니다.

• spanner.googleapis.com/api/adapter_request_count: Spanner가 초당 실행하는 어댑터 요청 수 또는 Spanner 서버에서 초당 발생하는 오류 수를 캡처하고 노출합니다.
• spanner.googleapis.com/api/adapter_request_latencies: Spanner가 어댑터 요청을 처리하는 데 걸리는 시간을 캡처하고 노출합니다.

커스텀 Cloud Monitoring 대시보드를 만들어 Cassandra 어댑터의 측정항목을 표시하고 모니터링할 수 있습니다. 대시보드에는 다음 차트가 포함되어 있습니다.

• P99 요청 지연 시간: 데이터베이스의 message_type당 서버 요청 지연 시간의 99번째 백분위수 분포입니다.

• P50 요청 지연 시간: 데이터베이스의 message_type당 서버 요청 지연 시간의 50번째 백분위수 분포입니다.

• 메시지 유형별 API 요청 수: 데이터베이스의 message_type당 API 요청 수입니다.

• 작업 유형별 API 요청 수: 데이터베이스의 op_type당 API 요청 수입니다.

• 오류율: 데이터베이스의 API 오류율입니다.

Google Cloud 콘솔

1. cassandra-adapter-dashboard.json 파일을 다운로드합니다. 이 파일에는 Monitoring에서 커스텀 대시보드를 채우는 데 필요한 정보가 있습니다.

2. Google Cloud 콘솔에서 대시보드 페이지로 이동합니다.

   대시보드로 이동

   검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Monitoring인 결과를 선택합니다.

3. 대시보드 개요 페이지에서 커스텀 대시보드 만들기를 클릭합니다.
4. 대시보드 툴바에서 대시보드 설정 아이콘을 클릭합니다. JSON, JSON 편집기를 차례로 선택합니다.
5. JSON 편집기 창에서 다운로드한 cassandra-adapter-dashboard.json 파일의 콘텐츠를 복사하여 편집기에 붙여넣습니다.
6. 대시보드에 변경사항을 적용하려면 변경사항 적용을 클릭합니다. 이 대시보드를 사용하지 않으려면 대시보드 개요 페이지로 돌아가세요.
7. 대시보드가 생성된 후 필터 추가를 클릭합니다. 그런 다음 project_id 또는 instance_id를 선택하여 Cassandra 어댑터를 모니터링합니다.

gcloud CLI

1. cassandra-adapter-dashboard.json 파일을 다운로드합니다. 이 파일에는 Monitoring에서 커스텀 대시보드를 채우는 데 필요한 정보가 있습니다.

2. 프로젝트에서 대시보드를 만들려면 gcloud monitoring dashboards create 명령어를 실행합니다.

   gcloud monitoring dashboards create --config-from-file=cassandra-adapter-dashboard.json
   

   자세한 내용은 gcloud monitoring dashboards create 참조를 확인하세요.

또한 다음 Spanner 측정항목은 어댑터를 모니터링하는 데 도움이 됩니다.

• CPU utilization metrics는 우선순위 및 작업 유형별로 분류된 사용자 및 시스템 작업의 CPU 사용량에 관한 정보를 제공합니다.
• Storage utilization metrics는 데이터베이스 및 백업 스토리지에 관한 정보를 제공합니다.
• Spanner built-in statistics tables는 쿼리, 트랜잭션, 읽기에 관한 인사이트를 제공하여 데이터베이스의 문제를 발견하는 데 도움이 됩니다.

시스템 통계의 전체 목록은 시스템 통계로 인스턴스 모니터링을 참조하세요. Spanner 리소스 모니터링에 대한 자세한 내용은 Cloud Monitoring으로 인스턴스 모니터링을 참조하세요.

가격 책정

Cassandra 엔드포인트 사용에 대한 추가 요금은 없습니다. 인스턴스에서 사용하는 컴퓨팅 용량과 데이터베이스에서 사용하는 스토리지 양에 표준 Spanner 가격 책정이 적용됩니다.

자세한 내용은 Spanner 가격 책정을 참조하세요.

다음 단계

• Cassandra에서 Spanner로 마이그레이션하는 방법 알아보기
• Cassandra 어댑터를 사용하여 Spanner에 연결하는 방법 알아보기