기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon Keyspaces(Apache Cassandra용)에서 서버리스 리소스 관리
Amazon Keyspaces(Apache Cassandra용)는 서버리스입니다. Amazon Keyspaces는 클러스터의 노드를 통해 워크로드의 스토리지 및 컴퓨팅 리소스를 배포, 관리 및 유지 관리하는 대신 스토리지 및 읽기/쓰기 처리량 리소스를 테이블에 직접 할당합니다.
Amazon Keyspaces는 테이블에 저장된 데이터를 기반으로 스토리지를 자동으로 프로비저닝합니다. 데이터를 작성, 업데이트 및 삭제할 때 스토리지를 확장 및 축소하고 사용하는 스토리지에 대해서만 비용을 지불합니다. 데이터는 고가용성을 위해 여러 [가용 영역](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)에 복제됩니다. Amazon Keyspaces는 테이블 크기를 지속적으로 모니터링하여 스토리지 요금을 결정합니다. Amazon Keyspaces가 청구 대상 데이터 크기를 계산하는 방법에 대한 자세한 내용은 [Amazon Keyspaces에서 행 크기 추정](calculating-row-size.md) 섹션을 참조하세요.
이 장에서는 Amazon Keyspaces 내 리소스 관리의 주요 측면을 다룹니다.
+ **행 크기 추정** - Amazon Keyspaces에서 인코딩된 행 크기를 추정하려면 파티션 키 메타데이터, 클러스터링 열 메타데이터, 열 식별자, 데이터 유형 및 행 메타데이터와 같은 요소를 고려합니다. 이 인코딩된 행 크기는 결제, 할당량 관리 및 프로비저닝된 처리량 용량 계획에 사용됩니다.
+ **용량 소비 추정** - 이 섹션에서는 범위 쿼리, 제한 쿼리, 테이블 스캔, 경량 트랜잭션, 정적 열 및 다중 리전 테이블과 같은 일반적인 시나리오에 대한 읽기 및 쓰기 용량 소비를 추정하는 방법의 예를 다룹니다. Amazon CloudWatch를 사용하여 실제 용량 사용률을 모니터링할 수 있습니다. CloudWatch를 사용한 모니터링에 대한 자세한 내용은 [Amazon CloudWatch를 사용하여 Amazon Keyspaces 모니터링](monitoring-cloudwatch.md) 섹션을 참조하세요.
+ **읽기/쓰기 용량 모드 구성** - 테이블에서 읽기 및 쓰기를 처리하기 위한 두 가지 용량 모드 중에서 선택할 수 있습니다.
+ **온디맨드 모드(기본값)** - 읽기 및 쓰기 처리량에 대한 요청당 비용을 지불합니다. Amazon Keyspaces는 이전에 도달한 트래픽 수준까지 용량을 즉시 확장할 수 있습니다.
+ **프로비저닝 모드** - 필요한 읽기 및 쓰기 용량 단위 수를 미리 지정합니다. 이 모드는 예측 가능한 처리량 성능을 유지하는 데 도움이 됩니다.
+ **오토 스케일링으로 처리량 용량 관리** - 프로비저닝된 테이블의 경우 실제 애플리케이션 트래픽에 따라 처리량 용량을 자동으로 조정하도록 오토 스케일링을 활성화할 수 있습니다. Amazon Keyspaces는 대상 추적을 사용하여 프로비저닝된 용량을 늘리거나 줄여 지정된 대상의 사용률을 유지합니다.
+ **버스트 용량을 효과적으로 사용** - Amazon Keyspaces는 트래픽 급증을 처리하기 위해 미사용 처리량의 일부를 예약하여 버스트 용량을 제공합니다. 이러한 유연성 덕분에 프로비저닝된 처리량을 초과하는 활동이 때때로 급증할 수 있습니다.
용량 오류를 해결하려면 [서버리스 용량 오류](troubleshooting.serverless.md#troubleshooting-serverless) 섹션을 참조하세요.
**Topics**
+ [Amazon Keyspaces에서 행 크기 추정](calculating-row-size.md)
+ [Amazon Keyspaces에서 읽기 및 쓰기 처리량의 용량 소비 추정](capacity-examples.md)
+ [Amazon Keyspaces의 읽기/쓰기 용량 모드 구성](ReadWriteCapacityMode.md)
+ [Amazon Keyspaces 오토 스케일링으로 처리량 용량 자동 관리](autoscaling.md)
+ [Amazon Keyspaces에서 버스트 용량을 효과적으로 사용하기](throughput-bursting.md)
# Amazon Keyspaces에서 행 크기 추정
Amazon Keyspaces는 한 자릿수 밀리초의 읽기 및 쓰기 성능을 제공하고 여러 AWS 가용 영역에 걸쳐 데이터를 내구성 있게 저장하는 완전관리형 스토리지를 제공합니다. Amazon Keyspaces는 모든 행과 프라이머리 키 열에 메타데이터를 연결하여 효율적인 데이터 액세스와 고가용성을 지원합니다.
이 주제에서는 Amazon Keyspaces에서 인코딩된 행 크기를 추정하는 방법에 대한 세부 정보를 제공합니다. 인코딩된 행 크기는 청구서 및 할당량 사용량을 계산할 때 사용됩니다. 테이블에 대해 프로비저닝된 처리량 용량 요구 사항을 추정할 때 인코딩된 행 크기를 사용할 수도 있습니다.
Amazon Keyspaces 내에서 인코딩된 행 크기를 계산하려는 경우 다음 지침을 사용할 수 있습니다.
**Topics**
+ [인코딩된 열 크기 추정](#calculating-row-size-columns)
+ [데이터 유형에 따라 인코딩된 데이터 값 크기 추정](#calculating-row-size-data-types)
+ [Amazon Keyspaces 기능이 행 크기에 미치는 영향 고려](#calculating-row-size-features)
+ [올바른 공식을 선택하여 행의 인코딩된 크기를 계산합니다.](#calculating-row-size-formula)
+ [행 크기 계산 예제](#calculating-row-size-example)
## 인코딩된 열 크기 추정
이 섹션에서는 Amazon Keyspaces에서 인코딩된 열 크기를 추정하는 방법을 보여줍니다.
+ **일반 열** - 기본 키, 클러스터링 열 또는 열이 아닌 `STATIC` 열인 일반 열의 경우 [데이터 유형에](cql.elements.md#cql.data-types) 따라 셀 데이터의 원시 크기를 사용하고 필요한 메타데이터를 추가합니다. Amazon Keyspaces가 데이터 유형 값과 메타데이터를 저장하는 방법의 데이터 유형과 몇 가지 주요 차이점은 다음 섹션에 나와 있습니다.
+ **파티션 키 열** - 파티션 키에는 최대 2,048바이트의 데이터가 포함될 수 있습니다. 파티션 키의 각 키 열에는 최대 3바이트의 메타데이터가 필요합니다. 행 크기를 계산할 때는 각 파티션 키 열이 전체 3바이트의 메타데이터를 사용한다고 가정해야 합니다.
+ **클러스터링 열** - 클러스터링 열은 최대 850바이트의 데이터를 저장할 수 있습니다. 데이터 값의 크기 외에도 각 클러스터링 열에는 메타데이터에 대한 데이터 값 크기의 최대 20%가 필요합니다. 행 크기를 계산할 때는 클러스터링 열 데이터 값 5바이트당 메타데이터 1바이트를 추가해야 합니다.
**참고**
효율적인 쿼리 및 내장 인덱싱을 지원하기 위해 Amazon Keyspaces는 각 파티션 키 및 클러스터링 키 열의 데이터 값을 두 번 저장합니다.
+ **열 이름** - 각 열 이름에 필요한 공간은 열 식별자를 사용하여 저장되며 열에 저장된 각 데이터 값에 추가됩니다. 열 식별자의 스토리지 값은 테이블의 전체 열 수에 따라 달라집니다.
+ 1-62개 열: 1바이트
+ 63-124개 열: 2바이트
+ 125-186개 열: 3바이트
62개 열을 추가할 때마다 1바이트를 추가합니다. Amazon Keyspaces에서는 단일 `INSERT` 또는 `UPDATE` 문으로 최대 225개의 일반 열을 수정할 수 있다는 점에 유의하세요. 자세한 내용은 [Amazon Keyspaces 서비스 할당량](quotas.md#table) 단원을 참조하십시오.
## 데이터 유형에 따라 인코딩된 데이터 값 크기 추정
이 섹션에서는 Amazon Keyspaces에서 다양한 데이터 유형의 인코딩된 크기를 추정하는 방법을 보여줍니다.
+ **문자열 유형** - Cassandra `ASCII`, `TEXT`및 `VARCHAR` 문자열 데이터 유형은 모두 UTF-8 바이너리 인코딩과 함께 유니코드를 사용하여 Amazon Keyspaces에 저장됩니다. Amazon Keyspaces의 문자열 크기는 UTF-8 인코딩된 바이트 수와 같습니다.
+ **숫자 유형** - Cassandra `INT`, `BIGINT`, `SMALLINT``TINYINT`, 및 `VARINT` 데이터 유형은 Amazon Keyspaces에 최대 38개의 유효 숫자로 가변 길이의 데이터 값으로 저장됩니다. 앞과 끝의 0은 잘립니다. 이러한 데이터 유형의 크기는 유효 숫자 2자리당 약 1바이트\$11바이트입니다.
+ **블롭 유형** - Amazon Keyspaces`BLOB`의는 값의 원시 바이트 길이와 함께 저장됩니다.
+ **부울 유형** - `Boolean` 값 또는 `Null` 값의 크기는 1바이트입니다.
+ **컬렉션 유형** -와 같은 컬렉션 데이터 유형을 저장`LIST`하거나 콘텐츠에 관계없이 3바이트의 메타데이터가 `MAP` 필요한 열입니다. `LIST` 또는 `MAP`의 크기는 (열 ID) \$1 합계(중첩 요소 크기) \$1 (3바이트)입니다. 빈 `LIST` 또는 `MAP`의 크기는 (열 ID) \$1 (3바이트)입니다. 또한 각 개별 `LIST` 또는 `MAP` 요소에는 1바이트의 메타데이터를 필요로 합니다.
+ **사용자 정의 유형** [- 사용자 정의 유형(UDT)](udts.md)은 콘텐츠에 관계없이 메타데이터에 3바이트가 필요합니다. 각 UDT 요소에 대해 Amazon Keyspaces에는 추가 1바이트의 메타데이터가 필요합니다.
UDT의 인코딩된 크기를 계산하려면 UDT `field value` 필드의 `field name` 및 로 시작합니다.
+ **필드 이름** - 최상위 UDT의 각 필드 이름은 식별자를 사용하여 저장됩니다. 식별자의 스토리지 값은 최상위 UDT의 전체 필드 수에 따라 달라지며 1\$13바이트 사이일 수 있습니다.
+ 1\$162개 필드: 1바이트
+ 63\$1124개 필드: 2바이트
+ 125\$1최대 필드: 3바이트
+ **필드 값** - 최상위 UDT의 필드 값을 저장하는 데 필요한 바이트는 저장된 데이터 유형에 따라 다릅니다.
+ **스칼라 데이터 유형** - 스토리지에 필요한 바이트는 일반 열에 저장된 동일한 데이터 유형과 동일합니다.
+ **동결된 UDT** - 각 동결된 중첩된 UDT에 대해 중첩된 UDT의 크기는 CQL 바이너리 프로토콜과 동일합니다. 중첩된 UDT의 경우 각 필드(빈 필드 포함)에 대해 4바이트가 저장되고 저장된 필드의 값은 필드 값의 CQL 이진 프로토콜 직렬화 형식입니다.
+ **동결된 컬렉션**:
+ **LIST** 및 **SET** - 중첩된 고정 `LIST` 또는의 경우 컬렉션의 각 요소에 대해 `SET`4바이트와 컬렉션 값의 CQL 바이너리 프로토콜 직렬화 형식이 저장됩니다.
+ **MAP** - 중첩된 고정의 경우 `MAP`각 키-값 페어에는 다음과 같은 스토리지 요구 사항이 있습니다.
+ 각 키에 대해 4바이트를 할당한 다음 키의 CQL 바이너리 프로토콜 직렬화 형식을 추가합니다.
+ 각 값에 대해 4바이트를 할당한 다음 값의 CQL 이진 프로토콜 직렬화 형식을 추가합니다.
+ **FROZEN 키워드** - 동결된 컬렉션 내에 중첩된 동결된 컬렉션의 경우 Amazon Keyspaces는 메타 데이터에 대해 추가 바이트를 요구하지 않습니다.
+ **STATIC 키워드** - `STATIC` 열 데이터는 최대 행 크기인 1MB에 포함되지 않습니다. 정적 열의 데이터 크기를 계산하려면 [Amazon Keyspaces의 논리적 파티션당 정적 열 크기 계산](static-columns-estimate.md) 섹션을 참조하세요.
## Amazon Keyspaces 기능이 행 크기에 미치는 영향 고려
이 섹션에서는 Amazon Keyspaces의 기능이 행의 인코딩된 크기에 미치는 영향을 보여줍니다.
+ **클라이언트 측 타임스탬프** - 클라이언트 측 타임스탬프는 기능이 켜져 있을 때 각 행의 모든 열에 대해 저장됩니다. 이러한 타임스탬프는 약 20\$140바이트(데이터에 따라 다름)를 차지하며 행의 스토리지 및 처리량 비용에 영향을 줍니다. 클라이언트 측 타임스탬프에 대한 자세한 내용은 섹션을 참조하세요[Amazon Keyspaces의 클라이언트 측 타임스탬프](client-side-timestamps.md).
+ **TTL(Time to Live)** - TTL 메타데이터는 기능이 켜져 있을 때 행에 대해 약 8바이트를 차지합니다. 또한 TTL 메타데이터는 각 행의 모든 열에 저장됩니다. TTL 메타데이터는 스칼라 데이터 유형 또는 고정 컬렉션을 저장하는 각 열에 대해 약 8바이트를 차지합니다. 열에 고정되지 않은 컬렉션 데이터 유형이 저장되어 있는 경우 컬렉션 TTL의 각 요소에 대해 메타데이터에 약 8바이트가 추가로 필요합니다. TTL이 활성화된 경우 컬렉션 데이터 유형을 저장하는 열의 경우 다음 공식을 사용할 수 있습니다.
```
total encoded size of column = (column id) + sum (nested elements + collection metadata (1 byte) + TTL metadata (8 bytes)) + collection column metadata (3 bytes)
```
TTL 메타데이터는 행의 스토리지 및 처리량 비용에 기여합니다. TTL에 대한 자세한 내용은 [Amazon Keyspaces(Apache Cassandra용)의 TTL(Time to Live)을 사용하여 데이터 만료](TTL.md) 섹션을 참조하세요.
## 올바른 공식을 선택하여 행의 인코딩된 크기를 계산합니다.
이 섹션에서는 Amazon Keyspaces의 데이터 행에 대한 스토리지 또는 용량 처리량 요구 사항을 추정하는 데 사용할 수 있는 다양한 공식을 보여줍니다.
데이터 행의 인코딩된 총 크기는 목표에 따라 다음 공식 중 하나를 기반으로 추정할 수 있습니다.
+ **처리량 용량** - 행의 인코딩된 크기를 추정하여 필요한 읽기/쓰기 요청 단위(RRUs/WRUs) 또는 읽기/쓰기 용량 단위(RCUs/WCUs:
```
total encoded size of row = partition key columns + clustering columns + regular columns
```
+ **스토리지 크기** -를 예측하기 위해 행의 인코딩된 크기를 추정하려면 행의 스토리지에 필요한 메타데이터를 `BillableTableSizeInBytes`추가합니다.
```
total encoded size of row = partition key columns + clustering columns + regular columns + row metadata (100 bytes)
```
**중요**
열 ID, 파티션 키 메타데이터, 클러스터링 열 메타데이터, 클라이언트 측 타임스탬프, TTL 및 행 메타데이터와 같은 모든 열 메타데이터는 최대 행 크기인 1MB에 포함됩니다.
## 행 크기 계산 예제
모든 열의 유형이 정수인 다음 테이블을 예로 들어 보겠습니다. 테이블에는 파티션 키 열 2개, 클러스터링 열 2개, 일반 열 1개가 있습니다. 이 테이블에는 5개의 열이 있으므로 열 이름 식별자에 필요한 공간은 1바이트입니다.
```
CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, primary key((pk_col1, pk_col2),ck_col1, ck_col2));
```
이 예제에서는 다음 문과 같이 테이블에 행을 쓸 때의 데이터 크기를 계산합니다.
```
INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, ck_col1, ck_col2, reg_col1) values(1,2,3,4,5);
```
이 쓰기 작업에 필요한 총 바이트를 추정하려면 다음 단계를 사용하면 됩니다.
1. 열에 저장된 데이터 유형의 바이트와 메타데이터 바이트를 더하여 파티션 키 열의 크기를 계산합니다. 모든 파티션 키 열에 대해 이 과정을 반복합니다.
1. 파티션 키(pk\$1col1)의 첫 번째 열 크기를 계산합니다.
```
(2 bytes for the integer data type) x 2 + 1 byte for the column id + 3 bytes for partition key metadata = 8 bytes
```
1. 파티션 키(pk\$1col2)의 두 번째 열 크기를 계산합니다.
```
(2 bytes for the integer data type) x 2 + 1 byte for the column id + 3 bytes for partition key metadata = 8 bytes
```
1. 두 열을 모두 더하여 파티션 키 열의 총 예상 크기를 구합니다.
```
8 bytes + 8 bytes = 16 bytes for the partition key columns
```
1. 열에 저장된 데이터 유형의 바이트와 메타데이터 바이트를 더하여 클러스터링 열의 크기를 계산합니다. 모든 클러스터링 열에 대해 이 과정을 반복합니다.
1. 클러스터링 열(ck\$1col1)의 첫 번째 열 크기를 계산합니다.
```
(2 bytes for the integer data type) x 2 + 20% of the data value (2 bytes) for clustering column metadata + 1 byte for the column id = 6 bytes
```
1. 클러스터링 열(ck\$1col2)의 두 번째 열 크기를 계산합니다.
```
(2 bytes for the integer data type) x 2 + 20% of the data value (2 bytes) for clustering column metadata + 1 byte for the column id = 6 bytes
```
1. 두 열을 모두 더하여 클러스터링 열의 총 예상 크기를 구합니다.
```
6 bytes + 6 bytes = 12 bytes for the clustering columns
```
1. 일반 열의 크기를 더합니다. 이 예제에서는 한 자리 정수를 저장하는 열이 하나뿐이며 이 경우 열 ID로 2바이트에 1바이트가 필요합니다.
1. 마지막으로 인코딩된 총 행 크기를 가져오려면 모든 열의 바이트를 합산합니다. 스토리지의 청구 가능 크기를 추정하려면 행 메타데이터에 100바이트를 추가합니다.
```
16 bytes for the partition key columns + 12 bytes for clustering columns + 3 bytes for the regular column + 100 bytes for row metadata = 131 bytes.
```
Amazon CloudWatch로 서버리스 리소스를 모니터링하는 방법을 알아보려면 [Amazon CloudWatch를 사용하여 Amazon Keyspaces 모니터링](monitoring-cloudwatch.md) 섹션을 참조하세요.
# Amazon Keyspaces에서 읽기 및 쓰기 처리량의 용량 소비 추정
Amazon Keyspaces에서 데이터를 읽거나 쓸 때 쿼리가 소비하는 읽기/쓰기 요청 단위(RRU/WRU) 또는 읽기/쓰기 용량 단위(RCU/WCU)의 양은 쿼리 실행에 필요한 총 데이터 양에 따라 달라집니다. 경우에 따라 클라이언트로 반환되는 데이터는 Amazon Keyspaces가 쿼리를 처리하기 위해 읽어야 하는 데이터의 하위 집합일 수 있습니다. 조건부 쓰기의 경우 Amazon Keyspaces는 조건부 확인이 실패하더라도 쓰기 용량을 사용합니다.
요청에 대해 처리되는 총 데이터 양을 추정하려면 행의 인코딩된 크기와 총 행 수를 고려해야 합니다. 이 주제에서는 Amazon Keyspaces가 쿼리를 처리하는 방법과 이것이 용량 소비에 미치는 영향을 보여주는 일반적인 시나리오 및 액세스 패턴의 몇 가지 예를 다룹니다. 예제에 따라 테이블의 용량 요구 사항을 추정하고 Amazon CloudWatch를 사용하여 이러한 사용 사례에 대한 읽기 및 쓰기 용량 소비를 관찰할 수 있습니다.
Amazon Keyspaces에서 인코딩된 행 크기를 계산하는 방법에 대한 자세한 내용은 [Amazon Keyspaces에서 행 크기 추정](calculating-row-size.md) 섹션을 참조하세요.
**Topics**
+ [Amazon Keyspaces에서 범위 쿼리의 용량 소비 추정](range_queries.md)
+ [제한 쿼리의 읽기 용량 소비 추정](limit_queries.md)
+ [테이블 스캔의 읽기 용량 소비 추정](table_scans.md)
+ [Amazon Keyspaces에서 경량 트랜잭션의 용량 소비 추정](lightweight_transactions.md)
+ [Amazon Keyspaces의 정적 열에 대한 용량 소비 추정](static-columns.md)
+ [Amazon Keyspaces에서 다중 리전 테이블의 용량 추정 및 프로비저닝](tables-multi-region-capacity.md)
+ [Amazon Keyspaces에서 Amazon CloudWatch로 읽기 및 쓰기 용량 소비량 추정](estimate_consumption_cw.md)
# Amazon Keyspaces에서 범위 쿼리의 용량 소비 추정
범위 쿼리의 읽기 용량 소비를 살펴보기 위해 온디맨드 용량 모드를 사용하는 다음 예제 테이블을 사용합니다.
```
pk1 | pk2 | pk3 | ck1 | ck2 | ck3 | value
-----+-----+-----+-----+-----+-----+-------
a | b | 1 | a | b | 50 |
a | b | 1 | a | b | 60 | value_1
a | b | 1 | a | b | 70 |
```
이제 이 테이블에서 다음 쿼리를 실행합니다.
```
SELECT * FROM amazon_keyspaces.example_table_1 WHERE pk1='a' AND pk2='b' AND pk3=1 AND ck1='a' AND ck2='b' AND ck3 > 50 AND ck3 < 70;
```
쿼리에서 다음 결과 세트를 수신하고 Amazon Keyspaces에서 수행하는 읽기 작업은 `LOCAL_QUORUM` 일관성 모드에서 2RRU를 사용합니다.
```
pk1 | pk2 | pk3 | ck1 | ck2 | ck3 | value
-----+-----+-----+-----+-----+-----+-------
a | b | 1 | a | b | 60 | value_1
```
Amazon Keyspaces는 쿼리를 처리하기 위해 `ck3=60` 및 `ck3=70` 값으로 행을 평가하는 데 2RRU를 사용합니다. 하지만 Amazon Keyspaces는 쿼리에 지정된 `WHERE` 조건이 true인 행, 즉 값이 `ck3=60`인 행만 반환합니다. 쿼리에 지정된 범위를 평가하기 위해 Amazon Keyspaces는 범위의 상한과 일치하는 행(이 경우 `ck3 = 70`)을 읽지만 결과에서 해당 행을 반환하지는 않습니다. 읽기 용량 소비량은 반환된 데이터가 아닌 쿼리를 처리할 때 읽은 데이터를 기반으로 합니다.
# 제한 쿼리의 읽기 용량 소비 추정
`LIMIT` 절을 사용하는 쿼리를 처리할 때 Amazon Keyspaces는 쿼리에 지정된 조건과 일치시키려고 할 때 최대 페이지 크기까지 행을 읽습니다. Amazon Keyspaces가 첫 페이지의 `LIMIT` 값을 충족하는 일치하는 데이터를 충분히 찾을 수 없는 경우 페이지가 매겨진 호출이 하나 이상 필요할 수 있습니다. 다음 페이지에서 읽기를 계속하려면 페이지 매김 토큰을 사용할 수 있습니다. 기본 페이지 크기는 1MB입니다. `LIMIT` 절을 사용할 때 읽기 용량을 줄이려면 페이지 크기를 줄일 수 있습니다. 페이지 매김에 대한 자세한 내용은 [Amazon Keyspaces의 결과 페이지 매김](paginating-results.md) 섹션을 참조하세요.
다음 쿼리에서 예제를 살펴보겠습니다.
```
SELECT * FROM my_table WHERE partition_key=1234 LIMIT 1;
```
페이지 크기를 설정하지 않으면 Amazon Keyspaces는 1행만 반환하더라도 1MB의 데이터를 읽습니다. Amazon Keyspaces가 한 행만 읽도록 하려면 이 쿼리의 페이지 크기를 1로 설정하면 됩니다. 이 경우 Amazon Keyspaces는 TTL(Time-to-Live) 설정 또는 클라이언트 측 타임스탬프를 기반으로 만료된 행이 없는 경우 한 행만 읽습니다.
`PAGE SIZE` 파라미터는 Amazon Keyspaces가 클라이언트에 반환하는 행 수가 아니라 각 요청에 대해 디스크에서 스캔하는 행 수를 결정합니다. Amazon Keyspaces는 키가 아닌 열이나 디스크의 데이터를 스캔한 `LIMIT` 후 등 사용자가 제공하는 필터를 적용합니다. 를 명시적으로 설정하지 않으면 `PAGE SIZE`Amazon Keyspaces는 필터를 적용하기 전에 최대 1MB의 데이터를 읽습니다. 예를 들어를 지정`LIMIT 1`하지 않고를 사용하는 경우 `PAGE SIZE`Amazon Keyspaces는 제한 절을 적용하고 단일 행만 반환하기 전에 디스크에서 수천 개의 행을 읽을 수 있습니다.
과다 읽기를 방지하려면 Amazon Keyspaces가 각 가져오기에 대해 스캔`PAGE SIZE`하는 행 수를 줄이는를 줄입니다. 예를 들어 쿼리`LIMIT 5`에서 `PAGE SIZE`를 정의하는 경우 Amazon Keyspaces가 페이지가 매겨진 각 호출에서 5\$110개의 행만 스캔하도록를 5\$110 사이의 값으로 설정합니다. 이 숫자를 수정하여 가져오기 수를 줄일 수 있습니다. 페이지 크기보다 큰 제한의 경우 Amazon Keyspaces는 페이지 매김 상태로 총 결과 수를 유지합니다. 행`LIMIT`이 10,000개인 경우 Amazon Keyspaces는 이러한 결과를 각각 5,000개의 행으로 구성된 두 페이지로 가져올 수 있습니다. 1MB 제한은 설정된 모든 페이지 크기의 상한입니다.
# 테이블 스캔의 읽기 용량 소비 추정
`ALLOW FILTERING` 옵션을 사용한 쿼리와 같이 전체 테이블 스캔을 초래하는 쿼리는 결과로 반환되는 것보다 더 많은 읽기를 처리하는 쿼리의 또 다른 예입니다. 또한 읽기 용량 소비량은 반환된 데이터가 아닌 읽은 데이터를 기반으로 합니다.
테이블 스캔 예제에서는 온디맨드 용량 모드에서 다음 예제 테이블을 사용합니다.
```
pk | ck | value
---+----+---------
pk | 10 |
pk | 20 | value_1
pk | 30 |
```
Amazon Keyspaces는 기본적으로 온디맨드 용량 모드에서 4개의 파티션으로 테이블을 생성합니다. 이 예제 테이블에서는 모든 데이터가 하나의 파티션에 저장되고 나머지 3개의 파티션은 비어 있습니다.
이제 이 테이블에서 다음 쿼리를 실행합니다.
```
SELECT * from amazon_keyspaces.example_table_2;
```
이 쿼리는 Amazon Keyspaces가 테이블의 4개 파티션을 모두 스캔하고 `LOCAL_QUORUM` 일관성 모드에서 6RRU를 사용하는 테이블 스캔 작업을 생성합니다. 먼저 Amazon Keyspaces는 `pk=‘pk’`를 사용하여 세 행을 읽기 위해 3RRU를 사용합니다. 그런 다음 Amazon Keyspaces는 테이블의 빈 파티션 3개를 스캔하기 위해 추가 3RRU를 사용합니다. 이 쿼리로 인해 테이블이 스캔되므로 Amazon Keyspaces는 데이터가 없는 파티션을 포함하여 테이블의 모든 파티션을 스캔합니다.
# Amazon Keyspaces에서 경량 트랜잭션의 용량 소비 추정
경량 트랜잭션(LWT)을 사용하면 테이블 데이터에 대해 조건부 쓰기 작업을 수행할 수 있습니다. 조건부 업데이트 작업은 현재 상태를 평가하는 조건에 따라 레코드를 삽입, 업데이트 및 삭제할 때 유용합니다.
Amazon Keyspaces에서 모든 쓰기 작업에는 LOCAL\$1QUORUM 일관성이 필요하며 LWT 사용에 대한 추가 요금은 없습니다. LWTs의 차이점은 LWT 조건 확인으로 인해가 생성되면 `FALSE`Amazon Keyspaces가 쓰기 용량 단위(WCUs) 또는 쓰기 요청 단위(WRUs. 사용되는 WCUs/WRUs 수는 행의 크기에 따라 달라집니다.
예를 들어 행 크기가 2KB인 경우 실패한 조건부 쓰기는 두 개의 WCUs/WRUs를 사용합니다. 행이 현재 테이블에 없는 경우 작업은 하나의 WCUs/WRUs를 사용합니다.
조건 확인 실패로 이어진 요청 수를 확인하려면 CloudWatch에서 `ConditionalCheckFailed` 지표를 모니터링할 수 있습니다.
## TTL(Time to Live)을 사용하여 테이블에 대한 LWT 비용 추정
LWTs 클라이언트 측 타임스탬프를 사용하지 않는 TTL로 구성된 테이블에 대한 추가 읽기 용량 단위(RCUs) 또는 읽기 요청 단위(RRUs)가 필요할 수 있습니다. 에서 `IF EXISTS` 또는 `IF NOT EXISTS` 키워드 조건 확인 결과를 사용하는 경우 `FALSE`다음 용량 단위가 사용됩니다.
+ RCUs/RRUs- 행이 있는 경우 사용된 RCUs/RRUs는 기존 행의 크기를 기반으로 합니다.
+ RCUs/RRUs- 행이 없으면 단일 RCU/RRU가 사용됩니다.
평가된 조건으로 인해 쓰기 작업이 성공하면 새 행의 크기에 따라 WCUs/WRUs가 사용됩니다.
# Amazon Keyspaces의 정적 열에 대한 용량 소비 추정
클러스터링 열이 있는 Amazon Keyspaces 테이블에서 `STATIC` 키워드를 사용하여 정적 열을 생성할 수 있습니다. 정적 열에 저장된 값은 논리적 파티션의 모든 행에서 공유됩니다. 이 열의 값을 업데이트하면 Amazon Keyspaces는 파티션의 모든 행에 변경 사항을 자동으로 적용합니다.
이 섹션에서는 정적 열에 쓸 때 인코딩된 데이터 크기를 계산하는 방법을 설명합니다. 이 프로세스는 행의 비정적 열에 데이터를 쓰는 프로세스와는 별도로 처리됩니다. 정적 데이터에 대한 크기 할당량 외에도 정적 열에 대한 읽기 및 쓰기 작업은 테이블의 측정 및 처리량 용량에도 독립적으로 영향을 미칩니다. 정적 열 및 페이지가 매겨진 범위 읽기 결과를 사용할 때 Apache Cassandra와의 기능적 차이점은 [페이지 매김](functional-differences.md#functional-differences.paging) 섹션을 참조하세요.
**Topics**
+ [Amazon Keyspaces의 논리적 파티션당 정적 열 크기 계산](static-columns-estimate.md)
+ [Amazon Keyspaces의 정적 데이터에 대한 읽기/쓰기 작업에 대한 용량 처리량 요구 사항 추정](static-columns-metering.md)
# Amazon Keyspaces의 논리적 파티션당 정적 열 크기 계산
이 섹션에서는 Amazon Keyspaces의 인코딩된 정적 열 크기를 추정하는 방법에 대한 세부 정보를 제공합니다. 인코딩된 크기는 요금 및 할당량 사용량을 계산할 때 사용됩니다. 또한 테이블의 프로비저닝된 처리량 용량 요구 사항을 계산할 때는 인코딩된 크기를 사용해야 합니다. Amazon Keyspaces 내에서 인코딩된 정적 열 크기를 계산하려는 경우 다음 지침을 사용할 수 있습니다.
+ 파티션 키는 최대 2048바이트의 데이터를 포함할 수 있습니다. 파티션 키의 각 키 열에는 최대 3바이트의 메타데이터가 필요합니다. 이러한 메타데이터 바이트는 파티션당 1MB의 정적 데이터 크기 할당량에 포함됩니다. 정적 데이터 크기를 계산할 때는 각 파티션 키 열이 전체 3바이트의 메타데이터를 사용한다고 가정해야 합니다.
+ 데이터 유형에 따른 정적 열 데이터 값의 원시 크기를 사용합니다. 데이터 유형에 대한 자세한 내용은 [데이터 타입](cql.elements.md#cql.data-types) 섹션을 참조하세요.
+ 메타데이터의 정적 데이터 크기에 104바이트를 추가합니다.
+ 클러스터링 열과 일반, 기본이 아닌 키 열은 정적 데이터 크기에 포함되지 않습니다. 행 내 비정적 데이터의 크기를 추정하는 방법에 대한 자세한 내용은 [Amazon Keyspaces에서 행 크기 추정](calculating-row-size.md) 섹션을 참조하세요.
인코딩된 정적 열의 총 크기는 다음 공식을 기반으로 합니다.
```
partition key columns + static columns + metadata = total encoded size of static data
```
모든 열의 유형이 정수인 다음 테이블을 예로 들어 보겠습니다. 테이블에는 파티션 키 열 2개, 클러스터링 열 2개, 일반 열 1개 및 정적 열 1개가 있습니다.
```
CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, static_col1 int static, primary key((pk_col1, pk_col2),ck_col1, ck_col2));
```
이 예제에서는 다음 문의 정적 데이터 크기를 계산합니다.
```
INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, static_col1) values(1,2,6);
```
이 쓰기 작업에 필요한 총 바이트를 추정하려면 다음 단계를 사용하면 됩니다.
1. 열에 저장된 데이터 유형의 바이트와 메타데이터 바이트를 더하여 파티션 키 열의 크기를 계산합니다. 모든 파티션 키 열에 대해 이 과정을 반복합니다.
1. 파티션 키(pk\$1col1)의 첫 번째 열 크기를 계산합니다.
```
4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes
```
1. 파티션 키(pk\$1col2)의 두 번째 열 크기를 계산합니다.
```
4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes
```
1. 두 열을 모두 더하여 파티션 키 열의 총 예상 크기를 구합니다.
```
7 bytes + 7 bytes = 14 bytes for the partition key columns
```
1. 정적 열의 크기를 더합니다. 이 예제에서는 정수를 저장하는 정적 열이 하나뿐입니다(4바이트 필요).
1. 마지막으로 정적 열 데이터의 인코딩된 총 크기를 구하려면 프라이머리 키 열과 정적 열의 바이트를 더하고 메타데이터에 대해 104바이트를 더 추가합니다.
```
14 bytes for the partition key columns + 4 bytes for the static column + 104 bytes for metadata = 122 bytes.
```
동일한 문을 사용하여 정적 및 비정적 데이터를 업데이트할 수도 있습니다. 쓰기 작업의 총 크기를 추정하려면 먼저 비정적 데이터 업데이트의 크기를 계산해야 합니다. 그런 다음 [Amazon Keyspaces에서 행 크기 추정](calculating-row-size.md)의 예제와 같이 행 업데이트 크기를 계산하고 결과를 더합니다.
이 경우 총 2MB를 쓸 수 있습니다. 즉 1MB는 최대 행 크기 할당량이고 1MB는 논리적 파티션당 최대 정적 데이터 크기 할당량입니다.
동일한 문에서 정적 및 비정적 데이터의 총 업데이트 크기를 계산하려면 다음 공식을 사용하면 됩니다.
```
(partition key columns + static columns + metadata = total encoded size of static data) + (partition key columns + clustering columns + regular columns + row metadata = total encoded size of row)
= total encoded size of data written
```
모든 열의 유형이 정수인 다음 테이블을 예로 들어 보겠습니다. 테이블에는 파티션 키 열 2개, 클러스터링 열 2개, 일반 열 1개 및 정적 열 1개가 있습니다.
```
CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, static_col1 int static, primary key((pk_col1, pk_col2),ck_col1, ck_col2));
```
이 예제에서는 다음 문과 같이 테이블에 행을 쓸 때의 데이터 크기를 계산합니다.
```
INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, ck_col1, ck_col2, reg_col1, static_col1) values(2,3,4,5,6,7);
```
이 쓰기 작업에 필요한 총 바이트를 추정하려면 다음 단계를 사용하면 됩니다.
1. 앞에 표시된 대로 정적 데이터의 인코딩된 총 크기를 계산합니다. 이 예제에서는 122바이트입니다.
1. [Amazon Keyspaces에서 행 크기 추정](calculating-row-size.md)의 단계에 따라 비정적 데이터의 업데이트를 기반으로 인코딩된 행의 총 크기를 추가합니다. 이 예제에서 행 업데이트의 총 크기는 134바이트입니다.
```
122 bytes for static data + 134 bytes for nonstatic data = 256 bytes.
```
# Amazon Keyspaces의 정적 데이터에 대한 읽기/쓰기 작업에 대한 용량 처리량 요구 사항 추정
Cassandra에서 정적 데이터는 개별 행이 아니라 논리적 파티션과 연결됩니다. Amazon Keyspaces의 논리적 파티션은 여러 물리적 스토리지 파티션에 걸쳐 있을 수 있으며 사실상 크기에 제한이 없습니다. 결과적으로 Amazon Keyspaces는 정적 데이터와 비정적 데이터에 대한 쓰기 작업을 별도로 측정합니다. 또한 정적 데이터와 비정적 데이터를 모두 포함하는 쓰기에는 데이터 일관성을 제공하기 위한 추가 기본 작업이 필요합니다.
정적 데이터와 비정적 데이터를 혼합하여 쓰기 작업을 수행하는 경우 두 개의 개별 쓰기 작업이 발생합니다. 하나는 비정적 데이터에 대한 것이고 다른 하나는 정적 데이터에 대한 것입니다. 이는 온디맨드 및 프로비저닝된 읽기/쓰기 용량 모드 모두에 적용됩니다.
다음 예제는 정적 열이 있는 Amazon Keyspaces의 테이블에 대해 프로비저닝된 처리량 용량 요구 사항을 계산할 때 필요한 읽기 용량 단위(RCU) 및 쓰기 용량 단위(WCU)를 추정하는 방법에 대한 세부 정보를 제공합니다. 다음 공식을 사용하여 정적 데이터와 비정적 데이터가 모두 포함된 쓰기를 테이블에서 처리하는 데 필요한 용량을 추정할 수 있습니다.
```
2 x WCUs required for nonstatic data + 2 x WCUs required for static data
```
예를 들어 애플리케이션이 초당 27KB의 데이터를 쓰고 각 쓰기에 25.5KB의 비정적 데이터와 1.5KB의 정적 데이터가 포함되는 경우 테이블에는 56WCU(2 x 26WCU \$1 2 x 2WCU)가 필요합니다.
Amazon Keyspaces는 여러 행의 읽기와 동일하게 정적 및 비정적 데이터의 읽기를 측정합니다. 따라서 동일한 작업에서 정적 및 비정적 데이터를 읽는 비용은 읽기를 수행하기 위해 처리된 데이터의 총 크기를 기준으로 합니다.
Amazon CloudWatch로 서버리스 리소스를 모니터링하는 방법을 알아보려면 [Amazon CloudWatch를 사용하여 Amazon Keyspaces 모니터링](monitoring-cloudwatch.md) 섹션을 참조하세요.
# Amazon Keyspaces에서 다중 리전 테이블의 용량 추정 및 프로비저닝
다음 두 가지 방법 중 하나로 다중 리전 테이블의 처리량 용량을 구성할 수 있습니다.
+ 쓰기 요청 단위(WRU)로 측정한 온디맨드 용량 모드
+ 쓰기 요청 단위(WRU)로 측정한 오토 스케일링으로 프로비저닝된 용량 모드
프로비저닝된 용량 모드를 Auto Scaling 또는 온디맨드 용량 모드와 함께 사용하여 다중 리전 테이블에 모든 사용자에게 복제된 쓰기를 수행할 수 있는 충분한 용량이 있는지 확인할 수 있습니다 AWS 리전.
**참고**
리전 중 하나에서 테이블의 용량 모드를 변경하면 모든 복제본의 용량 모드가 변경됩니다.
기본적으로 Amazon Keyspaces는 다중 리전 테이블에 온디맨드 모드를 사용합니다. 온디맨드 모드를 사용하면 애플리케이션에서 수행할 것으로 예상되는 읽기 및 쓰기 처리량을 지정할 필요가 없습니다. Amazon Keyspaces는 이전에 도달한 트래픽 수준까지 확장 또는 축소할 때 즉시 워크로드를 수용합니다. 워크로드 트래픽 수준이 새로운 피크를 기록할 경우에는 Amazon Keyspaces가 워크로드를 수용하기 위해 신속하게 조정을 수행합니다.
테이블에 대해 프로비저닝된 용량 모드를 선택하는 경우 애플리케이션에 필요한 초당 읽기 용량 단위(RCU) 및 쓰기 용량 단위(WCU) 수를 구성해야 합니다.
다중 리전 테이블의 처리량 용량 요구 사항을 계획하려면 먼저 각 리전에 필요한 초당 WCU 수를 추정해야 합니다. 그런 다음 테이블이 복제되는 모든 리전의 쓰기를 추가하고 합계를 사용하여 각 리전에 용량을 프로비저닝합니다. 이는 한 리전에서 수행되는 모든 쓰기도 각 복제본 리전에서 반복해야 하기 때문에 필요합니다.
테이블에 모든 리전으로부터의 쓰기를 처리할 용량이 충분하지 않은 경우 용량 예외가 발생합니다. 또한 리전 간 복제 대기 시간이 증가합니다.
예를 들어 미국 동부(버지니아 북부)에서 초당 5회 쓰기, 미국 동부(오하이오)에서 초당 10회 쓰기, 유럽(아일랜드)에서 초당 5회 쓰기가 예상되는 다중 리전 테이블이 있는 경우 테이블은 각 리전, 즉 미국 동부(버지니아 북부), 미국 동부(오하이오), 유럽(아일랜드)에서 20WCU를 소비할 것으로 예상해야 합니다. 즉, 이 예제에서는 테이블의 각 복제본에 대해 20WCU를 프로비저닝해야 합니다. Amazon CloudWatch를 사용하여 테이블의 용량 소비를 모니터링할 수 있습니다. 자세한 내용은 [Amazon CloudWatch를 사용하여 Amazon Keyspaces 모니터링](monitoring-cloudwatch.md) 단원을 참조하십시오.
각 쓰기는 1WCU로 청구되므로이 예제에서는 총 60WCUs 청구됩니다. 요금에 대한 자세한 내용은 [Amazon Keyspaces(Apache Cassandra용) 요금](https://aws.amazon.com/keyspaces/pricing)을 참조하세요.
Amazon Keyspaces 오토 스케일링을 통해 프로비저닝된 용량에 대한 자세한 내용은 [Amazon Keyspaces 오토 스케일링으로 처리량 용량 자동 관리](autoscaling.md) 섹션을 참조하세요.
**참고**
테이블이 오토 스케일링과 함께 프로비저닝된 용량 모드로 실행되는 경우 프로비저닝된 쓰기 용량은 각 리전의 오토 스케일링 설정 내에서 유동적으로 허용됩니다.
# Amazon Keyspaces에서 Amazon CloudWatch로 읽기 및 쓰기 용량 소비량 추정
CloudWatch 대시보드를 사용하여 읽기 및 쓰기 용량 소비를 추정하고 모니터링할 수 있습니다. Amazon Keyspaces에 사용 가능한 지표에 대한 자세한 내용은 [Amazon Keyspaces 지표 및 차원](metrics-dimensions.md) 섹션을 참조하세요.
CloudWatch의 특정 문에서 사용하는 읽기 및 쓰기 용량 단위를 모니터링하려면 다음 단계를 따르세요.
1. 샘플 데이터를 사용하여 새 테이블 생성
1. 테이블에 대한 Amazon Keyspaces CloudWatch 대시보드를 구성합니다. 시작하려면 [Github](https://github.com/aws-samples/amazon-keyspaces-cloudwatch-cloudformation-templates)에서 제공되는 대시보드 템플릿을 사용할 수 있습니다.
1. 예를 들어 `ALLOW FILTERING` 옵션을 사용하여 CQL 문을 실행하고 대시보드에서 전체 테이블 스캔에 사용된 읽기 용량 단위를 확인합니다.
# Amazon Keyspaces의 읽기/쓰기 용량 모드 구성
Amazon Keyspaces에는 테이블에서 읽기 및 쓰기 처리를 위한 두 가지 읽기/쓰기 용량 모드가 있습니다.
+ 온디맨드(기본값)
+ 프로비저닝됨
선택하는 읽기/쓰기 용량 모드는 읽기 및 쓰기 처리량에 대한 청구 방식과 테이블 처리량 용량 관리 방식을 제어합니다.
**Topics**
+ [온디맨드 용량 모드 구성](ReadWriteCapacityMode.OnDemand.md)
+ [프로비저닝된 용량 모드 구성](ReadWriteCapacityMode.Provisioned.md)
+ [Amazon Keyspaces에서 테이블의 용량 모드 보기](ReadWriteCapacityMode.ProvisionedThroughput.ManagingCapacity.md)
+ [Amazon Keyspaces에서 테이블의 용량 모드 변경](ReadWriteCapacityMode.SwitchReadWriteCapacityMode.md)
+ [Amazon Keyspaces의 테이블에 대한 사전 워밍 구성](warm-throughput.md)
# 온디맨드 용량 모드 구성
Amazon Keyspaces(Apache Cassandra용) *온디맨드* 용량 모드는 용량 계획 없이 초당 수천 개의 요청을 처리할 수 있는 유연한 청구 옵션입니다. 이 옵션은 읽기 및 쓰기 요청에 대해 요청당 지불 가격을 제공하므로 사용하는 만큼에 대해서만 비용을 지불하면 됩니다.
온디맨드 모드를 선택하면 Amazon Keyspaces는 테이블의 처리량 용량을 이전에 도달한 트래픽 수준까지 즉시 확장하고 애플리케이션 트래픽이 감소할 때 다시 축소할 수 있습니다. 워크로드의 트래픽 수준이 새로운 피크를 기록할 경우에는 서비스가 신속하게 조정을 수행하여 테이블의 처리량 용량을 증가시킵니다. 새 테이블과 기존 테이블 모두에 대해 온디맨드 용량 모드를 활성화할 수 있습니다.
온디맨드 모드는 다음 중 하나에 해당되는 경우에 유용한 옵션입니다.
+ 알 수 없는 워크로드를 포함하는 테이블을 새로 만드는 경우
+ 애플리케이션 트래픽이 예측 불가능한 경우가 있습니다.
+ 사용한 만큼에 대해서만 지불하는 요금제를 사용하려는 경우
온디맨드 모드를 시작하려면 콘솔을 사용하거나 몇 줄의 Cassandra 쿼리 언어(CQL) 코드를 사용하여 온디맨드 용량 모드를 사용하도록 새 테이블을 만들거나 기존 테이블을 업데이트하면 됩니다. 자세한 내용은 [테이블](cql.ddl.table.md) 단원을 참조하십시오.
**Topics**
+ [읽기 요청 단위 및 쓰기 요청 단위](#ReadWriteCapacityMode.requests)
+ [피크 트래픽 및 크기 조정 속성](#ReadWriteCapacityMode.PeakTraffic)
+ [온디맨드 용량 모드의 초기 처리량](#ReadWriteCapacityMode.InitialThroughput)
## 읽기 요청 단위 및 쓰기 요청 단위
온디맨드 용량 모드 테이블을 사용하면 애플리케이션에서 미리 사용할 것으로 예상되는 읽기 및 쓰기 처리량을 지정할 필요가 없습니다. Amazon Keyspaces에서는 읽기 요청 단위(RRU) 및 쓰기 요청 단위(WRU)의 측면에서 테이블에서 수행하는 읽기 및 쓰기에 대해 요금이 부과됩니다.
+ *RRU* 1은 최대 4KB 크기의 행에 대한 `LOCAL_QUORUM` 읽기 요청 1회 또는 ` LOCAL_ONE` 읽기 요청 2회를 나타냅니다. 4KB보다 큰 행을 읽어야 하는 경우 읽기 작업에 추가 RRU가 사용됩니다. 필요한 총 RRU 수는 행 크기, `LOCAL_QUORUM` 또는 `LOCAL_ONE` 읽기 일관성을 사용하려는지 여부에 따라 다릅니다. 예를 들어 8KB 행을 읽으려면 `LOCAL_QUORUM` 읽기 일관성을 사용하는 2RRU가 필요하고 `LOCAL_ONE` 읽기 일관성을 선택한 경우 1RRU가 필요합니다.
+ *WRU* 1은 최대 1KB 크기의 행에 대한 1회의 쓰기를 나타냅니다. 모든 쓰기는 `LOCAL_QUORUM` 일관성을 사용하며 간단한 트랜잭션(LWT) 사용에 대한 추가 비용은 없습니다. 1KB보다 큰 행을 써야 하는 경우 쓰기 작업에 추가 WRU가 사용됩니다. 필요한 WRU의 총 수는 행 크기에 따라 달라집니다. 예를 들어 행 크기가 2KB인 경우 쓰기 요청 하나를 수행하려면 2WRU가 필요합니다.
지원되는 일관성 수준에 대한 자세한 내용은 [지원되는 Apache Cassandra 읽기 및 쓰기 일관성 수준 및 관련 비용](consistency.md) 섹션을 참조하세요.
## 피크 트래픽 및 크기 조정 속성
온디맨드 용량 모드를 사용하는 Amazon Keyspaces 테이블은 애플리케이션의 트래픽 볼륨에 따라 자동으로 조정됩니다. 온디맨드 용량 모드의 테이블은 이전 피크 트래픽의 최대 2배 용량을 즉시 수용합니다. 예를 들어 애플리케이션의 트래픽 패턴은 초당 5,000\$110,000회 `LOCAL_QUORUM` 읽기 사이에서 다양할 수 있으며 이때 초당 10,000회 읽기가 이전 트래픽 피크입니다.
이 패턴을 사용하면 온디맨드 용량 모드는 초당 최대 20,000회 읽기의 지속적인 트래픽을 즉시 수용할 수 있습니다. 애플리케이션이 초당 20,000회 읽기 트래픽을 지속하는 경우 해당 피크가 새로운 이전 피크가 되어 후속 트래픽은 초당 최대 40,000회 읽기에 도달할 수 있습니다.
테이블에서 이전 피크의 2배 이상이 필요한 경우 Amazon Keyspaces가 트래픽 볼륨이 증가함에 따라 자동으로 추가 용량을 할당합니다. 이렇게 하면 테이블에 추가 요청을 처리하기에 충분한 처리량 용량을 확보할 수 있습니다. 하지만 30분 이내에 이전 피크의 두 배를 초과하면 처리량 용량 부족 오류가 발생할 수 있습니다.
예를 들어 애플리케이션의 트래픽 패턴이 초당 5,000\$110,000회의 강력히 일관된 읽기 사이에서 다양하다고 가정합니다. 이때 초당 20,000회 읽기는 이전에 도달한 트래픽 피크입니다. 이 경우 서비스에서는 초당 최대 40,000회의 읽기 횟수를 늘리기 전에 최소 30분 이상 트래픽 증가 간격을 두는 것이 좋습니다.
테이블의 읽기 및 쓰기 용량 소비를 추정하는 방법을 알아보려면 [Amazon Keyspaces에서 읽기 및 쓰기 처리량의 용량 소비 추정](capacity-examples.md) 섹션을 참조하세요.
계정의 기본 할당량 및 할당량을 높이는 방법에 대한 자세한 내용은 [Amazon Keyspaces(Apache Cassandra용)에 대한 할당량](quotas.md) 섹션을 참조하세요.
## 온디맨드 용량 모드의 초기 처리량
온디맨드 용량 모드가 활성화된 새 테이블을 생성하거나 처음으로 기존 테이블을 온디맨드 용량 모드로 전환하는 경우 이전에 온디맨드 용량 모드를 사용하여 트래픽을 처리하지 않았더라도 테이블의 이전 피크 설정은 다음과 같습니다.
+ **온디맨드 용량 모드로 새로 만든 테이블:** 이전 피크는 2,000WRU와 6,000RRU였습니다. 이전 피크의 최대 두 배까지 즉시 늘릴 수 있습니다. 이렇게 하면 새로 생성된 온디맨드 테이블에서 최대 4,000WRU와 12,000RRU를 처리할 수 있습니다.
+ **온디맨드 용량 모드로 전환된 기존 테이블:** 이전 피크는 테이블에 대해 프로비저닝된 이전 WCU 및 RCU의 절반이거나 온디맨드 용량 모드를 통해 새로 생성된 테이블의 설정 중 더 높은 값입니다.
# 프로비저닝된 용량 모드 구성
*프로비저닝된 처리량* 용량 모드를 선택하는 경우 애플리케이션에 필요한 초당 읽기 및 쓰기 횟수를 지정합니다. 이를 통해 Amazon Keyspaces 사용량을 관리하여 정의된 요청 속도 이하로 유지하여 예측 가능성을 유지할 수 있습니다. 프로비저닝된 처리량을 위한 자동 크기 조정에 대한 자세한 내용은 [Amazon Keyspaces 오토 스케일링으로 처리량 용량 자동 관리](autoscaling.md) 섹션을 참조하세요.
프로비저닝된 처리량 용량 모드는 다음 중 하나에 해당되는 경우에 유용한 옵션입니다.
+ 애플리케이션 트래픽이 예측 가능한 경우
+ 트래픽이 일관되거나 점진적으로 변화하는 애플리케이션을 실행할 경우
+ 용량 요구 사항을 예측할 수 있습니다.
## 읽기 용량 단위 및 쓰기 용량 단위
프로비저닝된 처리량 용량 모드 테이블의 경우 읽기 용량 단위(RCU) 및 쓰기 용량 단위(WCU)의 측면에서 처리량을 지정합니다.
+ *RCU* 1은 최대 4KB 크기의 행에 대해 초당 `LOCAL_QUORUM` 읽기 1회 또는 초당 `LOCAL_ONE` 읽기 2회를 나타냅니다. 4KB보다 큰 행을 읽어야 하는 경우 읽기 작업에 추가 RCU가 사용됩니다.
필요한 총 RCU 수는 행 크기, `LOCAL_QUORUM` 또는 `LOCAL_ONE` 읽기를 원하는지 여부에 따라 다릅니다. 예를 들어 행 크기가 8KB인 경우 초당 `LOCAL_QUORUM` 읽기 1회를 유지하려면 2RCU개가 필요하고, `LOCAL_ONE` 읽기를 선택하면 1RCU가 필요합니다.
+ *WCU* 1은 최대 1KB 크기의 행에 대한 초당 1회의 쓰기를 나타냅니다. 모든 쓰기는 `LOCAL_QUORUM` 일관성을 사용하며 간단한 트랜잭션(LWT) 사용에 대한 추가 비용은 없습니다. 1KB보다 큰 행을 써야 하는 경우 쓰기 작업에 추가 WCU가 사용됩니다.
필요한 WCU의 총 수는 행 크기에 따라 달라집니다. 예를 들어 행 크기가 2KB인 경우 초당 쓰기 요청 하나를 유지하려면 2WCU가 필요합니다. 테이블의 읽기 및 쓰기 용량 소비를 추정하는 방법에 대한 자세한 내용은 [Amazon Keyspaces에서 읽기 및 쓰기 처리량의 용량 소비 추정](capacity-examples.md) 섹션을 참조하세요.
애플리케이션이 더 큰 행(1MB의 Amazon Keyspaces 최대 행 크기까지)을 읽거나 쓸 경우 더 많은 용량 단위를 사용합니다. 행 크기를 추정하는 방법에 대한 자세한 내용은 [Amazon Keyspaces에서 행 크기 추정](calculating-row-size.md) 섹션을 참조하세요. 예를 들어 6RCU 및 6WCU로 프로비저닝된 테이블을 생성한다고 가정하겠습니다. 이렇게 설정하면 애플리케이션에서 다음을 수행할 수 있습니다.
+ 초당 최대 24KB의 `LOCAL_QUORUM` 읽기 수행(4KB × 6RCU)
+ 초당 최대 48KB의 `LOCAL_ONE` 읽기 수행(읽기 처리량의 2배)
+ 초당 최대 6KB 쓰기(1KB × 6WCU)
*프로비저닝된 처리량*은 애플리케이션이 테이블에서 사용할 수 있는 최대 처리량 용량의 양입니다. 애플리케이션이 프로비저닝된 처리량 용량을 초과하는 경우 용량 부족 오류가 발생할 수 있습니다.
예를 들어 처리량 용량이 충분하지 않은 읽기 요청은 `Read_Timeout` 예외와 함께 실패하고 `ReadThrottleEvents` 지표에 게시됩니다. 처리량 용량이 충분하지 않은 쓰기 요청은 `Write_Timeout` 예외와 함께 실패하고 `WriteThrottleEvents` 지표에 게시됩니다.
Amazon CloudWatch를 사용하여 프로비저닝된 처리량 지표와 실제 처리량 지표 및 용량 부족 이벤트를 모니터링할 수 있습니다. 이러한 지표에 대한 자세한 내용은 [Amazon Keyspaces 지표 및 차원](metrics-dimensions.md) 섹션을 참조하세요.
**참고**
용량 부족으로 오류가 반복되면 클라이언트 측 드라이버별 예외가 발생할 수 있습니다. 예를 들어 DataStax Java 드라이버가 `NoHostAvailableException`으로 실패합니다.
테이블의 처리량 용량 설정을 변경하려면 CQL을 사용한 AWS Management Console 또는 `ALTER TABLE` 문을 사용할 수 있습니다. 자세한 내용은 [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter) 섹션을 참조하세요.
계정의 기본 할당량 및 할당량을 높이는 방법에 대한 자세한 내용은 [Amazon Keyspaces(Apache Cassandra용)에 대한 할당량](quotas.md) 섹션을 참조하세요.
# Amazon Keyspaces에서 테이블의 용량 모드 보기
Amazon Keyspaces 시스템 키스페이스에서 시스템 테이블을 쿼리하여 테이블에 대한 용량 모드 정보를 검토할 수 있습니다. 또한 테이블이 온디맨드 또는 프로비저닝된 처리량 용량 모드를 사용하는지 확인할 수 있습니다. 테이블이 프로비저닝된 처리량 용량 모드로 구성된 경우 테이블에 대한 프로비저닝된 처리량 용량을 확인할 수 있습니다.
AWS CLI 를 사용하여 테이블의 용량 모드를 볼 수도 있습니다.
테이블의 프로비저닝된 처리량을 변경하려면 [Amazon Keyspaces에서 테이블의 용량 모드 변경](ReadWriteCapacityMode.SwitchReadWriteCapacityMode.md)를 사용합니다.
------
#### [ Cassandra Query Language (CQL) ]
**예제**
```
SELECT * from system_schema_mcs.tables where keyspace_name = 'mykeyspace' and table_name = 'mytable';
```
온디맨드 용량 모드로 구성된 테이블은 다음을 반환합니다.
```
{
"capacity_mode":{
"last_update_to_pay_per_request_timestamp":"1579551547603",
"throughput_mode":"PAY_PER_REQUEST"
}
}
```
온디맨드 처리량 용량 모드로 구성된 테이블은 다음을 반환합니다.
```
{
"capacity_mode":{
"last_update_to_pay_per_request_timestamp":"1579048006000",
"read_capacity_units":"5000",
"throughput_mode":"PROVISIONED",
"write_capacity_units":"6000"
}
}
```
`last_update_to_pay_per_request_timestamp` 값은 밀리초 단위로 측정됩니다.
------
#### [ CLI ]
를 사용하여 테이블의 처리량 용량 모드 보기 AWS CLI
```
aws keyspaces get-table --keyspace-name myKeyspace --table-name myTable
```
프로비저닝된 용량 모드의 테이블에 대한 명령의 출력은 이와 유사하게 보일 수 있습니다.
```
"capacitySpecification": {
"throughputMode": "PROVISIONED",
"readCapacityUnits": 4000,
"writeCapacityUnits": 2000
}
```
온디맨드 모드의 테이블 출력은 다음과 같습니다.
```
"capacitySpecification": {
"throughputMode": "PAY_PER_REQUEST",
"lastUpdateToPayPerRequestTimestamp": "2024-10-03T10:48:19.092000+00:00"
}
```
------
# Amazon Keyspaces에서 테이블의 용량 모드 변경
테이블을 프로비저닝된 용량 모드에서 온디맨드 용량 모드로 전환할 경우 Amazon Keyspaces에서 테이블 및 파티션의 구조가 다양하게 변경됩니다. 이 프로세스는 몇 분 정도 걸릴 수 있습니다. 전환 기간 동안 테이블은 이전에 프로비저닝된 WCU 및 RCU 양과 일치하는 처리량을 제공합니다.
온디맨드 용량 모드에서 프로비저닝된 용량 모드로 다시 전환할 경우 테이블이 온디맨드 용량 모드로 설정되었을 때 도달한 이전 피크와 일치하는 처리량을 제공합니다.
용량 모드를 전환할 때 다음 대기 기간이 적용됩니다.
+ 온디맨드 모드에서 새로 생성된 테이블은 언제든지 프로비저닝된 용량 모드로 전환할 수 있습니다. 하지만 테이블 생성 타임스탬프 이후 24시간이 지난 뒤에야 온디맨드 모드로 다시 전환할 수 있습니다.
+ 온디맨드 모드의 기존 테이블은 언제든지 프로비저닝된 용량 모드로 전환할 수 있습니다. 그러나 용량 모드를 프로비저닝됨에서 온디맨드로 전환하는 것은 24시간 동안 한 번만 가능합니다.
------
#### [ Cassandra Query Language (CQL) ]
**CQL을 사용하여 테이블의 처리량 용량 모드 변경**
1. 테이블의 용량 모드를 `PROVIOSIONED`로 변경하려면 워크로드 예상 피크 값을 기반으로 읽기 용량 및 쓰기 용량 단위를 구성해야 합니다. 다음 문은 이에 대한 예입니다. 이 문을 실행하여 테이블의 읽기 용량 또는 쓰기 용량 단위를 조정할 수도 있습니다.
```
ALTER TABLE catalog.book_awards WITH CUSTOM_PROPERTIES={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 6000, 'write_capacity_units': 3000}};
```
오토 스케일링을 사용하여 프로비저닝된 용량 모드를 구성하려면 [기존 테이블에서 오토 스케일링 구성](autoscaling.configureTable.md) 섹션을 참조하세요.
1. 테이블의 용량 모드를 온디맨드 모드로 변경하려면 처리량 모드를 `PAY_PER_REQUEST`로 설정합니다. 다음 문은 이에 대한 예입니다.
```
ALTER TABLE catalog.book_awards WITH CUSTOM_PROPERTIES={'capacity_mode':{'throughput_mode': 'PAY_PER_REQUEST'}};
```
1. 다음 문을 사용하여 테이블의 용량 모드를 확인할 수 있습니다.
```
SELECT * from system_schema_mcs.tables where keyspace_name = 'catalog' and table_name = 'book_awards';
```
온디맨드 용량 모드로 구성된 테이블은 다음을 반환합니다.
```
{
"capacity_mode":{
"last_update_to_pay_per_request_timestamp":"1727952499092",
"throughput_mode":"PAY_PER_REQUEST"
}
}
```
`last_update_to_pay_per_request_timestamp` 값은 밀리초 단위로 측정됩니다.
------
#### [ CLI ]
**를 사용하여 테이블의 처리량 용량 모드 변경 AWS CLI**
1. 테이블의 용량 모드를 `PROVIOSIONED`로 변경하려면 워크로드의 예상 피크 값을 기반으로 읽기 용량 및 쓰기 용량 단위를 구성해야 합니다. 다음 CLI 명령은 그 예입니다. 이 명령을 실행하여 테이블의 읽기 용량 또는 쓰기 용량 단위를 조정할 수도 있습니다.
```
aws keyspaces update-table --keyspace-name catalog --table-name book_awards
\--capacity-specification throughputMode=PROVISIONED,readCapacityUnits=6000,writeCapacityUnits=3000
```
오토 스케일링을 사용하여 프로비저닝된 용량 모드를 구성하려면 [기존 테이블에서 오토 스케일링 구성](autoscaling.configureTable.md) 섹션을 참조하세요.
1. 테이블의 용량 모드를 온디맨드 모드로 변경하려면 처리량 모드를 `PAY_PER_REQUEST`로 설정합니다. 다음 문은 이에 대한 예입니다.
```
aws keyspaces update-table --keyspace-name catalog --table-name book_awards
\--capacity-specification throughputMode=PAY_PER_REQUEST
```
1. 다음 명령을 사용하여 테이블에 대해 구성된 용량 모드를 검토할 수 있습니다.
```
aws keyspaces get-table --keyspace-name catalog --table-name book_awards
```
온디맨드 모드의 테이블 출력은 다음과 같습니다.
```
"capacitySpecification": {
"throughputMode": "PAY_PER_REQUEST",
"lastUpdateToPayPerRequestTimestamp": "2024-10-03T10:48:19.092000+00:00"
}
```
------
# Amazon Keyspaces의 테이블에 대한 사전 워밍 구성
Amazon Keyspaces는 온디맨드 또는 프로비저닝된 처리량을 기반으로 스토리지 파티션을 자동으로 확장하지만, 새 테이블 또는 갑작스러운 처리량 피크의 경우 필요한 스토리지 파티션을 할당하는 데 더 오래 걸릴 수 있습니다. 신규 또는 기존 테이블의 용량이 예상 피크 처리량을 지원할 만큼 충분한지 확인하려면 특정 *웜 처리량* 값을 수동으로 설정하여 테이블*을 사전 워밍*할 수 있습니다.
*웜 처리량*은 Amazon Keyspaces 테이블이 동시에 지원할 수 있는 읽기 및 쓰기 작업 수를 나타냅니다. 이러한 값은 기본적으로 모든 신규 및 기존 테이블에 사용할 수 있습니다. 온디맨드 모드를 사용하거나 프로비저닝된 처리량을 업데이트하는 경우 Amazon Keyspaces는 애플리케이션이 해당 값까지 요청을 즉시 실행할 수 있도록 합니다.
Amazon Keyspaces는 사용량이 증가함에 따라 웜 처리량 값을 자동으로 조정합니다. 예를 들어 짧은 시간 내에 테라바이트의 데이터를 로드해야 할 수 있는 다른 데이터베이스에서 데이터를 마이그레이션하는 경우 예정된 피크 이벤트에 대한 처리량 용량을 조정하려면 테이블 웜 처리량 값을 수동으로 늘릴 수 있습니다. 이는 요청 속도가 10배, 100배 이상 증가할 수 있는 계획된 피크 이벤트에 유용합니다. 먼저 현재 웜 처리량이 예상 트래픽을 처리하기에 충분한지 평가합니다. 그런 다음 계획된 피크 워크로드에 대해 테이블을 사전 워밍해야 하는 경우 처리량 설정 또는 [용량 모드를](ReadWriteCapacityMode.md) 변경하지 않고 수동으로 웜 처리량 값을 늘릴 수 있습니다.
읽기 작업, 쓰기 작업 또는 둘 다에 대해 테이블을 사전 워밍할 수 있습니다. 신규 및 기존 단일 리전 테이블과 다중 리전 테이블의 경우이 값을 늘릴 수 있으며 설정한 웜 처리량 설정은 다중 리전 테이블의 모든 복제본에 자동으로 적용됩니다. 언제든지 사전 워밍할 수 있는 Amazon Keyspaces 테이블 수에는 제한이 없습니다. 사전 워밍을 완료하는 데 걸리는 시간은 설정한 값과 테이블 크기에 따라 달라집니다. 동시에 사전 웜 요청을 제출할 수 있으며 이러한 요청은 테이블 작업을 방해하지 않습니다. 해당 리전의 계정에 대한 테이블 할당량 한도까지 테이블을 사전 워밍할 수 있습니다. [Service Quotas 콘솔](https://console.aws.amazon.com/servicequotas)을 사용하여 현재 할당량을 확인하고 필요한 경우 늘리세요.
Amazon Keyspaces가 온디맨드 사용량 또는 프로비저닝된 용량에 따라 조정하는 웜 처리량 값은 추가 비용 없이 모든 테이블에 대해 기본적으로 사용할 수 있습니다. 그러나 기본 웜 처리량 값을 수동으로 늘려 피크 트래픽 이벤트에 대해 테이블을 사전 워밍하는 경우 추가 요금이 적용됩니다. 자세한 내용은 [Amazon Keyspaces 요금을](https://aws.amazon.com/keyspaces/pricing/) 참조하세요.
다음은 Amazon Keyspaces 테이블을 사전 워밍할 때 고려할 수 있는 몇 가지 시나리오와 모범 사례입니다.
## 웜 처리량 및 고르지 않은 액세스 패턴
테이블의 웜 처리량은 초당 30,000개의 읽기 단위와 초당 10,000개의 쓰기 단위일 수 있지만 해당 값에 도달하기 전에 읽기 또는 쓰기에서 여전히 용량 초과 이벤트가 발생할 수 있습니다. 이는 핫 파티션 때문일 수 있습니다. Amazon Keyspaces는 거의 무제한 처리량을 지원하도록 규모를 조정할 수 있지만 각 개별 파티션은 초당 1,000개의 쓰기 단위와 초당 3,000개의 읽기 단위로 제한됩니다. 애플리케이션이 테이블 파티션의 작은 부분으로 트래픽을 너무 많이 구동하는 경우 테이블의 웜 처리량 값에 도달하기 전에도 용량 초과 이벤트가 발생할 수 있습니다. 원활한 확장성을 보장하고 핫 파티션을 방지하려면 [Amazon Keyspaces 모범 사례를](bp-partition-key-design.md) 따르는 것이 좋습니다.
## 프로비저닝된 테이블의 웜 처리량
웜 처리량이 초당 30,000개의 읽기 단위와 초당 10,000개의 쓰기 단위이지만 현재 프로비저닝된 처리량이 4,000개의 RCUs와 8,000개의 WCUs. 프로비저닝된 처리량 설정을 업데이트하여 테이블의 프로비저닝된 처리량을 최대 30,000RCUs 10,000WCUs 즉시 조정할 수 있습니다. 이러한 값 이상으로 프로비저닝된 처리량을 늘리면 새로운 피크 처리량을 설정했기 때문에 웜 처리량이 자동으로 더 높은 새 값으로 조정됩니다. 예를 들어 프로비저닝된 처리량을 50,000RCU로 설정하면 웜 처리량이 초당 50,000 읽기 단위로 증가합니다.
```
"ProvisionedThroughput":
{
"ReadCapacityUnits": 4000,
"WriteCapacityUnits": 8000
}
"WarmThroughput":
{
"ReadUnitsPerSecond": 30000,
"WriteUnitsPerSecond": 10000
}
```
## 온디맨드 테이블의 웜 처리량
새로운 온디맨드 테이블은 초당 12,000개의 읽기 단위와 초당 4,000개의 쓰기 단위의 웜 처리량으로 시작됩니다. 테이블은 이러한 수준까지 지속적인 트래픽을 즉시 수용할 수 있습니다. 요청이 초당 12,000개의 읽기 단위 또는 초당 4,000개의 쓰기 단위를 초과하면 웜 처리량이 자동으로 더 높은 값으로 조정됩니다.
```
"WarmThroughput":
{
"ReadUnitsPerSecond": 12000,
"WriteUnitsPerSecond": 4000
}
```
## Amazon Keyspaces 테이블 사전 워밍 모범 사례
Amazon Keyspaces 테이블에 사전 워밍을 구현할 때 다음 모범 사례를 따르세요.
필요한 용량을 정확하게 추정합니다.
사전 워밍에는 일회성 비용이 발생하므로 오버프로비저닝을 방지하기 위해 예상 워크로드를 기반으로 필요한 처리량을 신중하게 계산하세요.
테이블의 스키마 고려
행이 큰 테이블은 동일한 처리량에 더 많은 파티션이 필요할 수 있습니다. 사전 워밍 요구 사항을 추정할 때 평균 행 크기의 팩터입니다.
테이블 성능 모니터링
사전 워밍 후 CloudWatch 지표를 사용하여 테이블이 예상대로 로드를 처리하고 있는지 확인합니다. 자세한 내용은 [Amazon CloudWatch를 사용하여 사전 워밍된 테이블의 성능 모니터링](monitor-prewarming-cloudwatch.md) 단원을 참조하십시오.
할당량 관리
애플리케이션에 허용되는 기본 할당량(40,000RCUs/WCUs 또는 2,000개 파티션)보다 높은 처리량이 필요한 경우 트래픽이 많은 이벤트가 발생하기 훨씬 전에 요청 할당량을 늘리세요. 할당량 증가를 요청하려면 [ Service Quotas 콘솔](https://console.aws.amazon.com/servicequotas)을 사용하세요.
비용 최적화
일시적인 트래픽이 많은 이벤트의 경우 단기간 이벤트에 더 비용 효율적일 수 있으므로 용량이 많은 프로비저닝 모드로 전환하는 대신 사전 워밍을 사용하는 것이 좋습니다. 요금에 대한 자세한 내용은 [Amazon Keyspaces 요금을](https://aws.amazon.com/keyspaces/pricing/) 참조하세요.
**참고**
테스트 단계에서 애플리케이션의 성능 지표를 모니터링하여 사전 워밍 구성이 워크로드 요구 사항을 적절하게 지원하는지 확인합니다.
**Topics**
+ [웜 처리량 및 고르지 않은 액세스 패턴](#warm-throughput-scenarios-uneven)
+ [프로비저닝된 테이블의 웜 처리량](#warm-throughput-scenarios-provisioned)
+ [온디맨드 테이블의 웜 처리량](#warm-throughput-scenarios-ondemand)
+ [Amazon Keyspaces 테이블 사전 워밍 모범 사례](#prewarming-best-practices)
+ [웜 처리량이 더 높은 새 Amazon Keyspaces 테이블 생성](create-table-warm-throughput.md)
+ [기존 Amazon Keyspaces 테이블의 웜 처리량 증가](update-warm-throughput.md)
+ [Amazon Keyspaces 테이블의 웜 처리량 보기](view-warm-throughput.md)
+ [Amazon CloudWatch를 사용하여 사전 워밍된 테이블의 성능 모니터링](monitor-prewarming-cloudwatch.md)
# 웜 처리량이 더 높은 새 Amazon Keyspaces 테이블 생성
콘솔, CQL 또는를 사용하여 Amazon Keyspaces 테이블을 생성할 때 웜 처리량 값을 조정할 수 있습니다 AWS CLI.
------
#### [ Console ]
**웜 처리량 설정으로 새 테이블을 생성하는 방법**
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) Amazon Keyspaces 콘솔을 엽니다.
1. 탐색 창에서 **테이블**을 선택한 다음 **테이블 생성**을 선택합니다.
1. **테이블 세부 정보** 섹션의 **테이블 생성** 페이지에서 키스페이스를 선택하고 새 테이블의 이름을 입력합니다.
1. **열** 섹션에서 테이블의 스키마를 생성합니다.
1. **프라이머리 키** 섹션에서 테이블의 프라이머리 키를 정의하고 선택적 클러스터링 열을 선택합니다.
1. **테이블 설정** 섹션에서 **설정 사용자 지정**을 선택합니다.
1. **읽기/쓰기 용량 설정**을 계속합니다.
1. **용량 모드에서** **온디맨**드 또는 **프로비저닝됨을** 선택할 수 있습니다.
1. **테이블의 사전 워밍** 섹션에서 필요에 따라 **초당 읽기 단위** 및 **초당 쓰기 단위** 값을 늘려 계획된 피크 이벤트를 처리할 테이블을 준비할 수 있습니다.
Amazon Keyspaces가 온디맨드 사용량 또는 프로비저닝된 용량에 따라 조정하는 웜 처리량 값은 추가 비용 없이 모든 테이블에 대해 기본적으로 사용할 수 있습니다. 기본 웜 처리량 값을 수동으로 늘려 피크 트래픽 이벤트에 대해 테이블을 사전 워밍하는 경우 추가 요금이 적용됩니다.
1. 필요에 따라 다른 선택적 테이블 기능을 구성합니다. 그런 다음 **테이블 생성을** 선택합니다.
------
#### [ Cassandra Query Language (CQL) ]
+ 다음 방법 중 하나를 사용하여 웜 처리량이 있는 테이블을 생성합니다.
+ 프로비저닝된 모드의 경우 테이블을 생성하고 다음 CQL 구문을 사용하여 읽기 및 쓰기에 대한 예상 피크 용량을 지정합니다.
```
CREATE TABLE catalog.book_awards (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank))
WITH CUSTOM_PROPERTIES = {
'capacity_mode': {
'throughput_mode': 'PROVISIONED',
'read_capacity_units': 20000,
'write_capacity_units': 10000
},
'warm_throughput': {
'read_units_per_second': 40000,
'write_units_per_second': 20000
}
};
```
+ 온디맨드 모드의 경우 테이블을 생성하고 다음 CQL 구문을 사용하여 읽기 및 쓰기에 대한 예상 피크 용량을 지정합니다.
```
CREATE TABLE catalog.book_awards (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank))
WITH CUSTOM_PROPERTIES = {
'capacity_mode': {
'throughput_mode': 'PAY_PER_REQUEST'
},
'warm_throughput': {
'read_units_per_second': 40000,
'write_units_per_second': 20000
}
};
```
테이블의 용량 설정을 확인하려면 섹션을 참조하세요[Amazon Keyspaces 테이블의 웜 처리량 보기](view-warm-throughput.md).
------
#### [ CLI ]
1. 를 사용하여 다음 방법 중 하나를 사용하여 웜 처리량이 있는 테이블 생성 AWS CLI
+ 프로비저닝된 모드에서 새 테이블을 생성하고 새 테이블에 대한 읽기 및 쓰기의 예상 피크 용량 값을 지정합니다. 다음 문은 이에 대한 예입니다.
```
aws keyspaces create-table \
--keyspace-name 'catalog' \
--table-name 'book_awards' \
--schema-definition 'allColumns=[{name=year,type=int},{name=award,type=text},{name=rank,type=int},{name=category,type=text},{name=book_title,type=text},{name=author,type=text},{name=publisher,type=text}],partitionKeys=[{name=year},{name=award}],clusteringKeys=[{name=category,orderBy=ASC},{name=rank,orderBy=ASC}]' \
--capacity-specification throughputMode=PROVISIONED,readCapacityUnits=20000,writeCapacityUnits=10000 \
--warm-throughput-specification readUnitsPerSecond=40000,writeUnitsPerSecond=20000
```
+ 온디맨드 모드에서 새 테이블을 생성하고 새 테이블에 대한 읽기 및 쓰기의 예상 최대 용량 값을 지정합니다. 다음 문은 이에 대한 예입니다.
```
aws keyspaces create-table \
--keyspace-name 'catalog' \
--table-name 'book_awards' \
--schema-definition 'allColumns=[{name=year,type=int},{name=award,type=text},{name=rank,type=int},{name=category,type=text},{name=book_title,type=text},{name=author,type=text},{name=publisher,type=text}],partitionKeys=[{name=year},{name=award}],clusteringKeys=[{name=category,orderBy=ASC},{name=rank,orderBy=ASC}]' \
--warmThroughputSpecification readUnitsPerSecond=40000,writeUnitsPerSecond=20000
```
1. 명령의 출력은 다음 예제와 같이 테이블의 ARN을 반환합니다.
```
{
"resourceArn": "arn:aws::cassandra:us-east-1:111122223333:/keyspace/catalog/table/book_awards>"
}
```
테이블의 용량 설정을 확인하려면 섹션을 참조하세요[Amazon Keyspaces 테이블의 웜 처리량 보기](view-warm-throughput.md).
------
#### [ Java ]
**Java용 SDK를 사용하여 새 테이블을 생성합니다.**
+ 프로비저닝된 모드에서 새 테이블을 생성하고 새 테이블에 대한 읽기 및 쓰기의 예상 피크 용량 값을 지정합니다. 다음 코드 예제는이 예제입니다.
```
import software.amazon.awssdk.services.keyspaces.KeyspacesClient;
import software.amazon.awssdk.services.keyspaces.model.*;
public class PreWarmingExample {
public static void main(String[] args) {
KeyspacesClient keyspacesClient = KeyspacesClient.builder().build();
// Define schema
List columns = Arrays.asList(
ColumnDefinition.builder().name("year").type("int").build(),
ColumnDefinition.builder().name("award").type("text").build(),
ColumnDefinition.builder().name("rank").type("int").build(),
ColumnDefinition.builder().name("category").type("text").build(),
ColumnDefinition.builder().name("book_title").type("text").build(),
ColumnDefinition.builder().name("author").type("text").build(),
ColumnDefinition.builder().name("publisher").type("text").build()
);
List partitionKeys = Arrays.asList(
PartitionKey.builder().name("year").build(),
PartitionKey.builder().name("award").build()
);
List clusteringKeys = Arrays.asList(
ClusteringKey.builder().name("category").orderBy("ASC").build(),
ClusteringKey.builder().name("rank").orderBy("ASC").build()
);
SchemaDefinition schema = SchemaDefinition.builder()
.allColumns(columns)
.partitionKeys(partitionKeys)
.clusteringKeys(clusteringKeys)
.build();
// Define capacity specification
CapacitySpecification capacitySpec = CapacitySpecification.builder()
.throughputMode(ThroughputMode.PROVISIONED)
.readCapacityUnits(20000)
.writeCapacityUnits(10000)
.build();
// Define warm throughput specification
WarmThroughputSpecification warmThroughput = WarmThroughputSpecification.builder()
.readUnitsPerSecond(40000L)
.writeUnitsPerSecond(20000L)
.build();
// Create table with PreWarming
CreateTableRequest request = CreateTableRequest.builder()
.keyspaceName("catalog")
.tableName("book_awards")
.schemaDefinition(schema)
.capacitySpecification(capacitySpec)
.warmThroughputSpecification(warmThroughput)
.build();
CreateTableResponse response = keyspacesClient.createTable(request);
System.out.println("Table created with ARN: " + response.resourceArn());
}
}
```
------
# 기존 Amazon Keyspaces 테이블의 웜 처리량 증가
콘솔, CQL 또는를 사용하여 Amazon Keyspaces 테이블의 현재 웜 처리량 값을 늘릴 수 있습니다 AWS CLI.
------
#### [ Console ]
**콘솔을 사용하여 테이블의 사전 워밍 설정을 늘리는 방법**
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) Amazon Keyspaces 콘솔을 엽니다.
1. 탐색 창에서 **테이블**을 선택한 다음 업데이트할 테이블을 선택합니다.
1. 테이블의 **용량** 탭에서 **테이블에 대한 사전 워밍**을 계속 진행합니다.
1. **테이블에 대한 사전 워밍** 섹션에서 **편집**을 선택합니다.
1. **테이블의 사전 워밍 편집** 페이지에서 초**당 읽기 단위 및 초**당 **쓰기 단위 값을 업데이트할 수 있습니다**.
1. **변경 사항 저장**을 선택합니다. 테이블이 지정된 사전 워밍 설정으로 업데이트되고 있습니다.
------
#### [ Cassandra Query Language (CQL) ]
**CQL을 사용하여 테이블의 웜 처리량 설정 증가**
+ `ALTER TABLE`문을 사용하여 테이블의 웜 처리량을 늘립니다. 다음 문은 이에 대한 예입니다.
```
ALTER TABLE catalog.book_awards
WITH CUSTOM_PROPERTIES = {
'warm_throughput': {
'read_units_per_second': 60000,
'write_units_per_second': 30000
}
};
```
테이블의 업데이트된 용량 설정을 확인하려면 섹션을 참조하세요[Amazon Keyspaces 테이블의 웜 처리량 보기](view-warm-throughput.md).
------
#### [ CLI ]
**를 사용하여 테이블의 사전 워밍 설정 늘리기 AWS CLI**
+ 테이블의 웜 처리량을 늘리려면 `update-table` 명령을 사용할 수 있습니다. 다음 문은 이에 대한 예입니다.
```
aws keyspaces update-table \
--keyspace-name 'catalog' \
--table-name 'book_awards' \
--warmThroughputSpecification readUnitsPerSecond=60000,writeUnitsPerSecond=30000
```
테이블의 업데이트된 용량 설정을 확인하려면 섹션을 참조하세요[Amazon Keyspaces 테이블의 웜 처리량 보기](view-warm-throughput.md).
------
#### [ Java ]
**Java용 SDK를 사용하여 테이블의 사전 워밍 설정을 업데이트합니다.**
+ 테이블에 대한 웜 처리량 설정을 업데이트합니다. 다음 코드 예제는이 예제입니다.
```
import software.amazon.awssdk.services.keyspaces.KeyspacesClient;
import software.amazon.awssdk.services.keyspaces.model.*;
public class UpdatePreWarmingExample {
public static void main(String[] args) {
KeyspacesClient keyspacesClient = KeyspacesClient.builder().build();
// Define new warm throughput specification
WarmThroughputSpecification warmThroughput = WarmThroughputSpecification.builder()
.readUnitsPerSecond(60000L)
.writeUnitsPerSecond(30000L)
.build();
// Update table with new PreWarming settings
UpdateTableRequest request = UpdateTableRequest.builder()
.keyspaceName("catalog")
.tableName("book_awards")
.warmThroughputSpecification(warmThroughput)
.build();
UpdateTableResponse response = keyspacesClient.updateTable(request);
System.out.println("Table update requested: " + response.resourceArn());
}
}
```
------
# Amazon Keyspaces 테이블의 웜 처리량 보기
콘솔, CQL 또는를 사용하여 Amazon Keyspaces 테이블의 현재 웜 처리량 값을 볼 수 있습니다 AWS CLI.
------
#### [ Console ]
**콘솔을 사용하여 테이블의 사전 워밍 설정을 보는 방법.**
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) Amazon Keyspaces 콘솔을 엽니다.
1. 탐색 창에서 **테이블**을 선택한 다음 검토하려는 테이블을 선택합니다.
1. 테이블의 **용량** 탭에서 **테이블에 대한 사전 워밍**을 계속합니다.
------
#### [ Cassandra Query Language (CQL) ]
**CQL을 사용하여 테이블의 웜 처리량 설정 보기**
+ 테이블의 웜 처리량 설정을 보려면 다음 CQL 문을 사용할 수 있습니다.
```
SELECT custom_properties
FROM system_schema_mcs.tables
WHERE keyspace_name='catalog' and table_name='book_awards';
// Output:
...
custom_properties
----------------------------------------------------------------------------------
{
'warm_throughput':
{
'read_units_per_second': '40000',
'write_units_per_second': '20000',
'status': 'AVAILABLE'
}
}
...
```
------
#### [ CLI ]
**를 사용하여 테이블의 웜 처리량 설정 보기 AWS CLI**
+ 다음 예제와 같이 `get-table` 명령을 사용하여 테이블의 웜 처리량 설정을 볼 수 있습니다.
```
aws keyspaces get-table \
--keyspace-name 'catalog' \
--table-name 'book_awards'
```
다음은 프로비저닝된 모드에서 단일 리전 테이블에 대한 `get-table` 명령의 예제 출력을 보여줍니다.
```
{
"keyspaceName": "catalog",
"tableName": "book_awards",
... Existing Fields ...,
"capacitySpecificationSummary": {
"throughputMode": "PROVISIONED",
"readCapacityUnits": 20000,
"writeCapacityUnits": 10000
},
"warmThroughputSpecificationSummary": {
"readUnitsPerSecond": 40000,
"writeUnitsPerSecond": 20000,
"status": "AVAILABLE"
}
}
```
다음은 온디맨드 모드의 단일 리전 테이블에 대한 예제 출력을 보여줍니다.
```
{
"keyspaceName": "catalog",
"tableName": "book_awards_ondemand",
... Existing Fields ...,
"capacitySpecification": {
"throughputMode": "PAY_PER_REQUEST"
},
"warmThroughputSpecificationSummary": {
"readUnitsPerSecond": 40000,
"writeUnitsPerSecond": 20000,
"status": "AVAILABLE"
}
}
```
------
#### [ Java ]
**Java용 SDK를 사용하여 테이블의 사전 워밍 설정을 읽습니다.**
+ 를 사용하여 테이블의 웜 처리량 값을 읽습니다`get-table`. 다음 코드 예제는이 예제입니다.
```
import software.amazon.awssdk.services.keyspaces.KeyspacesClient;
import software.amazon.awssdk.services.keyspaces.model.*;
public class GetTableWithPreWarmingExample {
public static void main(String[] args) {
KeyspacesClient keyspacesClient = KeyspacesClient.builder().build();
// Get table details including PreWarming specification
GetTableRequest request = GetTableRequest.builder()
.keyspaceName("catalog")
.tableName("book_awards")
.build();
GetTableResponse response = keyspacesClient.getTable(request);
// Access PreWarming details
if (response.warmThroughputSpecification() != null) {
WarmThroughputSpecificationSummary warmThroughputSummary = response.warmThroughputSpecification();
System.out.println("PreWarming Status: " + warmThroughputSummary.status());
System.out.println("Read Units: " + warmThroughputSummary.readUnitsPerSecond());
System.out.println("Write Units: " + warmThroughputSummary.writeUnitsPerSecond());
// Check if PreWarming is active
if (warmThroughputSummary.status().equals("AVAILABLE")) {
System.out.println("Table is fully pre-warmed and ready for high throughput");
} else if (warmThroughputSummary.status().equals("UPDATING")) {
System.out.println("Table PreWarming is currently being updated");
}
} else {
System.out.println("Table does not have PreWarming enabled");
}
}
}
```
------
# Amazon CloudWatch를 사용하여 사전 워밍된 테이블의 성능 모니터링
Amazon Keyspaces 사전 워밍은 새로운 CloudWatch 지표를 도입하지 않지만 기존 Amazon Keyspaces 지표를 사용하여 사전 워밍된 테이블의 성능을 모니터링할 수 있습니다.
SuccessfulRequestLatency
이 지표를 모니터링하여 사전 워밍된 테이블이 예상 지연 시간으로 요청을 처리하고 있는지 확인합니다.
WriteThrottleEvents 및 ReadThrottleEvents
이러한 지표는 적절하게 사전 워밍된 테이블의 경우 낮게 유지되어야 합니다. 사전 워밍에도 불구하고 용량 부족 오류가 표시되는 경우 웜 처리량 값을 조정해야 할 수 있습니다.
ConsumedReadCapacityUnits 및 ConsumedWriteCapacityUnits
이러한 지표는 실제 용량 소비를 보여주므로 사전 워밍 구성이 적절한지 확인하는 데 도움이 될 수 있습니다.
ProvisionedReadCapacityUnits 및 ProvisionedWriteCapacityUnits
프로비저닝된 테이블의 경우 이러한 지표는 현재 할당된 용량을 표시합니다.
이러한 지표는 CloudWatch 콘솔에서 보거나 CloudWatch API를 사용하여 쿼리할 수 있습니다. 자세한 내용은 [Amazon CloudWatch를 사용하여 Amazon Keyspaces 모니터링](monitoring-cloudwatch.md) 단원을 참조하십시오.
# Amazon Keyspaces 오토 스케일링으로 처리량 용량 자동 관리
대부분의 데이터베이스 워크로드는 원래 주기적으로 반복되거나 미리 예측하기가 어렵습니다. 낮 시간 동안에는 대부분의 사용자가 활성 상태인 소셜 네트워킹 앱을 예로 들어 보겠습니다. 이러한 데이터베이스에서는 주간 활동을 처리할 수 있어야 하지만, 밤에는 동일한 수준의 처리량이 필요 없습니다.
빠른 속도로 도입 중인 새로운 모바일 게임 앱을 또 다른 예로 들 수 있습니다. 이 게임의 인기가 높아지면 사용 가능한 데이터베이스 리소스 양을 초과하여 성능이 느려지고 고객 불만이 발생할 것입니다. 이러한 종류의 워크로드는 대개 사용량 변화에 따라 수동 개입을 통해 데이터베이스 리소스의 규모를 늘리거나 줄여야 합니다.
Amazon Keyspaces(Apache Cassandra용)는 실제 애플리케이션 트래픽에 따라 처리량 용량을 자동으로 조정하여 가변 워크로드에 대한 처리량 용량을 효율적으로 프로비저닝할 수 있도록 지원합니다. Amazon Keyspaces는 Application Auto Scaling 서비스를 사용하여 자동으로 테이블의 읽기 및 쓰기 용량을 늘리거나 줄입니다. Application Auto Scaling에 대한 자세한 내용은 [Application Auto Scaling 사용 설명서](https://docs.aws.amazon.com/autoscaling/application/userguide/)를 참조하세요.
**참고**
Amazon Keyspaces Auto Scaling의 사용을 신속하게 시작하려면 [Amazon Keyspaces 오토 스케일링 정책 구성 및 업데이트](autoscaling.configure.md) 섹션을 참조하세요.
## Amazon Keyspaces Auto Scaling 작동 방식
아래 그림에는 Amazon Keyspaces Auto Scaling이 테이블의 처리량 용량을 관리하는 방법이 간단히 소개되어 있습니다.
![\[사용자가 Amazon Keyspaces 테이블을 변경할 때 관련된 다양한 서비스를 보여주는 다이어그램입니다. 이 서비스는 사용자의 읽기 또는 쓰기 사용량에 따라 용량을 변경하기 위해 ALTER TABLE 문을 실행하는 Amazon CloudWatch, Amazon SNS, 애플리케이션 오토 스케일링입니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/keyspaces_auto-scaling.png)
테이블에 대해 Auto Scaling을 활성화하기 위해 *규모 조정* 정책을 만듭니다. 이 규모 조정 정책을 통해 읽기 용량이나 쓰기 용량(또는 둘 다)을 조정할 것인지 여부와 테이블에 대해 할당된 용량 단위의 최댓값 및 최솟값 설정을 지정할 수 있습니다.
규모 조정 정책은 *목표 사용률*도 정의합니다. 목표 사용률이란 특정 시점에 프로비저닝된 용량 단위에 대한 소비된 용량 단위의 비율을 백분율로 나타낸 값입니다. Auto Scaling은 *목표 추적* 알고리즘을 사용하여 실제 워크로드에 따라 테이블의 프로비저닝된 처리량을 확대 또는 축소합니다. 이렇게 하면 실제 용량 사용률을 목표 사용률과 비슷하게 유지할 수 있습니다.
읽기 및 쓰기 용량에 대해 20%와 90% 사이에서 Auto Scaling 목표 사용률 값을 설정할 수 있습니다. 기본 목표 사용률은 70% 입니다. 트래픽이 빠르게 변하고 용량을 더 빨리 스케일 업하려는 경우 목표 사용률을 낮게 설정할 수 있습니다. 애플리케이션 트래픽이 더 느리게 변하고 처리량 비용을 줄이려는 경우 목표 사용률을 더 높게 설정할 수도 있습니다.
규모 조정 정책에 대한 자세한 내용은 [애플리케이션 오토 스케일링 사용 설명서](https://docs.aws.amazon.com/autoscaling/application/userguide/)**의 [애플리케이션 오토 스케일링을 위한 타겟 추적 규모 조정 정책](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)을 참조하세요.
확장 정책을 만들면 Amazon Keyspaces가 사용자를 대신하여 두 쌍의 Amazon CloudWatch 알람을 생성합니다. 각 쌍은 프로비저닝되고 사용된 처리량 설정의 상한값과 하한값을 나타냅니다. 테이블의 실제 사용률이 일정한 시간 동안 목표 사용률을 벗어나면 이러한 CloudWatch 경보가 트리거됩니다. Amazon CloudWatch에 대한 자세한 내용은 [Amazon CloudWatch 사용 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)를 참조하세요.
CloudWatch 경보 중 하나가 트리거되면 Amazon Simple Notification Service(SNS)에서 알림을 보냅니다(알림을 활성화한 경우). CloudWatch 경보를 받으면 크기 조정 정책을 평가하기 위해 Application Auto Scaling이 간접적으로 호출됩니다. 그러면 Amazon Keyspaces에 Alt Table 요청이 전송되어 테이블의 프로비저닝된 용량을 적절히 확장하거나 축소합니다. Amazon SNS 알림에 대한 자세한 내용은 [Amazon SNS 알림 설정](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)을 참조하세요.
Amazon Keyspaces는 테이블의 프로비저닝된 처리량 용량이 목표 사용률에 근접하도록 동적으로 확장하거나 축소함으로써 Alter Table 요청을 처리합니다.
**참고**
Amazon Keyspaces 오토 스케일링은 실제 워크로드가 일정 시간(분) 동안 높게(또는 낮게) 유지되는 경우에 한해 프로비저닝된 처리량 설정을 수정합니다. 의 목표 추적 알고리즘은 목표 사용률을 장기적으로 사용자가 선택한 값 안팎으로 유지되도록 합니다. 짧은 기간 동안 갑자기 급증하는 활동은 테이블에 기본 제공되는 버스트 용량으로 처리합니다.
## 다중 리전 테이블에 대한 오토 스케일링 작동 방식
프로비저닝된 용량 모드에서 모든 다중 리전 테이블 AWS 리전 의 모든 테이블 복제본에 대해 항상 충분한 읽기 및 쓰기 용량이 있도록 Amazon Keyspaces Auto Scaling을 구성하는 것이 좋습니다.
오토 스케일링과 함께 프로비저닝된 모드에서 다중 리전 테이블을 사용하는 경우 단일 테이블 복제본에 대한 오토 스케일링을 비활성화할 수 없습니다. 그러나 여러 리전에 대해 테이블의 읽기 오토 스케일링 설정을 조정할 수 있습니다. 예를 들어 테이블이 복제되는 각 리전에 대해 서로 다른 읽기 용량과 읽기 오토 스케일링 설정을 지정할 수 있습니다.
지정된 리전에서 테이블 복제본에 대해 구성하는 읽기 오토 스케일링 설정은 테이블의 일반 오토 스케일링 설정을 덮어씁니다. 하지만 쓰기 용량은 모든 테이블 복제본에서 동기화된 상태로 유지하여 모든 리전에서 쓰기를 복제할 수 있는 충분한 용량이 있는지 확인해야 합니다.
Amazon Keyspaces 오토 스케일링은 해당 리전의 사용량에 따라 각 AWS 리전 기반 테이블의 프로비저닝된 용량을 독립적으로 업데이트합니다. 따라서 오토 스케일링이 활성화되면 다중 리전 테이블의 각 리전에 프로비저닝된 용량이 다를 수 있습니다.
Amazon Keyspaces 콘솔 AWS CLI, API 또는 CQL을 사용하여 다중 리전 테이블 및 해당 복제본의 Auto Scaling 설정을 구성할 수 있습니다. 다중 리전 테이블에 대한 오토 스케일링 설정을 생성 및 업데이트하는 방법에 대한 자세한 내용은 [Amazon Keyspaces에서 다중 리전 테이블에 대한 프로비저닝된 용량 및 오토 스케일링 설정 업데이트](tables-mrr-autoscaling.md) 섹션을 참조하세요.
**참고**
다중 리전 테이블에 오토 스케일링을 사용하는 경우 항상 Amazon Keyspaces API 작업을 사용하여 오토 스케일링 설정을 구성해야 합니다. Application Auto Scaling API 작업을 직접 사용하여 Auto Scaling 설정을 구성하는 경우 다중 리전 테이블 AWS 리전 의를 지정할 수 없습니다. 이로 인해 지원되지 않는 구성이 발생할 수 있습니다.
## 사용 노트
Amazon Keyspaces Auto Scaling을 사용하려면 먼저 다음 내용을 이해해야 합니다.
+ 중동(UAE) 리전에서는 Amazon Keyspaces Auto Scaling을 사용할 수 없습니다.
+ Amazon Keyspaces Auto Scaling은 Auto Scaling 정책에 따라 필요한 만큼 자주 읽기 용량이나 쓰기 용량을 늘릴 수 있습니다. 모든 Amazon Keyspaces 할당량은 [Amazon Keyspaces(Apache Cassandra용)에 대한 할당량](quotas.md)에서 설명한 것처럼 효력이 유지됩니다.
+ Amazon Keyspaces Auto Scaling은 프로비저닝된 처리량 설정을 사용자가 수동으로 수정하는 것도 허용합니다. 이러한 수동 조정은 규모 조정과 관련된 기존의 CloudWatch 경보에는 영향을 주지 않습니다.
+ 콘솔을 사용하여 프로비저닝된 처리량 용량이 있는 테이블을 생성하는 경우 Amazon Keyspaces Auto Scaling이 기본적으로 활성화됩니다. 언제든지 Auto Scaling 설정을 변경할 수 있습니다. 자세한 내용은 [테이블에 대한 Amazon Keyspaces 오토 스케일링 끄기](autoscaling.turnoff.md) 단원을 참조하십시오.
+ CloudFormation 를 사용하여 조정 정책을 생성하는 경우 스택이 스택 템플릿과 동기화 CloudFormation 되도록에서 조정 정책을 관리해야 합니다. Amazon Keyspaces에서 조정 정책을 변경하면 CloudFormation 스택이 재설정될 때 스택 템플릿의 원래 값으로 덮어씁니다.
+ CloudTrail을 사용하여 Amazon Keyspaces Auto Scaling을 모니터링하는 경우, 구성 검증 프로세스의 일부로 Application Auto Scaling에서 이루어진 호출에 대한 알림이 표시될 수 있습니다. 이러한 알림을 필터링하려면 이러한 유효성 검사를 위한 `application-autoscaling.amazonaws.com`을 포함하는 `invokedBy` 필드를 사용합니다.
# Amazon Keyspaces 오토 스케일링 정책 구성 및 업데이트
콘솔, CQL 또는 AWS Command Line Interface (AWS CLI)를 사용하여 신규 및 기존 테이블에 대한 Amazon Keyspaces 자동 조정을 구성할 수 있습니다. 오토 스케일링 설정을 수정하거나 오토 스케일링을 비활성화할 수 있습니다.
스케일 인 및 스케일 아웃 휴지 시간 설정과 같은 고급 기능의 경우 CQL 또는 AWS CLI 를 사용하여 Amazon Keyspaces 조정 정책을 관리하는 것이 좋습니다.
**Topics**
+ [Amazon Keyspaces 오토 스케일링에 대한 권한 구성](autoscaling.permissions.md)
+ [오토 스케일링을 사용하여 새 테이블 만들기](autoscaling.createTable.md)
+ [기존 테이블에서 오토 스케일링 구성](autoscaling.configureTable.md)
+ [테이블의 Amazon Keyspaces 오토 스케일링 구성 보기](autoscaling.viewPolicy.md)
+ [테이블에 대한 Amazon Keyspaces 오토 스케일링 끄기](autoscaling.turnoff.md)
+ [Amazon CloudWatch에서 Amazon Keyspaces 테이블에 대한 오토 스케일링 활동 보기](autoscaling.activity.md)
# Amazon Keyspaces 오토 스케일링에 대한 권한 구성
시작하려면 위탁자에게 오토 스케일링 설정을 생성하고 관리할 수 있는 적절한 권한이 있는지 확인합니다. AWS Identity and Access Management (IAM)에서 AWS 관리`AmazonKeyspacesFullAccess`형 정책은 Amazon Keyspaces 조정 정책을 관리하는 데 필요합니다.
**중요**
테이블에서 자동 크기 조정을 비활성화하려면 `application-autoscaling:*` 권한이 필요합니다. 테이블을 삭제하려면 먼저 테이블의 오토 스케일링을 꺼야 합니다.
Amazon Keyspaces 콘솔 액세스 및 Amazon Keyspaces 오토 스케일링을 위해 IAM 사용자 또는 역할을 설정하려면 다음 정책을 추가합니다.
**`AmazonKeyspacesFullAccess` 정책 연결**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) IAM 콘솔을 엽니다.
1. IAM 콘솔 대시보드에서 **사용자**를 선택한 후 목록에서 해당 IAM 사용자 또는 역할을 선택합니다.
1. **요약** 페이지에서 **권한 추가**를 선택합니다.
1. **기존 정책 직접 첨부**를 선택합니다.
1. 정책 목록에서 **AmazonDynamoDBFullAccess**를 선택한 후 **다음: 검토**를 선택합니다.
1. **권한 추가**를 선택합니다.
# 오토 스케일링을 사용하여 새 테이블 만들기
새 Amazon Keyspaces 테이블을 만들 때 테이블의 쓰기 또는 읽기 용량에 대한 오토 스케일링을 자동으로 활성화할 수 있습니다. 이렇게 하면 Amazon Keyspaces가 사용자를 대신하여 애플리케이션 오토 스케일링에 연결하여 테이블을 확장 가능한 대상으로 등록하고 프로비저닝된 쓰기 또는 읽기 용량을 조정할 수 있습니다.
멀티 리전 테이블을 만들고 테이블 복제본에 대한 다양한 오토 스케일링 설정을 구성하는 방법의 자세한 내용은 [Amazon Keyspaces에서 오토 스케일링을 사용하는 프로비저닝된 모드에서 다중 리전 테이블 생성](tables-mrr-create-provisioned.md) 섹션을 참조하세요.
**참고**
Amazon Keyspaces Auto Scaling을 사용하려면 사용자 대신 Auto Scaling 작업을 수행하는 서비스 연결 역할(`AWSServiceRoleForApplicationAutoScaling_CassandraTable`)이 있어야 합니다. 이 역할은 자동으로 생성됩니다. 자세한 내용은 [Amazon Keyspaces에 대해 서비스 연결 역할 사용](using-service-linked-roles.md) 단원을 참조하십시오.
------
#### [ Console ]
**콘솔을 사용하여 오토 스케일링이 활성화된 새 테이블 생성**
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) Amazon Keyspaces 콘솔을 엽니다.
1. 탐색 창에서 **테이블**을 선택한 다음 **테이블 생성**을 선택합니다.
1. **테이블 세부 정보** 섹션의 **테이블 생성** 페이지에서 키스페이스를 선택하고 새 테이블의 이름을 입력합니다.
1. **열** 섹션에서 테이블의 스키마를 생성합니다.
1. **프라이머리 키** 섹션에서 테이블의 프라이머리 키를 정의하고 선택적 클러스터링 열을 선택합니다.
1. **테이블 설정** 섹션에서 **설정 사용자 지정**을 선택합니다.
1. **읽기/쓰기 용량 설정**을 계속합니다.
1. **용량 모드**에서 **프로비저닝됨**을 선택합니다.
1. **읽기 용량** 섹션에서 **자동 규모 조정**이 선택되어 있는지 확인합니다.
이 단계에서는 테이블의 최소 및 최대 읽기 용량 단위와 목표 사용률을 선택합니다.
+ **최소 용량 단위** - 테이블이 항상 지원할 준비가 되어 있어야 하는 최소 처리량 수준 값을 입력합니다. 값은 1에서 계정에 대해 초당 최대 처리량 할당량(기본값 40,000) 사이여야 합니다.
+ **최대 용량 단위** - 테이블에 프로비저닝하려는 최대 처리량을 입력합니다. 값은 1에서 계정에 대해 초당 최대 처리량 할당량(기본값 40,000) 사이여야 합니다.
+ **목표 사용률** — 목표 사용률을 20% \$1 90% 사이로 입력합니다. 트래픽이 정의된 목표 사용률을 초과하면 용량이 자동으로 스케일 업됩니다. 트래픽이 정의된 목표 미만으로 떨어지면 자동으로 다시 스케일 다운됩니다.
**참고**
계정의 기본 할당량 및 할당량을 높이는 방법에 대한 자세한 내용은 [Amazon Keyspaces(Apache Cassandra용)에 대한 할당량](quotas.md) 섹션을 참조하세요.
1. **쓰기 용량** 섹션에서 읽기 용량에 대해 이전 단계에서 정의한 것과 동일한 설정을 선택하거나 용량 값을 직접 구성합니다.
1. **테이블 생성**을 선택합니다. Auto Scaling 파라미터로 테이블이 생성됩니다.
------
#### [ Cassandra Query Language (CQL) ]
**CQL을 사용하여 Amazon Keyspaces 오토 스케일링으로 새 테이블 생성**
프로그래밍 방식으로 테이블에 대한 오토 스케일링 설정을 구성하려면 Amazon Keyspaces 오토 스케일링에 대한 파라미터가 포함된 `AUTOSCALING_SETTINGS` 문을 사용합니다. 파라미터는 테이블의 프로비저닝된 처리량을 조정하도록 Amazon Keyspaces에 지시하는 조건과 수행해야 할 추가 선택적 작업을 정의합니다. 이 예시에서는 *mytable*의 오토 스케일링 설정을 정의합니다.
정책에는 다음 요소가 포함됩니다.
+ `AUTOSCALING_SETTINGS` - Amazon Keyspaces가 사용자를 대신하여 처리량 용량을 조정할 수 있도록 허용할지를 지정합니다. 다음 값은 필수입니다.
+ `provisioned_write_capacity_autoscaling_update`:
+ `minimum_units`
+ `maximum_units`
+ `provisioned_read_capacity_autoscaling_update`:
+ `minimum_units`
+ `maximum_units`
+ `scaling_policy` - Amazon Keyspaces는 대상 추적 정책을 지원합니다. 대상 추적 정책을 정의하려면 다음 파라미터를 구성합니다.
+ `target_value` - Amazon Keyspaces 오토 스케일링은 프로비저닝된 용량 대비 소비된 용량의 비율을 이 값 또는 그 수준으로 유지하도록 합니다. `target_value`를 백분율로 지정합니다.
+ `disableScaleIn`: (선택 사항) 테이블에 `scale-in`을 비활성화 또는 활성화할지 여부를 지정하는 `boolean`입니다. 이 파라미터는 기본적으로 비활성화되어 있습니다. `scale-in`을 켜려면 `boolean` 값을 `FALSE`로 설정합니다. 즉, 사용자를 대신하여 테이블의 용량이 자동으로 스케일 다운됩니다.
+ `scale_out_cooldown` – 스케일 아웃 활동은 테이블의 프로비저닝된 처리량을 늘립니다. 스케일 아웃 활동을 위한 휴지 기간을 추가하려면 `scale_out_cooldown`에 대한 값(초)을 지정합니다. 값을 지정하지 않을 경우 기본값은 0입니다. 대상 추적 및 휴지 기간에 대한 자세한 내용을 알아보려면 *애플리케이션 오토 스케일링 사용 설명서*의 [대상 추적 조정 정책](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)을 참조하세요.
+ `scale_in_cooldown` – 스케일 인 활동은 테이블의 프로비저닝된 처리량을 줄입니다. 스케일 인 활동을 위한 휴지 기간을 추가하려면 `scale_in_cooldown`에 대한 값(초)을 지정합니다. 값을 지정하지 않을 경우 기본값은 0입니다. 대상 추적 및 휴지 기간에 대한 자세한 내용을 알아보려면 *애플리케이션 오토 스케일링 사용 설명서*의 [대상 추적 조정 정책](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)을 참조하세요.
**참고**
`target_value`의 용도를 자세히 이해하기 위해 쓰기 용량 단위 200으로 할당 처리량을 설정한 테이블을 예로 들어 보겠습니다. 이 테이블에 대해 `target_value`가 70퍼센트인 확장 정책을 만들려고 합니다.
테이블에 대한 쓰기 트래픽을 시작했더니 실제 쓰기 처리량이 150 용량 단위였다고 가정해 보겠습니다. 사용 용량 대 할당 용량의 비율은 150/200으로 75퍼센트입니다. 이 비율은 목표를 초과하므로 오토 스케일링은 프로비저닝된 쓰기 용량을 215로 늘려 비율이 (150/215) 또는 69.77%(`target_value`를 초과하지 않지만 최대한 가깝게)가 되게 합니다.
*mytable*의 경우 읽기 및 쓰기 용량 모두에 대한 `TargetValue`를 50%로 설정합니다. Amazon Keyspaces 오토 스케일링은 테이블의 프로비저닝된 처리량을 용량 단위 5\$110의 범위 내에서 조정하여 사용 용량과 프로비저닝된 용량 간의 비율이 50% 수준으로 유지되도록 합니다. 읽기 용량의 경우 `ScaleOutCooldown`과 `ScaleInCooldown`의 값을 60초로 설정합니다.
다음 문을 사용하여 오토 스케일링이 활성화된 새 Amazon Keyspaces 테이블을 만들 수 있습니다.
```
CREATE TABLE mykeyspace.mytable(pk int, ck int, PRIMARY KEY (pk, ck))
WITH CUSTOM_PROPERTIES = {
'capacity_mode': {
'throughput_mode': 'PROVISIONED',
'read_capacity_units': 1,
'write_capacity_units': 1
}
} AND AUTOSCALING_SETTINGS = {
'provisioned_write_capacity_autoscaling_update': {
'maximum_units': 10,
'minimum_units': 5,
'scaling_policy': {
'target_tracking_scaling_policy_configuration': {
'target_value': 50
}
}
},
'provisioned_read_capacity_autoscaling_update': {
'maximum_units': 10,
'minimum_units': 5,
'scaling_policy': {
'target_tracking_scaling_policy_configuration': {
'target_value': 50,
'scale_in_cooldown': 60,
'scale_out_cooldown': 60
}
}
}
};
```
------
#### [ CLI ]
**를 사용하여 Amazon Keyspaces Auto Scaling으로 새 테이블 생성 AWS CLI**
프로그래밍 방식으로 테이블에 대한 오토 스케일링 설정을 구성하려면 Amazon Keyspaces 오토 스케일링에 대한 파라미터를 정의하는 `autoScalingSpecification` 작업을 사용합니다. 파라미터는 테이블의 프로비저닝된 처리량을 조정하도록 Amazon Keyspaces에 지시하는 조건과 수행해야 할 추가 선택적 작업을 정의합니다. 이 예시에서는 *mytable*의 오토 스케일링 설정을 정의합니다.
정책에는 다음 요소가 포함됩니다.
+ `autoScalingSpecification` - Amazon Keyspaces가 사용자를 대신하여 용량 처리량을 조정할 수 있도록 허용할지를 지정합니다. 읽기 및 쓰기 용량에 오토 스케일링을 별도로 활성화할 수 있습니다. 그런 다음 `autoScalingSpecification`에 대한 다음 파라미터를 지정해야 합니다.
+ `writeCapacityAutoScaling` - 최대 및 최소 쓰기 용량 단위입니다.
+ `readCapacityAutoScaling` – 최대 및 최소 읽기 용량 단위입니다.
+ `scalingPolicy` - Amazon Keyspaces는 대상 추적 정책을 지원합니다. 대상 추적 정책을 정의하려면 다음 파라미터를 구성합니다.
+ `targetValue` - Amazon Keyspaces 오토 스케일링은 프로비저닝된 용량 대비 소비된 용량의 비율을 이 값 또는 그 수준으로 유지하도록 합니다. `targetValue`를 백분율로 지정합니다.
+ `disableScaleIn`: (선택 사항) 테이블에 `scale-in`을 비활성화 또는 활성화할지 여부를 지정하는 `boolean`입니다. 이 파라미터는 기본적으로 비활성화되어 있습니다. `scale-in`을 켜려면 `boolean` 값을 `FALSE`로 설정합니다. 즉, 사용자를 대신하여 테이블의 용량이 자동으로 스케일 다운됩니다.
+ `scaleOutCooldown` – 스케일 아웃 활동은 테이블의 프로비저닝된 처리량을 늘립니다. 스케일 아웃 활동을 위한 휴지 기간을 추가하려면 `ScaleOutCooldown`에 대한 값(초)을 지정합니다. 기본값은 0입니다. 대상 추적 및 휴지 기간에 대한 자세한 내용을 알아보려면 *애플리케이션 오토 스케일링 사용 설명서*의 [대상 추적 조정 정책](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)을 참조하세요.
+ `scaleInCooldown` – 스케일 인 활동은 테이블의 프로비저닝된 처리량을 줄입니다. 스케일 인 활동을 위한 휴지 기간을 추가하려면 `ScaleInCooldown`에 대한 값(초)을 지정합니다. 기본값은 0입니다. 대상 추적 및 휴지 기간에 대한 자세한 내용을 알아보려면 *애플리케이션 오토 스케일링 사용 설명서*의 [대상 추적 조정 정책](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)을 참조하세요.
**참고**
`TargetValue`의 용도를 자세히 이해하기 위해 쓰기 용량 단위 200으로 할당 처리량을 설정한 테이블을 예로 들어 보겠습니다. 이 테이블에 대해 `TargetValue`가 70퍼센트인 확장 정책을 만들려고 합니다.
테이블에 대한 쓰기 트래픽을 시작했더니 실제 쓰기 처리량이 150 용량 단위였다고 가정해 보겠습니다. 사용 용량 대 할당 용량의 비율은 150/200으로 75퍼센트입니다. 이 비율은 목표를 초과하므로 오토 스케일링은 프로비저닝된 쓰기 용량을 215로 늘려 비율이 (150/215) 또는 69.77%(`TargetValue`를 초과하지 않지만 최대한 가깝게)가 되게 합니다.
*mytable*의 경우 읽기 및 쓰기 용량 모두에 대한 `TargetValue`를 50%로 설정합니다. Amazon Keyspaces 오토 스케일링은 테이블의 프로비저닝된 처리량을 용량 단위 5\$110의 범위 내에서 조정하여 사용 용량과 프로비저닝된 용량 간의 비율이 50% 수준으로 유지되도록 합니다. 읽기 용량의 경우 `ScaleOutCooldown`과 `ScaleInCooldown`의 값을 60초로 설정합니다.
복잡한 오토 스케일링 설정이 있는 테이블을 생성할 때는 JSON 파일에서 오토 스케일링 설정을 로드하는 것이 유용합니다. 다음 예제의 경우, [auto-scaling.zip](samples/auto-scaling.zip)에서 오토 스케일링 예제 JSON 파일을 다운로드하고 파일 경로를 메모하여 `auto-scaling.json`을 추출할 수 있습니다. 이 예제에서는 JSON 파일이 현재 디렉터리에 위치합니다. 다양한 파일 경로 옵션에 대해서는 [파일에서 매개변수를 로드하는 방법](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-file.html#cli-usage-parameters-file-how)을 참조하세요.
```
aws keyspaces create-table --keyspace-name mykeyspace --table-name mytable
\ --schema-definition 'allColumns=[{name=pk,type=int},{name=ck,type=int}],partitionKeys=[{name=pk},{name=ck}]'
\ --capacity-specification throughputMode=PROVISIONED,readCapacityUnits=1,writeCapacityUnits=1
\ --auto-scaling-specification file://auto-scaling.json
```
------
# 기존 테이블에서 오토 스케일링 구성
기존 Amazon Keyspaces 테이블을 업데이트하여 테이블의 쓰기 또는 읽기 용량에 대한 오토 스케일링을 켤 수 있습니다. 현재 온디맨드 용량 모드에 있는 테이블을 업데이트하는 경우 먼저 테이블의 용량 모드를 프로비저닝된 용량 모드로 변경해야 합니다.
멀티 리전 테이블에 대한 오토 스케일링 설정을 업데이트하는 방법에 대한 자세한 내용은 [Amazon Keyspaces에서 다중 리전 테이블에 대한 프로비저닝된 용량 및 오토 스케일링 설정 업데이트](tables-mrr-autoscaling.md) 섹션을 참조하세요.
Amazon Keyspaces Auto Scaling을 사용하려면 사용자 대신 Auto Scaling 작업을 수행하는 서비스 연결 역할(`AWSServiceRoleForApplicationAutoScaling_CassandraTable`)이 있어야 합니다. 이 역할은 자동으로 생성됩니다. 자세한 내용은 [Amazon Keyspaces에 대해 서비스 연결 역할 사용](using-service-linked-roles.md) 단원을 참조하십시오.
------
#### [ Console ]
**기존 테이블에 Amazon Keyspaces 오토 스케일링 구성**
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) Amazon Keyspaces 콘솔을 엽니다.
1. 작업할 테이블을 선택하고 **용량** 탭으로 이동합니다.
1. **용량 설정** 섹션에서 **편집**을 선택합니다.
1. **용량 모드**에서 테이블이 **프로비저닝된** 용량 모드를 사용하고 있는지 확인합니다.
1. **자동 규모 조정**을 선택하고 [오토 스케일링을 사용하여 새 테이블 만들기](autoscaling.createTable.md)의 6단계를 참조하여 읽기 및 쓰기 용량을 편집합니다.
1. Auto Scaling 설정이 정의되면 **저장**을 선택합니다.
------
#### [ Cassandra Query Language (CQL) ]
**CQL을 사용하여 Amazon Keyspaces 오토 스케일링으로 기존 테이블 구성**
기존 Amazon Keyspaces 테이블에 대한 `ALTER TABLE` 문을 사용하여 테이블의 쓰기 또는 읽기 용량에 대한 오토 스케일링을 구성할 수 있습니다. 현재 온디맨드 용량 모드인 테이블을 업데이트하는 경우 `capacity_mode`를 프로비저닝됨으로 설정해야 합니다. 테이블이 이미 프로비저닝된 용량 모드에 있는 경우 이 필드를 생략할 수 있습니다.
다음 예제에서 문은 온디맨드 용량 모드에 있는 테이블 *mytable*을 업데이트합니다. 이 문은 테이블의 용량 모드를 오토 스케일링이 활성화된 프로비저닝 모드로 변경합니다.
쓰기 용량은 목표값이 50%인 5\$110개의 용량 단위 범위 내에서 구성됩니다. 읽기 용량 또한 목표값이 50%인 5\$110개의 용량 단위 범위 내에서 구성됩니다. 읽기 용량의 경우 `scale_out_cooldown`과 `scale_in_cooldown`의 값을 60초로 설정합니다.
```
ALTER TABLE mykeyspace.mytable
WITH CUSTOM_PROPERTIES = {
'capacity_mode': {
'throughput_mode': 'PROVISIONED',
'read_capacity_units': 1,
'write_capacity_units': 1
}
} AND AUTOSCALING_SETTINGS = {
'provisioned_write_capacity_autoscaling_update': {
'maximum_units': 10,
'minimum_units': 5,
'scaling_policy': {
'target_tracking_scaling_policy_configuration': {
'target_value': 50
}
}
},
'provisioned_read_capacity_autoscaling_update': {
'maximum_units': 10,
'minimum_units': 5,
'scaling_policy': {
'target_tracking_scaling_policy_configuration': {
'target_value': 50,
'scale_in_cooldown': 60,
'scale_out_cooldown': 60
}
}
}
};
```
------
#### [ CLI ]
**를 사용하여 Amazon Keyspaces Auto Scaling으로 기존 테이블 구성 AWS CLI**
기존 Amazon Keyspaces 테이블의 경우 `UpdateTable` 작업을 사용하여 테이블의 쓰기 또는 읽기 용량에 대한 오토 스케일링을 켤 수 있습니다.
다음 명령을 사용하여 기존 테이블에 대해 Amazon Keyspaces 오토 스케일링을 켤 수 있습니다. 테이블에 대한 오토 스케일링 설정은 JSON 파일에서 로드됩니다. 다음 예제의 경우, [auto-scaling.zip](samples/auto-scaling.zip)에서 오토 스케일링 예제 JSON 파일을 다운로드하고 파일 경로를 메모하여 `auto-scaling.json`을 추출할 수 있습니다. 이 예제에서는 JSON 파일이 현재 디렉터리에 위치합니다. 다양한 파일 경로 옵션에 대해서는 [파일에서 매개변수를 로드하는 방법](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-file.html#cli-usage-parameters-file-how)을 참조하세요.
다음 예제에서 사용된 오토 스케일링 설정에 대한 자세한 내용은 [오토 스케일링을 사용하여 새 테이블 만들기](autoscaling.createTable.md)을 참조하세요.
```
aws keyspaces update-table --keyspace-name mykeyspace --table-name mytable
\ --capacity-specification throughputMode=PROVISIONED,readCapacityUnits=1,writeCapacityUnits=1
\ --auto-scaling-specification file://auto-scaling.json
```
------
# 테이블의 Amazon Keyspaces 오토 스케일링 구성 보기
콘솔, CQL 또는 AWS CLI 를 사용하여 테이블의 Amazon Keyspaces 자동 조정 설정을 보고 업데이트할 수 있습니다.
------
#### [ Console ]
****
**콘솔을 사용하여 오토 스케일링 설정 보기**
1. 보려는 테이블을 선택하고 **용량** 탭으로 이동합니다.
1. **용량 설정** 섹션에서 **편집**을 선택합니다. **읽기 용량** 또는 **쓰기 용량** 섹션에서 설정을 수정할 수 있습니다. 이러한 설정에 대한 자세한 내용은 [오토 스케일링을 사용하여 새 테이블 만들기](autoscaling.createTable.md) 섹션을 참조하세요.
------
#### [ Cassandra Query Language (CQL) ]
**CQL을 사용하여 테이블의 Amazon Keyspaces 오토 스케일링 정책 보기**
테이블의 오토 스케일링 구성에 대한 세부 정보를 보려면 다음 명령을 사용합니다.
```
SELECT * FROM system_schema_mcs.autoscaling WHERE keyspace_name = 'mykeyspace' AND table_name = 'mytable';
```
이 명령의 출력은 다음과 같습니다.
```
keyspace_name | table_name | provisioned_read_capacity_autoscaling_update | provisioned_write_capacity_autoscaling_update
---------------+------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
mykeyspace | mytable | {'minimum_units': 5, 'maximum_units': 10, 'scaling_policy': {'target_tracking_scaling_policy_configuration': {'scale_out_cooldown': 60, 'disable_scale_in': false, 'target_value': 50, 'scale_in_cooldown': 60}}} | {'minimum_units': 5, 'maximum_units': 10, 'scaling_policy': {'target_tracking_scaling_policy_configuration': {'scale_out_cooldown': 0, 'disable_scale_in': false, 'target_value': 50, 'scale_in_cooldown': 0}}}
```
------
#### [ CLI ]
**를 사용하여 테이블의 Amazon Keyspaces 오토 스케일링 정책 보기 AWS CLI**
테이블의 오토 스케일링 구성을 보려면 `get-table-auto-scaling-settings` 작업을 사용하면 됩니다. 다음 CLI 명령은 그 예입니다.
```
aws keyspaces get-table-auto-scaling-settings --keyspace-name mykeyspace --table-name mytable
```
이 명령의 출력은 다음과 같습니다.
```
{
"keyspaceName": "mykeyspace",
"tableName": "mytable",
"resourceArn": "arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/mytable",
"autoScalingSpecification": {
"writeCapacityAutoScaling": {
"autoScalingDisabled": false,
"minimumUnits": 5,
"maximumUnits": 10,
"scalingPolicy": {
"targetTrackingScalingPolicyConfiguration": {
"disableScaleIn": false,
"scaleInCooldown": 0,
"scaleOutCooldown": 0,
"targetValue": 50.0
}
}
},
"readCapacityAutoScaling": {
"autoScalingDisabled": false,
"minimumUnits": 5,
"maximumUnits": 10,
"scalingPolicy": {
"targetTrackingScalingPolicyConfiguration": {
"disableScaleIn": false,
"scaleInCooldown": 60,
"scaleOutCooldown": 60,
"targetValue": 50.0
}
}
}
}
}
```
------
# 테이블에 대한 Amazon Keyspaces 오토 스케일링 끄기
언제든지 테이블의 Amazon Keyspaces 오토 스케일링을 끌 수 있습니다. 더 이상 테이블의 읽기 또는 쓰기 용량을 확장할 필요가 없는 경우 오토 스케일링을 꺼서 Amazon Keyspaces가 테이블의 읽기 또는 쓰기 용량 설정을 계속 수정하지 않도록 하는 것이 좋습니다. 콘솔 CQL 또는 AWS CLI를 사용하여 테이블을 업데이트할 수 있습니다.
오토 스케일링을 끄면 사용자를 대신하여 생성된 CloudWatch 경보도 삭제됩니다.
Application Auto Scaling이 Amazon Keyspaces 테이블에 액세스하는 데 사용하는 서비스 연결 역할을 삭제하려면 [Amazon Keyspaces에 대한 서비스 연결 역할 삭제](using-service-linked-roles-app-auto-scaling.md#delete-service-linked-role-app-auto-scaling)의 단계를 따르세요.
**참고**
애플리케이션 오토 스케일링에서 사용하는 서비스 연결 역할을 삭제하려면 모든 AWS 리전에 걸쳐 계정의 모든 테이블에서 오토 스케일링을 비활성화해야 합니다.
------
#### [ Console ]
**콘솔을 사용하여 테이블의 Amazon Keyspaces 오토 스케일링 끄기**
**Amazon Keyspaces 콘솔 사용**
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home) Amazon Keyspaces 콘솔을 엽니다.
1. 업데이트하려는 테이블을 선택하고 **용량** 탭으로 이동합니다.
1. **용량 설정** 섹션에서 **편집**을 선택합니다.
1. Amazon Keyspaces 오토 스케일링을 비활성화하려면 **자동 규모 조정** 확인란의 선택을 취소합니다. 오토 스케일링을 비활성화하면 애플리케이션 오토 스케일링으로 확장 가능한 대상인 테이블의 등록이 취소됩니다.
------
#### [ Cassandra Query Language (CQL) ]
**CQL을 사용하여 테이블의 Amazon Keyspaces 오토 스케일링 끄기**
다음 문은 테이블 *mytable*의 쓰기 용량에 대한 오토 스케일링을 끕니다.
```
ALTER TABLE mykeyspace.mytable
WITH AUTOSCALING_SETTINGS = {
'provisioned_write_capacity_autoscaling_update': {
'autoscaling_disabled': true
}
};
```
------
#### [ CLI ]
**를 사용하여 테이블에 대한 Amazon Keyspaces 자동 조정 끄기 AWS CLI**
다음 명령은 테이블의 읽기 용량에 대한 오토 스케일링을 끕니다. 또한 사용자를 대신하여 생성한 CloudWatch 경보를 삭제합니다.
```
aws keyspaces update-table --keyspace-name mykeyspace --table-name mytable
\ --auto-scaling-specification readCapacityAutoScaling={autoScalingDisabled=true}
```
------
# Amazon CloudWatch에서 Amazon Keyspaces 테이블에 대한 오토 스케일링 활동 보기
사용량 및 성능에 관한 지표를 생성하는 Amazon CloudWatch를 사용하여 Amazon Keyspaces Auto Scaling이 리소스를 어떻게 사용하는지 모니터링할 수 있습니다. [Application Auto Scaling 사용 설명서](https://docs.aws.amazon.com/autoscaling/application/userguide/monitoring-cloudwatch.html)의 단계에 따라 CloudWatch 대시보드를 생성합니다.
# Amazon Keyspaces에서 버스트 용량을 효과적으로 사용하기
Amazon Keyspaces는 *버스트 용량*을 제공해 파티션당 처리량 프로비저닝에서 어느 정도 유연성을 제공합니다. 파티션의 처리량을 완전히 사용하지 않을 때마다 Amazon Keyspaces는 나중에 사용량 급증을 처리하기 위해 처리량 *버스트*에 사용하지 않은 용량 일부를 예약해 둡니다.
Amazon Keyspaces는 현재 5분(300초)에 해당하는 미사용 읽기 및 쓰기 용량을 비축합니다. 가끔 발생하는 읽기 또는 쓰기 작업의 버스트 중 이러한 추가 용량 단위는 빠르게, 테이블에 대해 정의한 초당 프로비저닝된 처리량 용량보다도 빠르게 소모될 수 있습니다.
Amazon Keyspaces는 또한 사전 통지 없이 배경 유지 관리와 다른 작업에 버스트 용량을 사용할 수도 있습니다.
향후 버스트 용량의 세부 정보가 변경될 수도 있습니다.