Amazon Neptune DB 클러스터 및 인스턴스

Amazon Neptune DB 클러스터는 쿼리를 통해 데이터에 대한 액세스를 관리합니다. 클러스터는 다음과 같이 구성됩니다.

• 기본 DB 인스턴스 1개.

• 읽기 전용 복제본 DB 인스턴스 최대 15개.

클러스터의 모든 인스턴스는 신뢰성과 고가용성을 위해 설계된 동일한 기본 관리형 스토리지 볼륨을 공유합니다.

Neptune 엔드포인트를 통해 DB 클러스터의 DB 인스턴스에 연결할 수 있습니다.

Neptune DB 클러스터의 기본 DB 인스턴스

기본 DB 인스턴스는 DB 클러스터의 기본 스토리지 볼륨에 대한 모든 쓰기 작업을 조정합니다. 또한 읽기 작업도 지원합니다.

Neptune DB 클러스터에는 기본 DB 인스턴스가 하나만 있을 수 있습니다. 기본 인스턴스를 사용할 수 없게 되면 Neptune은 사용자가 지정할 수 있는 우선순위의 읽기 전용 복제본 인스턴스 중 하나로 자동 장애 조치합니다.

Neptune DB 클러스터의 읽기 전용 복제본 DB 인스턴스

DB 클러스터를 위한 기본 인스턴스를 생성한 다음에는 읽기 전용 쿼리를 지원하기 위해 DB 클러스터에 15개까지 읽기 전용 복제본 인스턴스를 생성할 수 있습니다.

Neptune 읽기 전용 복제본 DB 인스턴스는 클러스터 볼륨의 읽기 연산에만 사용되므로, 읽기 용량을 확장하는 데 적합합니다. 모든 쓰기 연산은 기본 인스턴스에서 관리합니다. 읽기 전용 복제본 DB 인스턴스마다 자체 엔드포인트가 있습니다.

클러스터 스토리지 볼륨은 클러스터의 모든 인스턴스에서 공유되므로, 전체 읽기 전용 복제본 인스턴스는 복제 지연이 거의 없이 쿼리 결과에 대해 동일한 데이터를 반환합니다. 이러한 지연은 대개 기본 인스턴스에서 업데이트를 쓴 후 100밀리초를 넘지 않습니다. 하지만 쓰기 작업의 볼륨이 매우 클 때는 다소 길어질 수 있습니다.

읽기 전용 복제본이 기본 인스턴스의 장애 조치 대상 역할을 하기 때문에 여러 가용 영역에서 하나 이상의 읽기 전용 복제본 인스턴스를 사용 가능하면 가용성이 향상될 수 있습니다. 즉, 기본 인스턴스에 장애가 발생하면 Neptune은 읽기 전용 복제본 인스턴스를 기본 인스턴스로 승격합니다. 이 경우 승격된 인스턴스가 재부팅되는 동안 잠시 중단이 발생하며, 이 동안 기본 인스턴스에 대한 읽기 및 쓰기 요청이 예외적으로 실패합니다.

반대로 DB 클러스터에 읽기 전용 복제본 인스턴스가 포함되어 있지 않으면 기본 인스턴스에 장애가 발생해도 DB 클러스터를 다시 만들 때까지 사용할 수 없습니다. 기본 인스턴스를 다시 만드는 것은 읽기 전용 복제본을 승격하는 것보다 훨씬 더 오래 걸립니다.

고가용성을 보장하려면 기본 인스턴스와 동일한 DB 인스턴스 클래스를 갖고 기본 인스턴스와는 다른 가용 영역에 위치한 하나 이상의 읽기 전용 복제본 인스턴스를 생성하는 것이 좋습니다. Neptune DB 클러스터의 내결함성을 참조하세요.

이 콘솔을 사용하면 DB 클러스터 생성 시 다중 AZ를 지정함으로써 간편하게 다중 AZ 배포를 생성할 수 있습니다. DB 클러스터가 단일 가용 영역에 있는 경우에는 다중 AZ DB 클러스터가 다른 가용 영역에 Neptune 복제본을 추가하도록 할 수 있습니다.

참고

암호화되지 않은 Neptune DB 클러스터의 암호화된 읽기 전용 복제본 인스턴스 또는 암호화된 Neptune DB 클러스터에 대한 암호화되지 않은 읽기 전용 복제본 인스턴스를 생성할 수 없습니다.

