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

비용 최적화 요소

AWS Well-Architected Framework의 비용 최적화 원칙은 불필요한 비용을 방지하는 데 중점을 둡니다. 다음 권장 사항은 Amazon Neptune의 비용 최적화 설계 원칙 및 아키텍처 모범 사례를 충족하는 데 도움이 될 수 있습니다.

비용 최적화 원칙은 다음 핵심 영역에 중점을 둡니다.

필요한 사용 패턴 및 서비스 이해

Neptune은 데이터 모델에 식별 가능한 그래프 구조가 있고 쿼리가 관계를 탐색하고 여러 홉을 통과해야 하는 경우 워크로드에 적합합니다. 그래프 데이터베이스는 다음 패턴에 적합하지 않습니다.

특정 액세스 패턴에 대해 여러 목적별 데이터베이스를 함께 사용하면 모든 요구 사항을 해결할 수 있는지 고려합니다. 예제:

다음을 포함하여 Neptune과 상호 작용하고 보완하는 서비스와 관련된 비용을 이해합니다.

비용에 주의를 기울여 리소스 선택

Neptune 요금은 시간당 인스턴스 비용(또는 서버리스에 소비되는 Neptune 컴퓨팅 단위), 데이터 I/O 및 스토리지 사용량을 기준으로 합니다. 인스턴스는 평균적으로 전체 비용의 85%를 차지하므로 적정 규모로 조정하면 비용에 상당한 영향을 미칠 수 있습니다. 인스턴스를 적정 규모로 조정하는 가장 좋은 방법은 다양한 인스턴스에서 애플리케이션 성능을 테스트하고 다음 요소를 비교하는 것입니다.

인스턴스 비용은 동일한 인스턴스 패밀리 내 크기에 따라 선형적으로 조정됩니다. db.r6i.2xlarge 인스턴스의 시간당 비용은 db.r6i.xlarge 인스턴스의 두 배이며 리소스 할당도 두 배입니다. db.r6i.24xlarge 인스턴스는 db.r6i.xlarge 인스턴스의 시간당 비용의 24배입니다.

지원해야 하는 동시 쿼리 수를 추정합니다. 읽기 전용 쿼리를 처리하기 위해 0~15개의 읽기 복제본을 보유할 수 있습니다. 요일, 주 또는 월에 따라 요구 사항이 다른 경우 여러 개의 작은 인스턴스를 사용하여 일정에 따라 조정할 수 있습니다. 인스턴스의 각 vCPU는 동시 쿼리를 처리하기 위한 두 개의 스레드를 제공합니다. 각각 4개의 vCPU가 있는 3개의 db.r6i.xlarge 읽기 복제본은 24개의 동시 쿼리를 처리할 수 있습니다.

트래픽 볼륨이 초당 쿼리(QPS)로 측정되는 경우 쿼리의 평균 지연 시간을 확인하기 위해 실험해야 합니다. Neptune 클러스터가 지원할 수 있는 초당 쿼리 수는 vCPU × 2 × (1 second/average query latency)와 같습니다. 예를 들어 vCPU가 4개이고 쿼리 지연 시간이 100밀리초(0.1초)인 경우 QPS = 4 × 2 × (1s/0.1s) = 80 queries per second입니다.

프로비저닝된 인스턴스는 지속적이고 안정적이며 예측 가능한 워크로드에서 서버리스보다 저렴합니다. 서버리스는 하루에 몇 시간 동안만 사용량이 매우 많고(예: db.r6i.4xlarge) 남은 시간 동안 트래픽이 거의 없는 워크로드(예: Neptune 컴퓨팅 유닛 1개)가 있는 경우 비용을 최적화할 수 있는 기회를 제공합니다. 몇 시간 동안 스케일 업했다가 다시 스케일 다운하는 서버리스 인스턴스는 프로비저닝된 db.r6i.4xlarge 인스턴스를 하루 종일 사용하는 것보다 비용이 저렴합니다.

Neptune 1.4.5.0 이상으로 업그레이드하고 r8g 인스턴스를 활용하여 r7g 또는와 같은 이전 세대 인스턴스보다 저렴한 비용으로 더 나은 읽기 및 쓰기 처리량을 달성하는 것이 좋습니다r6g. 자세한 내용은 Amazon Neptune v1.4.5를 사용하는 AWS Graviton4 R8g 인스턴스를 사용하여 쿼리 가격 대비 성능을 4.7배 향상(블로그 게시물)을 참조하세요.AWS

