기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 읽기 쿼리를 가속화할 수 있는 Neptune 조회 캐시
Amazon Neptune은 `R5d` 인스턴스의 NVMe 기반 SSD를 사용하여 속성값 또는 RDF 리터럴을 자주 반복적으로 조회하는 쿼리의 읽기 성능을 향상시키는 조회 캐시를 구현합니다. 조회 캐시는 이러한 값을 NVMe SSD 볼륨에 임시로 저장하므로, 빠르게 액세스할 수 있습니다.
메모리가 아닌 클러스터 스토리지 볼륨에서 속성값이나 리터럴을 검색해야 하는 경우 많은 수의 버텍스와 엣지 또는 많은 RDF 트리플의 속성을 반환하는 읽기 쿼리는 지연 시간이 길어질 수 있습니다. 자격 증명 그래프에서 많은 수의 전체 이름을 반환하거나 사기 감지 그래프에서 IP 주소를 반환하는 장기 실행 읽기 쿼리를 예로 들 수 있습니다. 쿼리에서 반환되는 속성값 또는 RDF 리터럴의 수가 증가하면 사용 가능한 메모리가 줄어들고 쿼리 실행 성능이 크게 저하될 수 있습니다.
# Neptune 조회 캐시의 사용 사례
조회 캐시는 읽기 쿼리가 매우 많은 수의 버텍스 및 엣지 또는 RDF 트리플의 속성을 반환하는 경우에만 유용합니다.
쿼리 성능을 최적화하기 위해 Amazon Neptune은 `R5d` 인스턴스 유형을 사용하여 이러한 속성값 또는 리터럴에 대한 대량 캐시를 생성합니다. 그러면 캐시에서 검색하는 것이 클러스터 스토리지 볼륨에서 검색하는 것보다 훨씬 빠릅니다.
일반적으로 다음 세 조건이 모두 충족되는 경우에만 조회 캐시를 활성화하는 것이 좋습니다.
+ 읽기 쿼리의 지연 시간이 증가하는 경우.
+ 또한 읽기 쿼리를 실행할 때 `BufferCacheHitRatio` [CloudWatch 지표](cw-metrics.md#cw-metrics-available)가 감소하는 경우([Amazon CloudWatch를 사용하여 Neptune 모니터링](cloudwatch.md) 참조).
+ 읽기 쿼리가 결과를 렌더링하기 전에 반환 값을 구체화하는 데 많은 시간을 소비하고 있는 경우(쿼리에 대해 구체화되고 있는 속성값의 수를 확인하는 방법은 아래 Gremlin 프로필 예제 참조).
**참고**
이 기능은 위에서 설명한 특정 *시나리오에서만* 유용합니다. 예를 들어, 조회 캐시는 집계 쿼리에 전혀 도움이 되지 않습니다. 조회 캐시를 활용할 수 있는 쿼리를 실행하는 경우가 아니라면 동일하고 비용이 저렴한 `R5` 인스턴스 유형 대신 `R5d` 인스턴스 유형을 사용할 이유가 없습니다.
Gremlin을 사용하는 경우 [Gremlin `profile` API](gremlin-profile-api.md)로 쿼리의 구체화 비용을 평가할 수 있습니다. '인덱스 작업'에는 실행 중에 구체화된 용어 수가 표시됩니다.
```
Index Operations
Query execution:
# of statement index ops: 3
# of unique statement index ops: 3
Duplication ratio: 1.0
# of terms materialized: 5273
Serialization:
# of statement index ops: 200
# of unique statement index ops: 140
Duplication ratio: 1.43
# of terms materialized: 32693
```
구체화된 숫자가 아닌 용어의 수는 Neptune이 수행해야 하는 용어 조회 횟수에 정비례합니다.
# 조회 캐시 사용
조회 캐시는 기본적으로 자동 활성화되는 `R5d` 인스턴스 유형에서만 사용할 수 있습니다. Neptune `R5d` 인스턴스는 `R5` 인스턴스와 사양이 동일하며, 최대 1.8TB의 로컬 NVMe 기반 SSD 스토리지를 제공합니다. 조회 캐시는 인스턴스별로 다르며, 혜택을 받는 워크로드는 특히 Neptune 클러스터의 `R5d` 인스턴스로 전달되고 다른 워크로드는 `R5` 또는 다른 인스턴스 유형으로 전달될 수 있습니다.
Neptune 인스턴스에서 조회 캐시를 사용하려면 해당 인스턴스를 `R5d` 인스턴스 유형으로 업그레이드하면 됩니다. 이 작업을 수행하면 Amazon Neptune은 자동으로 [neptune\$1lookup\$1cache](parameters.md#parameters-db-cluster-parameters-neptune_lookup_cache) DB 클러스터 파라미터를 `1`(활성화됨)으로 설정하고 해당 인스턴스에 조회 캐시를 생성합니다. 그런 다음 [인스턴스 상태](access-graph-status.md) API를 사용하여 캐시가 활성화되었는지 확인할 수 있습니다.
마찬가지로 특정 인스턴스에서 조회 캐시를 비활성화하려면 인스턴스 규모를 `R5d` 인스턴스 유형에서 동등한 `R5` 인스턴스 유형으로 축소하세요.
`R5d` 인스턴스가 시작되면 조회 캐시가 활성화되고 콜드 스타트 모드가 됩니다. 즉, 비어 있습니다. Neptune은 쿼리를 처리하는 동안 먼저 조회 캐시에서 속성값 또는 RDF 리터럴을 확인하고 속성이 아직 없으면 추가합니다. 이렇게 하면 캐시가 점차 워밍업됩니다.
속성값 또는 RDF 리터럴 조회가 필요한 읽기 쿼리를 R5d *리더* 인스턴스로 보내면 캐시가 워밍업되는 동안 읽기 성능이 약간 저하됩니다. 그러나 캐시를 워밍업하면 읽기 성능이 크게 향상되고 클러스터 스토리지가 아닌 캐시에 조회가 발생하여 I/O 비용이 감소할 수도 있습니다. 메모리 사용률도 향상됩니다.
*라이터* 인스턴스가 `R5d`인 경우 쓰기 작업마다 조회 캐시를 자동으로 워밍업합니다. 이 접근 방식은 쓰기 쿼리의 지연 시간을 약간 늘리지만, 조회 캐시를 더 효율적으로 워밍업합니다. 그런 다음 속성-값 또는 RDF 리터럴 조회가 필요한 읽기 쿼리를 라이터 인스턴스로 보내면 값이 이미 캐싱되어 있기 때문에 읽기 성능이 즉시 향상되기 시작합니다.
또한 `R5d` 라이터 인스턴스에서 대량 로더를 실행하는 경우 캐시 때문에 성능이 약간 저하될 수도 있습니다.
조회 캐시는 각 노드별로 적용되므로, 호스트 교체는 캐시를 콜드 스타트로 재설정합니다.
DB 클러스터의 모든 인스턴스에서 조회 캐시를 일시적으로 비활성화하려면 DB 클러스터 파라미터 [neptune\$1lookup\$1cache](parameters.md#parameters-db-cluster-parameters-neptune_lookup_cache)를 `0`(비활성화)으로 설정할 수 있습니다. 하지만 일반적으로 특정 인스턴스 규모를 `R5d` 인스턴스 유형에서 `R5` 인스턴스 유형으로 축소하여 해당 인스턴스의 캐시를 비활성화하는 것이 더 합리적입니다.