Neptune 읽기 전용 복제본 DB 인스턴스 생성 방법에 대한 자세한 내용은 콘솔을 사용하여 Neptune 리더 인스턴스 생성 섹션을 참조하세요.

Neptune DB 클러스터의 DB 인스턴스 크기 조정

사용자 및 메모리 요구 CPU 사항에 따라 Neptune DB 클러스터의 인스턴스 크기를 조정합니다. 인스턴스의 개수에 vCPUs 따라 들어오는 쿼리를 처리하는 쿼리 스레드 수가 결정됩니다. 인스턴스의 메모리 양에 따라 기본 스토리지 볼륨에서 가져온 데이터 페이지의 복사본을 저장하는 데 사용되는 버퍼 캐시의 크기가 결정됩니다.

각 Neptune DB 인스턴스의 쿼리 스레드 수는 해당 인스턴스의 2x와 같습니다. vCPUs 예를 r5.4xlarge 들어 An은 vCPUs 16개이면 쿼리 스레드가 32개이므로 32개의 쿼리를 동시에 처리할 수 있습니다.

모든 쿼리 스레드가 점유된 상태에서 도착한 추가 쿼리는 서버 측 대기열에 추가되고 쿼리 스레드가 사용 가능한 상태가 되는 대로 처리됩니다. FIFO 이 서버 측 대기열에는 약 8,000개의 보류 중인 요청을 보관할 수 있습니다. 용량이 가득 차면 Neptune은 추가 요청에 ThrottlingException으로 응답합니다. MainRequestQueuePendingRequests CloudWatch 메트릭을 사용하거나 Gremlin 쿼리 상태 엔드포인트를 매개 변수와 함께 사용하여 보류 중인 요청 수를 모니터링할 수 있습니다. includeWaiting

클라이언트 관점에서 볼 때 쿼리 실행 시간에는 쿼리를 실제로 실행하는 데 소요된 시간 외에 대기열에 머문 시간도 포함됩니다.

기본 DB 인스턴스의 모든 쿼리 스레드를 활용하는 지속적인 동시 쓰기 로드는 90% 이상의 CPU 사용률을 보이는 것이 이상적이며, 이는 서버의 모든 쿼리 스레드가 유용한 작업에 적극적으로 참여하고 있음을 나타냅니다. 그러나 동시 쓰기 로드가 지속되더라도 실제 CPU 사용률은 다소 낮은 경우가 많습니다. 이는 일반적으로 쿼리 스레드가 기본 스토리지 볼륨에 대한 I/O 연산이 완료될 때까지 대기하기 때문입니다. Neptune은 3개의 가용 영역에 걸쳐 6개의 데이터 사본을 만드는 쿼럼 쓰기를 사용하며, 6개의 스토리지 노드 중 4개의 스토리지 노드가 쓰기를 승인해야 내구성이 있다고 간주됩니다. 쿼리 스레드가 스토리지 볼륨에서 이 쿼럼을 대기하는 동안 쿼럼이 중지되어 사용률이 감소합니다. CPU

연속 쓰기를 수행하고 첫 번째 쓰기가 완료될 때까지 기다렸다가 다음 쓰기를 시작하는 직렬 쓰기 부하가 있는 경우 CPU 사용률은 여전히 낮을 것으로 예상할 수 있습니다. 정확한 양은 쿼리 스레드 수 (쿼리 스레드가 많을수록 CPU 쿼리당 전체 수가 적음) 에 따라 달라지지만 I/O 대기 시 일부 감소가 발생할 수 있습니다. vCPUs

DB 인스턴스의 크기를 조정하는 최적의 방법에 대한 자세한 내용은 적합한 Neptune DB 인스턴스 유형 선택을 참조하세요. 각 인스턴스 유형의 요금은 Neptune 요금 페이지를 참조하세요.

Neptune의 DB 인스턴스 성능 모니터링

Neptune의 CloudWatch 측정치를 사용하여 DB 인스턴스의 성능을 모니터링하고 클라이언트가 관찰한 쿼리 지연 시간을 추적할 수 있습니다. Neptune에서 DB 인스턴스 성능을 모니터링하는 CloudWatch 데 사용을 참조하세요.