Neptune 클러스터는 기본적으로 표준 스토리지로 생성됩니다(콘솔을 사용하여 생성하는 경우 기본적으로 I/O 최적화 스토리지 선택). I/O 최적화 스토리지를 사용하면 스토리지 및 인스턴스에 약간 더 높은 비용을 지불하지만 I/O 비용은 없습니다. 이로 인해 반복 비용이 더 예측 가능하게 발생하지만 I/O 사용량이 일반적으로 낮은 경우 표준 스토리지를 활용하는 것이 더 비용 효율적일 수 있습니다. 처음에 많은 데이터를 로드하려는 경우 I/O 최적화 스토리지를 선택하고 초기 데이터 로드를 수행한 다음 표준 스토리지로 전환하여 비용을 최적화할 수 있습니다. 스토리지 유형은 결제 모델에만 영향을 미치며 Neptune DB 클러스터 또는 인스턴스 구성에는 기술적 차이가 없습니다. 30일에 한 번씩 스토리지 유형을 변경할 수 있습니다. 30일 후 세부 Neptune 비용을 확인하고 Neptune 요금 페이지를 사용하여 I/O 최적화 스토리지를 사용하여 비용이 더 높았는지 여부를 계산합니다. 그렇다면 표준 스토리지를 계속 사용하고, 그렇지 않으면 I/O 최적화로 다시 전환하세요.

워크로드에 가장 적합한 Neptune 인스턴스 구성 선택

2025년 7월 15일 AWS 계정 이전에를 생성한 경우 AWS 프리 티어를 사용하여 Neptune을 사용한 엔트리 레벨 실험을 수행할 수 있습니다. 750시간의 무료 db.t3.medium 및 db.t4g.medium 인스턴스 사용만으로도 작은 규모에서 Neptune을 이해하기에 충분합니다. 무료 평가판 기간이 종료된 후에도 클러스터는 유지됩니다. 단, 이후 사용량에 대해서는 요금이 부과됩니다.

db.t3.medium 및 db.t4g.medium 인스턴스는 openCypher, Graph Explorer 또는 다양한 생성형 AI 통합을 사용하지 않는 저비용 개발 환경에 적합합니다. 이러한 인스턴스는 패밀리 인스턴스(8:1) 또는 R 패밀리 인스턴스(1X6:1)보다 RAM-to-vCPU 비율(2:1)이 작습니다. 이렇게 하면 openCypher 성능, GenAI 통합(LLM에 그래프 스키마를 알리기 위해) 및 Graph Explorer를 활성화하는 DFE 엔진 통계를 사용할 수 없습니다. T 패밀리 인스턴스를 사용할 때 특히 앞서 언급한 워크로드의 경우 성능 프로필이 크게 다를 수 있습니다. 이러한 인스턴스는 쿼리가 그래프의 상당 부분을 탐색할 OutOfMemoryExceptions 때의 발생을 증가시킬 수도 있습니다. 후자 조건이 영향을 받을 수 있는지 확인하려면 BufferCacheHitRatio CloudWatch 지표를 확인합니다.

프로덕션 환경을 나타내지 않는 일관되지 않은 결과가 발생할 수 있으므로 T 패밀리 인스턴스로 성능 또는 로드 테스트를 수행하지 않는 것이 좋습니다.

프로비저닝된 인스턴스는 워크로드가 매우 안정적이고 예측 가능한 경우 최상의 비용과 성능 조합을 제공합니다. 필요한 요청 동시성과 쿼리 복잡성에 따라 인스턴스 크기를 선택합니다. 동시성이 높을수록 vCPU가 더 많이 필요합니다. 쿼리 복잡성이 높을수록 RAM이 더 많이 필요합니다. MainRequestQueuePendingRequests CloudWatch 지표를 사용하여 전자의 영향을 확인합니다(0보다 크면 처리할 수 있는 것보다 동시 요청어 더 많은 상태임을 나타냄). BufferCacheHitRatio CloudWatch 지표를 사용하여 후자의 영향을 확인합니다. 99.9% 미만으로 자주 떨어지는 비율은 평가 중인 그래프의 작업 부분을 포함할 RAM이 부족하여 캐시 스왑이 더 자주 발생함을 나타냅니다. R 인스턴스 패밀리가 충분한 동시성을 제공하지만 RAM이 충분하지 않은 경우 인스턴스 X 패밀리를 사용해 보는 것이 좋습니다.

