기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Amazon Keyspaces: 작동 방식
Amazon Keyspaces는 Cassandra를 관리하는 데 따르는 관리 오버헤드를 제거합니다. 이유를 이해하려면 먼저 Cassandra 아키텍처로 시작한 다음 Amazon Keyspaces와 비교해 보는 것이 좋습니다.
상위 수준 아키텍처: Apache Cassandra vs. Amazon Keyspaces
기존 Apache Cassandra는 하나 이상의 노드로 구성된 클러스터에 배포됩니다. 클러스터 확장에 따라 각 노드를 관리하고 노드를 추가 및 제거하는 것은 사용자의 책임입니다.
클라이언트 프로그램은 노드 중 하나에 연결하고 Cassandra 쿼리 언어(CQL) 문을 실행하여 Cassandra에 액세스합니다. CQL은 관계형 데이터베이스에서 널리 사용되는 언어인 SQL과 유사합니다. Cassandra는 관계형 데이터베이스가 아니지만 CQL은 Cassandra에서 데이터를 쿼리하고 조작하기 위한 친숙한 인터페이스를 제공합니다.
다음 다이어그램은 네 개의 노드로 구성된 간단한 Apache Cassandra 클러스터를 보여 줍니다.
프로덕션 Cassandra 배포는 하나 이상의 물리적 데이터 센터에 있는 수백 대의 물리적 컴퓨터에서 실행되는 수백 개의 노드로 구성될 수 있습니다. 이로 인해 소프트웨어를 설치, 유지 관리 및 운영하는 것 외에도 서버를 프로비저닝, 패치 및 관리해야 하는 애플리케이션 개발자에게 운영상의 부담이 발생할 수 있습니다.
Amazon Keyspaces(Apache Cassandra용)를 사용하면 서버를 프로비저닝, 패치 또는 관리할 필요가 없으므로 더 나은 애플리케이션을 구축하는 데 집중할 수 있습니다. Amazon Keyspaces는 읽기 및 쓰기를 위한 두 가지 처리량 용량 모드(온디맨드 및 프로비저닝)를 제공합니다. 테이블의 처리량 용량 모드를 선택하여 워크로드의 예측 가능성과 변동성을 기반으로 읽기 및 쓰기 가격을 최적화할 수 있습니다.
온디맨드 모드를 사용하면 애플리케이션이 실제로 수행하는 읽기 및 쓰기에 대한 비용만 지불합니다. 테이블의 처리량 용량을 미리 지정할 필요가 없습니다. Amazon Keyspaces는 애플리케이션 트래픽이 증가하거나 감소할 때 거의 즉시 수용하므로 트래픽을 예측할 수 없는 애플리케이션에 적합한 옵션입니다.
프로비저닝된 용량 모드를 사용하면 애플리케이션 트래픽을 예측할 수 있고 테이블의 용량 요구 사항을 미리 예측할 수 있는 경우 처리량 가격을 최적화하는 데 도움이 됩니다. 프로비저닝된 용량 모드를 사용하면 애플리케이션에서 수행할 것으로 예상되는 초당 읽기 및 쓰기 수를 지정합니다. 자동 크기 조정을 활성화하여 테이블의 프로비저닝된 용량을 자동으로 늘리거나 줄일 수 있습니다.
워크로드의 트래픽 패턴에 대해 자세히 알아보거나 테이블 트래픽이 많이 발생할 것으로 예상되는 주요 이벤트와 같이 트래픽이 크게 급증할 것으로 예상되는 경우 테이블의 용량 모드를 하루에 한 번 변경할 수 있습니다. 읽기 및 쓰기 용량 프로비저닝에 대한 자세한 내용은 Amazon Keyspaces의 읽기/쓰기 용량 모드 섹션을 참조하세요.
Amazon Keyspaces(Apache Cassandra용)는 내구성과 고가용성을 위해 여러 가용 영역
다음 다이어그램은 Amazon Keyspaces의 아키텍처를 보여 줍니다.
클라이언트 프로그램은 미리 결정된 엔드포인트(호스트 이름 및 포트 번호)에 연결하고 CQL 문을 발행하여 Amazon Keyspaces에 액세스합니다. 사용 가능한 엔드포인트 목록은 Amazon Keyspaces의 서비스 엔드포인트 섹션을 참조하세요.
Cassandra 데이터 모델
Amazon Keyspaces에서 최적의 성능을 달성하려면 비즈니스 사례에 맞게 데이터를 모델링하는 방법이 매우 중요합니다. 잘못된 데이터 모델은 성능을 크게 저하시킬 수 있습니다.
CQL은 SQL과 비슷해 보이지만 Cassandra와 관계형 데이터베이스의 백엔드는 매우 다르므로 접근 방식도 달라야 합니다. 고려해야 할 몇 가지 중요한 문제는 다음과 같습니다.
- 스토리지
-
각 행은 레코드를 나타내고 각 열은 해당 레코드 내의 필드를 나타내는 테이블로 Cassandra 데이터를 시각화할 수 있습니다.
- 테이블 디자인: 쿼리 우선
-
CQL에는
JOIN이 없습니다. 따라서 비즈니스 사용 사례에 맞게 데이터의 형태와 데이터에 액세스하는 방법을 고려하여 테이블을 설계해야 합니다. 이로 인해 데이터가 중복되어 비정규화가 발생할 수 있습니다. 각 테이블을 특정 액세스 패턴에 맞게 특별히 디자인해야 합니다. - 파티션
-
데이터는 디스크의 파티션에 저장됩니다. 데이터가 저장되는 파티션 수와 파티션 간에 데이터가 분산되는 방식은 파티션 키에 따라 결정됩니다. 파티션 키를 정의하는 방법은 쿼리 성능에 상당한 영향을 미칠 수 있습니다.
- 프라이머리 키
-
Cassandra에서 데이터는 키-값 페어로 저장됩니다. 이를 위해 모든 Cassandra 테이블에는 테이블의 각 행에 대한 키인 프라이머리 키가 있어야 합니다. 프라이머리 키는 필수 파티션 키와 선택적 클러스터링 열로 구성됩니다. 프라이머리 키를 구성하는 데이터는 테이블의 모든 레코드에서 고유해야 합니다.
-
파티션 키 - 프라이머리 키의 파티션 키 부분이 필요하며 데이터가 저장되는 클러스터의 파티션을 결정합니다. 파티션 키는 단일 열이거나 둘 이상의 열로 구성된 복합 값일 수 있습니다. 단일 열 파티션 키로 인해 단일 파티션 또는 극소수의 파티션에 대부분의 데이터가 포함되어 대부분의 디스크 I/O 작업이 수행될 경우 복합 파티션 키를 사용합니다.
-
클러스터링 열 - 프라이머리 키의 선택적 클러스터링 열 부분에 따라 각 파티션 내에서 데이터가 클러스터링되고 정렬되는 방식이 결정됩니다. 프라이머리 키에 클러스터링 열을 포함하는 경우 클러스터링 열에 하나 이상의 열이 있을 수 있습니다. 클러스터링 열에 여러 열이 있는 경우 정렬 순서는 클러스터링 열에 열이 나열된 순서(왼쪽에서 오른쪽)에 따라 결정됩니다.
-
애플리케이션에서 Amazon Keyspaces에 액세스
Amazon Keyspaces(Apache Cassandra용)는 Apache Cassandra 쿼리 언어(CQL) API를 구현하므로 이미 사용하고 있는 CQL 및 Cassandra 드라이버를 사용할 수 있습니다. 애플리케이션을 업데이트하는 것은 Amazon Keyspaces 서비스 엔드포인트를 가리키도록 Cassandra 드라이버 또는 cqlsh 구성을 업데이트하는 것만큼 쉽습니다.
참고
시작하는 데 도움이 되도록, GitHub
Cassandra 클러스터에 연결하여 테이블을 쿼리하는 다음 Python 프로그램을 고려해 보세요.
from cassandra.cluster import Cluster #TLS/SSL configuration goes here ksp = 'MyKeyspace' tbl = 'WeatherData' cluster = Cluster(['NNN.NNN.NNN.NNN'], port=NNNN) session = cluster.connect(ksp) session.execute('USE ' + ksp) rows = session.execute('SELECT * FROM ' + tbl) for row in rows: print(row)
Amazon Keyspaces에서 동일한 프로그램을 실행하려면 다음을 수행해야 합니다.
-
클러스터 엔드포인트 및 포트 추가: 예를 들어 호스트를
cassandra.us-east-2.amazonaws.com과 같은 서비스 엔드포인트와9142의 포트 번호로 교체할 수 있습니다. -
TLS/SSL 구성 추가: Cassandra 클라이언트 Python 드라이버를 사용하여 Amazon Keyspaces에 연결하기 위한 TLS/SSL 구성을 추가하는 방법에 대한 자세한 내용은 Cassandra Python 클라이언트 드라이버를 사용하여 프로그래밍 방식으로 Amazon Keyspaces에 액세스 섹션을 참조하세요.
