DynamoDB 테이블의 오토 스케일링 설정 평가
이 섹션에서는 DynamoDB 테이블의 Auto Scaling 설정을 평가하는 방법을 간략히 살펴봅니다. Amazon DynamoDB Auto Scaling은 애플리케이션 트래픽과 대상 사용률 지표를 기반으로 테이블 및 글로벌 보조 인덱스(GSI) 처리량을 관리하는 기능입니다. 이렇게 하면 테이블 또는 GSI가 애플리케이션 패턴에 필요한 용량을 확보할 수 있습니다.
AWS Auto Scaling 서비스는 현재 테이블 사용률을 모니터링하고 이를 목표 사용률 값(TargetValue
)과 비교합니다. 할당된 용량을 늘리거나 줄여야 할 시기가 되면 알려 줍니다.
주제
Auto Scaling 설정 이해하기
목표 사용률, 초기 단계 및 최종 값에 대한 올바른 값을 정의하려면 운영 팀의 참여가 필요합니다. 이렇게 하면 AWS Auto Scaling 정책을 트리거하는 데 사용될 값을 과거 애플리케이션 사용량을 기반으로 적절하게 정의할 수 있습니다. 사용률 목표는 Auto Scaling 규칙이 적용되기 전에 일정 기간 동안 도달해야 하는 총 용량의 백분율입니다.
높은 사용률 목표(약 90%의 목표)를 설정하면 Auto Scaling이 시작되기 전에 일정 기간 동안 트래픽이 90%보다 높아야 합니다. 애플리케이션이 매우 일정하고 트래픽 급증이 발생하지 않는 한 높은 사용률 목표를 사용해서는 안 됩니다.
매우 낮은 사용률(50% 미만의 목표)을 설정하면 애플리케이션이 Auto Scaling 정책을 실행하기 전에 프로비저닝된 용량의 50%에 도달해야 합니다. 애플리케이션 트래픽이 매우 빠른 속도로 증가하지 않는 한 이는 대개 용량 미사용 및 리소스 낭비로 이어집니다.
목표 사용률이 낮은(<= 50%) 테이블을 식별하는 방법
AWS CLI 또는 AWS Management Console을 사용하여 DynamoDB 리소스의 Auto Scaling 정책에 대한 TargetValues
를 모니터링하고 식별할 수 있습니다.
목표 사용률 값이 50% 이하이면 테이블 사용률 지표를 살펴보고 해당 지표가 과소 프로비저닝되었는지 과다 프로비저닝되었는지 확인해야 합니다.
계절적 변동이 있는 워크로드를 해결하는 방법
다음과 같은 시나리오를 생각해 보세요. 대부분의 경우 애플리케이션이 최소 평균값 미만으로 작동하지만 사용률 목표가 낮기 때문에 애플리케이션이 하루 중 특정 시간에 발생하는 이벤트에 신속하게 반응할 수 있고 충분한 용량이 확보되어 제한을 피할 수 있습니다. 이 시나리오는 일반적인 업무 시간(오전 9시~오후 5시)에는 사용량이 아주 많지만 업무 시간 이후에는 기본 수준에서 작동하는 애플리케이션이 있는 경우에 일반적입니다. 일부 사용자는 오전 9시 이전에 연결을 시작하므로 애플리케이션은 이 낮은 임계값을 사용하여 사용량이 많은 시간대에 필요한 용량에 빠르게 도달합니다.
이 시나리오는 다음과 같이 진행될 수 있습니다.
-
오후 5시에서 오전 9시 사이에는
ConsumedWriteCapacity
단위가 90에서 100 사이로 유지됩니다. -
사용자가 오전 9시 이전에 애플리케이션에 연결하기 시작하면 용량 단위가 크게 늘어납니다(지금까지 본 최대값은 1,500WCU).
-
평균적인 애플리케이션 사용량은 근무 시간 동안 800에서 1,200 사이로 다양합니다.
이전 시나리오에 해당하는 경우 예약된 Auto Scaling을 사용하는 것을 고려해 보세요. 예약된 Auto Scaling에서는 테이블에 애플리케이션 Auto Scaling 규칙을 구성하면서도 필요한 특정 간격으로만 추가 용량을 프로비저닝하는 덜 적극적인 대상 사용률을 적용할 수 있습니다.
AWS CLI를 통해 다음 단계를 실행하여 시간과 요일을 기준으로 실행되는 예약된 Auto Scaling 규칙을 생성할 수 있습니다.
-
Application Auto Scaling을 사용하여 DynamoDB 테이블 또는 GSI를 확장 가능한 목표로 등록하세요. 확장 가능한 목표란 Application Auto Scaling이 스케일 아웃 또는 스케일 인할 수 있는 리소스입니다.
aws application-autoscaling register-scalable-target \ --service-namespace dynamodb \ --scalable-dimension dynamodb:table:WriteCapacityUnits \ --resource-id table/<table-name> \ --min-capacity 90 \ --max-capacity 1500
-
요구 사항에 따라 예약된 작업 설정
시나리오를 다루려면 두 가지 규칙이 필요합니다. 하나는 스케일 업 규칙이고 다른 하나는 스케일 다운 규칙입니다. 예약된 작업을 스케일 업하기 위한 첫 번째 규칙:
aws application-autoscaling put-scheduled-action \ --service-namespace dynamodb \ --scalable-dimension dynamodb:table:WriteCapacityUnits \ --resource-id 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 dynamodb \ --scalable-dimension dynamodb:table:WriteCapacityUnits \ --resource-id 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"
-
다음 명령을 실행하여 두 규칙이 모두 활성화되었는지 확인합니다.
aws application-autoscaling describe-scheduled-actions --service-namespace dynamodb
다음과 같은 결과가 나와야 합니다.
{ "ScheduledActions": [ { "ScheduledActionName": "my-5-8-scheduled-down-action", "ScheduledActionARN": "arn:aws:autoscaling:<region>:<account>:scheduledAction:<uuid>:resource/dynamodb/table/<table-name>:scheduledActionName/my-5-8-scheduled-down-action", "ServiceNamespace": "dynamodb", "Schedule": "cron(15 17 ? * MON-FRI *)", "Timezone": "Australia/Brisbane", "ResourceId": "table/<table-name>", "ScalableDimension": "dynamodb: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:<region>:<account>:scheduledAction:<uuid>:resource/dynamodb/table/<table-name>:scheduledActionName/my-8-5-scheduled-action", "ServiceNamespace": "dynamodb", "Schedule": "cron(45 8 ? * MON-FRI *)", "Timezone": "Australia/Brisbane", "ResourceId": "table/<table-name>", "ScalableDimension": "dynamodb:table:WriteCapacityUnits", "ScalableTargetAction": { "MinCapacity": 800, "MaxCapacity": 1500 }, "CreationTime": "2022-03-15T17:28:57.816000+10:00" } ] }
다음 그림은 항상 70% 목표 사용률을 유지하는 샘플 워크로드를 보여 줍니다. Auto Scaling 규칙이 여전히 적용되고 있으며 처리량은 감소하지 않는다는 점에 유의하세요.
자세히 보면 애플리케이션에 급증이 발생하여 70% 오토 스케일링 임곗값이 트리거되고, 오토 스케일링이 강제로 시작되어 테이블에 필요한 추가 용량을 제공하는 것을 볼 수 있습니다. 예약된 Auto Scaling 작업은 최대값과 최소값에 영향을 미치며 이를 설정하는 것은 사용자의 책임입니다.
알 수 없는 패턴으로 급증하는 워크로드를 해결하는 방법
이 시나리오에서는 애플리케이션 패턴을 아직 모르고 워크로드에 제한이 발생하지 않도록 하기 위해 애플리케이션이 매우 낮은 사용률 목표를 사용합니다.
대신 온디맨드 용량 모드를 사용하는 것을 고려해 봅니다. 온디맨드 테이블은 트래픽 패턴을 모르는 급증하는 워크로드에 적합합니다. 온디맨드 용량 모드를 사용하면 애플리케이션이 테이블에서 수행하는 데이터 읽기 및 쓰기에 대해 요청당 요금을 지불합니다. DynamoDB는 늘어나거나 줄어드는 워크로드를 즉시 수용하기 때문에 애플리케이션에서 수행할 것으로 예상되는 읽기 및 쓰기 처리량을 지정할 필요가 없습니다.
연결된 애플리케이션으로 워크로드를 해결하는 방법
이 시나리오에서 애플리케이션은 다른 시스템에 의존합니다. 예를 들어 애플리케이션 로직의 이벤트에 따라 트래픽이 크게 급증할 수 있는 일괄 처리 시나리오가 이에 해당합니다.
이러한 이벤트에 대응하여 특정 요구 사항에 따라 테이블 용량 및 TargetValues
를 늘릴 수 있는 사용자 지정 Auto Scaling 로직을 개발하는 것을 고려해 보세요. Amazon EventBridge를 활용하고 Lambda 및 Step Functions와 같은 AWS 서비스의 조합을 사용하여 특정 애플리케이션 요구 사항에 대응할 수 있습니다.