

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# Amazon Keyspaces의 읽기/쓰기 용량 모드 구성
<a name="ReadWriteCapacityMode"></a>

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)

# 온디맨드 용량 모드 구성
<a name="ReadWriteCapacityMode.OnDemand"></a>

Amazon Keyspaces(Apache Cassandra용) *온디맨드* 용량 모드는 용량 계획 없이 초당 수천 개의 요청을 처리할 수 있는 유연한 청구 옵션입니다. 이 옵션은 읽기 및 쓰기 요청에 대해 요청당 지불 가격을 제공하므로 사용하는 만큼에 대해서만 비용을 지불하면 됩니다.

 온디맨드 모드를 선택하면 Amazon Keyspaces는 테이블의 처리량 용량을 이전에 도달한 트래픽 수준까지 즉시 확장하고 애플리케이션 트래픽이 감소할 때 다시 축소할 수 있습니다. 워크로드의 트래픽 수준이 새로운 피크를 기록할 경우에는 서비스가 신속하게 조정을 수행하여 테이블의 처리량 용량을 증가시킵니다. 새 테이블과 기존 테이블 모두에 대해 온디맨드 용량 모드를 활성화할 수 있습니다.

온디맨드 모드는 다음 중 하나에 해당되는 경우에 유용한 옵션입니다.
+ 알 수 없는 워크로드를 포함하는 테이블을 새로 만드는 경우 
+ 애플리케이션 트래픽이 예측 불가능한 경우가 있습니다.
+ 사용한 만큼에 대해서만 지불하는 요금제를 사용하려는 경우 

온디맨드 모드를 시작하려면 콘솔을 사용하거나 몇 줄의 Cassandra 쿼리 언어(CQL) 코드를 사용하여 온디맨드 용량 모드를 사용하도록 새 테이블을 만들거나 기존 테이블을 업데이트하면 됩니다. 자세한 내용은 [테이블](cql.ddl.table.md) 단원을 참조하십시오.

