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

# Amazon Neptune Gremlin과 함께 AWS Lambda를 사용하기 위한 권장 사항
<a name="lambda-functions-gremlin-recommendations"></a>

이제 Lambda 실행 컨텍스트의 전체 수명 주기 동안 함수 간접 호출마다 연결 및 그래프 순회 소스를 하나씩 사용하는 대신 단일 연결 및 그래프 순회 소스를 사용하는 것이 좋습니다(모든 함수 간접 호출은 하나의 클라이언트 요청만 처리함). 동시 클라이언트 요청은 별도의 실행 컨텍스트에서 실행되는 여러 함수 인스턴스에서 처리되므로, 함수 인스턴스 내에서 동시 요청을 처리하기 위해 연결 풀을 유지할 필요가 없습니다. 사용 중인 Gremlin 드라이버에 연결 풀이 있는 경우 하나의 연결만 사용하도록 구성하세요.

연결 실패를 처리하려면 각 쿼리에 대해 재시도 로직을 사용하세요. 실행 컨텍스트의 수명 기간 동안 단일 연결을 유지하는 것이 목표이긴 하지만, 예상치 못한 네트워크 이벤트로 인해 연결이 갑자기 종료될 수 있습니다. 이러한 연결 실패는 사용 중인 드라이버에 따라 다른 오류로 나타납니다. Lambda 함수를 코딩하여 이러한 연결 문제를 처리하고 필요한 경우 재연결을 시도해야 합니다.

일부 Gremlin 드라이버는 자동으로 재연결을 처리합니다. 예를 들어, Java 드라이버는 클라이언트 코드를 대신하여 Neptune에 대한 연결 재설정을 자동으로 시도합니다. 이 드라이버를 사용하면 함수 코드에서 쿼리를 백오프하고 다시 시도하기만 하면 됩니다. 반대로 JavaScript와 Python 드라이버는 자동 재연결 로직을 구현하지 않으므로, 이러한 드라이버를 사용하면 함수 코드에서 백오프 후 다시 연결을 시도하고 연결이 다시 설정된 후에만 쿼리를 재시도해야 합니다.

여기의 코드 예제는 클라이언트가 재연결을 처리한다고 가정하지 않고 재연결 로직을 포함하고 있습니다.

# Lambda에서의 Gremlin 쓰기 요청 사용에 대한 권장 사항
<a name="lambda-functions-gremlin-write-recommendations"></a>

Lambda 함수가 그래프 데이터를 수정하는 경우 다음 예외를 처리하기 위해 back-off-and-retry 전략을 채택하는 것을 고려해 보세요.
+ **`ConcurrentModificationException`**   –   Neptune 트랜잭션 체계는 쓰기 요청이 때때로 `ConcurrentModificationException`와 함께 실패한다는 것을 의미합니다. 이러한 상황에서는 지수 백오프 기반 재시도 메커니즘을 사용해 보세요.
+ **`ReadOnlyViolationException`**   –   계획된 이벤트 또는 예상치 못한 이벤트의 결과로 클러스터 토폴로지가 언제든지 변경될 수 있으므로, 쓰기 책임이 클러스터의 한 인스턴스에서 다른 인스턴스로 이전될 수 있습니다. 함수 코드가 더 이상 기본(라이터) 인스턴스가 아닌 인스턴스에 쓰기 요청을 보내려고 하면 요청이 실패하고 `ReadOnlyViolationException`이 발생합니다. 이 경우 기존 연결을 닫고 클러스터 엔드포인트에 다시 연결한 다음 요청을 재시도하세요.

