기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon Keyspaces: 작동 방식
Amazon Keyspaces는 Cassandra를 관리하는 데 따르는 관리 오버헤드를 제거합니다. 이유를 이해하려면 먼저 Cassandra 아키텍처로 시작한 다음 Amazon Keyspaces와 비교해 보는 것이 좋습니다.
**Topics**
+ [상위 수준 아키텍처: Apache Cassandra vs. Amazon Keyspaces](#how-it-works.cassandra-arch)
+ [Cassandra 데이터 모델](#how-it-works.data-model)
+ [애플리케이션에서 Amazon Keyspaces에 액세스](#how-it-works.keyspaces-arch.accessing)
## 상위 수준 아키텍처: Apache Cassandra vs. Amazon Keyspaces
기존 Apache Cassandra는 하나 이상의 노드로 구성된 클러스터에 배포됩니다. 클러스터 확장에 따라 각 노드를 관리하고 노드를 추가 및 제거하는 것은 사용자의 책임입니다.
클라이언트 프로그램은 노드 중 하나에 연결하고 Cassandra 쿼리 언어(CQL) 문을 실행하여 Cassandra에 액세스합니다. *CQL*은 관계형 데이터베이스에서 널리 사용되는 언어인 SQL과 유사합니다. Cassandra는 관계형 데이터베이스가 아니지만 CQL은 Cassandra에서 데이터를 쿼리하고 조작하기 위한 친숙한 인터페이스를 제공합니다.
다음 다이어그램은 네 개의 노드로 구성된 간단한 Apache Cassandra 클러스터를 보여 줍니다.
![\[4개의 노드를 포함하고 클라이언트 애플리케이션과 상호 작용하는 Apache Cassandra 클러스터의 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/keyspaces_cassandra-hi-level.png)
프로덕션 Cassandra 배포는 하나 이상의 물리적 데이터 센터에 있는 수백 대의 물리적 컴퓨터에서 실행되는 수백 개의 노드로 구성될 수 있습니다. 이로 인해 소프트웨어를 설치, 유지 관리 및 운영하는 것 외에도 서버를 프로비저닝, 패치 및 관리해야 하는 애플리케이션 개발자에게 운영상의 부담이 발생할 수 있습니다.
Amazon Keyspaces(Apache Cassandra용)를 사용하면 서버를 프로비저닝, 패치 또는 관리할 필요가 없으므로 더 나은 애플리케이션을 구축하는 데 집중할 수 있습니다. Amazon Keyspaces는 읽기 및 쓰기를 위한 두 가지 처리량 용량 모드(온디맨드 및 프로비저닝)를 제공합니다. 테이블의 처리량 용량 모드를 선택하여 워크로드의 예측 가능성과 변동성을 기반으로 읽기 및 쓰기 가격을 최적화할 수 있습니다.
온디맨드 모드를 사용하면 애플리케이션이 실제로 수행하는 읽기 및 쓰기에 대한 비용만 지불합니다. 테이블의 처리량 용량을 미리 지정할 필요가 없습니다. Amazon Keyspaces는 애플리케이션 트래픽이 증가하거나 감소할 때 거의 즉시 수용하므로 트래픽을 예측할 수 없는 애플리케이션에 적합한 옵션입니다.
프로비저닝된 용량 모드를 사용하면 애플리케이션 트래픽을 예측할 수 있고 테이블의 용량 요구 사항을 미리 예측할 수 있는 경우 처리량 가격을 최적화하는 데 도움이 됩니다. 프로비저닝된 용량 모드를 사용하면 애플리케이션에서 수행할 것으로 예상되는 초당 읽기 및 쓰기 수를 지정합니다. [자동 크기 조정](https://docs.aws.amazon.com/keyspaces/latest/devguide/autoscaling.html)을 활성화하여 테이블의 프로비저닝된 용량을 자동으로 늘리거나 줄일 수 있습니다.
워크로드의 트래픽 패턴에 대해 자세히 알아보거나 테이블 트래픽이 많이 발생할 것으로 예상되는 주요 이벤트와 같이 트래픽이 크게 급증할 것으로 예상되는 경우 테이블의 용량 모드를 하루에 한 번 변경할 수 있습니다. 읽기 및 쓰기 용량 프로비저닝에 대한 자세한 내용은 [Amazon Keyspaces의 읽기/쓰기 용량 모드 구성](ReadWriteCapacityMode.md) 섹션을 참조하세요.
Amazon Keyspaces(Apache Cassandra용)는 내구성과 고가용성을 위해 여러 [가용 영역](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)에 데이터 사본 3개를 저장합니다. 또한 보안에 매우 민감한 조직의 요구 사항에 부합하도록 구축된 데이터 센터 및 네트워크 아키텍처의 혜택을 누릴 수 있습니다. 새 Amazon Keyspaces 테이블을 생성하고 모든 클라이언트 연결에 전송 계층 보안(TLS)이 필요한 경우 저장 시 암호화가 자동으로 활성화됩니다. 추가 AWS 보안 기능에는 [모니터링](https://docs.aws.amazon.com/keyspaces/latest/devguide/monitoring.html), [AWS Identity and Access Management](https://docs.aws.amazon.com/keyspaces/latest/devguide/security_iam_service-with-iam.html)및 [Virtual Private Cloud(VPC) 엔드포인트](https://docs.aws.amazon.com/keyspaces/latest/devguide/vpc-endpoints.html)가 포함됩니다. 사용 가능한 모든 보안 기능의 개요는 [Amazon Keyspaces(Apache Cassandra용)의 보안](security.md) 섹션을 참조하세요.
다음 다이어그램은 Amazon Keyspaces의 아키텍처를 보여 줍니다.
![\[클라이언트 애플리케이션과 상호 작용하는 Amazon Keyspaces의 다이어그램\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/keyspaces-hi-level.png)
클라이언트 프로그램은 미리 결정된 엔드포인트(호스트 이름 및 포트 번호)에 연결하고 CQL 문을 발행하여 Amazon Keyspaces에 액세스합니다. 사용 가능한 엔드포인트 목록은 [Amazon Keyspaces의 서비스 엔드포인트](programmatic.endpoints.md) 섹션을 참조하세요.
## Cassandra 데이터 모델
Amazon Keyspaces에서 최적의 성능을 달성하려면 비즈니스 사례에 맞게 데이터를 모델링하는 방법이 매우 중요합니다. 잘못된 데이터 모델은 성능을 크게 저하시킬 수 있습니다.
CQL은 SQL과 비슷해 보이지만 Cassandra와 관계형 데이터베이스의 백엔드는 매우 다르므로 접근 방식도 달라야 합니다. 고려해야 할 몇 가지 중요한 문제는 다음과 같습니다.
**스토리지**
각 행은 레코드를 나타내고 각 열은 해당 레코드 내의 필드를 나타내는 테이블로 Cassandra 데이터를 시각화할 수 있습니다.
**테이블 디자인: 쿼리 우선**
CQL에는 `JOIN`이 없습니다. 따라서 비즈니스 사용 사례에 맞게 데이터의 형태와 데이터에 액세스하는 방법을 고려하여 테이블을 설계해야 합니다. 이로 인해 데이터가 중복되어 비정규화가 발생할 수 있습니다. 각 테이블을 특정 액세스 패턴에 맞게 특별히 디자인해야 합니다.
**파티션**
데이터는 디스크의 파티션에 저장됩니다. 데이터가 저장되는 파티션 수와 파티션 간에 데이터가 분산되는 방식은 *파티션 키*에 따라 결정됩니다. 파티션 키를 정의하는 방법은 쿼리 성능에 상당한 영향을 미칠 수 있습니다. 모범 사례는 [Amazon Keyspaces에서 파티션 키를 효과적으로 사용하는 방법](bp-partition-key-design.md) 섹션을 참조하세요.
**프라이머리 키**
Cassandra에서 데이터는 키-값 페어로 저장됩니다. 모든 Cassandra 테이블에는 테이블의 각 행에 대한 고유 키인 프라이머리 키가 있어야 합니다. 프라이머리 키는 필수 파티션 키와 선택적 클러스터링 열로 구성됩니다. 프라이머리 키를 구성하는 데이터는 테이블의 모든 레코드에서 고유해야 합니다.
+ **파티션 키** - 프라이머리 키의 파티션 키 부분이 필요하며 데이터가 저장되는 클러스터의 파티션을 결정합니다. 파티션 키는 단일 열이거나 둘 이상의 열로 구성된 복합 값일 수 있습니다. 단일 열 파티션 키로 인해 단일 파티션 또는 극소수의 파티션에 대부분의 데이터가 포함되어 대부분의 디스크 I/O 작업이 수행될 경우 복합 파티션 키를 사용합니다.
+ **클러스터링 열** - 프라이머리 키의 선택적 클러스터링 열 부분에 따라 각 파티션 내에서 데이터가 클러스터링되고 정렬되는 방식이 결정됩니다. 프라이머리 키에 클러스터링 열을 포함하는 경우 클러스터링 열에 하나 이상의 열이 있을 수 있습니다. 클러스터링 열에 여러 열이 있는 경우 정렬 순서는 클러스터링 열에 열이 나열된 순서(왼쪽에서 오른쪽)에 따라 결정됩니다.
NoSQL 설계 및 Amazon Keyspaces에 대한 자세한 내용은 [NoSQL 설계의 주요 차이점 및 설계 원칙](bp-general-nosql-design.md) 섹션을 참조하세요. Amazon Keyspaces 및 데이터 모델링에 대한 자세한 내용은 [데이터 모델링 모범 사례: 데이터 모델 설계를 위한 권장 사항](data-modeling.md) 섹션을 참조하세요.
## 애플리케이션에서 Amazon Keyspaces에 액세스
Amazon Keyspaces(Apache Cassandra용)는 Apache Cassandra 쿼리 언어(CQL) API를 구현하므로 이미 사용하고 있는 CQL 및 Cassandra 드라이버를 사용할 수 있습니다. 애플리케이션을 업데이트하는 것은 Amazon Keyspaces 서비스 엔드포인트를 가리키도록 Cassandra 드라이버 또는 `cqlsh` 구성을 업데이트하는 것만큼 쉽습니다. 필수 자격 증명에 대한 자세한 내용은 [Amazon Keyspaces에 대한 AWS 자격 증명 생성 및 구성](access.credentials.md) 섹션을 참조하세요.
**참고**
시작하는 데 도움이 되도록, [GitHub](https://github.com/aws-samples/amazon-keyspaces-examples)의 Amazon Keyspaces 코드 예제 리포지토리에서 다양한 Cassandra 클라이언트 드라이버를 사용하여 Amazon Keyspaces에 접속하는 엔드 투 엔드 코드 샘플을 찾을 수 있습니다.
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-1.amazonaws.com`과 같은 서비스 엔드포인트와 `9142`의 포트 번호로 교체할 수 있습니다.
+ **TLS/SSL 구성 추가**: Cassandra 클라이언트 Python 드라이버를 사용하여 Amazon Keyspaces에 연결하기 위한 TLS/SSL 구성을 추가하는 방법에 대한 자세한 내용은 [Cassandra Python 클라이언트 드라이버를 사용하여 프로그래밍 방식으로 Amazon Keyspaces에 액세스](using_python_driver.md) 섹션을 참조하세요.