성능 효율성 요소

AWS Well-Architected Framework의 성능 효율성 원칙은 데이터를 수집하거나 쿼리하는 동안 성능을 최적화하는 방법에 중점을 둡니다. 성능 최적화는 다음과 같은 점진적이고 지속적인 프로세스입니다.

• 비즈니스 요구 사항 확인

• 워크로드 성능 측정

• 성능이 낮은 구성 요소 식별

• 비즈니스 요구 사항에 맞게 구성 요소 튜닝

성능 효율성 원칙은 사용할 올바른 그래프 데이터 모델 및 쿼리 언어를 식별하는 데 도움이 되는 사용 사례별 지침을 제공합니다. 또한 Neptune Analytics로 데이터를 수집하고 사용할 때 따라야 할 모범 사례도 포함되어 있습니다.

성능 효율성 원칙은 다음 주요 영역에 중점을 둡니다.

• 그래프 모델링

• 쿼리 최적화

• 그래프 적정 크기 조정

• 쓰기 최적화

분석을 위한 그래프 모델링 이해

Amazon Neptune에 AWS Well-Architected Framework 적용 가이드에서는 성능 효율성을 위한 그래프 모델링에 대해 설명합니다. 성능에 영향을 미치는 모델링 결정에는 필요한 노드 및 엣지 선택, IDs, 레이블 및 속성, 엣지 방향, 레이블이 일반 레이블인지 아니면 특정 노드인지 여부, 일반적으로 쿼리 엔진이 그래프를 탐색하여 일반적인 쿼리를 처리할 수 있는 효율성이 포함됩니다.

이러한 고려 사항은 Neptune Analytics에도 적용되지만 트랜잭션 및 분석 사용 패턴을 구분하는 것이 중요합니다. Neptune 데이터베이스와 같은 트랜잭션 데이터베이스의 쿼리에 효율적인 그래프 모델은 분석을 위해 재구성해야 할 수 있습니다.

예를 들어 신용 카드 결제에서 사기 패턴을 확인하는 것이 목적인 Neptune 데이터베이스의 사기 그래프를 생각해 보세요. 이 그래프에는 계정과 결제의 계정, 결제 및 기능(예: 이메일 주소, IP 주소, 전화번호)을 나타내는 노드가 있을 수 있습니다. 이 연결된 그래프는 지정된 결제에서 시작하고 여러 홉을 사용하여 관련 기능 및 계정을 찾는 가변 길이 경로를 통과하는 등의 쿼리를 지원합니다. 다음 그림은 이러한 그래프를 보여줍니다.

분석 요구 사항은 기능으로 연결된 계정 커뮤니티를 찾는 등 더 구체적일 수 있습니다. 이를 위해 WCC(약하게 연결된 구성 요소) 알고리즘을 사용할 수 있습니다. 이전 예제의 모델에 대해 실행하려면 여러 유형의 노드와 엣지를 통과해야 하므로 비효율적입니다. 다음 다이어그램의 모델이 더 효율적입니다. 계정 자체 또는 계정의 결제가 기능을 공유하는 경우 account 노드를 shares feature 엣지와 연결합니다. 예를 들어 [e-mail] 123에는 이메일 기능이 있으며 결제()에 동일한 이메일을 Account 456 사용합니다Payment def.

WCC의 계산 복잡성은 이며O(|E|logD), 여기서 |E|는 그래프의 엣지 수이고 D는 노드를 연결하는 직경(가장 긴 경로의 길이)입니다. 트랜잭션 모델은 필수 노드와 엣지를 생략하기 때문에 엣지 수와 직경을 최적화하고 WCC 알고리즘의 복잡성을 줄입니다.

Neptune Analytics를 사용하는 경우 필요한 알고리즘 및 분석 쿼리에서 다시 작업합니다. 필요한 경우 모델을 재구성하여 이러한 쿼리를 최적화합니다. 그래프에 데이터를 로드하기 전에 모델을 재구성하거나 그래프의 기존 데이터를 수정하는 쿼리를 작성할 수 있습니다.

쿼리 최적화

다음 권장 사항에 따라 Neptune Analytics 쿼리를 최적화합니다.

• 파라미터화된 쿼리와 기본적으로 활성화된 쿼리 계획 캐시를 사용합니다. 계획 캐시를 사용하면 엔진이 나중에 사용할 수 있도록 쿼리를 준비합니다. 단, 쿼리가 100밀리초 이내에 완료되므로 후속 호출에 소요되는 시간이 절약됩니다.

• 느린 쿼리의 경우 설명 계획을 실행하여 병목 현상을 파악하고 그에 따라 개선합니다.

• 벡터 유사성 검색을 사용하는 경우 임베딩이 작을수록 정확한 유사성 결과가 산출되는지 확인합니다. 더 작은 임베딩을 더 효율적으로 생성, 저장 및 검색할 수 있습니다.

• Neptune Analytics에서 openCypher를 사용하기 위한 문서화된 모범 사례를 따릅니다. 예를 들어 UNWIND 절에서 평면화된 맵을 사용하고 가능한 경우 엣지 레이블을 지정합니다.

