DynamoDB Auto Scaling을 사용하여 자동으로 처리량 용량 관리

많은 데이터베이스 워크로드는 본질적으로 주기적인 반면 다른 워크로드는 미리 예측하기 어렵습니다. 낮 시간 동안에는 대부분의 사용자가 활성 상태인 소셜 네트워킹 앱을 한 가지 예로 들어 보겠습니다. 이러한 데이터베이스에서는 주간 활동을 처리할 수 있어야 하지만, 밤에는 동일한 수준의 처리량이 필요 없습니다. 예상치 못한 빠른 속도로 도입 중인 새로운 모바일 게임 앱을 또 다른 예로 들 수 있습니다. 이 게임의 인기가 너무 높아지면 사용 가능한 데이터베이스 리소스 양을 초과하여 성능이 느려지고 고객 불만이 발생할 것입니다. 이러한 종류의 워크로드는 대개 사용량 변화에 따라 수동 개입을 통해 데이터베이스 리소스의 규모를 늘리거나 줄여야 합니다.

Amazon DynamoDB Auto Scaling은 AWS Application Auto Scaling 서비스를 사용하여 프로비저닝된 처리 능력을 실제 트래픽 패턴에 따라 사용자 대신 동적으로 조정합니다. 따라서 테이블 또는 글로벌 보조 인덱스(GSI)에 따라 할당된 읽기 및 쓰기 용량을 늘려 제한 없이 갑작스러운 트래픽 증가를 처리할 수 있습니다. 워크로드가 감소할 경우 Application Auto Scaling은 사용하지 않는 프로비저닝된 용량에 대한 요금을 지불하지 않도록 처리량을 줄일 수 있습니다.

Application Auto Scaling을 사용하여 테이블 또는 글로벌 보조 인덱스의 크기 조정 정책을 생성합니다. 이 규모 조정 정책을 통해 읽기 용량이나 쓰기 용량(또는 둘 다)을 조정할 것인지 여부와 테이블 또는 인덱스에 대해 할당된 용량 단위의 최댓값 및 최솟값 설정을 지정할 수 있습니다.

크기 조정 정책에는 특정 시점에 소비된 프로비저닝된 처리량의 비율인 목표 사용률도 포함됩니다. Application Auto Scaling은 목표 추적 알고리즘을 사용하여 실제 워크로드에 따라 테이블(또는 인덱스)의 프로비저닝된 처리량을 위나 아내로 조정하여 실제 용량 사용률이 목표 사용률 값이나 그에 가까운 수준으로 유지되도록 합니다.

DynamoDB 출력은 1분 동안 프로비저닝된 처리량을 소비했습니다. Auto Scaling은 소비된 용량이 구성된 목표 사용률을 2분 연속으로 초과할 때 트리거됩니다. CloudWatch 경보가 Auto Scaling을 트리거하기 전에 최대 몇 분의 짧은 지연이 있을 수 있습니다. 이러한 지연을 통해 정확한 CloudWatch 지표 평가가 이루어집니다. 하지만 소비된 처리량의 급증 간격이 1분보다 크면 Auto Scaling이 트리거되지 않을 수 있습니다. 마찬가지로 15개의 연속 데이터 포인트가 목표 사용률보다 낮을 때 스케일 다운 이벤트가 발생할 수 있습니다. 두 경우 모두 Auto Scaling이 트리거된 후 UpdateTable가 간접적으로 호출됩니다. 그런 다음 테이블 또는 인덱스의 프로비저닝된 용량을 업데이트하는 데 몇 분 정도 걸립니다. 이 기간 동안 테이블의 이전 프로비저닝된 용량을 초과하는 모든 요청은 제한됩니다.

읽기 및 쓰기 용량에 대해 20%와 90% 사이에서 Auto Scaling 목표 사용률 값을 설정할 수 있습니다.

DynamoDB Auto Scaling 작동 방식

아래 그림에는 DynamoDB Auto Scaling이 테이블의 처리 용량을 관리하는 방법이 간단히 소개되어 있습니다.

다음은 앞의 그림에 소개된 Auto Scaling 프로세스를 요약한 단계입니다.

DynamoDB Auto Scaling의 작동 방식을 알아보기 위해 ProductCatalog라는 테이블이 있다고 가정합니다. 이 테이블에는 부정기적으로 데이터가 대량 로드되며, 따라서 쓰기 활동이 많지는 않습니다. 그러나 읽기 활동은 높은 수준으로 이루어지며 그 양은 시간에 따라 달라집니다. ProductCatalog에 대한 Amazon CloudWatch 지표를 모니터링함으로써 이 테이블에 읽기 용량 단위 1,200개가 필요하다는 사실을 알 수 있습니다(활동이 최대 수준일 때 DynamoDB에서 읽기 요청을 제한하지 않아도 되는 정도). 이와 함께 ProductCatalog에는 읽기 트래픽이 최소 수준일 때 읽기 용량 단위가 최소한 150개 필요하다고 판단됩니다. 제한 방지에 대한 자세한 내용은 DynamoDB의 제한 문제 섹션을 참조하세요.

그러므로 읽기 용량 단위 150개 ~ 1,200개 범위에서 목표 사용률 70%면 ProductCatalog 테이블에 적당하다고 결정합니다. 목표 사용률이란 프로비저닝된 용량 단위에 대한 소비된 용량 단위의 비율을 백분율로 나타낸 값입니다. Application Auto Scaling은 목표 추적 알고리즘을 사용하여 ProductCatalog의 프로비저닝된 읽기 용량을 필요에 따라 조절함으로써 사용률이 70% 안팎으로 유지되도록 합니다.

ProductCatalog 테이블에 대해 DynamoDB Auto Scaling을 활성화하기 위해 크기 조정 정책을 만듭니다. 이 정책은 다음을 지정합니다.

크기 조정 정책이 생성되면 Application Auto Scaling은 사용자 대신 Amazon CloudWatch 경보 쌍을 생성합니다. 각 쌍은 할당된 처리량(throughput) 설정의 상한값과 하한값을 나타냅니다. 테이블의 실제 사용률이 일정한 시간 동안 목표 사용률을 벗어나면 이러한 CloudWatch 경보가 트리거됩니다.

CloudWatch 경보 중 하나가 트리거되면 Amazon SNS에서 알림을 보냅니다(알림을 활성화한 경우). 그러면 CloudWatch 경보가 Application Auto Scaling을 호출하고, 여기서 다시 DynamoDB에 알려 ProductCatalog 테이블의 프로비저닝된 용량을 적절히 상향 또는 하향 조정하도록 합니다.

규모 조정 이벤트 중에 AWS Config에는 기록된 구성 항목당 요금이 부과됩니다. 규모 조정 이벤트가 발생하면 각 읽기 및 쓰기 Auto Scaling 이벤트에 대해 4개의 CloudWatch 경보가 생성됩니다. 즉, ProvisionedCapacity 경보인 ProvisionedCapacityLow, ProvisionedCapacityHigh와 ConsumedCapacity 경보인 AlarmHigh, AlarmLow입니다. 그 결과 총 8개의 경보가 발생합니다. 따라서 AWS Config는 모든 규모 조정 이벤트에 대해 8개의 구성 항목을 기록합니다.

사용 노트

DynamoDB Auto Scaling을 사용하려면 먼저 다음 내용을 이해해야 합니다.