또한 back-off-and-retry 전략을 사용하여 쓰기 요청 문제를 처리하는 경우 생성 및 업데이트 요청에 대해 멱등성 쿼리를 구현하는 것도 좋습니다. 예를 들어, [fold().coalesce().unfold()](http://kelvinlawrence.net/book/Gremlin-Graph-Guide.html#upsert)를 사용해 보세요.

# Lambda에서의 Gremlin 읽기 요청 사용에 대한 권장 사항
<a name="lambda-functions-gremlin-read-recommendations"></a>

클러스터에 하나 이상의 읽기 전용 복제본이 있는 경우 이러한 복제본 간에 읽기 요청의 균형을 맞추는 것이 좋습니다. 한 가지 옵션은 [리더 엔드포인트](feature-overview-endpoints.md)를 사용하는 것입니다. 리더 엔드포인트는 복제본을 추가 또는 제거하거나 복제본을 승격하여 새 기본 인스턴스로 만들 때 클러스터 토폴로지가 변경되더라도 복제본 간의 연결 균형을 유지합니다.

하지만 리더 엔드포인트를 사용하면 경우에 따라 클러스터 리소스가 고르지 않게 사용될 수 있습니다. 리더 엔드포인트는 DNS 항목이 가리키는 호스트를 주기적으로 변경하여 작동합니다. DNS 항목이 변경되기 전에 클라이언트가 많은 연결을 열면 모든 연결 요청이 단일 Neptune 인스턴스로 전송됩니다. 처리량이 높은 Lambda 시나리오에서 Lambda 함수에 대한 동시 요청이 많으면 각각 고유한 연결을 가진 여러 실행 컨텍스트가 생성되는 경우가 이에 해당합니다. 이러한 연결이 거의 동시에 생성되는 경우 연결은 모두 클러스터의 동일한 복제본을 가리키고 실행 컨텍스트가 재활용될 때까지 해당 복제본을 계속 가리킬 가능성이 높습니다.

요청을 인스턴스 간에 분산할 수 있는 한 방법은 리더 엔드포인트가 아닌 복제 인스턴스 엔드포인트 목록에서 무작위로 선택한 인스턴스 엔드포인트에 연결하도록 Lambda 함수를 구성하는 것입니다. 이 접근 방식의 단점은 클러스터 구성 요소가 변경될 때마다 Lambda 코드가 클러스터를 모니터링하고 엔드포인트 목록을 업데이트하여 클러스터 토폴로지의 변경을 처리해야 한다는 것입니다.

클러스터의 인스턴스 간 읽기 요청의 균형을 유지해야 하는 Java Lambda 함수를 작성하는 경우, 클러스터 토폴로지를 인식하고 Neptune 클러스터의 인스턴스 세트에 연결과 요청을 공정하게 분배하는 Java Gremlin 클라이언트인 [Amazon Neptune용 Gremlin 클라이언트](https://github.com/aws/neptune-gremlin-client)를 사용할 수 있습니다. [이 블로그 게시물](https://aws.amazon.com/blogs/database/load-balance-graph-queries-using-the-amazon-neptune-gremlin-client/)에는 Amazon Neptune용 Gremlin 클라이언트를 사용하는 샘플 Java Lambda 함수가 포함되어 있습니다.

# Neptune Gremlin Lambda 함수의 콜드 스타트를 늦출 수 있는 요인
<a name="lambda-functions-gremlin-cold-start-recommendations"></a>

AWS Lambda 함수가 처음 간접적으로 호출되는 경우를 콜드 스타트라고 합니다. 콜드 스타트의 지연 시간을 증가시킬 수 있는 몇 가지 요인은 다음과 같습니다.
+ **Lambda 함수에 충분한 메모리를 할당해야 합니다.**   –   AWS Lambda는 함수에 할당한 [메모리에 비례하여 CPU 주기를 선형적으로 할당](https://docs.aws.amazon.com/lambda/latest/dg/configuration-console.html)하기 때문에 콜드 스타트 동안 Lambda 함수의 컴파일 속도가 EC2에서보다 상당히 느릴 수 있습니다. 1,769MB의 메모리를 사용하는 함수는 1개의 전체 vCPU(1초당 하나의 vCPU-초 크레딧)와 맞먹습니다. 적절한 CPU 주기를 수신하기에 충분한 메모리를 할당하지 않을 경우의 영향은 Java로 작성된 대규모 Lambda 함수의 경우 특히 두드러집니다.
+ **[IAM 데이터베이스 인증을 활성화](iam-auth-enable.md)하면 콜드 스타트가 느려질 수 있습니다.**   –   AWS Identity and Access Management(IAM) 데이터베이스 인증은 특히 Lambda 함수가 새 서명 키를 생성해야 하는 경우 콜드 스타트를 늦출 수도 있습니다. 이 지연 시간은 콜드 스타트에만 영향을 주고 후속 요청에는 영향을 주지 않습니다. IAM DB 인증이 연결 보안 인증 정보를 설정하고 나면 Neptune이 여전히 유효한지 주기적으로 검증하기 때문입니다.