기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Neo4j에서 Neptune으로 애플리케이션 마이그레이션
Neo4j에서 Neptune으로 데이터를 마이그레이션한 후 다음 단계는 애플리케이션 자체를 마이그레이션하는 것입니다. 데이터와 마찬가지로 사용하는 도구, 요구 사항, 아키텍처 차이 등에 따라 애플리케이션을 마이그레이션하는 방법에는 여러 가지가 있습니다. 이 프로세스에서 일반적으로 고려해야 하는 사항이 아래에 요약되어 있습니다.
## Neo4j에서 Neptune으로 이동 시 마이그레이션 연결
현재 Bolt 드라이버를 사용하지 않거나 다른 드라이버를 사용하려는 경우, 반환된 데이터에 대한 전체 액세스를 제공하는 [HTTPS 엔드포인트](access-graph-opencypher-queries.md)에 연결할 수 있습니다.
[Bolt 프로토콜](access-graph-opencypher-bolt.md)을 사용하는 애플리케이션이 있는 경우 이러한 연결을 Neptune으로 마이그레이션하고 Neo4j에서 사용한 것과 동일한 드라이버를 사용하여 애플리케이션을 연결하도록 할 수 있습니다. Neptune에 연결하려면 다음 중 하나 이상의 애플리케이션을 변경해야 할 수 있습니다.
+ 클러스터 엔드포인트와 클러스터 포트(기본값: 8182)를 사용하려면 URL과 포트를 업데이트해야 합니다.
+ Neptune은 모든 연결에서 SSL을 사용해야 하므로 각 연결에 대해 암호화되도록 지정해야 합니다.
+ Neptune은 [IAM 정책 및 역할](iam-auth.md) 할당을 통해 인증을 관리합니다. IAM 정책 및 역할은 애플리케이션 내에서 매우 유연한 수준의 사용자 관리를 제공하므로 클러스터를 구성하기 전에 [IAM 개요](iam-auth.md)의 정보를 읽고 이해하는 것이 중요합니다.
+ [Neptune에서의 Bolt 연결 동작](access-graph-opencypher-bolt.md#access-graph-opencypher-bolt-connections)에서 설명한 것처럼 Neptune의 Bolt 연결은 Neo4j와 다르게 동작합니다.
+ [openCypher와 Bolt를 사용한 Neptune 모범 사례](best-practices-opencypher.md)에서 자세한 내용 및 제안을 확인할 수 있습니다.
[Bolt 프로토콜을 사용하여 Neptune에 대한 openCypher 쿼리 생성](access-graph-opencypher-bolt.md)에는 Java, Python, .NET, NodeJS와 같이 일반적으로 사용되는 언어에 대한 코드 샘플과 IAM 인증 사용과 같은 연결 시나리오에 대한 코드 샘플이 있습니다.
## Neo4j에서 Neptune으로 이동할 때 클러스터 인스턴스로 쿼리 라우팅
Neo4j 클라이언트 애플리케이션은 [라우팅 드라이버](https://neo4j.com/docs/driver-manual/1.7/client-applications/#routing_drivers_bolt_routing)를 사용하고 [액세스 모드](https://neo4j.com/docs/driver-manual/1.7/sessions-transactions/#driver-transactions-access-mode)를 지정하여 읽기 및 쓰기 요청을 인과 클러스터의 적절한 서버로 라우팅합니다.
클라이언트 애플리케이션을 Neptune으로 마이그레이션할 때는 [Neptune 엔드포인트](feature-overview-endpoints.md)를 사용하여 쿼리를 클러스터의 적절한 인스턴스로 효율적으로 라우팅하세요.
+ Neptune에 대한 모든 연결은 URL의 `bolt+routing://` 또는 `neo4j://` 대신 `bolt://`를 사용해야 합니다.
+ 클러스터 엔드포인트는 클러스터의 현재 기본 인스턴스에 연결됩니다. 클러스터 엔드포인트를 사용하여 쓰기 요청을 기본 서버로 라우팅합니다.
+ 리더 엔드포인트는 클러스터의 읽기 복제본 인스턴스 간에 [연결을 분산](best-practices-general-basic.md#best-practices-general-loadbalance)합니다. 읽기 복제본이 없는 단일 인스턴스 클러스터가 있는 경우 리더 엔드포인트는 쓰기 작업을 지원하는 기본 인스턴스에 연결합니다. 클러스터에 하나 이상의 읽기 복제본 인스턴스가 포함된 경우 리더 엔드포인트로 쓰기 요청을 보내면 예외가 발생합니다.
+ 클러스터의 각 인스턴스는 자체 인스턴스 엔드포인트를 가질 수도 있습니다. 클라이언트 애플리케이션이 클러스터의 특정 인스턴스에 요청을 보내야 하는 경우 인스턴스 엔드포인트를 사용하세요.
자세한 내용은 [Neptune 엔드포인트 고려 사항](feature-overview-endpoints.md#feature-overview-endpoint-considerations) 섹션을 참조하세요.
## Neptune의 데이터 일관성
Neo4j 인과 클러스터를 사용하는 경우 읽기 전용 복제본은 결국 코어 서버와 일치하지만 클라이언트 애플리케이션은 [인과적 연결](https://neo4j.com/docs/driver-manual/1.7/sessions-transactions/#driver-transactions-causal-chaining)을 사용하여 인과적 일관성을 보장할 수 있습니다. 인과적 연결에는 트랜잭션 간에 북마크를 전달하는 작업이 수반되며, 이를 통해 클라이언트 애플리케이션이 코어 서버에 쓴 다음 읽기 전용 복제본에서 자체 쓰기를 읽을 수 있습니다.
Neptune에서 읽기 복제본 인스턴스는 최종적으로 라이터와 일관성을 유지하며 복제 지연은 보통 100밀리초 미만입니다. 하지만 변경 내용이 복제되기 전까지는 기존 엣지와 정점의 업데이트와 새 엣지 및 정점의 추가는 복제본 인스턴스에 표시되지 않습니다. 따라서 애플리케이션이 각 쓰기를 읽음으로써 Neptune에서 즉각적인 일관성을 유지해야 하는 경우 쓰기 후 읽기 작업에 클러스터 엔드포인트를 사용하세요. 이 경우에만 읽기 작업에도 클러스터 엔드포인트를 사용합니다. 다른 모든 상황에서는 리더 엔드포인트를 읽기에 사용하세요.
## Neo4j에서 Neptune으로 쿼리 마이그레이션
Neptune의 [openCypher 지원](https://aws.amazon.com/blogs/database/announcing-the-general-availability-of-opencypher-support-for-amazon-neptune/)으로 Neo4j에서 쿼리를 마이그레이션하는 데 필요한 작업량이 크게 줄어들긴 하지만 마이그레이션할 때는 여전히 몇 가지 차이점이 있습니다.
+ 위의 [데이터 모델 최적화](migration-data-migration.md#migration-data-model-optimization)에서 설명한 것처럼, Neptune에 최적화된 그래프 데이터 모델을 만들려면 데이터 모델을 수정해야 할 수 있으며, 이 경우 쿼리와 테스트를 변경해야 합니다.
+ Neo4j는 Neptune에서 구현한 openCypher 사양에 포함되지 않은 다양한 Cypher 전용 언어 확장을 제공합니다. 사용된 사용 사례 및 기능에 따라 openCypher 언어 내에서, Gremlin 언어를 사용하거나, [Neptune의 OpenCypher에서 실행되도록 Cypher 쿼리를 재작성](migration-opencypher-rewrites.md)에 설명된 다른 메커니즘을 통해 해결 방법이 있을 수 있습니다.
+ 애플리케이션은 종종 Bolt 드라이버 자체 대신 다른 미들웨어 구성 요소를 사용하여 데이터베이스와 상호 작용합니다. 사용 중인 도구나 미들웨어가 지원되는지 [Neo4j에 대한 Neptune의 호환성](migration-compatibility.md)에서 확인해 보세요.
+ 장애 조치의 경우 연결에 제공된 클러스터 엔드포인트가 IP 주소로 확인되었기 때문에 Bolt 드라이버가 이전 라이터 또는 리더 인스턴스에 계속 연결될 수 있습니다. [장애 조치 후 새로운 연결 생성](best-practices-opencypher.md#best-practices-opencypher-renew-connection)에 설명된 대로 애플리케이션의 적절한 오류 처리를 통해 이 문제를 처리해야 합니다.
+ 해결할 수 없는 충돌이나 잠금-대기 제한 시간으로 인해 트랜잭션이 취소되면 Neptune이 `ConcurrentModificationException`으로 응답합니다. 자세한 내용은 [엔진 오류 코드](errors-engine-codes.md) 섹션을 참조하세요. 모범 사례에 따라 클라이언트는 이러한 예외를 항상 포착해 처리해야 합니다.
`ConcurrentModificationException`은 여러 스레드 또는 여러 애플리케이션이 동시에 시스템에 쓰는 경우가 가끔 발생합니다. [트랜잭션 격리 수준](transactions-neptune.md#transactions-neptune-mutation) 때문에 이러한 충돌을 피할 수 없는 경우도 있습니다.
+ Neptune은 동일한 데이터에 대해 Gremlin 쿼리와 openCypher 쿼리를 모두 실행할 수 있도록 지원합니다. 즉, 일부 시나리오에서는 보다 강력한 쿼리 기능을 갖춘 Gremlin을 사용하여 쿼리의 일부 기능을 수행하는 것을 고려해야 할 수도 있습니다.
위의 [인프라 프로비저닝](migration-provisioning-infrastructure.md)에서 설명한 것처럼 각 애플리케이션은 적절한 크기 조정을 거쳐 인스턴스 수, 인스턴스 크기 및 클러스터 토폴로지가 모두 애플리케이션의 특정 워크로드에 맞게 최적화되도록 해야 합니다.
여기에서 설명하는 애플리케이션 마이그레이션 고려 사항은 가장 일반적인 고려 사항이지만 여기에 모두 나열되어 있지는 않습니다. 각 애플리케이션은 고유합니다. 추가 질문이 있는 경우 AWS 고객 지원 팀에 문의하거나 계정 팀에 문의하세요.
## Neo4j 전용 기능 및 도구 마이그레이션
Neo4j에는 애플리케이션에서 사용할 수 있는 기능을 갖춘 다양한 사용자 지정 기능과 애드온이 있습니다. 이 기능을 마이그레이션해야 할 필요성을 평가할 때 동일한 목표를 달성하기 위해 AWS 내에 더 나은 접근 방식이 있는지 조사하는 것이 도움이 되는 경우가 많습니다. [Neo4j와 Neptune의 아키텍처 차이](migration-architectural-differences.md)를 고려하면 다른 AWS 서비스나 [통합](integrations.md)을 활용하는 효과적인 대안을 찾을 수 있는 경우가 많습니다.
Neo4J 전용 기능 목록과 제안된 해결 방법은 [Neo4j에 대한 Neptune의 호환성](migration-compatibility.md) 섹션을 참조하세요.