기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon Neptune Serverless
Amazon Neptune Serverless는 매우 크게 증가하는 처리 수요를 충족하기 위해 필요에 따라 DB 클러스터의 규모를 조정하고 수요가 감소하면 다시 스케일 다운하도록 설계된 온디맨드 자동 확장 구성입니다. Neptune 데이터베이스의 워크로드 모니터링 및 용량 조정 프로세스를 자동화하는 데 도움이 됩니다. 용량은 애플리케이션 수요에 따라 자동으로 조정되며 애플리케이션에서 실제로 필요한 리소스에 대해서만 요금이 청구됩니다.
## Neptune Serverless 사용 사례
Neptune Serverless 요구 사항이 많고 매우 가변적인 워크로드에 적합하며 데이터베이스 사용량이 일반적으로 짧은 시간 동안 높게 나타난 후 오랜 시간 작업이 적거나 전혀 작업이 없을 때 매우 유용할 수 있습니다. Neptune Serverless는 다음과 같은 사용 사례에 특히 유용합니다.
+ **가변 워크로드** – 워크로드의 증가가 갑작스럽고 예측할 수 없는 증가가 CPU 활동에서 실행되는 경우입니다. Neptune Serverless를 사용하면 활동이 급증하는 시점이 지난 다음 그래프 데이터베이스에서 자동으로 용량의 규모를 조정하여 워크로드 수요를 충족하도록 다시 스케일 다운합니다. 더 이상 정점 또는 평균 용량에 맞춰 프로비저닝하지 않아도 됩니다. 정점의 워크로드를 처리하기 위해 용량 상한을 지정할 수 있으며, 필요한 경우가 아니면 그 용량이 사용되지 않습니다.
Neptune Serverless의 세분화된 규모 조정을 사용하면 워크로드 요구 사항과 용량을 매우 비슷하게 일치시킬 수 있습니다. Neptune Serverless는 필요에 따라 세분화된 증분으로 용량을 추가하거나 제거할 수 있습니다. 용량이 조금만 더 필요한 경우 [Neptune 용량 단위(NCU)](neptune-serverless-capacity-scaling.md)의 절반만 추가할 수 있습니다.
+ **멀티 테넌트 애플리케이션** - Neptune Serverless를 활용하면 해당 테넌트 클러스터를 개별적으로 관리할 필요 없이 실행해야 하는 각 애플리케이션에 대해 별도의 DB 클러스터를 만들 수 있습니다. 각 테넌트 클러스터는 여러 요인에 따라 사용 중인 기간과 유휴 기간이 다를 수 있지만 Neptune Serverless는 사용자 개입 없이 효율적으로 규모를 조정할 수 있습니다.
+ **새 애플리케이션** - 새 애플리케이션을 배포할 때 필요한 데이터베이스 용량이 어느 정도인지 잘 모르는 경우가 많습니다. Neptune Serverless를 사용하면 새 애플리케이션이 개발됨에 따라 해당 애플리케이션의 용량 요구 사항을 충족하도록 자동으로 규모를 조정할 수 있는 DB 클러스터를 설정할 수 있습니다.
+ **용량 계획** - 클러스터에 있는 모든 DB 인스턴스의 DB 인스턴스 클래스를 수정하여 일반적으로 데이터베이스 용량을 조정하거나 워크로드에 가장 적합한 데이터베이스 용량을 확인한다고 가정해 보겠습니다. Neptune Serverless를 사용하면 이런 관리 오버헤드 발생을 방지할 수 있습니다. 대신 새 DB 클러스터나 인스턴스를 만들지 않고도 기존 DB 인스턴스를 프로비저닝된 인스턴스에서 서버리스로 또는 서버리스에서 프로비저닝된 인스턴스로 수정할 수 있습니다.
+ **개발 및 테스트** - Neptune Serverless는 개발 및 테스트 환경에도 적합합니다. Neptune Serverless를 사용하면 가장 까다로운 애플리케이션을 테스트하기에 충분한 최대 용량으로 DB 인스턴스를 만들고 테스트 사이에 시스템이 유휴 상태일 수 있는 다른 모든 시간에는 낮은 최소 용량으로 DB 인스턴스를 만들 수 있습니다.
Neptune Serverless는 컴퓨팅 용량만 규모를 조정합니다. 스토리지 볼륨은 동일하게 유지되며 서버리스 크기 조정의 영향을 받지 않습니다.
**참고**
또한 [Neptune Serverless와 Neptune Auto Scaling을 사용](manage-console-autoscaling.md#autoscaling-with-serverless)하여 다양한 종류의 워크로드 변동을 처리할 수 있습니다.
## Amazon Neptune Serverless 제약 조건
+ Neptune Serverless는 다음 리전에서만 사용할 수 있습니다.
+ 미국 동부(버지니아 북부): `us-east-1`
+ 미국 동부(오하이오): `us-east-2`
+ 미국 서부(캘리포니아 북부): `us-west-1`
+ 미국 서부(오레곤): `us-west-2`
+ 캐나다(중부): `ca-central-1`
+ 유럽(스톡홀름): `eu-north-1`
+ 유럽(스페인): `eu-south-2`
+ 유럽(아일랜드): `eu-west-1`
+ 유럽(런던): `eu-west-2`
+ 유럽(파리): `eu-west-3`
+ 유럽(프랑크푸르트): `eu-central-1`
+ 아시아 태평양(도쿄): `ap-northeast-1`
+ 아시아 태평양(서울): `ap-northeast-2`
+ 아시아 태평양(싱가포르): `ap-southeast-1`
+ 아시아 태평양(시드니): `ap-southeast-2`
+ 아시아 태평양(자카르타): `ap-southeast-3`
+ 아시아 태평양(홍콩): `ap-east-1`
+ 아시아 태평양(뭄바이): `ap-south-1`
+ 남아메리카(상파울루): `sa-east-1`
+ **초기 엔진 버전에서는 사용할 수 없음** - Neptune Serverless는 엔진 릴리스 1.2.0.1 이상에서만 사용할 수 있습니다.
+ **Neptune 조회 캐시와 호환되지 않음** - [조회 캐시](feature-overview-lookup-cache.md)는 서버리스 DB 인스턴스에서는 작동하지 않습니다.
+ **서버리스 인스턴스의 최대 메모리는 256GB** - `MaxCapacity`를 128NCU(지원되는 최고 설정)로 설정하면 Neptune Serverless 인스턴스의 메모리를 256GB까지 규모를 조정할 수 있으며, 이는 `R6g.8XL` 프로비저닝된 인스턴스 유형과 동일합니다.
# Neptune Serverless DB 클러스터의 용량 규모 조정
Neptune Serverless DB 클러스터를 설정하는 것은 일반 프로비저닝 클러스터를 설정하는 것과 비슷합니다. 규모 조정을 위한 최소 및 최대 단위를 추가로 구성하고 인스턴스 유형을 `db.serverless`로 설정해야 합니다. 규모 조정 구성은 Neptune 용량 단위(NCU)에 정의되며, 각 NCU는 관련 가상 프로세서 용량(vCPU) 및 네트워킹과 함께 2GiB(기비바이트)의 메모리(RAM)로 구성됩니다. `ServerlessV2ScalingConfiguration` 객체의 일부로 설정되며 다음과 같이 JSON으로 표시됩니다.
```
"ServerlessV2ScalingConfiguration": {
"MinCapacity": (minimum NCUs, a floating-point number such as 1.0),
"MaxCapacity": (maximum NCUs, a floating-point number such as 128.0)
}
```
언제든지 각 Neptune 라이터 또는 리더 인스턴스의 용량은 해당 인스턴스에서 현재 사용 중인 NCU 수를 나타내는 부동 소수점 숫자로 측정됩니다. 인스턴스 수준에서 CloudWatch [ServerlessDatabaseCapacity](neptune-serverless-using.md#neptune-serverless-monitoring) 지표를 사용하여 특정 DB 인스턴스가 현재 사용하고 있는 NCU 수를 확인하고 [NCUUtilization](neptune-serverless-using.md#neptune-serverless-monitoring) 지표를 사용하여 인스턴스가 최대 용량 중 몇 퍼센트를 사용하고 있는지 확인할 수 있습니다. 이 두 지표 모두 DB 클러스터 수준에서도 사용할 수 있어 DB 클러스터 전체의 평균 리소스 사용률을 보여 줍니다.
Neptune Serverless DB 클러스터를 생성할 때 모든 서버리스 인스턴스에 대해 **Neptune 용량 단위**(NCU)의 최소 및 최대 수를 설정합니다.
지정하는 최소 NCU 값은 DB 클러스터의 서버리스 인스턴스를 축소할 수 있는 최소 크기를 설정하며, 마찬가지로 최대 NCU 값에 따라 서버리스 인스턴스가 증가할 수 있는 최대 크기가 결정됩니다. 설정할 수 있는 최댓값은 128.0NCU이고, 가장 낮은 최솟값은 1.0NCU입니다.
Neptune은 CPU, 메모리 및 네트워크 등의 리소스 사용률을 모니터링하여 각 Neptune Serverless 인스턴스의 부하를 지속적으로 추적합니다. 로드는 애플리케이션의 데이터베이스 작업, 서버의 백그라운드 처리 및 기타 관리 작업에 의해 생성됩니다.
서버리스 인스턴스의 부하가 현재 용량 한도에 도달하거나 Neptune이 다른 성능 문제를 감지하면 인스턴스가 자동으로 스케일 업합니다. 인스턴스의 부하가 감소하면 구성된 최소 용량 단위로 스케일 다운되며, 메모리보다 CPU 용량이 먼저 해제됩니다. 이 아키텍처를 사용하면 제어된 단계별 감소 방식으로 리소스를 릴리스할 수 있으며 수요 변동을 효과적으로 처리할 수 있습니다.
리더 인스턴스를 라이터 인스턴스와 함께 확장하거나 승격 티어를 설정하여 독립적으로 규모를 조정하도록 할 수 있습니다. 승격 티어 0과 1의 리더 인스턴스는 라이터와 동시에 규모 조정되므로 장애 조치 시 라이터에서 워크로드를 빠르게 인계받을 수 있도록 적절한 용량으로 크기가 유지됩니다. 승격 티어 2에서 15까지의 리더는 라이터 인스턴스와는 별개일 뿐 아니라 다른 리더들과도 독립적으로 규모 조정됩니다.
고가용성을 보장하기 위해 Neptune DB 클러스터를 다중 AZ 클러스터로 생성한 경우 Neptune Serverless는 데이터베이스 부하에 따라 모든 AZ의 인스턴스의 규모를 조정합니다. 보조 AZ에 있는 리더 인스턴스의 승격 티어를 0 또는 1로 설정하여 언제든지 현재 워크로드를 인계받을 수 있도록 기본 AZ에 있는 라이터 인스턴스의 용량과 함께 스케일 업하거나 다운할 수 있습니다.
**참고**
Neptune DB 클러스터의 스토리지는 모든 데이터의 사본 6개로 구성되며 클러스터를 다중 AZ 클러스터로 생성했는지 여부와 관계없이 3개의 AZ에 분산되어 있습니다. 스토리지 복제는 스토리지 하위 시스템에서 처리되며 Neptune Serverless의 영향을 받지 않습니다.
## Neptune Serverless DB 클러스터의 최소 용량 값 선택
최소 용량으로 설정할 수 있는 최솟값은 `1.0`NCU입니다.
애플리케이션에서 효율적으로 작동하는 데 필요한 값보다 최솟값을 낮게 설정하지 않습니다. 이 값을 너무 낮게 설정하면 메모리 집약적인 특정 워크로드에서 제한 시간 비율이 높아질 수 있습니다.
최솟값을 최대한 낮게 설정하면 수요가 적을 때 클러스터에서 최소한의 리소스를 사용하므로 비용을 절감할 수 있습니다. 그러나 워크로드가 매우 낮은 수준에서 매우 높은 수준으로 크게 변동하는 경향이 있는 경우 최솟값이 높을수록 Neptune Serverless 인스턴스가 더 빠르게 스케일 업되므로 최솟값을 더 높게 설정하는 것이 좋습니다.
그 이유는 Neptune이 현재 용량을 기반으로 확장 증분을 선택하기 때문입니다. 현재 용량이 낮으면 Neptune은 처음에 느리게 스케일 업됩니다. 최솟값이 더 높으면 Neptune은 더 큰 규모 조정 증분으로 시작하므로 갑자기 증가하는 워크로드에 맞춰 더 빠르게 스케일 업할 수 있습니다.
## Neptune Serverless DB 클러스터의 최대 용량 값 선택
최대 용량으로 설정할 수 있는 최댓값은 `128.0`NCU이고, 최대 용량으로 설정할 수 있는 최솟값은 `2.5`NCU입니다. 최대 용량 값은 적어도 설정한 최소 용량보다는 커야 합니다.
일반적으로 애플리케이션에서 발생할 수 있는 최대 부하를 처리할 수 있을 만큼 최댓값을 충분히 높게 설정합니다. 이 값을 너무 낮게 설정하면 메모리 집약적인 특정 워크로드에서 제한 시간 비율이 높아질 수 있습니다.
최댓값을 최대한 높게 설정하면 애플리케이션이 예상치 못한 워크로드도 처리할 수 있다는 이점이 있습니다. 단점은 리소스 비용을 예측하고 제어할 수 있는 기능이 어느 정도 상실된다는 점입니다. 예상치 못한 수요 급증으로 인해 예상한 예산보다 훨씬 많은 비용이 발생할 수 있습니다.
신중하게 목표한 최댓값을 사용하면 최대 수요를 충족하는 동시에 Neptune 컴퓨팅 비용을 제한할 수 있다는 이점이 있습니다.
**참고**
Neptune Serverless DB 클러스터의 용량 범위를 변경하면 일부 구성 파라미터의 기본값이 변경됩니다. Neptune은 이러한 새 기본값 중 일부를 즉시 적용할 수 있지만 일부 동적 파라미터 변경 사항은 재부팅 후에만 적용됩니다. `pending-reboot` 상태는 일부 파라미터 변경 사항을 적용하려면 재부팅이 필요함을 나타냅니다.
## 기존 구성을 사용하여 서버리스 요구 사항을 추정합니다.
일반적으로 특히 높거나 낮은 워크로드를 직면하여 프로비저닝된 DB 인스턴스의 DB 인스턴스 클래스를 수정하는 경우 해당 경험을 사용하여 동등한 Neptune Serverless 용량 범위를 대략적으로 추정할 수 있습니다.
### 최적의 최소 용량 설정 추정
기존 Neptune DB 클러스터에 대해 알고 있는 내용을 적용하여 가장 적합한 서버리스 최소 용량 설정을 추정할 수 있습니다.
프로비저닝된 워크로드에 `T3` 또는 `T4g`와 같은 소규모 DB 인스턴스 클래스에 비해 너무 높은 메모리 요구 사항이 있는 경우 `R5` 또는 `R6g` DB 인스턴스 클래스에 필적하는 메모리를 제공하는 최소 NCU 설정을 선택합니다.
예를 들어 클러스터의 워크로드가 낮은 경우 `db.r6g.xlarge` DB 인스턴스 클래스를 사용한다고 가정합니다. 이 DB 인스턴스 클래스는 32GiB의 메모리를 갖고 있으므로 최소 NCU 설정을 16으로 지정하여 거의 동일한 용량으로 스케일 다운할 수 있는 서버리스 인스턴스를 만들 수 있습니다(각 NCU는 약 2GiB의 메모리에 해당). `db.r6g.xlarge` 인스턴스가 때때로 충분히 활용되지 않는 경우 더 낮은 값을 지정할 수 있습니다.
DB 인스턴스가 메모리 또는 버퍼 캐시에 지정된 양의 데이터를 보유할 수 있을 때 애플리케이션이 가장 효율적으로 작동한다면, 이를 위한 충분한 메모리를 제공할 수 있을 만큼 최소 NCU 설정을 크게 지정하는 것을 고려합니다. 그렇지 않으면 서버리스 인스턴스가 스케일 다운될 때 데이터가 버퍼 캐시에서 제거될 수 있으며, 시간이 지나면서 인스턴스가 다시 스케일 업되며 버퍼 캐시로 데이터를 다시 읽어야 합니다. 데이터를 버퍼 캐시로 다시 가져오기 위한 I/O 양이 많은 경우 최소 NCU 값을 높이는 것이 더 효과적일 수 있습니다.
서버리스 인스턴스가 대부분 특정 용량으로 실행되는 경우 최소 용량을 그보다 약간 낮게 설정하는 것이 좋습니다. Neptune Serverless는 현재 용량이 필요한 용량보다 크게 낮지 않은 경우 스케일 업할 양과 속도를 가장 효과적으로 추정할 수 있습니다.
프로비저닝된 라이터 및 Neptune Serverless 리더가 있는 [혼합 구성](neptune-serverless-configuration.md#neptune-serverless-mixed-configuration)의 경우 리더는 라이터와 함께 규모를 조정할 수 없습니다. 독립적으로 규모를 조정하므로 최소 용량을 낮게 설정하면 과도한 복제 지연이 발생할 수 있습니다. 쓰기 집약도가 매우 높은 워크로드가 있는 경우 라이터가 변경한 내용을 따라잡기에 충분한 용량이 없을 수 있습니다. 이 경우 쓰기 용량과 비슷한 최소 용량을 설정합니다. 승격 티어 2\$115에 있는 리더에서 복제본 지연이 관찰되면 클러스터의 최소 용량 설정을 늘리는 것이 좋습니다.
### 최적의 최대 용량 설정 추정
기존 Neptune DB 클러스터에 대해 알고 있는 내용을 적용하여 가장 적합한 서버리스 최대 용량 설정을 추정할 수 있습니다.
예를 들어 클러스터의 워크로드가 높은 경우 `db.r6g.4xlarge` DB 인스턴스 클래스를 사용한다고 가정합니다. 이 DB 인스턴스 클래스에는 128GiB의 메모리가 있으므로 최대 NCU 설정을 64로 지정하여 동등한 Neptune Serverless 인스턴스를 설정할 수 있습니다(각 NCU는 약 2GiB의 메모리에 해당). `db.r6g.4xlarge` 인스턴스가 항상 워크로드를 처리할 수 없는 경우에 대비하여 DB 인스턴스가 더 스케일 업되도록 더 높은 값을 지정할 수 있습니다.
워크로드에 예상치 못한 급증이 발생하는 경우가 드물다면, 이러한 급증 중에도 애플리케이션 성능을 유지할 수 있도록 최대 용량을 충분히 높게 설정하는 것이 좋습니다. 반면 최대 용량을 더 낮게 설정하여 예상치 못한 급증 시 처리량을 줄일 수 있지만 Neptune이 예상 워크로드를 문제 없이 처리할 수 있도록 하고 이로 인해 비용이 제한될 수 있습니다.
# Neptune Serverless DB 클러스터 및 인스턴스의 추가 구성
Neptune Serverless DB 클러스터의 [최소 및 최대 용량을 설정](neptune-serverless-capacity-scaling.md)하는 것 외에도 고려해야 할 몇 가지 다른 구성 옵션이 있습니다.
## DB 클러스터에서 서버리스 인스턴스와 프로비저닝된 인스턴스 결합
DB 클러스터는 서버리스만 사용할 필요는 없습니다. 서버리스 인스턴스와 프로비저닝된 인스턴스를 조합하여 만들 수 있습니다(혼합 구성).
예를 들어 서버리스 인스턴스에서 사용할 수 있는 것보다 많은 쓰기 용량이 필요하다고 가정하겠습니다. 이 경우 대규모로 프로비저닝된 라이터를 사용하여 클러스터를 설정하고 리더용 서버리스 인스턴스를 사용할 수 있습니다.
또는 클러스터의 쓰기 워크로드는 다양하지만 읽기 워크로드는 일정하다고 가정합니다. 이 경우 서버리스 라이터와 하나 이상의 프로비저닝된 리더로 클러스터를 설정할 수 있습니다.
혼합 구성 DB 클러스터를 생성하는 방법은 [Amazon Neptune Serverless 사용](neptune-serverless-using.md)에서 참조하세요.
## Neptune Serverless 인스턴스의 승격 티어 설정
여러 개의 서버리스 인스턴스를 포함하는 클러스터 또는 프로비저닝된 인스턴스와 서버리스 인스턴스가 혼합된 클러스터의 경우 각 서버리스 인스턴스의 승격 티어 설정을 유의해야 합니다. 이 설정은 프로비저닝된 DB 인스턴스보다 서버리스 인스턴스에 대해 더 많은 동작을 제어합니다.
에서 **데이터베이스 생성** AWS Management Console, **인스턴스 수정** 및 **리더 추가** 페이지의 **추가 구성**에서 **장애 조치 우선 순위를** 사용하여이 설정을 지정합니다. **데이터베이스** 페이지에서 선택 사항인 **우선 순위 티어** 열에 기존 인스턴스에 대해 이 속성이 표시됩니다. DB 클러스터 또는 인스턴스의 세부 정보 페이지에서도 이 속성을 확인할 수 있습니다.
프로비저닝된 인스턴스의 경우 티어 0\$115를 선택하면 Neptune이 장애 조치 작업 중에 라이터로 승격할 리더 DB 인스턴스를 선택하는 순서만 결정됩니다. Neptune Serverless 리더 인스턴스의 경우 티어 번호에 따라 인스턴스를 라이터 인스턴스의 용량에 맞춰 스케일 업할지 아니면 자체 워크로드만을 기준으로 독립적으로 크기 조정할지도 결정됩니다.
티어 0 또는 1의 Neptune Serverless 리더 인스턴스는 장애 조치 시 라이터에서 인계받을 준비가 되도록 최소한 라이터 인스턴스만큼 높은 최소 용량으로 유지됩니다. 라이터가 프로비저닝된 인스턴스인 경우 Neptune은 상응하는 서버리스 용량을 추정하고 이 추정치를 서버리스 리더 인스턴스의 최소 용량으로 사용합니다.
티어 2\$115의 Neptune Serverless 리더 인스턴스는 최소 용량에 대해 이러한 제약 조건을 갖고 있지 않으며 라이터와 관계없이 규모를 조정할 수 있습니다. 유휴 상태일 때 클러스터의 [용량 범위](neptune-serverless-capacity-scaling.md)에 지정된 최소 NCU 값으로 스케일 다운할 수 있습니다. 하지만 읽기 워크로드가 급격히 급증하면 문제가 발생할 수 있습니다.
## 리더 용량을 라이터 용량에 맞게 조정합니다.
한 가지 명심해야 할 점은 과도한 복제 지연을 방지하기 위해 리더 인스턴스가 라이터 인스턴스의 속도를 따라잡을 수 있도록 해야 한다는 것입니다. 이는 서버리스 리더 인스턴스가 라이터 인스턴스와 동기화되어 자동으로 스케일 인되지 않는 2가지 상황에서 특히 문제가 됩니다.
+ 라이터가 프로비저닝되면 리더는 서버리스 상태가 됩니다.
+ 라이터가 서버리스이면 서버리스 리더는 승격 티어 2\$115에 포함됩니다.
두 경우 모두 예상 라이터 용량과 일치하도록 최소 서버리스 용량을 설정하여 리더 작업 시간이 초과되어 재시작이 발생할 수 있는 일이 없도록 합니다. 프로비저닝된 라이터 인스턴스의 경우 프로비저닝된 인스턴스의 최소 용량과 일치하도록 최소 용량을 설정합니다. 서버리스 라이터의 경우 최적의 설정을 예측하기 어려울 수 있습니다.
인스턴스 용량 범위가 클러스터 수준에서 설정되기 때문에 모든 서버리스 인스턴스는 동일한 최소 및 최대 용량 설정으로 제어됩니다. 티어 0과 1의 리더 인스턴스는 라이터 인스턴스와 동기화되어 스케일 인되지만, 승격 티어 2\$115의 인스턴스는 워크로드에 따라 서로 독립적으로 규모가 조정되며 라이터 인스턴스와도 독립적으로 규모 조정이 이뤄집니다. 최소 용량을 너무 낮게 설정하면 티어 2\$115의 유휴 인스턴스를 너무 낮게 스케일 다운하여 라이터 작업의 급격한 증가를 처리할 수 있을 만큼 빠르게 규모를 조정할 수 없습니다.
## 제한 시간 값을 너무 높게 설정하면 안 됨
특히 서버리스 인스턴스에서 쿼리 제한 시간 값을 너무 높게 설정하면 예상치 못한 비용이 발생할 수 있습니다.
제한 시간을 적절하게 설정하지 않으면 강력하고 값비싼 인스턴스 유형이 필요하고 매우 오랫동안 계속 실행되는 쿼리가 실수로 실행되어 예상치 못한 비용이 발생할 수 있습니다. 대부분의 쿼리를 수용하고 예기치 않게 오래 실행되는 쿼리의 제한 시간만 발생시키는 쿼리 제한 시간 값을 사용하면 이러한 상황을 피할 수 있습니다.
이는 파라미터를 사용하여 설정된 일반 쿼리 제한 시간 값과 쿼리 힌트를 사용하여 설정된 쿼리별 제한 시간 값 모두에 해당됩니다.
## Neptune Serverless 구성 최적화
Neptune Serverless DB 클러스터가 실행 중인 워크로드에 맞게 조정되지 않은 경우 최적으로 실행되지 않는 것을 알 수 있습니다. 메모리 문제 없이 규모를 조정할 수 있도록 최소 또는 최대 용량 설정을 조정할 수 있습니다.
+ 클러스터의 최소 용량 설정 증대 이렇게 하면 유휴 인스턴스가 애플리케이션 및 사용 설정된 기능에 필요한 용량보다 적은 메모리 용량으로 다시 규모가 조정되는 상황을 해결할 수 있습니다.
+ 클러스터의 최대 용량 설정 증대 이렇게 하면 사용량이 많은 데이터베이스가 워크로드를 처리할 수 있는 충분한 메모리 및 사용 설정된 모든 메모리 집약적인 기능으로 용량을 스케일 업할 수 없는 상황을 해결할 수 있습니다.
+ 해당 인스턴스의 워크로드를 변경합니다. 예를 들어 클러스터에 리더 인스턴스를 추가하여 읽기 로드를 더 많은 인스턴스에 분산할 수 있습니다.
+ 리소스를 적게 사용하도록 애플리케이션 쿼리를 조정합니다.
+ Neptune Serverless에서 사용 가능한 최대 NCU보다 큰 프로비저닝된 인스턴스를 사용하여 워크로드의 메모리 및 CPU 요구 사항에 더 적합한지 확인합니다.
# Amazon Neptune Serverless 사용
새 Neptune DB 클러스터를 서버리스 클러스터로 만들거나 경우에 따라 기존 DB 클러스터를 변환하여 서버리스를 사용할 수 있습니다. 또한 서버리스 DB 클러스터의 DB 인스턴스를 서버리스 인스턴스로 또는 서버리스 인스턴스에서 변환할 수 있습니다. Neptune Serverless AWS 리전 는 지원되는 중 하나에서만 사용할 수 있으며 몇 가지 다른 제한 사항이 있습니다( 참조[Amazon Neptune Serverless 제약 조건](neptune-serverless.md#neptune-serverless-limitations)).
또한 [Neptune CloudFormation 스택](get-started-cfn-create.md)을 사용하여 Neptune Serverless DB 클러스터를 생성할 수 있습니다.
## 서버리스를 사용하는 새 DB 클러스터 생성
서버리스를 사용하는 Neptune DB 클러스터를 만들려면 프로비저닝된 클러스터를 만들 때와 같은 방법으로 [AWS Management Console을 사용](manage-console-launch-console.md)하여 만들 수 있습니다. 차이점은 **DB 인스턴스 크기**에서 **DB 인스턴스 클래스**를 **서버리스**로 설정해야 한다는 점입니다. 이렇게 할 때 클러스터의 [서버리스 용량 범위를 설정](neptune-serverless-capacity-scaling.md)해야 합니다.
다음과 같은 AWS CLI 명령을 사용하여를 사용하여 서버리스 DB 클러스터를 생성할 수도 있습니다(Windows에서는 '\$1'를 '^'로 대체).
```
aws neptune create-db-cluster \
--region (an AWS 리전 region that supports serverless) \
--db-cluster-identifier (ID for the new serverless DB cluster) \
--engine neptune \
--engine-version (optional: 1.2.0.1 or above) \
--serverless-v2-scaling-configuration "MinCapacity=1.0, MaxCapacity=128.0"
```
다음과 같이 `serverless-v2-scaling-configuration` 파라미터를 지정할 수도 있습니다.
```
--serverless-v2-scaling-configuration '{"MinCapacity":1.0, "MaxCapacity":128.0}'
```
그런 다음 `ServerlessV2ScalingConfiguration` 속성에 대해 `describe-db-clusters` 명령을 실행하면 지정한 다음의 용량 범위 설정이 반환됩니다.
```
"ServerlessV2ScalingConfiguration": {
"MinCapacity": (the specified minimum number of NCUs),
"MaxCapacity": (the specified maximum number of NCUs)
}
```
## 기존 DB 클러스터 또는 인스턴스를 서버리스로 변환
엔진 버전 1.2.0.1 이상을 사용하는 Neptune DB 클러스터가 있는 경우 이를 서버리스로 변환할 수 있습니다. 이 프로세스에는 약간의 가동 중지가 발생합니다.
첫 번째 단계는 기존 클러스터에 용량 범위를 추가하는 것입니다. 를 사용하거나 다음과 같은 AWS CLI 명령을 AWS Management Console사용하여이 작업을 수행할 수 있습니다(Windows에서는 '\$1'를 '^'로 대체).
```
aws neptune modify-db-cluster \
--db-cluster-identifier (your DB cluster ID) \
--serverless-v2-scaling-configuration \
MinCapacity=(minimum number of NCUs, such as 2.0), \
MaxCapacity=(maximum number of NCUs, such as 24.0)
```
다음 단계는 클러스터의 기존 기본 인스턴스(라이터)를 대체할 새 서버리스 DB 인스턴스를 만드는 것입니다. 이 작업과 모든 후속 단계는 AWS Management Console 또는를 사용하여 수행할 수 있습니다 AWS CLI. 두 경우 모두 DB 인스턴스 클래스를 서버리스로 지정합니다. AWS CLI 명령은 다음과 같습니다(Windows에서는 '\$1'를 '^'로 대체).
```
aws neptune create-db-instance \
--db-instance-identifier (an instance ID for the new writer instance) \
--db-cluster-identifier (ID of the DB cluster) \
--db-instance-class db.serverless \
--engine neptune
```
새 라이터 인스턴스를 사용할 수 있게 되면 장애 조치를 수행하여 해당 인스턴스를 클러스터의 라이터 인스턴스로 만듭니다.
```
aws neptune failover-db-cluster \
--db-cluster-identifier (ID of the DB cluster) \
--target-db-instance-identifier (instance ID of the new serverless instance)
```
이어서 다음과 같이 이전 라이터 인스턴스를 삭제합니다.
```
aws neptune delete-db-instance \
--db-instance-identifier (instance ID of the old writer instance) \
--skip-final-snapshot
```
마지막으로 동일한 작업을 수행하여 서버리스 인스턴스로 변환하려는 기존의 프로비저닝된 각 리더 인스턴스를 대신할 새 서버리스 인스턴스를 만들고 기존의 프로비저닝된 인스턴스를 삭제합니다. 리더 인스턴스에는 장애 조치가 필요하지 않습니다.
## 기존 서버리스 DB 클러스터의 용량 범위 수정
다음과 같이 Neptune Serverless DB 클러스터의 용량 범위를 AWS CLI 를 사용하여 변경할 수 있습니다(Windows의 경우 '\$1' 기호를 '^' 기호로 대체).
```
aws neptune modify-db-cluster \
--region (an AWS region that supports serverless) \
--db-cluster-identifier (ID of the serverless DB cluster) \
--apply-immediately \
--serverless-v2-scaling-configuration MinCapacity=4.0, MaxCapacity=32
```
용량 범위를 변경하면 일부 구성 파라미터의 기본값이 변경됩니다. Neptune은 이러한 새 기본값 중 일부를 즉시 적용할 수 있지만 일부 동적 파라미터 변경 사항은 재부팅 후에만 적용됩니다. `pending-reboot` 상태는 일부 파라미터 변경 사항을 적용하려면 재부팅이 필요함을 나타냅니다.
## 서버리스 DB 인스턴스를 프로비저닝된 인스턴스로 변경
Neptune Serverless 인스턴스를 프로비저닝된 인스턴스로 변환하려면 인스턴스 클래스를 프로비저닝된 인스턴스 클래스 중 하나로 변경하기만 하면 됩니다. [Neptune DB 인스턴스 수정(및 즉시 적용)](manage-console-instances-modify.md)을(를) 참조하세요.
## Serverless용 Gremlin 클라이언트 구성
Neptune Serverless와 함께 Gremlin WebSocket 클라이언트를 사용하는 경우 이벤트 규모 조정 중에 안정적인 연결을 유지하도록 클라이언트의 하트비트 간격을 적절하게 구성해야 합니다. Java, Go, JavaScript/Node.js 및 Python 클라이언트에 대한 자세한 구성 지침은 섹션을 참조하세요[Neptune Serverless에 대한 하트비트 구성](best-practices-gremlin-heartbeat-serverless.md).
## Amazon CloudWatch로 서버리스 용량 모니터링
CloudWatch를 사용하여 DB 클러스터에 있는 모든 Neptune Serverless 인스턴스의 용량과 사용률을 모니터링할 수 있습니다. 클러스터 수준과 인스턴스 수준 모두에서 현재 다음과 같이 서버리스 용량을 추적할 수 있는 두 가지 CloudWatch 지표가 있습니다.
+ **`ServerlessDatabaseCapacity`** - 인스턴스 수준 지표로, `ServerlessDatabaseCapacity`는 현재 인스턴스 용량을 NCU 단위로 보고합니다. 클러스터 수준의 지표로, 클러스터 내 모든 DB 인스턴스의 `ServerlessDatabaseCapacity` 값 평균을 보고합니다.
+ **`NCUUtilization`** - 이 지표는 사용 가능한 용량의 비율을 보고합니다. 이 값은 현재 `ServerlessDatabaseCapacity`(인스턴스 수준 또는 클러스터 수준 중 하나)를 DB 클러스터의 최대 용량 설정으로 나눈 값으로 계산됩니다.
클러스터 수준에서 이 지표가 100%에 가까워지면(즉, 클러스터가 최대한 크게 규모가 조정된 경우) 최대 용량 설정을 늘리는 것을 고려합니다.
라이터 인스턴스가 최대 용량에 근접하고 리더 인스턴스의 용량이 100%에 가까워지면 읽기 워크로드를 분산하기 위해 더 많은 리더 인스턴스를 추가하는 것이 좋습니다.
서버리스 인스턴스와 프로비저닝된 인스턴스의 경우 `CPUUtilization` 및 `FreeableMemory` 지표의 의미가 약간 다르다는 점을 참고합니다. 서버리스 컨텍스트에서 `CPUUtilization`은 현재 사용 중인 CPU 양을 최대 용량에서 사용할 수 있는 CPU 양으로 나눈 비율입니다. 마찬가지로 `FreeableMemory`는 인스턴스가 최대 용량에 도달했을 때 사용할 수 있는 여유 메모리의 양을 보고합니다.
다음 예제에서는 Linux AWS CLI 에서를 사용하여 1시간 동안 10분마다 측정된 지정된 DB 인스턴스의 최소, 최대 및 평균 용량 값을 검색하는 방법을 보여줍니다. Linux `date` 명령은 현재 날짜 및 시각을 기준으로 시작 및 종료 시각을 지정합니다. `--query` 파라미터의 `sort_by` 함수는 다음과 같이 `Timestamp` 필드를 기준으로 결과를 시간순으로 정렬합니다.
```
aws cloudwatch get-metric-statistics \
--metric-name "ServerlessDatabaseCapacity" \
--start-time "$(date -d '1 hour ago')" \
--end-time "$(date -d 'now')" \
--period 600 \
--namespace "AWS/Neptune"
--statistics Minimum Maximum Average \
--dimensions Name=DBInstanceIdentifier,Value=(instance ID) \
--query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' \
--output table
```