기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 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 문을 실행하고 대시보드에서 전체 테이블 스캔에 사용된 읽기 용량 단위를 확인합니다.