**Topics**
+ [읽기 요청 단위 및 쓰기 요청 단위](#ReadWriteCapacityMode.requests)
+ [피크 트래픽 및 크기 조정 속성](#ReadWriteCapacityMode.PeakTraffic)
+ [온디맨드 용량 모드의 초기 처리량](#ReadWriteCapacityMode.InitialThroughput)

## 읽기 요청 단위 및 쓰기 요청 단위
<a name="ReadWriteCapacityMode.requests"></a>

 온디맨드 용량 모드 테이블을 사용하면 애플리케이션에서 미리 사용할 것으로 예상되는 읽기 및 쓰기 처리량을 지정할 필요가 없습니다. 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) 섹션을 참조하세요.

## 피크 트래픽 및 크기 조정 속성
<a name="ReadWriteCapacityMode.PeakTraffic"></a>

온디맨드 용량 모드를 사용하는 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) 섹션을 참조하세요.

## 온디맨드 용량 모드의 초기 처리량
<a name="ReadWriteCapacityMode.InitialThroughput"></a>

온디맨드 용량 모드가 활성화된 새 테이블을 생성하거나 처음으로 기존 테이블을 온디맨드 용량 모드로 전환하는 경우 이전에 온디맨드 용량 모드를 사용하여 트래픽을 처리하지 않았더라도 테이블의 이전 피크 설정은 다음과 같습니다.
+  **온디맨드 용량 모드로 새로 만든 테이블:** 이전 피크는 2,000WRU와 6,000RRU였습니다. 이전 피크의 최대 두 배까지 즉시 늘릴 수 있습니다. 이렇게 하면 새로 생성된 온디맨드 테이블에서 최대 4,000WRU와 12,000RRU를 처리할 수 있습니다.
+  **온디맨드 용량 모드로 전환된 기존 테이블:** 이전 피크는 테이블에 대해 프로비저닝된 이전 WCU 및 RCU의 절반이거나 온디맨드 용량 모드를 통해 새로 생성된 테이블의 설정 중 더 높은 값입니다.

# 프로비저닝된 용량 모드 구성
<a name="ReadWriteCapacityMode.Provisioned"></a>

 *프로비저닝된 처리량* 용량 모드를 선택하는 경우 애플리케이션에 필요한 초당 읽기 및 쓰기 횟수를 지정합니다. 이를 통해 Amazon Keyspaces 사용량을 관리하여 정의된 요청 속도 이하로 유지하여 예측 가능성을 유지할 수 있습니다. 프로비저닝된 처리량을 위한 자동 크기 조정에 대한 자세한 내용은 [Amazon Keyspaces 오토 스케일링으로 처리량 용량 자동 관리](autoscaling.md) 섹션을 참조하세요.

프로비저닝된 처리량 용량 모드는 다음 중 하나에 해당되는 경우에 유용한 옵션입니다.
+ 애플리케이션 트래픽이 예측 가능한 경우 
+ 트래픽이 일관되거나 점진적으로 변화하는 애플리케이션을 실행할 경우 
+ 용량 요구 사항을 예측할 수 있습니다.

## 읽기 용량 단위 및 쓰기 용량 단위
<a name="ReadWriteCapacityMode.Provisioned.Units"></a>

 프로비저닝된 처리량 용량 모드 테이블의 경우 읽기 용량 단위(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에서 테이블의 용량 모드 보기
<a name="ReadWriteCapacityMode.ProvisionedThroughput.ManagingCapacity"></a>

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에서 테이블의 용량 모드 변경
<a name="ReadWriteCapacityMode.SwitchReadWriteCapacityMode"></a>

테이블을 프로비저닝된 용량 모드에서 온디맨드 용량 모드로 전환할 경우 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의 테이블에 대한 사전 워밍 구성
<a name="warm-throughput"></a>

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 테이블을 사전 워밍할 때 고려할 수 있는 몇 가지 시나리오와 모범 사례입니다.

## 웜 처리량 및 고르지 않은 액세스 패턴
<a name="warm-throughput-scenarios-uneven"></a>

테이블의 웜 처리량은 초당 30,000개의 읽기 단위와 초당 10,000개의 쓰기 단위일 수 있지만 해당 값에 도달하기 전에 읽기 또는 쓰기에서 여전히 용량 초과 이벤트가 발생할 수 있습니다. 이는 핫 파티션 때문일 수 있습니다. Amazon Keyspaces는 거의 무제한 처리량을 지원하도록 규모를 조정할 수 있지만 각 개별 파티션은 초당 1,000개의 쓰기 단위와 초당 3,000개의 읽기 단위로 제한됩니다. 애플리케이션이 테이블 파티션의 작은 부분으로 트래픽을 너무 많이 구동하는 경우 테이블의 웜 처리량 값에 도달하기 전에도 용량 초과 이벤트가 발생할 수 있습니다. 원활한 확장성을 보장하고 핫 파티션을 방지하려면 [Amazon Keyspaces 모범 사례를](bp-partition-key-design.md) 따르는 것이 좋습니다.

## 프로비저닝된 테이블의 웜 처리량
<a name="warm-throughput-scenarios-provisioned"></a>

웜 처리량이 초당 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
    }
```

## 온디맨드 테이블의 웜 처리량
<a name="warm-throughput-scenarios-ondemand"></a>

새로운 온디맨드 테이블은 초당 12,000개의 읽기 단위와 초당 4,000개의 쓰기 단위의 웜 처리량으로 시작됩니다. 테이블은 이러한 수준까지 지속적인 트래픽을 즉시 수용할 수 있습니다. 요청이 초당 12,000개의 읽기 단위 또는 초당 4,000개의 쓰기 단위를 초과하면 웜 처리량이 자동으로 더 높은 값으로 조정됩니다.

```
"WarmThroughput": 
    { 
        "ReadUnitsPerSecond": 12000,
        "WriteUnitsPerSecond": 4000
    }
```

## Amazon Keyspaces 테이블 사전 워밍 모범 사례
<a name="prewarming-best-practices"></a>

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 테이블 생성
<a name="create-table-warm-throughput"></a>

콘솔, 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<ColumnDefinition> 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<PartitionKey> partitionKeys = Arrays.asList(
              PartitionKey.builder().name("year").build(),
              PartitionKey.builder().name("award").build()
          );
          
          List<ClusteringKey> 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 테이블의 웜 처리량 증가
<a name="update-warm-throughput"></a>

콘솔, 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 테이블의 웜 처리량 보기
<a name="view-warm-throughput"></a>

콘솔, 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를 사용하여 사전 워밍된 테이블의 성능 모니터링
<a name="monitor-prewarming-cloudwatch"></a>

Amazon Keyspaces 사전 워밍은 새로운 CloudWatch 지표를 도입하지 않지만 기존 Amazon Keyspaces 지표를 사용하여 사전 워밍된 테이블의 성능을 모니터링할 수 있습니다.

SuccessfulRequestLatency  
이 지표를 모니터링하여 사전 워밍된 테이블이 예상 지연 시간으로 요청을 처리하고 있는지 확인합니다.

WriteThrottleEvents 및 ReadThrottleEvents  
이러한 지표는 적절하게 사전 워밍된 테이블의 경우 낮게 유지되어야 합니다. 사전 워밍에도 불구하고 용량 부족 오류가 표시되는 경우 웜 처리량 값을 조정해야 할 수 있습니다.

ConsumedReadCapacityUnits 및 ConsumedWriteCapacityUnits  
이러한 지표는 실제 용량 소비를 보여주므로 사전 워밍 구성이 적절한지 확인하는 데 도움이 될 수 있습니다.

ProvisionedReadCapacityUnits 및 ProvisionedWriteCapacityUnits  
프로비저닝된 테이블의 경우 이러한 지표는 현재 할당된 용량을 표시합니다.

이러한 지표는 CloudWatch 콘솔에서 보거나 CloudWatch API를 사용하여 쿼리할 수 있습니다. 자세한 내용은 [Amazon CloudWatch를 사용하여 Amazon Keyspaces 모니터링](monitoring-cloudwatch.md) 단원을 참조하십시오.