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

ISVs 운영 모범 사례

이 섹션의 많은 지침은 모든 고객에 대한 모범 사례이지만 ISVs.

최신 버전으로 Neptune 클러스터 업데이트

Amazon Neptune 릴리스 정보에서 모든 버전에 여러 버그 수정, 성능 개선 및 새로운 기능이 포함되어 있음을 확인할 수 있습니다. Neptune 클러스터를 가능한 한 최신 버전으로 유지합니다.

워크로드에서 이전에 검색되지 않은 버그를 발견하고 클러스터가 최신 버전인 경우 Neptune 엔지니어는 클러스터에 대한 프라이빗 패치를 생성할 수 있습니다(보증되고 원하는 경우). 패치는 해당 수정 사항을 정식으로 사용할 수 있는 다음 릴리스까지 연결될 수 있습니다. 클러스터를 최신 버전으로 업데이트하는 데 도움이 되도록 Neptune 블루/그린 솔루션을 사용합니다.

데이터 수집을 위해 삭제 및 교체 대신 델타 사용

여러 기술을 사용하여 Neptune에 데이터를 수집하거나 쓸 수 있습니다. 많은 고객이 피드에 변경 사항이 수신될 때마다 그래프를 삭제하고 다시 삽입하여 데이터 수집을 간소화하려고 합니다. 각 노드에 last-modified 속성을 추가하고 지정된 날짜 이후 수정되지 않은 노드를 주기적으로 스캔하여 삭제할 수 있습니다. 이러한 기술은 데이터 수집 프로세스를 단순화하지만 Neptune 클러스터에 장기적인 상태 및 확장성 영향을 미칩니다.

먼저 Neptune은 문자열의 사전 인코딩을 사용합니다. 노드 및 엣지의 IDs를 명시적으로 지정하지 않는 한 Neptune은 ID에 대한 문자열로 표시되는 GUID를 생성하고 해당 문자열을 사전에 저장합니다. 객체를 지속적으로 삭제하고 추가하는 경우 자동으로 생성된 IDs로 인해 사전에 팽창이 발생합니다.

둘째, Neptune은 최대 초당 약 120K 객체를 수집하도록 스케일 업합니다. 객체를 지속적으로 삭제하고 추가하는 경우 기본적으로 변경되지 않는 객체에서 해당 대역폭을 많이 소비합니다. 이렇게 하면 클러스터에서 호스팅할 수 있는 테넌트 수가 제한되고, 클러스터에 더 큰 라이터 인스턴스가 필요하며, 더 많은 I/O 작업이 필요합니다. 이러한 모든 요인으로 인해 비용이 증가합니다.

삭제 및 추가 메서드를 사용하는 대신 변경된 내용의 실제 델타를 계산하는 방법을 개발하는 것이 좋습니다. 그러나 일부 데이터 소스는 이에 도움이 되지 않습니다(예: 현재 상태를 반환하는 API 호출 또는 변경된 내용을 정확하게 추적하지 않는 이벤트). 원시 데이터 소스가 변경 사항을 식별하는 데 도움이 되지 않는 경우 추출, 변환 및 로드(ETL) 프로세스를 사용하여 델타를 계산합니다. 예를 들어 각 이전 데이터 캡처의 스냅샷을 Parquet 형식으로 유지하고, AWS Glue 를 사용하여 해당 스냅샷 간의 차이를 계산하고, 차이점만 Neptune에 푸시할 수 있습니다.

테넌트와 함께 Neptune 비용이 어떻게 발전할지 모델링합니다.

사일로, 풀 또는 하이브리드 모델을 사용하든 클라우드 비용은 테넌트의 크기에 따라 조정됩니다. 동시 연결이 더 많이 필요한 테넌트는 동시 연결이 적은 테넌트보다 더 큰 인스턴스 또는 더 많은 읽기 전용 복제본이 필요합니다. 더 빠른 데이터 수집이 필요한 테넌트에도 마찬가지입니다.

Neptune 클러스터 비용의 세 가지 구성 요소는 인스턴스 크기(및 수), 데이터 크기(GB-월), I/O 작업(백만 개당)입니다. 이러한 비용은 일반적으로 워크로드별로 다르지만 크기 및 데이터 볼륨에 따라 규모가 조정되지만 AWS 도구를 사용하여 측정할 수 있습니다. 시간이 지남에 따라 크기가 어떻게 달라지는지 포함하여 테넌트 크기의 주요 지표를 기준으로 규모 조정의 경제를 추적하고 이해합니다. I/O 요금의 예측 불가능이 마진에 영향을 미치는 경우 보다 예측 가능한 비용으로 Neptune I/O 최적화 스토리지를 선택하는 것이 좋습니다.

고객 수요에 맞게 클러스터 확장

Neptune 인스턴스 크기의 크기를 올바르게 조정하기 위한 시도된 공식이나 실제 공식은 없습니다. Neptune 설명서는 지침을 제공하지만 직접 매핑을 추천할 변수가 너무 많습니다. 이러한 변수에는 다음이 포함되지만 이에 국한되지는 않습니다.

워크로드 및 테넌트 프로파일에 대한 최적의 크기를 결정하기 위한 테스트를 계획합니다. 일반적으로 비용 효율성과 예측 가능성을 위해 프로비저닝된 인스턴스를 사용하는 것이 좋습니다. 고객 경험 목표가 비용보다 최적의 규모 조정을 우선시하는 경우 Neptune Serverless 인스턴스를 사용하여 워크로드 변동에 관계없이 보다 일관된 경험을 보장하는 것이 좋습니다.

테넌트 읽기 워크로드의 피크와 트러프에 상당한 변동성이 있는 경우 Neptune Serverless 인스턴스를 Neptune Auto Scaling과 결합합니다.   새 읽기 전용 복제본이 초기화된 후 온라인 상태가 되는 데 보통 10~15분이 걸립니다. 즉, Auto Scaling만으로는 트래픽의 장기적인 변화를 처리할 수 있지만 빠르게 변화하는 활동 급증에는 충분하지 않습니다. Neptune Serverless와 Neptune Auto Scaling을 결합하여 인스턴스를 확장 또는 축소하고 읽기 전용 복제본 수를 확장 및 축소할 수 있습니다.

테넌트의 워크로드 프로파일 또는 서비스 수준 계약(SLAs)이 크게 다른 경우 사용자 지정 엔드포인트 및 전용 읽기 전용 복제본을 사용하여 트래픽을 해당 트래픽에 최적화된 인스턴스로 전달하는 것이 좋습니다. 최적화에는 인스턴스의 다른 크기, 특정 쿼리 패턴 또는 버퍼 캐시 사전 워밍이 포함될 수 있습니다.