• 그래프 알고리즘을 사용할 때는 알고리즘의 입력 및 출력, 컴퓨팅 복잡성, 작동 방식을 광범위하게 이해해야 합니다.

  • 그래프 알고리즘을 호출하기 전에 MATCH 절을 사용하여 입력 노드 세트를 최소화합니다. 예를 들어 노드가 너비 우선 검색(BFS)을 수행하도록 제한하려면 Neptune Analytics 설명서에 제공된 예제를 따르세요.

  • 가능하면 노드 및 엣지 레이블을 기준으로 필터링합니다. 예를 들어 BFS에는 특정 노드 레이블(vertexLabel) 또는 특정 엣지 레이블()에 대한 순회를 필터링하는 입력 파라미터가 있습니다edgeLabels.

  • 와 같은 경계 파라미터를 사용하여 결과를 제한maxDepth합니다.

  • concurrency 파라미터로 실험합니다. 사용 가능한 모든 알고리즘 스레드를 사용하여 처리를 병렬화하는 값 0으로 시도해 보세요. 파라미터를 1로 설정하여 단일 스레드 실행과 비교합니다. 알고리즘은 단일 스레드에서, 특히 병렬 처리로 실행 시간이 크게 단축되지 않고 오버헤드가 발생할 수 있는 얕은 너비 우선 검색과 같은 작은 입력에서 더 빠르게 완료될 수 있습니다.

  • 유사한 유형의 알고리즘 중에서 선택합니다. 예를 들어 Bellman-Ford와 delta-stepping은 모두 단일 소스 최단 경로 알고리즘입니다. 자체 데이터 세트로 테스트할 때 두 알고리즘을 모두 시도하고 결과를 비교합니다. Delta-stepping은 계산 복잡성이 낮기 때문에 Bellman-Ford보다 빠른 경우가 많습니다. 그러나 성능은 데이터 세트 및 입력 파라미터, 특히 delta 파라미터에 따라 달라집니다.

쓰기 최적화

Neptune Analytics에서 쓰기 작업을 최적화하려면 다음 사례를 따르세요.

• 그래프에 데이터를 로드하는 가장 효율적인 방법을 찾습니다. Amazon S3의 데이터에서 로드할 때 데이터가 50GB보다 큰 경우 대량 가져오기를 사용합니다. 더 작은 데이터의 경우 배치 로드를 사용합니다. 배치 로드를 실행할 때 out-of-memory 오류가 발생하는 경우 m-NCU 값을 늘리거나 로드를 여러 요청으로 분할하는 것이 좋습니다. 이를 위한 한 가지 방법은 S3 버킷의 여러 접두사로 파일을 분할하는 것입니다. 이 경우 각 접두사에 대해 배치 로드를 개별적으로 호출합니다.

• 대량 가져오기 또는 배치 로더를 사용하여 초기 그래프 데이터 세트를 채웁니다. 트랜잭션 openCypher 생성, 업데이트 및 삭제 작업은 작은 변경에만 사용합니다.

• 대량 가져오기 또는 동시성이 1(단일 스레드)인 배치 로더를 사용하여 그래프에 임베딩을 수집합니다. 다음 방법 중 하나를 사용하여 임베딩을 미리 로드해 보세요.

• 벡터 유사성 검색 알고리즘에서 정확한 유사성 검색에 필요한 벡터 임베딩의 차원을 평가합니다. 가능하면 더 작은 차원을 사용합니다. 따라서 임베딩의 로드 속도가 빨라집니다.

• 필요한 경우 변형 알고리즘을 사용하여 알고리즘 결과를 기억합니다. 예를 들어 도 변형 중심 알고리즘은 각 입력 노드의 정도를 찾고 해당 값을 노드의 속성으로 씁니다. 이러한 노드를 둘러싼 연결이 이후에 변경되지 않으면 속성에 올바른 결과가 포함됩니다. 알고리즘을 다시 실행할 필요가 없습니다.

• 다시 시작해야 하는 경우 그래프 재설정 관리 작업을 사용하여 모든 노드, 엣지 및 임베딩을 지웁니다. 그래프가 큰 경우 openCypher 쿼리를 사용하여 모든 노드, 엣지 및 임베딩을 삭제할 수 없습니다. 대규모 데이터 세트에 대한 단일 드롭 쿼리는 시간 초과될 수 있습니다. 크기가 증가하면 데이터 세트를 제거하는 데 시간이 더 걸리고 트랜잭션 크기가 증가합니다. 반대로 그래프 재설정을 완료하는 데 걸리는 시간은 거의 일정하며, 작업은 스냅샷을 실행하기 전에 스냅샷을 생성하는 옵션을 제공합니다.

적절한 크기의 그래프

전체 성능은 Neptune Analytics 그래프의 프로비저닝된 용량에 따라 달라집니다. 용량은 메모리 최적화 Neptune 용량 단위(m-NCUs)라는 단위로 측정됩니다. 그래프 크기와 쿼리를 지원하기에 그래프의 크기가 충분한지 확인합니다. 용량이 증가해도 개별 쿼리의 성능이 반드시 개선되는 것은 아닙니다.

가능하면 Amazon S3 또는 기존 Neptune 클러스터 또는 스냅샷과 같은 기존 소스에서 데이터를 가져와 그래프를 생성합니다. 최소 및 최대 용량에 경계를 둘 수 있습니다. 기존 그래프에서 프로비저닝된 용량을 변경할 수도 있습니다.

NumQueuedRequestsPerSec, , , NumOpenCypherRequestsPerSecGraphStorageUsagePercentGraphSizeBytes, 등의 CloudWatch 지표를 모니터링CPUUtilization하여 그래프의 크기가 적절한지 평가합니다. 그래프 크기와 로드를 지원하는 데 더 많은 용량이 필요한지 확인합니다. 이러한 지표 중 일부를 해석하는 방법에 대한 자세한 내용은 운영 우수성 원칙 섹션을 참조하세요.