서버리스 인스턴스의 이상적인 사용 사례는 Neptune 설명서에 설명되어 있습니다. 프로비저닝 또는 서버리스 중 가장 적합한 옵션이 확실하지 않고 비용이 주요 관심사인 경우 서버리스에서 워크로드를 테스트하여 사용된 NCU 수를 확인하고 프로비저닝(N hours × hourly provisioned cost) 비용을 서버리스(sum of NCUs × hourly cost per NCU)와 비교합니다. 동일한 크기의 프로비저닝 인스턴스에 대해 잘 모르는 경우 NCU 하나는 약 2GB의 RAM과 관련 vCPU 및 네트워킹에 해당합니다. 프로비저닝된 인스턴스가 r6i 패밀리인 경우 비율은 연결된 네트워킹과 함께 RAM 8GB당 vCPU 1개 또는 NCUs 4개입니다. Amazon Neptune 요금 계산기는 최적의 비용 구성을 결정하는 데 도움이 되는 비교도 제공합니다.

기본 및 복제본 인스턴스에 서버리스를 사용하는 경우 승격 티어 0 및 1의 읽기 복제본은 라이터 인스턴스에 따라 NCU를 조정하므로 장애 조치 이벤트가 발생할 경우 적절하게 조정됩니다. 라이터 또는 리더 중 어떤 인스턴스가 가장 많은 트래픽을 수신하는지에 따라 이러한 인스턴스에 대한 NCU 제한을 설정합니다.

클러스터가 연중무휴로 필요하지 않은 환경에서는 사용하지 않을 때 Neptune 인스턴스를 끄고 사용하기 전에 다시 시작하는 스크립트를 작성하는 것이 좋습니다. Neptune 인스턴스는 필요한 유지 관리 업데이트가 적용되도록 7일마다 자동으로 다시 시작됩니다. 인스턴스를 장기간 끄려는 경우 주간 스크립트를 사용하여 인스턴스를 다시 종료합니다.

데이터 스토리지 적정 규모 조정 및 전송

보다 효율적인 쿼리(예: 그래프에서 사용해야 하는 노드, 엣지 및 속성 수가 더 적은 쿼리)는 I/O 전송을 줄이고 필요한 버퍼 캐시가 적기 때문에 더 작은 인스턴스를 사용할 수 있습니다. 쿼리 언어의 프로파일 또는 설명 엔드포인트를 사용하여 쿼리를 최적화하고 쿼리 성능에 맞게 그래프 모델을 최적화하는 방법을 고려합니다.

Neptune은 큰 문자열에서 사전 인코딩을 사용하며, 해당 사전은 효율성이 아니라 성능에 최적화되어 있습니다. 속성에 대해 큰 BLOB, JSON 또는 빈번하게 변경되는 문자열이 있는 경우 Amazon S3, Amazon DynamoDB 또는 Amazon DocumentDB에서 이를 Neptune 외부에 저장하고 Neptune 노드 내에는 참조만 저장하는 방법을 고려합니다.

경우에 따라 더 큰 인스턴스 크기를 선택하는 방법이 더 저렴할 수 있습니다. 낮은 BufferCacheHitRatio로 인해 I/O 비용이 매우 높은 경우 더 큰 버퍼 캐시를 사용하면 해당 비용을 크게 줄일 수 있습니다. 스토리지에서 자주 전환되고 I/O 전송 비율을 발생시키는 대신 모든 데이터가 캐시에 맞춰지기 때문입니다.

Neptune은 쓸 때 복사 복제를 사용합니다. 그래프를 여러 샤드로 분할하기 위해 복제하는 경우 복제된 클러스터에서 원치 않는 데이터를 삭제하지 않는 방법이 더 효율적일 수 있습니다. 이 경우 새 데이터 페이지가 생성되어 스토리지 비용이 증가하기 때문입니다. 복제 이벤트 이전에 변경되지 않는 데이터는 두 클러스터에서 공유되는 단일 데이터 페이지에 존재하고, 해당 단일 사본에 대해서만 요금이 부과됩니다.

워크로드에 상당한 차이가 있는지 테스트하지 않은 경우 OSGP 인덱스를 활성화하거나 R5d 인스턴스를 사용하지 마세요. 둘 다 거의 발생하지 않는 시나리오를 위해 설계되었으며, 최소한의 이익 또는 전혀 얻는 이익 없이 비용이 증가할 수 있습니다.