Neo4j에서 Neptune으로 마이그레이션할 때 인프라 프로비저닝 - Amazon Neptune

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Neo4j에서 Neptune으로 마이그레이션할 때 인프라 프로비저닝

Amazon Neptune 클러스터는 스토리지, 쓰기 용량, 읽기 용량의 3차원으로 확장할 수 있도록 구축되었습니다. 아래 섹션에서는 마이그레이션 시 고려해야 할 특정 옵션에 대해 설명합니다.

스토리지 프로비저닝

모든 Neptune 클러스터의 스토리지는 관리 오버헤드 없이 자동으로 프로비저닝됩니다. 클러스터의 스토리지 요구 사항이 증가함에 따라 10GB 청크 단위로 동적으로 크기가 조정됩니다. 따라서 향후 데이터 증가에 대처하기 위해 스토리지를 예측하여 프로비저닝하거나 오버프로비저닝할 필요가 없습니다.

쓰기 용량 프로비저닝

Neptune은 Neptune 요금 페이지에서 제공되는 모든 인스턴스 크기에 맞게 세로로 확장할 수 있는 단일 라이터 인스턴스를 제공합니다. 라이터 인스턴스에서 데이터를 읽고 쓸 때 모든 트랜잭션은 Neptune의 트랜잭션 격리 수준에서 정의한 대로 데이터 격리를 통해 ACID를 준수합니다.

라이터 인스턴스의 최적 크기를 선택하려면 로드 테스트를 실행하여 워크로드에 맞는 최적의 인스턴스 크기를 결정해야 합니다. Neptune 내의 모든 인스턴스는 DB 인스턴스 클래스를 수정하여 언제든지 크기를 조정할 수 있습니다. 아래 클러스터를 프로비저닝할 때 최적의 인스턴스 크기 추정에 설명된 것처럼 동시성 및 평균 쿼리 지연 시간을 기준으로 시작 인스턴스 크기를 추정할 수 있습니다.

읽기 용량 프로비저닝

Neptune은 읽기 전용 복제본 인스턴스를 클러스터 내에 최대 15개(또는 Neptune 글로벌 데이터베이스의 경우 그 이상) 까지 추가하여 수평적으로 확장하고, Neptune 요금 페이지에서 제공하는 모든 인스턴스 크기에 맞춰 수직으로 확장할 수 있도록 구축되었습니다. 모든 Neptune 읽기 전용 복제본 인스턴스는 동일한 기본 스토리지 볼륨을 사용하므로 지연을 최소화하면서 투명한 데이터 복제가 가능합니다.

Neptune 클러스터 내에서 읽기 요청을 수평적으로 확장할 수 있을 뿐만 아니라 읽기 복제본은 라이터 인스턴스의 장애 조치 대상 역할을 하여 고가용성을 가능하게 합니다. 클러스터에서 읽기 전용 복제본의 적절한 수와 배치를 결정하는 방법에 대한 제안은 Amazon Neptune 기본 운영 지침을 참조하세요.

연결 및 워크로드를 예측할 수 없는 애플리케이션을 위해 Neptune은 지정한 기준에 따라 Neptune 복제본 수를 자동으로 조정할 수 있는 자동 크기 조정 기능도 지원합니다.

읽기 전용 복제본 인스턴스의 최적 크기와 수를 결정하려면 부하 테스트를 실행하여 지원해야 하는 읽기 워크로드의 특성을 파악해야 합니다. Neptune 내의 모든 인스턴스는 DB 인스턴스 클래스를 수정하여 언제든지 크기를 조정할 수 있습니다. 다음 섹션에 설명된 것처럼 동시성 및 평균 쿼리 지연 시간을 기준으로 시작 인스턴스 크기를 추정할 수 있습니다.

Neptune Serverless를 사용하여 필요에 따라 리더 및 라이터 인스턴스를 자동으로 확장할 수 있습니다.

예상 워크로드에 필요한 컴퓨팅 파워를 추정할 수 있으면 도움이 되는 경우가 많지만, 읽기 및 쓰기 용량을 자동으로 확장 및 축소하도록 Neptune Serverless 기능을 구성할 수 있습니다. 이를 통해 최대 요구 사항을 충족하는 동시에 수요가 감소하면 자동으로 규모를 축소할 수 있습니다.

클러스터를 프로비저닝할 때 최적의 인스턴스 크기 추정

최적의 인스턴스 크기를 예측하려면 Neptune의 평균 쿼리 지연 시간, 워크로드가 실행되는 시점의 평균 쿼리 지연 시간, 처리 중인 동시 쿼리 수를 알아야 합니다. 대략적인 인스턴스 크기는 평균 쿼리 지연 시간에 동시 쿼리 수를 곱한 값으로 계산할 수 있습니다. 이를 통해 워크로드를 처리하는 데 필요한 평균 동시 스레드 수를 알 수 있습니다.

Neptune 인스턴스의 각 vCPU는 두 개의 동시 쿼리 스레드를 지원할 수 있으므로 스레드를 2로 나누면 필요한 vCPU 수가 나오며, 이 수를 Neptune 요금 페이지의 적절한 인스턴스 크기와 연관시킬 수 있습니다. 예:

Average Query Latency: 30ms (0.03s) Number of concurrent queries: 1000/second Number of threads needed: 0.03 x 1000 = 30 threads Number of vCPUs needed: 30 / 2 = 15 vCPUs

이를 인스턴스의 vCPU 수와 연관시켜 보면 이 워크로드에 대해 권장되는 r5.4xlarge 인스턴스라는 대략적인 추정치를 얻을 수 있습니다. 이 추정치는 대략적인 것이며 인스턴스 크기 선택에 대한 초기 지침을 제공하기 위한 것일 뿐입니다. 모든 애플리케이션은 적절한 크기 조정을 거쳐 워크로드에 적합한 적절한 인스턴스 수와 유형을 결정해야 합니다.

메모리 요구 사항과 처리 요구 사항도 고려해야 합니다. Neptune은 쿼리로 액세스하는 데이터를 주 메모리 버퍼 풀 캐시에서 사용할 수 있을 때 가장 성능이 좋습니다. 메모리를 충분히 프로비저닝하면 I/O 비용도 크게 줄일 수 있습니다.

Neptune 클러스터의 인스턴스 크기 조정에 대한 추가 세부 정보 및 지침은 Neptune DB 클러스터의 DB 인스턴스 크기 조정 페이지에서 확인할 수 있습니다.