기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Amazon Keyspaces 테이블 비용 최적화 이 섹션에서는 기존 Amazon Keyspaces 테이블의 비용을 최적화하는 방법에 대한 모범 사례를 다룹니다. 다음 전략을 검토하여 요구 사항에 가장 적합한 비용 최적화 전략을 확인하고 반복적으로 접근해야 합니다. 각 전략은 비용에 영향을 미칠 수 있는 요소, 비용 최적화 기회를 찾는 방법, 비용 절감을 위해 이러한 모범 사례를 구현하는 방법에 대한 권장 가이드의 개요를 제공합니다. **Topics** + [테이블 수준에서 비용 평가](CostOptimization_TableLevelCostAnalysis.md) + [테이블 용량 모드 평가](CostOptimization_TableCapacityMode.md) + [테이블의 Application Auto Scaling 설정 평가](CostOptimization_AutoScalingSettings.md) + [사용하지 않는 리소스를 파악하여 Amazon Keyspaces에서 비용 최적화](CostOptimization_UnusedResources.md) + [테이블 사용 패턴을 평가하여 성능 및 비용 최적화](CostOptimization_TableUsagePatterns.md) + [적절한 규모의 프로비저닝을 위해 프로비저닝된 용량 평가](CostOptimization_RightSizedProvisioning.md) # 테이블 수준에서 비용 평가 내에 있는 Cost Explorer 도구를 AWS Management Console 사용하면 읽기, 쓰기, 스토리지 및 백업 요금과 같이 유형별로 분류된 비용을 확인할 수 있습니다. 월별 또는 일과 같은 기간별로 요약된 비용도 확인할 수 있습니다. Cost Explorer의 일반적인 과제 중 하나는 Cost Explorer가 특정 테이블의 비용을 기준으로 필터링하거나 그룹화할 수 없기 때문에 특정 테이블의 비용만 쉽게 검토할 수 없다는 것입니다. 테이블의 **모니터** 탭에 있는 Amazon Keyspaces 콘솔에서 각 테이블의 **청구 가능 테이블 크기(바이트)** 지표를 볼 수 있습니다. 테이블당 추가 비용 관련 정보가 필요한 경우 이 섹션에서는 Cost Explorer 에서 [태그 지정](tagging-keyspaces.md)을 사용하여 개별 테이블 비용 분석을 수행하는 방법을 보여줍니다. **Topics** + [단일 Amazon Keyspaces 테이블의 비용을 확인하는 방법](#CostOptimization_TableLevelCostAnalysis_ViewInfo) + [Cost Explorer의 기본 보기](#CostOptimization_TableLevelCostAnalysis_CostExplorer) + [Cost Explorer에서 테이블 태그를 사용하고 적용하는 방법](#CostOptimization_TableLevelCostAnalysis_Tagging) ## 단일 Amazon Keyspaces 테이블의 비용을 확인하는 방법 프라이머리 키 스키마, 청구 가능한 테이블 크기 및 용량 관련 지표를 포함하여 콘솔에서 Amazon Keyspaces 테이블에 대한 기본 정보를 볼 수 있습니다. 테이블 크기를 사용하여 테이블의 월별 스토리지 비용을 계산할 수 있습니다. 예를 들어 미국 동부(버지니아 북부)에서는 GB당 0.25 USD입니다 AWS 리전. 테이블이 프로비저닝된 용량 모드를 사용하는 경우 현재 읽기 용량 단위(RCU) 및 쓰기 용량 단위(WCU) 설정도 반환됩니다. 이 정보를 사용하여 테이블의 현재 읽기 및 쓰기 비용을 계산할 수 있습니다. 특히 Amazon Keyspaces Amazon Keyspaces으로 테이블을 구성한 경우 이러한 비용이 변경될 수 있습니다. ## Cost Explorer의 기본 보기 Cost Explorer의 기본 보기는 처리량(throughput) 및 스토리지와 같은 사용된 리소스 비용을 보여주는 차트를 제공합니다. 월별 또는 일별 합계와 같이 기간별로 비용을 그룹화하도록 선택할 수 있습니다. 스토리지, 읽기, 쓰기 및 기타 카테고리의 비용도 세분화하여 비교할 수 있습니다. ![\[Cost Explorer 보기에서 사용된 리소스의 비용이 표시된 이미지입니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/CostOptimization/CostExplorerView.png) ## Cost Explorer에서 테이블 태그를 사용하고 적용하는 방법 기본적으로 Cost Explorer는 여러 테이블의 비용을 합산하므로 특정 테이블에 대한 비용 요약을 제공하지 않습니다. 하지만 [AWS 리소스 태깅](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)을 사용하여 메타데이터 태그로 각 테이블을 식별할 수 있습니다. 태그는 프로젝트 또는 부서에 속한 모든 리소스를 식별하는 등 다양한 용도로 사용할 수 있는 키-값 쌍입니다. 자세한 내용은 [Amazon Keyspaces 리소스에 대한 태그 및 레이블 작업](tagging-keyspaces.md) 단원을 참조하십시오. 이 예제에서는 이름이 **MyTable**인 테이블을 사용합니다. 1. **table\$1name**의 키와 **MyTable**의 값으로 태그를 설정합니다. 1. [Cost Explorer 탐색기에서 태그를 활성화](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)한 후 태그 값을 필터링하여 각 테이블의 비용을 더 잘 파악할 수 있습니다. **참고** Cost Explorer에 태그가 표시되려면 하루나 이틀이 걸릴 수 있습니다. 콘솔에서 직접 또는 CQL, AWS CLI또는 AWS SDK를 사용하여 프로그래밍 방식으로 메타데이터 태그를 설정할 수 있습니다. 조직의 새 테이블 생성 프로세스의 일부로 **table\$1name** 태그를 설정하도록 요구하는 것이 좋습니다. 자세한 내용은 [Amazon Keyspace에 대한 태그를 사용하여 비용 할당 보고서 생성](CostAllocationReports.md) 단원을 참조하십시오. # 테이블 용량 모드 평가 이 섹션에서는 Amazon Keyspaces 테이블에 적절한 용량 모드를 선택하는 방법을 간략히 살펴봅니다. 각 모드는 처리량(throughput) 변화에 대한 대응력 및 사용량 청구 방식 측면에서 다양한 워크로드의 요구 사항을 충족하도록 조정됩니다. 결정을 내릴 때 이러한 요소들의 균형을 맞춰야 합니다. **Topics** + [사용할 수 있는 테이블 용량 모드](#CostOptimization_TableCapacityMode_Overview) + [온디맨드 용량 모드를 선택하는 경우](#CostOptimization_TableCapacityMode_OnDemand) + [프로비저닝된 용량 모드를 선택하는 경우](#CostOptimization_TableCapacityMode_Provisioned) + [테이블 용량 모드를 선택할 때 고려해야 할 추가 요소](#CostOptimization_TableCapacityMode_AdditionalFactors) ## 사용할 수 있는 테이블 용량 모드 Amazon Keyspaces 테이블을 생성할 때 온디맨드 또는 프로비저닝된 용량 모드를 선택해야 합니다. 자세한 내용은 [Amazon Keyspaces의 읽기/쓰기 용량 모드 구성](ReadWriteCapacityMode.md) 단원을 참조하십시오. **온디맨드 용량 모드** 온디맨드 용량 모드는 Amazon Keyspaces 테이블의 용량을 계획하거나 프로비저닝할 필요가 없도록 설계되었습니다. 이 모드에서 테이블은 리소스를 스케일 업 또는 다운할 필요 없이 요청을 즉시 수용합니다(테이블의 이전 최대 처리량(throughput)의 최대 2배). 온디맨드 테이블은 테이블에 대한 실제 요청 수를 계산하여 청구되므로 프로비저닝된 것이 아니라 사용한 만큼만 비용을 지불하면 됩니다. **프로비저닝된 용량 모드** 프로비저닝된 용량 모드는 테이블이 요청에 사용할 수 있는 용량을 직접 또는 Application Auto Scaling의 도움으로 정의할 수 있는 보다 전통적인 모델입니다. 지정된 시간에 테이블에 대해 특정 용량이 프로비저닝되기 때문에 비용은 요청 수가 아닌 프로비저닝된 용량을 기준으로 결제됩니다. 할당된 용량을 초과하면 테이블이 요청을 거부하고 애플리케이션 사용자의 경험을 감소시킬 수도 있습니다. 프로비저닝된 용량 모드에서는 두 가지를 모두 달성하기 위해 테이블을 과도하게 프로비저닝하지 않거나 과소 프로비저닝하지 않는 균형이 필요하며, 처리량 용량 부족 오류가 발생하지 않으며, 비용이 최적화되어야 합니다. ## 온디맨드 용량 모드를 선택하는 경우 비용을 최적화할 때 다음 그래프와 유사한 예측 불가능한 워크로드가 있는 경우 온디맨드 모드가 최선의 선택입니다. 이러한 유형의 워크로드에 영향을 미치는 요소는 다음과 같습니다. + 예측할 수 없는 요청 타이밍(트래픽 급증 초래) + 다양한 볼륨의 요청(배치 워크로드로 인한 요청) + 지정된 1시간 동안 피크의 0 또는 18% 미만으로 떨어짐(개발 또는 테스트 환경의 결과) ![\[트래픽이 무작위로 최고조에 달하는 워크로드가 표시된 이미지입니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeOnDemand.png) 위와 같은 특성을 가진 워크로드의 경우 Application Auto Scaling을 사용하여 트래픽 급증에 대응할 수 있는 테이블 용량을 충분히 유지하면 바람직하지 않은 결과가 발생할 수 있습니다. 테이블이 과도하게 프로비저닝되어 필요 이상으로 비용이 많이 들거나, 테이블이 제대로 프로비저닝되지 않아 요청으로 인해 불필요하게 저용량 처리량 오류가 발생할 수 있습니다. 이런 경우에는 온디맨드 테이블이 더 나은 선택입니다. 온디맨드 테이블은 요청에 따라 청구되기 때문에 비용 최적화를 위해 테이블 수준에서 더 이상 수행해야 할 작업이 없습니다. 워크로드에 여전히 위의 특성이 있는지 확인하기 위해 온디맨드 테이블을 정기적으로 평가해야 합니다. 워크로드가 안정화되면 프로비저닝 모드로 변경하여 비용 최적화를 유지하는 것이 좋습니다. ## 프로비저닝된 용량 모드를 선택하는 경우 프로비저닝된 용량 모드에 대한 이상적인 워크로드는 아래 그래프와 같이 사용 패턴이 더 예측 가능한 워크로드입니다. 예측 가능한 워크로드에 영향을 미치는 요소는 다음과 같습니다. + 특정 시간 또는 일별 예측 가능한/주기적 트래픽 + 제한적인 단기 트래픽 폭주 ![\[트래픽 피크가 제한되어 있어 상당히 예측 가능한 워크로드가 표시된 이미지입니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeProvisioned.png) 지정된 시간 또는 일의 트래픽 볼륨이 더 안정적이기 때문에 프로비저닝된 용량을 테이블의 실제 사용된 용량에 비교적 가깝게 설정할 수 있습니다. 프로비저닝된 용량 테이블의 비용 최적화는 궁극적으로 테이블에서 `ThrottledRequests` 이벤트를 늘리지 않고 할당된 용량(파란색 선)을 사용된 용량(주황색 선)에 최대한 가깝게 만드는 연습입니다. 두 선 사이의 공간은 낭비된 용량뿐만 아니라 처리량 용량 부족 오류로 인해 발생할 수 있는 나쁜 사용자 경험에 대비한 용량을 나타냅니다. Amazon Keyspaces는 프로비저닝된 용량 테이블에 대한 Application Auto Scaling을 제공하므로 사용자를 대신하여 자동으로 균형을 조정할 수 있습니다. 하루 종일 사용된 용량을 추적하고 몇 가지 변수를 기반으로 테이블의 프로비저닝된 용량을 구성할 수 있습니다. **최소 용량 단위** 테이블의 최소 용량을 설정하여 처리량 용량 부족 오류의 발생을 줄일 수 있지만 테이블 비용이 줄어들지는 않습니다. 테이블 사용량이 낮은 기간이 있다가 갑자기 사용량이 급증한 경우 최소값으로 설정하면 Application Auto Scaling이 테이블 용량을 너무 낮게 설정하는 것을 방지할 수 있습니다. **최대 용량 단위** 테이블의 최대 용량을 설정하여 테이블 확장을 의도한 것보다 높게 제한할 수 있습니다. 대규모 로드 테스트가 필요하지 않은 개발 또는 테스트 테이블에는 최대값을 적용하는 것이 좋습니다. 모든 테이블에 대해 최대값을 설정할 수 있지만 실수로 처리량 용량 부족 오류가 발생하지 않도록 프로덕션에서 사용할 때 테이블 기준선에 대해 이 설정을 정기적으로 평가해야 합니다. **목표 사용률** 테이블의 목표 사용률을 설정하는 것은 프로비저닝된 용량 테이블에 대한 비용 최적화의 기본 수단입니다. 여기서 백분율 값을 낮게 설정하면 테이블이 오버프로비저닝되는 양이 늘어나 비용이 증가하지만 처리량 용량 부족 오류의 위험은 줄어듭니다. 여기서 백분율 값을 높게 설정하면 테이블이 오버프로비저닝되는 양이 줄어들지만 처리량 용량 부족 오류의 위험이 커집니다. ## 테이블 용량 모드를 선택할 때 고려해야 할 추가 요소 두 용량 모드 중 하나를 결정할 때 고려해야 할 몇 가지 추가 요소가 있습니다. 두 테이블 모드 중 하나를 결정할 때는 이러한 추가 할인이 테이블 비용에 얼마나 영향을 미치는지 고려합니다. 대부분의 경우 비교적 예측하기 어려운 워크로드라도 예약 용량이 있는 오버프로비저닝된 용량 테이블에서 실행하는 것이 더 저렴할 수 있습니다. **워크로드의 예측 가능성 향상** 경우에 따라 워크로드에 예측 가능한 패턴과 예측할 수 없는 패턴이 모두 있는 것처럼 보일 수 있습니다. 온디맨드 테이블에서는 이러한 워크로드도 쉽게 지원할 수 있지만, 워크로드에 있는 예측할 수 없는 패턴을 개선할 수 있다면 비용을 더 줄일 수 있을 것입니다. 이러한 패턴의 가장 일반적인 원인 중 하나는 일괄 가져오기입니다. 이러한 유형의 트래픽은 테이블을 실행할 때 처리량 용량 부족 오류가 발생할 정도로 테이블의 기준 용량을 초과하는 경우가 많습니다. 프로비저닝된 용량 테이블에서 이와 같은 워크로드를 계속 실행하려면 다음 옵션을 사용해봅니다. + 예약된 시간에 일괄 처리가 발생하는 경우 실행 전에 Application Auto Scaling 용량을 늘리도록 예약할 수 있습니다. + 일괄 처리가 무작위로 발생하는 경우 최대한 빨리 실행하는 대신 실행 시간을 연장하는 것이 좋습니다. + 가져오기 속도가 처음에는 느린 속도에서 시작해서 Application Auto Scaling이 테이블 용량 조정을 시작할 수 있을 때까지 몇 분 동안 서서히 오르도록 증가 기간을 가져오기에 추가합니다. # 테이블의 Application Auto Scaling 설정 평가 이 섹션에서는 Amazon Keyspaces 테이블의 애플리케이션 오토 스케일링 설정을 평가하는 방법을 간략히 살펴봅니다. [Amazon Keyspaces Auto Scaling은](autoscaling.md) 애플리케이션 트래픽과 대상 사용률 지표를 기반으로 테이블 처리량을 관리하는 기능입니다. 이렇게 하면 테이블이 애플리케이션 패턴에 필요한 용량을 확보할 수 있습니다. Application Auto Scaling 서비스는 현재 테이블 사용률을 모니터링하고 이를 목표 사용률 값(`TargetValue`)과 비교합니다. 할당된 용량을 늘리거나 줄여야 할 시기가 되면 알려 줍니다. **Topics** + [Application Auto Scaling 설정 이해하기](#CostOptimization_AutoScalingSettings_UnderProvisionedTables) + [목표 사용률이 낮은(<= 50%) 테이블을 식별하는 방법](#CostOptimization_AutoScalingSettings_IdentifyLowUtilization) + [계절적 변동이 있는 워크로드를 해결하는 방법](#CostOptimization_AutoScalingSettings_SeasonalVariance) + [알 수 없는 패턴으로 급증하는 워크로드를 해결하는 방법](#CostOptimization_AutoScalingSettings_UnknownPatterns) + [연결된 애플리케이션으로 워크로드를 해결하는 방법](#CostOptimization_AutoScalingSettings_BetweenRanges) ## Application Auto Scaling 설정 이해하기 목표 사용률, 초기 단계 및 최종 값에 대한 올바른 값을 정의하려면 운영 팀의 참여가 필요합니다. 이렇게 하면 Application Auto Scaling 정책을 트리거하는 데 사용될 값을 과거 애플리케이션 사용량을 기반으로 적절하게 정의할 수 있습니다. 사용률 목표는 Application Auto Scaling 규칙이 적용되기 전에 일정 기간 동안 도달해야 하는 총 용량의 백분율입니다. **높은 사용률 목표(약 90%의 목표)**를 설정하면 Application Auto Scaling이 활성화되기 전에 일정 기간 동안 트래픽이 90%보다 높아야 합니다. 애플리케이션이 매우 일정하고 트래픽 급증이 발생하지 않는 한 높은 사용률 목표를 사용해서는 안 됩니다. 매우 **낮은 사용률(50% 미만의 목표)**을 설정하면 애플리케이션이 Application Auto Scaling 정책을 실행하기 전에 프로비저닝된 용량의 50%에 도달해야 합니다. 애플리케이션 트래픽이 매우 빠른 속도로 증가하지 않는 한 이는 대개 용량 미사용 및 리소스 낭비로 이어집니다. ## 목표 사용률이 낮은(<= 50%) 테이블을 식별하는 방법 AWS CLI 또는를 사용하여 Amazon Keyspaces 리소스에서 `TargetValues` Application Auto Scaling 정책의를 AWS Management Console 모니터링하고 식별할 수 있습니다. **참고** Amazon Keyspaces 오토 스케일링과 함께 프로비저닝된 용량 모드에서 다중 리전 테이블을 사용하는 경우 Amazon Keyspaces API 작업을 사용하여 오토 스케일링을 구성해야 합니다. Amazon Keyspaces가 사용자를 대신하여 호출하는 기본 애플리케이션 오토 스케일링 API 작업에는 다중 리전 기능이 없습니다. 자세한 내용은 [Amazon Keyspaces에서 다중 리전 테이블에 대한 프로비저닝된 용량 및 오토 스케일링 설정 보기](tables-mrr-view.md) 단원을 참조하십시오. ------ #### [ AWS CLI ] 1. 다음 명령을 실행하여 전체 리소스 목록을 반환합니다. ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra ``` 이 명령은 모든 Amazon Keyspaces 리소스에 발행된 Application Auto Scaling 정책의 전체 목록을 반환합니다. 특정 테이블에서만 리소스를 검색하려는 경우 `–resource-id parameter`를 추가하면 됩니다. 예제: ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name” ``` 1. 다음 명령을 실행하여 특정 테이블에 대한 Auto Scaling 정책만 반환하세요. ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name” ``` Application Auto Scaling 정책에 대한 값은 아래에 강조 표시되어 있습니다. 과다 프로비저닝을 방지하기 위해 목표값을 50%보다 높게 설정해야 합니다. 다음과 유사한 결과가 출력되어야 합니다. ``` { "ScalingPolicies": [ { "PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy::resource/keyspaces/table/table-name-scaling-policy", "PolicyName": $”, "ServiceNamespace": "cassandra", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:WriteCapacityUnits", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "KeyspacesWriteCapacityUtilization" } }, "Alarms": [ ... ], "CreationTime": "2022-03-04T16:23:48.641000+10:00" }, { "PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy::resource/keyspaces/table/table-name-scaling-policy", "PolicyName":$”, "ServiceNamespace": "cassandra", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:ReadCapacityUnits", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "KeyspacesReadCapacityUtilization" } }, "Alarms": [ ... ], "CreationTime": "2022-03-04T16:23:47.820000+10:00" } ] } ``` ------ #### [ AWS Management Console ] 1. 에 로그인 AWS Management Console 하고 [시작하기 AWS Management Console](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html)의 CloudWatch 서비스 페이지로 이동합니다. 필요한 AWS 리전 경우 적절한를 선택합니다. 1. 왼쪽 탐색 메뉴에서 **Tables**(테이블)를 선택합니다. **Tables**(테이블) 페이지에서 테이블 **이름**을 선택합니다. 1. **테이블 세부 정보** 페이지의 **용량** 탭에서 테이블의 Application Auto Scaling 설정을 검토합니다. ------ 목표 사용률 값이 50% 이하이면 테이블 사용률 지표를 살펴보고 해당 지표가 [과소 프로비저닝되었는지 과다 프로비저닝되었는지](CostOptimization_RightSizedProvisioning.md) 확인해야 합니다. ## 계절적 변동이 있는 워크로드를 해결하는 방법 다음과 같은 시나리오를 생각해 보세요. 대부분의 경우 애플리케이션이 최소 평균값 미만으로 작동하지만 사용률 목표가 낮기 때문에 애플리케이션이 하루 중 특정 시간에 발생하는 이벤트에 신속하게 반응할 수 있고 충분한 용량이 확보되어 제한을 피할 수 있습니다. 이 시나리오는 일반적인 업무 시간(오전 9시\$1오후 5시)에는 사용량이 아주 많지만 업무 시간 이후에는 기본 수준에서 작동하는 애플리케이션이 있는 경우에 일반적입니다. 일부 사용자는 오전 9시 이전에 연결을 시작하므로 애플리케이션은 이 낮은 임계값을 사용하여 사용량이 많은 시간대에 *필요한* 용량에 빠르게 도달합니다. 이 시나리오는 다음과 같이 진행될 수 있습니다. + 오후 5시에서 오전 9시 사이에는 `ConsumedWriteCapacityUnits` 단위가 90에서 100 사이로 유지됩니다. + 사용자가 오전 9시 이전에 애플리케이션에 연결하기 시작하면 용량 단위가 크게 늘어납니다(지금까지 본 최대값은 1,500WCU). + 평균적인 애플리케이션 사용량은 근무 시간 동안 800에서 1,200 사이로 다양합니다. 애플리케이션에 이전 시나리오가 적용되는 경우, [예약된 Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html)을 사용하면 테이블에 구성된 Application Auto Scaling 규칙이 유지되면서도 필요한 특정 간격으로만 추가 용량을 프로비저닝하는 덜 적극적인 대상 사용률을 적용할 수 있습니다. AWS CLI 를 사용하여 다음 단계를 실행하여 시간대와 요일을 기반으로 실행되는 예약된 Auto Scaling 규칙을 생성할 수 있습니다. 1. Application Auto Scaling를 사용하여 Amazon Keyspaces 테이블을 확장 가능한 대상으로 등록합니다. 확장 가능한 목표란 Application Auto Scaling 이 스케일 아웃 또는 스케일 인할 수 있는 리소스입니다. ``` aws application-autoscaling register-scalable-target \ --service-namespace cassandra \ --scalable-dimension cassandra:table:WriteCapacityUnits \ --resource-id keyspace/keyspace-name/table/table-name \ --min-capacity 90 \ --max-capacity 1500 ``` 1. 요구 사항에 따라 예약된 작업 설정 시나리오를 다루려면 두 가지 규칙이 필요합니다. 하나는 스케일 업 규칙이고 다른 하나는 스케일 다운 규칙입니다. 예약된 작업을 스케일 업하기 위한 첫 번째 규칙은 다음 예제와 같습니다. ``` aws application-autoscaling put-scheduled-action \ --service-namespace cassandra \ --scalable-dimension cassandra:table:WriteCapacityUnits \ --resource-id keyspace/keyspace-name/table/table-name \ --scheduled-action-name my-8-5-scheduled-action \ --scalable-target-action MinCapacity=800,MaxCapacity=1500 \ --schedule "cron(45 8 ? * MON-FRI *)" \ --timezone "Australia/Brisbane" ``` 예약된 작업을 스케일 다운하기 위한 두 번째 규칙은 다음 예제와 같습니다. ``` aws application-autoscaling put-scheduled-action \ --service-namespace cassandra \ --scalable-dimension cassandra:table:WriteCapacityUnits \ --resource-id keyspace/keyspace-name/table/table-name \ --scheduled-action-name my-5-8-scheduled-down-action \ --scalable-target-action MinCapacity=90,MaxCapacity=1500 \ --schedule "cron(15 17 ? * MON-FRI *)" \ --timezone "Australia/Brisbane" ``` 1. 다음 명령을 실행하여 두 규칙이 모두 활성화되었는지 확인합니다. ``` aws application-autoscaling describe-scheduled-actions --service-namespace cassandra ``` 다음과 같은 결과가 나와야 합니다. ``` { "ScheduledActions": [ { "ScheduledActionName": "my-5-8-scheduled-down-action", "ScheduledActionARN": "arn:aws:autoscaling:us-east-1:111122223333:scheduledAction::resource/keyspaces/table/table-name:scheduledActionName/my-5-8-scheduled-down-action", "ServiceNamespace": "cassandra", "Schedule": "cron(15 17 ? * MON-FRI *)", "Timezone": "Australia/Brisbane", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:WriteCapacityUnits", "ScalableTargetAction": { "MinCapacity": 90, "MaxCapacity": 1500 }, "CreationTime": "2022-03-15T17:30:25.100000+10:00" }, { "ScheduledActionName": "my-8-5-scheduled-action", "ScheduledActionARN": "arn:aws:autoscaling:us-east-1:111122223333:scheduledAction::resource/keyspaces/table/table-name:scheduledActionName/my-8-5-scheduled-action", "ServiceNamespace": "cassandra", "Schedule": "cron(45 8 ? * MON-FRI *)", "Timezone": "Australia/Brisbane", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:WriteCapacityUnits", "ScalableTargetAction": { "MinCapacity": 800, "MaxCapacity": 1500 }, "CreationTime": "2022-03-15T17:28:57.816000+10:00" } ] } ``` 다음 그림은 항상 70% 목표 사용률을 유지하는 샘플 워크로드를 보여 줍니다. Auto Scaling 규칙이 여전히 적용되고 있으며 처리량은 감소하지 않는다는 점에 유의하세요. ![\[하루 동안 프로비저닝된 용량과 소비된 용량을 비교하여 초당 단위의 쓰기 사용량을 보여주는 그래프입니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings3.png) 자세히 보면 애플리케이션에 급증이 발생하여 70% Auto Scaling 임계값이 트리거되고, Auto Scaling이 강제로 시작되어 테이블에 필요한 추가 용량을 제공하는 것을 볼 수 있습니다. 예약된 오토 스케일링 작업은 최대값과 최소값에 영향을 미치며 이를 설정하는 것은 사용자의 책임입니다. ![\[프로비저닝된 용량과 소비된 용량을 비교하여 초당 단위의 쓰기 사용량을 보여주는 그래프의 보다 자세한 보기로, 특정 시간을 확대합니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings4.png) ![\[하루 동안 프로비저닝된 용량과 소비된 용량을 비교하여 초당 쓰기 사용량을 단위로 표시하는 그래프의 세부 보기를 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings5.png) ## 알 수 없는 패턴으로 급증하는 워크로드를 해결하는 방법 이 시나리오에서는 애플리케이션 패턴을 아직 모르고 워크로드에 용량 처리량 부족 오류가 발생하지 않도록 하기 위해 애플리케이션이 매우 낮은 사용률 목표를 사용합니다. 대신 [온디맨드 용량 모드를](ReadWriteCapacityMode.OnDemand.md) 사용하는 것을 고려해 봅니다. 온디맨드 테이블은 트래픽 패턴을 모르는 급증하는 워크로드에 적합합니다. 온디맨드 용량 모드를 사용하면 애플리케이션이 테이블에서 수행하는 데이터 읽기 및 쓰기에 대해 요청당 요금을 지불합니다. Amazon Keyspaces는 늘어나거나 줄어드는 워크로드를 즉시 수용하기 때문에 애플리케이션에서 수행할 것으로 예상되는 읽기 및 쓰기 처리량을 지정할 필요가 없습니다. ## 연결된 애플리케이션으로 워크로드를 해결하는 방법 이 시나리오에서 애플리케이션은 다른 시스템에 의존합니다. 예를 들어 애플리케이션 로직의 이벤트에 따라 트래픽이 크게 급증할 수 있는 일괄 처리 시나리오가 이에 해당합니다. 이러한 이벤트에 대응하여 특정 요구 사항에 따라 테이블 용량 및 `TargetValues`를 늘릴 수 있는 사용자 지정 Application Auto Scaling 로직을 개발하는 것을 고려해 보세요. " Amazon EventBridge 및 Step Functions와 같은 AWS 서비스의 조합을 통해 특정 애플리케이션 요구 사항에 대응할 수 있습니다. # 사용하지 않는 리소스를 파악하여 Amazon Keyspaces에서 비용 최적화 이 섹션에서는 미사용 리소스를 정기적으로 평가하는 방법을 간략히 살펴봅니다. 애플리케이션 요구 사항이 발전함에 따라 미사용 리소스가 없고 이로 인해 불필요한 Amazon Keyspaces 비용이 발생하지 않도록 해야 합니다. 아래 설명된 절차는 Amazon CloudWatch 지표를 사용하여 미사용 리소스를 식별하고 비용을 절감하기 위한 조치를 취합니다. Amazon Keyspaces에서 원시 데이터를 수집하여 읽기 가능하며 실시간에 가까운 지표로 처리하는 CloudWatch를 통해 Amazon Keyspaces를 모니터링할 수 있습니다. 이러한 통계는 일정 기간 동안 유지되므로 기록 정보에 액세스하여 사용률을 더 잘 파악할 수 있습니다. 기본적으로 Amazon Keyspaces 지표 데이터는 CloudWatch에 자동으로 전송됩니다. 자세한 내용은 [Amazon CloudWatch 사용 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)의 [Amazon CloudWatch란 무엇인가요?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#metrics-retention) 및 *지표 보존 기간*을 참조하세요. **Topics** + [미사용 리소스를 식별하는 방법](#CostOptimization_UnusedResources_Identifying) + [미사용 테이블 리소스 식별](#CostOptimization_UnusedResources_Tables) + [미사용 테이블 리소스 정리](#CostOptimization_UnusedResources_Tables_Cleanup) + [미사용 시점 복구(PITR) 백업 제거](#CostOptimization_UnusedResources_Backups) ## 미사용 리소스를 식별하는 방법 미사용 테이블을 식별하려면 30일 동안 다음 CloudWatch 지표를 검토하여 특정 테이블에 활성 읽기나 쓰기가 있는지 파악합니다. **`ConsumedReadCapacityUnits`** 일정 기간 동안 사용된 읽기 용량 단위의 수로, 이를 통해 사용된 용량이 얼마나 사용되었는지 추적할 수 있습니다. 테이블에 대해 소비된 총 읽기 용량을 검색할 수 있습니다. **`ConsumedWriteCapacityUnits`** 일정 기간 동안 사용된 쓰기 용량 단위의 수로, 이를 통해 사용된 용량을 얼마나 사용했는지 추적할 수 있습니다. 테이블에 대해 소비된 총 쓰기 용량을 검색할 수 있습니다. ## 미사용 테이블 리소스 식별 Amazon CloudWatch는 미사용 리소스를 식별하는 데 사용할 수 있는 Amazon Keyspaces 테이블 지표를 제공하는 모니터링 및 관찰성 서비스입니다. CloudWatch 지표는 AWS Management Console 과 AWS Command Line Interface를 통해 확인할 수 있습니다 ------ #### [ AWS Command Line Interface ] 를 통해 테이블 지표를 보려면 다음 명령을 사용할 AWS Command Line Interface수 있습니다. 1. 먼저 테이블의 읽기를 평가합니다. **참고** 테이블 이름이 계정 내에서 고유하지 않은 경우 키스페이스의 이름도 지정해야 합니다. ``` aws cloudwatch get-metric-statistics --metric-name ConsumedReadCapacityUnits --start-time --end-time --period --namespace AWS/Cassandra --statistics Sum -- dimensions Name=TableName,Value= ``` 테이블을 미사용 테이블로 잘못 식별하지 않으려면 더 오랜 기간 동안 지표를 평가하세요. 적절한 시작 시간 및 종료 시간 범위(예: **30일**)와 적절한 기간(예: **86400**)을 선택합니다. 반환된 데이터에서 **0**보다 큰 모든 **합계**는 해당 기간 동안 수신된 읽기 트래픽을 평가 중인 테이블을 나타냅니다. 다음 결과에는 평가 기간에 읽기 트래픽을 수신한 테이블이 표시됩니다. ``` { "Timestamp": "2022-08-25T19:40:00Z", "Sum": 36023355.0, "Unit": "Count" }, { "Timestamp": "2022-08-12T19:40:00Z", "Sum": 38025777.5, "Unit": "Count" }, ``` 다음 결과에는 평가 기간에 읽기 트래픽을 수신하지 않은 테이블이 표시됩니다. ``` { "Timestamp": "2022-08-01T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-20T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, ``` 1. 다음으로 테이블의 쓰기를 평가하세요. ``` aws cloudwatch get-metric-statistics --metric-name ConsumedWriteCapacityUnits --start-time --end-time --period --namespace AWS/Cassandra --statistics Sum -- dimensions Name=TableName,Value= ``` 테이블을 미사용 테이블로 잘못 식별하지 않으려면 더 오랜 기간 동안 지표를 평가하는 것이 좋습니다. 적절한 시작 시간 및 종료 시간 범위(예: **30 days(30일)**)와 적절한 기간(예: **86400**)을 선택합니다. 반환된 데이터에서 **0**보다 큰 모든 **합계**는 해당 기간 동안 수신된 읽기 트래픽을 평가 중인 테이블을 나타냅니다. 다음 결과에는 평가 기간에 쓰기 트래픽을 수신한 테이블이 표시됩니다. ``` { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 41014457.0, "Unit": "Count" }, { "Timestamp": "2022-08-18T20:15:00Z", "Sum": 40048531.0, "Unit": "Count" }, ``` 다음 결과에는 평가 기간에 쓰기 트래픽을 수신하지 않은 테이블이 표시됩니다. ``` { "Timestamp": "2022-07-31T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, ``` ------ #### [ AWS Management Console ] 다음 단계에서는 AWS Management Console을 통해 리소스 사용률을 평가할 수 있습니다. 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) CloudWatch 서비스 페이지로 이동합니다. 필요한 경우 콘솔 오른쪽 상단 AWS 리전 에서 적절한를 선택합니다. 1. 왼쪽 탐색 메뉴에서 **지표**를 선택한 다음 **모든 지표**를 선택합니다. 1. 위 작업을 수행하면 두 개의 패널이 있는 대시보드가 열립니다. 상단 패널에서는 현재 그래프로 표시된 지표를 확인할 수 있습니다. 하단에서는 그래프로 나타낼 수 있는 지표를 선택할 수 있습니다. 하단 패널에서 Amazon Keyspaces를 선택합니다. 1. Amazon Keyspaces 지표 선택 패널에서 **테이블 지표** 범주를 선택하면 현재 리전의 테이블에 해당하는 지표가 표시됩니다. 1. 메뉴를 아래로 스크롤하여 테이블 이름을 식별한 후 테이블에 해당하는 `ConsumedReadCapacityUnits` 및 `ConsumedWriteCapacityUnits` 지표를 선택합니다. 1. **그래프로 표시된 지표(2)** 탭을 선택하고 **통계** 열을 **합계**로 조정합니다. 1. 테이블을 미사용 테이블로 잘못 식별하지 않으려면 더 오랜 기간 동안 테이블 지표를 평가하세요. 그래프 패널 상단에서 테이블을 평가할 적절한 기간(예: 1개월)을 선택합니다. **사용자 지정**을 선택하고 드롭다운 메뉴에서 **1개월**을 선택한 다음 **적용**을 선택합니다. 1. 테이블의 그래프로 표시된 지표를 평가하여 사용 중인지 확인하세요. 지표가 **0**을 초과하면 평가된 기간 동안 테이블이 사용되었음을 나타냅니다. 읽기와 쓰기 모두에 대해 **0**에 있는 평면 그래프는 미사용 테이블을 나타냅니다. ------ ## 미사용 테이블 리소스 정리 미사용 테이블 리소스를 식별한 경우 다음과 같은 방법으로 지속적인 비용을 줄일 수 있습니다. **참고** 미사용 테이블을 식별했지만 나중에 액세스해야 할 경우를 대비하여 계속 사용할 수 있으려면 온디맨드 모드로 전환하는 것이 좋습니다. 그렇지 않으면 테이블을 삭제하는 방안을 고려할 수 있습니다. **용량 모드** Amazon Keyspaces는 Amazon Keyspaces 테이블의 데이터 읽기, 쓰기, 저장에 대한 요금을 청구합니다. Amazon Keyspaces에는 테이블에서 읽기 및 쓰기 처리를 위한 특정 결제를 위한 [두 가지 용량 모드](ReadWriteCapacityMode.md)가 있습니다. 읽기/쓰기 용량 모드는 읽기 및 쓰기 처리량에 대한 청구 방법과 용량 관리 방법을 제어합니다. 온디맨드 모드 테이블의 경우 애플리케이션에서 수행할 것으로 예상되는 읽기 및 쓰기 처리량을 지정할 필요가 없습니다. Amazon Keyspaces에서는 읽기 요청 단위 및 쓰기 요청 단위의 측면에서 애플리케이션이 테이블에서 수행하는 읽기 및 쓰기에 대해 요금이 부과됩니다. 테이블에 활동이 없는 경우 처리량(throughput)에 대한 비용은 지불하지 않지만 스토리지 요금은 계속 부과됩니다. **테이블 삭제** 미사용 테이블을 발견하여 삭제하려는 경우 먼저 데이터를 백업하거나 내보내는 것이 좋습니다. 를 통한 백업은 콜드 스토리지 계층화를 활용하여 비용을 더욱 절감할 AWS Backup 수 있습니다. 수명 주기를 사용하여 [백업을 콜드 스토리지로 이동하는 방법에 대한 정보는 백업 관리 계획](https://docs.aws.amazon.com/aws-backup/latest/devguide/about-backup-plans) 설명서를 참조하세요. 테이블을 백업한 후 AWS Management Console 또는 AWS Command Line Interface를 통해 테이블을 삭제할 수 있습니다. ## 미사용 시점 복구(PITR) 백업 제거 Amazon Keyspaces는 35일간 연속 백업을 제공하여 실수로 쓰거나 삭제하지 못하도록 해주는 시점 복구를 제공합니다. PITR 백업에는 비용이 발생합니다. 테이블에 더 이상 필요하지 않을 수 있는 백업이 활성화되어 있는지 확인하려면 [Amazon Keyspaces에 대한 시점 복구를 통한 데이터 백업 및 복원](PointInTimeRecovery.md)의 설명서를 참조하세요. # 테이블 사용 패턴을 평가하여 성능 및 비용 최적화 이 섹션에서는 Amazon Keyspaces 테이블을 효율적으로 사용하고 있는지 평가하는 방법을 간략히 살펴봅니다. Amazon Keyspaces에 최적화되지 않은 특정 사용 패턴이 있으며, 이러한 패턴은 성능 및 비용 측면에서 모두 최적화될 수 있는 여지가 있습니다. **Topics** + [강력히 일관된 읽기 작업 줄이기](#CostOptimization_TableUsagePatterns_StronglyConsistentReads) + [Time to Live(TTL) 활성화](#CostOptimization_TableUsagePatterns_TTL) ## 강력히 일관된 읽기 작업 줄이기 Amazon Keyspaces를 사용하면 요청별로 [읽기 일관성](consistency.md#ReadConsistency)을 구성할 수 있습니다. 기본적으로 읽기 요청은 최종적으로 일관됩니다. 최종 읽기 일관성은 최대 4KB의 데이터에 대해 0.5RCU의 요금이 부과됩니다. 분산 워크로드의 대부분은 유연하며 최종 일관성을 허용합니다. 하지만 강력히 일관된 읽기가 필요한 액세스 패턴이 있을 수 있습니다. 강력히 일관된 읽기는 최대 4KB의 데이터에 대해 1RCU의 요금이 부과되므로 읽기 비용이 두 배로 늘어납니다. Amazon Keyspaces는 동일한 테이블에서 두 정합성 모델을 모두 사용할 수 있는 유연성을 제공합니다. 워크로드와 애플리케이션 코드를 평가하여 강력히 일관된 읽기가 필요한 경우에만 사용되는지 확인할 수 있습니다. ## Time to Live(TTL) 활성화 [Time to Live(TTL)](TTL.md)를 통해 테이블의 데이터를 자동으로 만료시켜 애플리케이션 로직을 간소화하고 스토리지 가격을 최적화할 수 있습니다. 더 이상 필요하지 않은 데이터는 설정한 TTL 값에 따라 테이블에서 자동으로 삭제됩니다. # 적절한 규모의 프로비저닝을 위해 프로비저닝된 용량 평가 이 섹션에서는 Amazon Keyspaces 테이블에 적절한 규모의 프로비저닝이 있는지 평가하는 방법을 간략히 살펴봅니다. 워크로드가 발전함에 따라 운영 절차를 적절하게 수정해야 합니다. 특히 Amazon Keyspaces 테이블이 프로비저닝 모드로 구성되어 있고 테이블을 과다 프로비저닝하거나 과소 프로비저닝할 위험이 있는 경우에는 더욱 그렇습니다. 이 섹션에 설명된 절차에는 프로덕션 애플리케이션을 지원하는 Amazon Keyspaces 테이블에서 캡처해야 하는 통계 정보가 필요합니다. 애플리케이션 동작을 이해하려면 애플리케이션의 데이터 계절성을 포착할 수 있을 만큼 충분히 중요한 기간을 정의해야 합니다. 예를 들어 애플리케이션이 주간 패턴을 보이는 경우 3주 기간을 사용하면 애플리케이션 처리량 요구 사항을 분석할 시간을 충분히 확보할 수 있습니다. 어디서부터 시작해야 할지 모르겠다면 아래 계산에 최소 한 달 분량의 데이터 사용량을 사용해 보세요. 용량을 평가하는 동안 Amazon Keyspaces 테이블에 **읽기 용량 단위(RCU)**와 **쓰기 용량 단위(WCU)**를 별개로 구성할 수 있습니다. **Topics** + [Amazon Keyspaces 테이블에서 소비 지표를 검색하는 방법](#CostOptimization_RightSizedProvisioning_ConsumptionMetrics) + [과소 프로비저닝된 Amazon Keyspaces 테이블을 식별하는 방법](#CostOptimization_RightSizedProvisioning_UnderProvisionedTables) + [과다 프로비저닝된 Amazon Keyspaces 테이블을 식별하는 방법](#CostOptimization_RightSizedProvisioning_OverProvisionedTables) ## Amazon Keyspaces 테이블에서 소비 지표를 검색하는 방법 테이블 용량을 평가하려면 다음 CloudWatch 지표를 모니터링하고 적절한 차원을 선택하여 테이블 정보를 검색하세요. | 읽기 용량 단위 | 쓰기 용량 단위 | | --- | --- | | `ConsumedReadCapacityUnits` | `ConsumedWriteCapacityUnits` | | `ProvisionedReadCapacityUnits` | `ProvisionedWriteCapacityUnits` | | `ReadThrottleEvents` | `WriteThrottleEvents` | AWS CLI 또는를 통해이 작업을 수행할 수 있습니다 AWS Management Console. ------ #### [ AWS CLI ] 테이블 소비 지표를 검색하기 전에 먼저 CloudWatch API를 사용하여 일부 과거 데이터 포인트를 캡처해야 합니다. 먼저 두 개의 파일(`write-calc.json` 및 `read-calc.json`)을 만듭니다. 이러한 파일은 테이블에 대한 계산을 나타냅니다. 아래 표에 표시된 대로 일부 필드를 환경에 맞게 업데이트해야 합니다. **참고** 테이블 이름이 계정 내에서 고유하지 않은 경우 키스페이스의 이름도 지정해야 합니다. | 필드 이름 | 정의 | 예제 | | --- | --- | --- | | | 분석하려는 테이블 이름 | SampleTable | | | 사용률 목표를 평가하는 데 사용하는 기간(초 단위) | 1시간인 경우 3,600 지정 | | | 평가 간격의 시작 부분으로, ISO8601 형식으로 지정 | 2022-02-21T23:00:00 | | | 평가 간격의 끝부분으로, ISO8601 형식으로 지정 | 2022-02-22T06:00:00 | 쓰기 계산 파일은 지정된 날짜 범위에 해당하는 기간 동안 프로비저닝되고 소비된 WCU 수를 검색합니다. 또한 분석에 사용할 수 있는 사용률도 생성합니다. `write-calc.json` 파일의 전체 내용은 다음 예제와 같은 형식으로 보입니다. ``` { "MetricDataQueries": [ { "Id": "provisionedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ProvisionedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ConsumedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": """ } ] }, "Period": , "Stat": "Sum" }, "Label": "", "ReturnData": false }, { "Id": "m1", "Expression": "consumedWCU/PERIOD(consumedWCU)", "Label": "Consumed WCUs", "ReturnData": false }, { "Id": "utilizationPercentage", "Expression": "100*(m1/provisionedWCU)", "Label": "Utilization Percentage", "ReturnData": true } ], "StartTime": "", "EndTime": "", "ScanBy": "TimestampDescending", "MaxDatapoints": 24 } ``` 읽기 계산 파일은 비슷한 지표를 사용합니다. 이 파일은 지정된 날짜 범위에 해당하는 기간 동안 프로비저닝되고 소비된 RCU 수를 검색합니다. `read-calc.json` 파일의 콘텐츠는 다음 예제와 같아야 합니다. ``` { "MetricDataQueries": [ { "Id": "provisionedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ProvisionedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ConsumedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Sum" }, "Label": "", "ReturnData": false }, { "Id": "m1", "Expression": "consumedRCU/PERIOD(consumedRCU)", "Label": "Consumed RCUs", "ReturnData": false }, { "Id": "utilizationPercentage", "Expression": "100*(m1/provisionedRCU)", "Label": "Utilization Percentage", "ReturnData": true } ], "StartTime": "", "EndTime": "", "ScanBy": "TimestampDescending", "MaxDatapoints": 24 } ``` 파일을 만들었으면 사용률 데이터 검색을 시작할 수 있습니다. 1. 쓰기 사용률 데이터를 검색하려면 다음 명령을 실행합니다. ``` aws cloudwatch get-metric-data --cli-input-json file://write-calc.json ``` 1. 읽기 사용률 데이터를 검색하려면 다음 명령을 실행합니다. ``` aws cloudwatch get-metric-data --cli-input-json file://read-calc.json ``` 두 쿼리의 결과는 분석에 사용할 수 있는 일련의 JSON 형식 데이터 포인트입니다. 결과는 지정한 데이터 포인트 수, 기간 및 고유한 워크로드 데이터에 따라 달라집니다. 다음 예제와 같을 수 있습니다. ``` { "MetricDataResults": [ { "Id": "utilizationPercentage", "Label": "Utilization Percentage", "Timestamps": [ "2022-02-22T05:00:00+00:00", "2022-02-22T04:00:00+00:00", "2022-02-22T03:00:00+00:00", "2022-02-22T02:00:00+00:00", "2022-02-22T01:00:00+00:00", "2022-02-22T00:00:00+00:00", "2022-02-21T23:00:00+00:00" ], "Values": [ 91.55364583333333, 55.066631944444445, 2.6114930555555556, 24.9496875, 40.94725694444445, 25.61819444444444, 0.0 ], "StatusCode": "Complete" } ], "Messages": [] } ``` **참고** 짧은 기간과 긴 시간 범위를 지정하는 경우 스크립트에서 기본값인 24로 설정되어 있는 `MaxDatapoints` 값을 수정해야 할 수 있습니다. 이는 시간당 하나의 데이터 포인트, 하루에 24개의 데이터 포인트를 나타냅니다. ------ #### [ AWS Management Console ] 1. 에 로그인 AWS Management Console 하고 [시작하기 AWS Management Console](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html)의 CloudWatch 서비스 페이지로 이동합니다. 필요한 AWS 리전 경우 적절한를 선택합니다. 1. 왼쪽 탐색 메뉴에서 지표 섹션을 찾은 다음 **모든 지표**를 선택합니다. 1. 그러면 두 개의 패널이 있는 대시보드가 열립니다. 상단 패널에는 그래프가 표시되고 하단 패널에는 그래프로 표시하려는 지표가 표시됩니다. Amazon Keyspaces 패널을 선택합니다. 1. 하위 패널에서 **테이블 지표** 범주를 선택합니다. 현재의 테이블을 보여줍니다 AWS 리전. 1. 메뉴를 아래로 스크롤하고 쓰기 작업 지표(`ConsumedWriteCapacityUnits` 및 `ProvisionedWriteCapacityUnits`)를 선택하여 테이블 이름을 식별합니다. **참고** 이 예제에서는 쓰기 작업 지표에 대해 설명하지만 다음 단계를 사용하여 읽기 작업 지표를 그래프로 표시할 수도 있습니다. 1. **Graphed metrics (2)**(그래프로 표시된 지표(2)) 탭을 선택하여 수식을 수정합니다. 기본적으로 CloudWatch는 그래프에 통계 함수 **Average**를 선택합니다. 1. 그래프로 표시된 지표 두 개를 모두 선택한 상태에서(왼쪽의 확인란) **Add math**(수식 추가), **Common**(공통) 메뉴를 차례로 선택한 다음 **Percentage** 함수를 선택합니다. 절차를 두 번 반복합니다. 처음으로 **Percentage** 함수를 선택할 때. 두 번째로 **Percentage** 함수를 선택할 때. 1. 이제 하단 메뉴에 네 개의 지표가 있어야 합니다. `ConsumedWriteCapacityUnits` 계산 작업을 해봅시다. 일관성을 유지하려면 AWS CLI 이름을 섹션에서 사용한 이름과 일치해야 합니다. **m1 ID**를 클릭하고 이 값을 **ConsumedWCU**로 변경합니다. 1. 통계를 **Average**에서 **Sum**으로 변경합니다. 이 작업을 수행하면 **ANOMALY\$1DETECTION\$1BAND**라는 또 다른 지표가 자동으로 생성됩니다. 이 절차의 범위에서는 새로 생성된 **ad1 지표**에서 확인란을 선택 취소하여 이 절차를 무시해도 됩니다. 1. 8단계를 반복하여 **m2 ID**의 이름을 **provisionedWCU**로 변경합니다. 통계는 **Average**로 설정된 상태로 둡니다. 1. **Expression1** 레이블을 선택하고 값을 **m1**로 업데이트한 다음 레이블을 **Consumed WCUs**로 업데이트합니다. **참고** 데이터를 제대로 시각화하려면 **m1**(왼쪽의 확인란) 및 **provisionedWCU**만 선택했는지 확인하세요. **Details**(세부 정보)를 클릭하고 수식을 **consumedWCU/PERIOD(consumedWCU)**로 변경하여 수식을 업데이트합니다. 이 단계는 또 다른 **ANOMALY\$1DETECTION\$1BAND** 지표를 생성할 수도 있지만 이 절차의 범위에서는 무시해도 됩니다. 1. 이제 두 개의 그래픽이 생겼을 것입니다. 하나는 테이블의 프로비저닝된 WCU를 나타내고 다른 하나는 소비된 WCU를 나타냅니다. 1. Expression2 그래픽(**e2**)을 선택하여 백분율 수식을 업데이트합니다. 레이블 및 ID의 이름을 **utilizationPercentage**로 변경합니다. 수식의 이름을 **100\$1(m1/provisionedWCU)**와 일치하도록 변경합니다. 1. 사용률 패턴을 시각화하려면 **utilizationPercentage**를 제외한 모든 지표에서 확인란을 선택 취소하세요. 기본 간격은 1분으로 설정되어 있지만 필요에 따라 자유롭게 수정할 수 있습니다. 결과는 워크로드의 실제 데이터에 따라 달라집니다. 간격의 사용률이 100%를 초과하는 경우 처리량 용량 부족 오류 이벤트가 발생하기 쉽습니다. Amazon Keyspaces는 [버스트 용량](throughput-bursting.md)을 제공하지만 버스트 용량이 소진되는 즉시 100%를 초과하는 용량에 처리량 용량 부족 오류 이벤트가 발생합니다. ------ ## 과소 프로비저닝된 Amazon Keyspaces 테이블을 식별하는 방법 대부분의 워크로드에서 테이블은 프로비저닝된 용량의 80%를 초과하여 지속적으로 소비하는 경우 과소 프로비저닝된 것으로 간주됩니다. [버스트 용량](throughput-bursting.md)은 고객이 원래 프로비저닝된 것보다 더 많은(테이블에 정의된 초당 프로비저닝된 처리량보다 많은) RCU/WCU를 일시적으로 소비할 수 있도록 하는 Amazon Keyspaces 기능입니다. 버스트 용량은 특수 이벤트 또는 사용량 급증으로 인한 갑작스러운 트래픽 증가를 흡수하기 위해 만들어졌습니다. 이 버스트 용량 제한에 대한 자세한 내용은 [Amazon Keyspaces에서 버스트 용량을 효과적으로 사용하기](throughput-bursting.md)을(를) 참조하세요. 사용되지 않은 RCU와 WCU가 소진되었을 때 프로비저닝된 용량보다 더 많은 용량을 소비하려고 하면 용량 처리량 부족 오류 이벤트가 발생합니다. 애플리케이션 트래픽이 80% 사용률에 가까워지면 용량 처리량 부족 오류 이벤트의 위험이 훨씬 높아집니다. 80% 사용률 규칙은 데이터의 계절성 및 트래픽 증가에 따라 달라집니다. 다음 시나리오를 고려해 보세요. + 지난 12개월 동안 트래픽이 약 90%의 사용률로 **안정적**이었다면 테이블의 용량이 적절한 것입니다. + 애플리케이션 트래픽이 3개월 이내에 매월 8%씩 **증가**하면 100%에 도달하게 됩니다. + 애플리케이션 트래픽이 4개월이 조금 넘는 기간 이내에 5%씩 **증가**해도 100%에 도달하게 됩니다. 위 쿼리의 결과는 사용률을 보여줍니다. 이를 참고하여 필요에 따라 테이블 용량을 늘리도록 선택하는 데 도움이 될 수 있는 다른 지표(예: 월별 또는 주별 증가율)를 추가로 평가해 보세요. 운영 팀과 협력하여 워크로드와 테이블에 적합한 비율을 정하세요. 일별 또는 주별로 데이터를 분석할 때 데이터가 왜곡되는 특수한 시나리오가 있습니다. 예를 들어 근무 시간 동안 사용량이 급증하다가 근무 시간 외에는 거의 0으로 떨어지는 계절성 애플리케이션의 경우, 프로비저닝된 용량을 늘리거나 줄일 하루 중 시간(및 요일)을 지정하는 [Application Auto Scaling을 예약](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html)하면 효과를 볼 수 있습니다. 바쁜 시간을 처리하기 위해 더 높은 용량을 목표로 하는 대신 계절성이 덜 두드러지는 경우 [Amazon Keyspaces 테이블 Auto Scaling](autoscaling.md) 구성을 활용할 수도 있습니다. ## 과다 프로비저닝된 Amazon Keyspaces 테이블을 식별하는 방법 위 스크립트에서 얻은 쿼리 결과는 일부 초기 분석을 수행하는 데 필요한 데이터 포인트를 제공합니다. 데이터 세트의 여러 간격에 사용률이 20% 미만인 값이 표시되면 테이블이 과다 프로비저닝된 것일 수 있습니다. WCU 및 RCU 수를 줄여야 하는지 여부를 더 자세히 정의하려면 해당 간격의 다른 측정값을 다시 살펴봐야 합니다. 테이블에 낮은 사용 간격이 여러 개 있는 경우 Application Auto Scaling을 예약하거나 사용률을 기반으로 테이블에 대한 기본 Application Auto Scaling 정책을 구성하여 Application Auto Scaling 정책을 사용하면 이점을 얻을 수 있습니다. 워크로드에 사용률이 낮고 제한은 높은 비율(간격의 **Max(ThrottleEvents)/Min(ThrottleEvents)**)이 있는 경우 며칠(또는 몇 시간) 동안 트래픽이 많이 증가하지만 그렇지 않은 경우에 트래픽이 지속적으로 낮은 변동이 심한 워크로드일 때 이런 일이 발생할 수 있습니다. 이러한 시나리오에서는 [예약된 Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html)을 사용하는 것이 유용할 수 있습니다.