Parameter Store 처리량 관리
Parameter Store 처리량은 Systems Manager가 처리할 수 있는 초당 API 트랜잭션 수(TPS)를 정의합니다. 처리량 설정은 개별 API가 아닌 Parameter Store에 전체로 적용됩니다. 기본적으로 Parameter Store는 적은 용량 또는 중간 용량의 워크로드에 적합한 표준 처리량 할당량으로 구성됩니다. 대용량 워크로드의 경우 더 높은 처리량을 활성화할 수 있습니다. 그러면 사용자 계정 및 리전에 대해 초당 지원되는 최대 트랜잭션 수가 증가합니다. 필요에 따라 더 높은 처리량을 활성화하거나 비활성화할 수 있습니다.
Parameter Store의 처리량 할당량
다음 표에는 기본 처리량과 더 높은 처리량을 사용하는 여러 API 카테고리의 트랜잭션 한도가 나와 있습니다. API 작업에는 AWS 콘솔 사용, AWS CLI 명령 및 애플리케이션 읽기가 포함됩니다. 할당량 및 속도 제한에 대한 자세한 내용은 AWS Systems Manager 엔드포인트 및 할당량을 참조하세요.
| API 작업 | 기본 처리량 | 처리량이 향상됨 |
|---|---|---|
| GetParameter, GetParameters 및 GetParametersByPath | 결합된 세 API 작업 모두에서 공유되는 40 TPS |
GetParameter: 10,000 TPS, GetParameters: 1,000 TPS, GetParametersByPath: 100 TPS |
| DeleteParameter 및 DeleteParameters | 3 TPS |
5 TPS |
| DescribeParameters, GetParameterHistory, LabelParameterVersion, UnlabelParameterVersion 및 PutParameter | 3 TPS |
10 TPS |
이 컨텍스트에서 트랜잭션은 단일 리전에서 계정에 대한 하나의 API 작업입니다. 예를 들어 다음 명령은 단일 트랜잭션을 생성합니다.
aws ssm get-parameter --name "/myapp/prod/log-level"
API 작업은 여러 애플리케이션에 분산될 수 있습니다. 예를 들어 다음의 각 시나리오에서는 기본 처리량 한도인 40TPS에 도달합니다.
-
1개의 애플리케이션이
GetParameter를 초당 40회 직접 호출합니다. -
10개의 애플리케이션이
GetParameter를 초당 4회 직접 호출합니다. -
40개의 애플리케이션이
GetParameter를 초당 1회 직접 호출합니다.
처리량 한도는 카테고리 내 모든 API에 적용됩니다. 예를 들어 애플리케이션에 대해 다음과 같은 동시 파라미터 직접 호출 조합은 파라미터 검색 API의 기본 한도인 40TPS를 충족합니다.
-
GetParameter는 초당 25회 직접 호출됩니다. -
GetParameters는 초당 10회 직접 호출됩니다. -
GetParameterByPath는 초당 5회 직접 호출됩니다.
DescribeParameters 직접 호출에는 별도의 처리량 한도가 적용됩니다. 애플리케이션은 표준 처리량의 전체 한도를 초과하지 않고도 초당 3회의 DescribeParameters 직접 호출을 수행하면서 이전의 직접 호출을 수행할 수 있습니다.
프로덕션 요청이 표준 작업 중 또는 트래픽이 많은 계획된 기간에 처리량 한도를 초과하는 경우 다음과 같은 최적화 기술을 사용합니다.
Parameter Store에서 처리량 최적화
Parameter Store가 짧은 간격으로 파라미터에 대한 여러 요청을 수신하면 애플리케이션에 스로틀링이 발생할 수 있습니다. 예를 들어 CloudWatch Logs 또는 애플리케이션 로그에 GetParameter, GetParameters 또는 GetParametersByPath를 직접 호출할 때 SDK에서 발생한 ThrottlingException 또는 RateExceeded 오류가 표시됩니다. 경우에 따라 애플리케이션 로직이 API 직접 호출을 성공적으로 재시도하지만 애플리케이션 지연 시간이 증가합니다. 그 결과 애플리케이션 중단, 최적화되지 않은 사용자 환경, 배포 실패, 복잡한 해결 방법, 개발자 시간 손실과 같은 문제가 발생할 수 있습니다.
다음을 비롯한 여러 요인으로 인해 애플리케이션에서 Parameter Store의 할당량 한도에 도달할 수 있습니다.
-
트래픽 급증으로 인해 애플리케이션이 빠르게 스케일 아웃됩니다. 예를 들어 애플리케이션이 일반적으로 5개의 Amazon EC2 인스턴스에서 실행됩니다. 트래픽이 갑자기 증가하면 Amazon EC2 Auto Scaling은 50개의 인스턴스를 더 시작합니다. 각 인스턴스가 시작할 때 파라미터를 읽는 경우 결합된 요청은 기본 요청 제한을 초과할 수 있습니다.
-
컨테이너 서비스가 동시에 많은 태스크를 시작합니다. 예를 들어 Amazon ECS 서비스는 업데이트 중에 많은 대체 작업을 시작할 수 있으며 각 작업은 시작 시 Parameter Store에서 설정을 읽을 수 있습니다.
-
Lambda 함수가 동시에 많은 요청을 수신합니다. 예를 들어 Lambda는 늘어난 트래픽을 처리하기 위해 많은 함수 환경을 시작할 수 있습니다. 각 함수 환경이 시작할 때 파라미터를 읽을 수 있습니다.
-
빌드 또는 릴리스 프로세스가 짧은 시간 간격으로 많은 파라미터를 읽습니다. 예를 들어 빌드 작업이 여러 애플리케이션 또는 환경에 대한 설정을 읽을 수 있습니다.
-
애플리케이션은 경로별로 많은 파라미터를 읽습니다. 예를 들어 애플리케이션은 필요한 특정 파라미터만 읽는 대신,
/myapp/prod/아래 모든 파라미터를 반복적으로 읽습니다. 이러한 반복된 요청은 기본 요청 한도를 초과할 수 있습니다.
다음과 같은 보완적인 방법으로 Parameter Store 스로틀링을 해결할 수 있습니다.
-
처리량 감소
애플리케이션이 필요한 것보다 많은 데이터를 검색하거나 비효율적인 방식으로 검색하고 있을 수 있습니다.
-
더 높은 처리량 활성화
지정된 리전 및 계정에 대한 처리량 할당량을 늘려 애플리케이션 복원력을 높일 수 있습니다. 트래픽이 많은 기간에는 언제든지 더 높은 처리량 설정을 활성화하거나 비활성화할 수 있습니다. 스로틀링 오류가 정기적으로 생성되는 프로덕션 워크로드의 경우 설정을 영구적으로 활성화하는 방법을 고려합니다.
Parameter Store에서 처리량 감소
표준 처리량이든, 더 높은 처리량이든 Parameter Store에 대한 직접 호출 빈도와 유형을 검토하세요. 경우에 따라 파라미터를 변경하지 않고도 요청 수를 줄일 수 있습니다. 비용은 구독 또는 티어 모델이 아닌 사용량에 따라 결정되므로 청구되는 API 상호 작용이 줄어듭니다.
-
모든 요청에서 동일한 값을 읽는 대신, 애플리케이션에서 파라미터 값을 캐시합니다.
예를 들어 애플리케이션이
/myapp/prod/log-level을 분당 여러 번 읽는 경우 애플리케이션은 값을 한 번 읽고 짧은 시간 동안 해당 값을 재사용할 수 있습니다. 이 기법은 Parameter Store에 대한 반복 직접 호출을 줄입니다. 자주 변경되는 값에 대해서는 더 짧은 재사용 기간을 선택하고, 거의 변경되지 않는 값에 대해서는 더 긴 재사용 기간을 선택합니다. -
여러 파라미터의 이름을 알고 있는 경우 GetParameters를 사용합니다.
예를 들어 파라미터
/myapp/prod/database/host,/myapp/prod/log-level및/myapp/prod/vendor/merchant-id에 대해 별도의 GetParameter 직접 호출을 수행하는 대신, 단일GetParameters요청으로 이러한 파라미터 목록을 검색할 수 있습니다. -
애플리케이션에 필요한 것보다 더 많은 파라미터를 읽지 마세요.
애플리케이션에 알려진 몇 개의 파라미터만 필요한 경우
/myapp/prod/와 같은 전체 경로를 반복적으로 읽는 대신,GetParameter또는GetParameters를 사용합니다. 애플리케이션에 경로 아래의 파라미터 그룹이 필요한 경우 GetParametersByPath를 사용합니다. 더 높은 처리량을 사용하는 경우GetParameter할당량은GetParametersByPath할당량의 100배입니다. -
많은 리소스가 동시에 시작되면 파라미터 읽기를 분산합니다.
예를 들어 업데이트 중에 많은 Amazon EC2 인스턴스 또는 Amazon ECS 태스크가 시작되는 경우 모든 리소스가 정확히 동시에 파라미터를 읽지 않도록 하세요. 할당량은 초당 기준으로 적용됩니다. 가능한 경우 파라미터를 한 번 읽고 값을 애플리케이션에 캐싱하거나 요청이 모두 동시에 수행되지 않도록 약간의 지연을 추가합니다.
-
Lambda 함수의 경우 AWS 파라미터 및 시크릿 Lambda 확장을 사용하는 방법을 고려합니다.
확장은 함수에서 재사용할 수 있도록 파라미터 값을 로컬에 저장할 수 있습니다. 이 기법은 Parameter Store에 대한 직접 호출 수를 줄이고 파라미터 값을 검색하는 데 필요한 시간을 줄일 수도 있습니다. 이 기법에 대한 연습 예제는 Using the AWS Parameter and Secrets Lambda extension to cache parameters and secrets
를 참조하세요.
처리량 증가
대용량 워크로드의 경우 더 높은 처리량을 활성화할 수 있습니다. 이 설정에서는 유료로 사용자 계정 및 리전에 대해 지원되는 초당 최대 트랜잭션 수를 늘릴 수 있습니다. 다음 시나리오에서는 더 높은 처리량을 고려하세요.
-
일시적으로 애플리케이션에 더 높은 처리량이 필요합니다.
예를 들어 웹 스토어는 주말 할인 중에 파라미터를 더 자주 읽을 수 있습니다. 판매가 시작되기 전에 더 높은 처리량을 활성화한 다음, 할인이 종료된 후에는 표준 처리량으로 돌아갈 수 있습니다. Parameter Store 설정 페이지에서 또는 AWS CLI를 사용하여 언제든지 더 높은 처리량을 활성화하거나 비활성화할 수 있습니다.
-
프로덕션 애플리케이션이 파라미터를 정기적으로 동시에 검색하지만, 스로틀링 문제가 발생합니다.
동시 검색은 여러 인스턴스, 컨테이너, 함수 또는 빌드 작업이 Parameter Store에서 동시에 파라미터를 읽을 때 나타날 수 있습니다. 예는 다음과 같습니다.
-
애플리케이션이 빠르게 스케일 아웃됩니다. 예를 들어 애플리케이션이 일반적으로 5개의 Amazon EC2 인스턴스에서 실행됩니다. 트래픽이 갑자기 증가하면 Amazon EC2 Auto Scaling은 50개의 인스턴스를 더 시작합니다. 각 인스턴스가 시작할 때 파라미터를 읽는 경우 결합된 요청은 기본 요청 제한을 초과할 수 있습니다.
-
컨테이너 서비스가 동시에 많은 태스크를 시작합니다. 예를 들어 Amazon ECS 서비스는 업데이트 중에 많은 대체 작업을 시작할 수 있으며 각 작업은 시작 시 Parameter Store에서 설정을 읽을 수 있습니다.
-
Lambda 함수가 동시에 많은 요청을 수신합니다. 예를 들어 Lambda는 늘어난 트래픽을 처리하기 위해 많은 함수 환경을 시작할 수 있습니다. 각 함수 환경이 시작할 때 파라미터를 읽을 수 있습니다.
-
빌드 또는 릴리스 프로세스가 짧은 시간 간격으로 많은 파라미터를 읽습니다. 예를 들어 빌드 작업이 여러 애플리케이션 또는 환경에 대한 설정을 읽을 수 있습니다.
-
높은 처리량을 위한 비용 고려 사항
처리량이 더 높은 옵션의 경우 추가 요금이 적용됩니다. 현재 Parameter Store API 요금 및 예제는 AWS Systems Manager 요금
요금은 Parameter Store API 상호 작용을 기반으로 합니다. API 상호 작용은 API 요청과 개별 파라미터 간 상호 작용으로 정의됩니다. 예를 들어 단일 GetParameter 요청이 10개의 파라미터를 반환하는 경우 이 요청은 청구 목적으로 10개의 Parameter Store API 상호 작용으로 계산됩니다.
트래픽이 증가하는 짧은 기간에 더 높은 처리량으로 전환하려는 시나리오를 고려합니다. 웹 스토어는 주말 할인을 진행하고 할인 중에 1,000,000 Parameter Store API 상호 작용을 수행합니다. 이 예제에서 더 높은 처리량에 대한 비용이 10,000 API 상호 작용당 $0.05인 경우 총 추가 비용은 약 $5입니다. 할인이 끝날 때 표준 처리량으로 다시 전환하여 비용 발생을 중지할 수 있습니다.
처리량 및 파라미터 티어 결합
처리량은 파라미터 티어와 독립적으로 작동합니다. 파라미터 티어는 스토리지 제한 및 기능 가용성을 제어하지만 처리량 설정은 요청 볼륨을 제어합니다. 성능 및 규모 조정 요구 사항을 충족하기 위해 티어와 처리량을 함께 사용할 수 있습니다.
예를 들어 간단하고 부하가 낮은 애플리케이션을 지원하기 위해 기본 처리량과 함께 표준 파라미터를 사용할 수 있습니다. 높은 빈도의 대규모 액세스 패턴을 지원하기 위해 고급 파라미터를 더 높은 처리량과 결합할 수 있습니다. 일반적으로 사용하는 파라미터 티어에 관계없이 애플리케이션이 기본 TPS 제한을 초과할 때(예: 동시 읽기 또는 쓰기 버스트 중) 처리량을 늘려야 합니다.
최대 처리량 및 기타 Parameter Store 할당량에 대한 자세한 내용은 AWS Systems Manager 엔드포인트 및 할당량을 참조하세요.
Parameter Store에서 처리량 설정 변경
다음 절차에서는 Systems Manager를 사용하여 Parameter Store가 현재 AWS 계정 및 AWS 리전에 대해 처리할 수 있는 초당 트랜잭션 수를 변경하는 방법을 설명합니다. 이 설정은 언제든지 변경할 수 있습니다.