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

# Neptune과 Neo4j의 아키텍처에 대한 차이점
<a name="migration-architectural-differences"></a>

고객이 Neo4j에서 Neptune으로 애플리케이션을 처음 마이그레이션하는 것을 고려할 때 인스턴스 크기를 기준으로 유사 항목을 비교하려는 경우가 많습니다. 그러나 Neo4j와 Neptune의 아키텍처에는 근본적인 차이점이 있습니다. Neo4j는 데이터 로드, 데이터 ETL, 애플리케이션 쿼리, 데이터 스토리지 및 관리 작업이 모두 EC2 인스턴스와 같은 동일한 컴퓨팅 리소스 세트에서 이루어지는 올인원 접근 방식을 기반으로 합니다.

반면 Neptune은 OLTP 중심의 그래프 데이터베이스로서 아키텍처에서 책임을 구분하고 리소스를 분리하여 동적으로 독립적으로 규모를 조정할 수 있습니다.

Neo4j에서 Neptune으로 마이그레이션할 때 애플리케이션의 데이터 내구성, 가용성 및 확장성 요구 사항을 결정하세요. Neptune의 클러스터 아키텍처는 높은 내구성, 가용성 및 확장성이 필요한 애플리케이션의 설계를 단순화합니다. Neptune의 클러스터 아키텍처를 이해하면 이러한 요구 사항을 충족하는 Neptune 클러스터 토폴로지를 설계할 수 있습니다.

## Neo4j의 클러스터 아키텍처
<a name="migration-neo4j-cluster-architecture"></a>

많은 프로덕션 애플리케이션은 Neo4j의 [인과 클러스터링](https://neo4j.com/docs/operations-manual/current/clustering/introduction/)을 사용하여 데이터 내구성, 고가용성 및 확장성을 제공합니다. Neo4j의 클러스터링 아키텍처는 코어 서버 및 읽기 전용 복제본 인스턴스를 사용합니다.
+ 코어 서버는 Raft 프로토콜을 사용하여 데이터를 복제하여 데이터 내구성과 내결함성을 제공합니다.
+ 읽기 전용 복제본은 트랜잭션 로그 전달을 사용하여 데이터를 비동기적으로 복제하여 읽기 처리량이 높은 워크로드를 처리합니다.

코어 서버든 읽기 전용 복제본이든 클러스터의 모든 인스턴스에는 그래프 데이터의 전체 사본이 포함됩니다.

## Neptune의 클러스터 아키텍처
<a name="migration-neptune-cluster-architecture"></a>

[Neptune 클러스터](feature-overview-db-clusters.md)는 기본 라이터 인스턴스와 최대 15개의 읽기 전용 복제본 인스턴스로 구성됩니다. 클러스터의 모든 인스턴스는 인스턴스와는 별개인 동일한 기본 분산 스토리지 서비스를 공유합니다.
+ 기본 라이터 인스턴스는 데이터베이스에 대한 모든 쓰기 작업을 조정하며 수직적으로 규모를 조정할 수 있어 다양한 쓰기 워크로드를 유연하게 지원합니다. 또한 읽기 작업도 지원합니다.
+ 읽기 전용 복제본 인스턴스는 기본 스토리지 볼륨에서 읽기 작업을 지원하며, 높은 읽기 워크로드를 지원하도록 수평적으로 규모를 조정할 수 있습니다. 또한 기본 인스턴스의 장애 조치 대상 역할을 하여 고가용성을 제공합니다.
**참고**  
쓰기 워크로드가 많다면 읽기 복제본 인스턴스를 라이터 인스턴스와 같은 크기로 규모를 조정하여 리더가 데이터 변경에 일관성을 유지할 수 있도록 하는 것이 가장 좋습니다.
+ 기본 스토리지 볼륨은 데이터베이스에 있는 데이터가 증가함에 따라 스토리지 용량을 자동으로 규모를 조정하여 최대 128테비바이트(TiB)의 스토리지가 됩니다.

인스턴스 크기는 동적이고 독립적입니다. 클러스터가 실행되는 동안 각 인스턴스의 크기를 조정할 수 있으며, 클러스터가 실행되는 동안 읽기 전용 복제본을 추가하거나 제거할 수 있습니다.

[Neptune Serverless](neptune-serverless.md) 기능은 수요 증가 및 감소에 따라 컴퓨팅 용량을 자동으로 스케일 업 및 다운할 수 있습니다. 이렇게 하면 관리 오버헤드를 줄일 수 있을 뿐만 아니라, 성능 저하나 오버프로비저닝 없이도 대규모 수요 급증을 처리하도록 데이터베이스를 구성할 수 있습니다.

Neptune 클러스터는 최대 7일간 중지할 수 있습니다.

또한 Neptune은 [자동 크기 조정](manage-console-autoscaling.md)을 지원하여 워크로드에 따라 리더 인스턴스 크기를 자동으로 조정합니다.

Neptune의 [글로벌 데이터베이스 기능](neptune-global-database.md)을 사용하면 최대 5개의 다른 리전에 클러스터를 미러링할 수 있습니다.

Neptune은 [설계를 통한 내결함성](backup-restore-overview-fault-tolerance.md)을 지니고 있습니다.
+ 클러스터 볼륨은 클러스터의 모든 인스턴스에 데이터 스토리지를 제공하며, 단일 AWS 리전에 속하는 다중 가용 영역(AZ)을 아우릅니다. 각 AZ는 클러스터 데이터의 전체 사본을 포함합니다.
+ 기본 인스턴스를 사용할 수 없게 되면 Neptune은 일반적으로 30초 이내에 데이터 손실 없이 기존 읽기 전용 복제본을 통해 자동으로 장애 조치를 처리합니다. 클러스터에 기존 읽기 전용 복제본이 없다면 Neptune은 데이터 손실 없이 새 기본 인스턴스를 자동으로 프로비저닝합니다.

이 모든 것이 의미하는 바는 Neo4j 인과 클러스터에서 Neptune으로 마이그레이션할 때 높은 데이터 내구성과 고가용성을 위해 클러스터 토폴로지를 명시적으로 설계할 필요가 없다는 것입니다. 따라서 다음과 같은 몇 가지 방법을 통해 예상되는 읽기 및 쓰기 워크로드와 향상된 가용성 요구 사항에 맞게 클러스터 크기를 조정할 수 있습니다.
+ 읽기 작업의 규모를 조정하려면 [읽기 전용 복제본 인스턴스를 추가](feature-overview-db-clusters.md#feature-overview-read-replicas)하거나 [Neptune Serverless](neptune-serverless.md) 기능을 활성화하세요.
+ 가용성을 향상하려면 여러 가용 영역의 클러스터에 기본 인스턴스 및 읽기 복제본을 배포하는 것이 좋습니다.
+ 장애 조치 시간을 줄이려면 기본 인스턴스의 장애 조치 대상으로 사용할 수 있는 읽기 전용 복제본 인스턴스를 하나 이상 프로비저닝해야 합니다. [각 복제본에 우선순위를 지정](manage-console-add-replicas.md)함으로써 장애 이후 기본 인스턴스로 승격할 읽기 복제본 순서를 사용자 지정할 수 있습니다. 기본 인스턴스로 승격되는 경우 장애 조치 대상이 애플리케이션의 쓰기 워크로드를 처리할 수 있는 인스턴스 클래스를 갖도록 하는 것이 가장 좋습니다.