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

신뢰성 요소

신뢰성 원칙은 워크로드가 의도한 기능을 예상대로 올바르고 일관되게 수행할 수 있는 능력을 포함합니다. 여기에는 전체 수명 주기에 걸쳐 워크로드를 운영 및 테스트할 수 있는 기능이 포함됩니다.

신뢰할 수 있는 워크로드는 소프트웨어와 인프라에 대한 사전 설계 결정에서 시작됩니다. 아키텍처 선택은 모든 AWS Well-Architected 원칙에서 워크로드 동작에 영향을 미칩니다. 신뢰성을 달성하려면 특정 패턴을 따라야 합니다.

신뢰성 원칙은 다음 핵심 영역에 중점을 둡니다.

Neptune 서비스 할당량 이해

중국 및 GovCloud(할당량이 64TiB임)를 제외한 지원되는 모든 AWS 리전 에서 Neptune 클러스터 볼륨은 최대 128테라바이트(TiB) 크기까지 늘어날 수 있습니다.

128TiB 할당량은 그래프에 약 2,000~4,000억 개의 객체를 저장하기에 충분합니다. 레이블이 지정된 속성 그래프(LPG)에서 객체는 노드, 엣지 또는 노드나 엣지의 속성입니다. 리소스 설명 프레임워크(RDF) 그래프에서 객체는 쿼드입니다.

Neptune Serverless 클러스터의 경우 Neptune 용량 단위(NCU)의 최소 및 최대 수를 모두 설정합니다. 각 NCU는 2기가바이트(GiB)의 메모리와 관련 vCPU 및 네트워킹으로 구성됩니다. 최소 및 최대 NCU 값이 클러스터의 모든 서버리스 인스턴스에 적용됩니다. 설정할 수 있는 최댓값은 128.0NCU이고, 가장 낮은 최솟값은 1.0NCU입니다. Amazon CloudWatch 지표 ServerlessDatabaseCapacity 및 NCUUtilization을 관찰하여 일반적으로 실행되는 범위를 캡처하고 해당 범위 내에서 원치 않는 동작이나 비용을 상호 연관시켜 애플리케이션에 가장 적합한 NCU 범위를 최적화합니다. 많은 워크로드에서 1.0 NCU는 시작점보다 너무 낮으며 일정 기간 동안 활동이 없으면 신뢰할 수 없는 동작이 발생합니다. 워크로드가 충분히 빠르게 조정되지 않는 경우 확장하는 동안 초기 급증에 충분한 처리를 제공하도록 최소 NCU를 늘립니다.

각 AWS 계정 에는 생성할 수 있는 데이터베이스 리소스 수에 대한 각 리전의 할당량이 있습니다. 이러한 리소스에는 DB 인스턴스 및 DB 클러스터가 포함됩니다. 리소스에 대한 제한에 도달하면 해당 리소스 생성을 위한 추가 호출이 예외와 함께 실패합니다. 일부 할당량은 요청에 따라 늘릴 수 있는 소프트 할당량입니다. Amazon Neptune과 Amazon RDS, Amazon Aurora 및 Amazon DocumentDB(MongoDB 호환) 사이에서 공유되는 할당량 목록과 사용 가능한 경우 할당량 증가를 요청하는 링크는 Amazon RDS의 할당량을 참조하세요.

Neptune 배포 패턴 이해

Neptune DB 클러스터에는 기본 DB 인스턴스 1개와 최대 15개의 Neptune 복제본이 있습니다. 기본 DB 인스턴스는 읽기 및 쓰기 작업을 지원하고, 클러스터 볼륨에 대한 모든 데이터 수정을 수행합니다. Neptune 복제본은 기본 DB 인스턴스와 동일한 스토리지 볼륨에 연결되며 읽기 작업만 지원합니다. Neptune 복제본은 기본 DB 인스턴스에서 읽기 워크로드를 오프로드할 수 있습니다.

고가용성을 달성하려면 읽기 복제본을 사용합니다. 읽기 복제본이 기본 인스턴스의 장애 조치 대상 역할을 하기 때문에 여러 가용 영역에서 하나 이상의 읽기 복제본 인스턴스를 사용 가능하면 가용성이 향상될 수 있습니다. 즉, 라이터 인스턴스에서 장애가 발생하면 Neptune은 읽기 복제본 인스턴스를 기본 인스턴스로 승격합니다. 이 경우 승격된 인스턴스가 재부팅되는 동안 잠시 중단(보통 30초 미만)이 발생하며, 이 동안 기본 인스턴스에 대한 읽기 및 쓰기 요청이 예외적으로 실패합니다. 최고의 신뢰성을 위해 서로 다른 가용 영역에 있는 두 개의 읽기 복제본을 고려합니다. 가용 영역 1의 기본 인스턴스가 오프라인 상태가 되면 가용 영역 2의 인스턴스가 기본 인스턴스로 승격되지만 이 경우 쿼리를 처리할 수 없습니다. 따라서 전환 중에 읽기 쿼리를 처리하려면 가용 영역 3의 인스턴스가 필요합니다.

Neptune Serverless를 사용하는 경우 모든 가용 영역의 리더 및 라이터 인스턴스는 데이터베이스 로드에 따라 서로 독립적으로 스케일 업 및 스케일 다운됩니다. 리더 인스턴스의 승격 계층을 0 또는 1로 설정하여 라이터 인스턴스의 용량과 함께 스케일 업 및 스케일 다운할 수 있습니다. 이렇게 하면 언제든지 현재 워크로드를 인계받을 수 있습니다.

애플리케이션에 전 세계 공간이 있거나 다중 리전 장애 조치가 필요한 경우 Neptune 글로벌 데이터베이스를 사용하는 것이 좋습니다. Amazon Neptune 글로벌 데이터베이스는 여러 개에 걸쳐 AWS 리전있으므로 지연 시간이 짧은 전역 읽기를 활성화하고 드물게 중단이 전체에 영향을 미치는 경우 빠른 복구를 제공합니다 AWS 리전. Neptune 글로벌 데이터베이스는 한 리전의 기본 DB 클러스터와 다른 리전의 최대 5개의 보조 DB 클러스터로 구성됩니다.

Neptune 클러스터 관리 및 규모 조정

Neptune 오토 스케일링을 사용하여 CPU 사용률 임계치에 따라 연결성 및 워크로드 요구 사항을 충족하도록 DB 클러스터의 Neptune 복제본 수를 자동으로 조정할 수 있습니다. 오토 스케일링을 사용하면 Neptune DB 클러스터가 갑작스러운 워크로드 증가를 처리할 수 있습니다. 워크로드가 감소하면 오토 스케일링은 불필요한 복제본을 제거하여 미사용 용량에 대한 비용을 지불하지 않도록 합니다. 새 인스턴스 시작에는 최대 15분이 걸릴 수 있으므로 오토 스케일링만으로는 수요의 급격한 변화를 위한 충분한 솔루션이 아닙니다.

오토 스케일링은 이미 기본 라이터 인스턴스와 하나 이상의 읽기 복제본 인스턴스가 있는 Neptune DB 클러스터에서만 사용할 수 있습니다(see Amazon Neptune DB Clusters and Instances 참조). 또한 클러스터의 모든 읽기 복제본 인스턴스는 사용 가능한 상태여야 합니다. 읽기 복제본이 사용 가능하지 않은 상태인 경우 Neptune 오토 스케일링은 클러스터의 모든 읽기 복제본을 사용할 수 있을 때까지 아무 작업도 수행하지 않습니다.

수요가 빠르게 변하는 경우 서버리스 인스턴스를 사용하는 방법을 고려합니다. 서버리스 인스턴스는 단기간에 수직적 스케일링을 수행할 수 있는 반면, 오토 스케일링은 장기간에 수평적 스케일링을 수행합니다. 이 구성은 서버리스 인스턴스에서 수직적 스케일링을 수행하는 반면 오토 스케일링은 새 읽기 복제본을 인스턴스화하여 단일 서버리스 인스턴스의 최대 용량을 초과하는 워크로드를 처리하기 때문에 최적의 확장성을 제공합니다. Amazon Neptune Serverless의 용량 조정에 대한 자세한 내용은 Capacity scaling in a Neptune Serverless DB cluster를 참조하세요.

예측 가능한 시간에 조정 요구 사항을 변경해야 하는 경우 최소 인스턴스, 최대 인스턴스 및 임계치에 대한 변경을 예약하여 이러한 전환 요구 사항을 더 잘 처리할 수 있습니다. 필요할 때 해당 인스턴스가 온라인 상태가 될 수 있도록 스케일 아웃 이벤트를 최소 15분 전에 예약해야 합니다.

DB 파라미터 그룹에서 파라미터를 사용하여 Amazon Neptune에서 데이터베이스 구성을 관리합니다. 파라미터 그룹은 하나 이상의 DB 인스턴스에 적용되는 엔진 구성 값의 컨테이너 역할을 합니다. 파라미터 그룹에서 클러스터 파라미터를 수정할 때 정적 파라미터와 동적 파라미터의 차이와 적용 방법 및 시기를 이해합니다. 상태 엔드포인트를 사용하여 현재 적용된 구성을 확인합니다.

백업 및 장애 조치 이벤트 관리

Neptune은 클러스터 볼륨을 자동으로 백업한 후 백업 보존 기간 동안 백업된 데이터를 유지합니다. Neptune 백업은 연속적으로 또는 증분식으로 이루어지기 때문에 백업 보존 기간 내에 어떤 시점으로든 신속하게 복구가 가능합니다. DB 클러스터를 생성 또는 수정할 때 1일에서 35일 사이의 백업 보존 기간을 지정할 수 있습니다.

백업 보존 기간을 넘겨서 백업을 유지하려는 경우 클러스터 볼륨에서 데이터 스냅샷을 생성할 수도 있습니다. 스냅샷을 저장하면 Neptune 표준 스토리지 비용이 발생합니다.

DB 클러스터의 Amazon Neptune 스냅샷을 생성하면 Neptune은 개별 인스턴스가 아닌 모든 데이터를 백업하여 클러스터의 스토리지 볼륨 스냅샷을 생성합니다. 이 DB 클러스터 스냅샷에서 복원하여 추후 새로운 DB 클러스터를 생성할 수 있습니다. DB 클러스터를 복원할 때 복원 원본으로 사용할 DB 클러스터 스냅샷의 이름을 제공한 다음, 이 복원 작업에서 생성되는 새 DB 클러스터의 이름을 제공합니다.

시스템이 장애 조치 이벤트에 어떻게 응답하는지 테스트합니다. Neptune API를 사용하여 장애 조치 이벤트를 강제로 실행합니다. 장애 조치로 재부팅은 DB 인스턴스 결함을 시뮬레이션하여 테스트하거나, 장애 조치 이후 원래 가용 영역으로 작업을 복구할 때 유용한 기능입니다. 다중 AZ 배포에 대한 자세한 내용은 다중 AZ 배포 구성 및 관리를 참조하세요. DB 라이터 인스턴스를 재부팅하면 예비 복제본으로 장애 조치가 발생합니다. Neptune 복제본을 재부팅하면 장애 조치가 시작되지 않습니다.

신뢰성을 위해 클라이언트를 설계합니다. 장애 조치 이벤트 중에 동작을 테스트합니다. 지수 백오프 로직을 사용하여 클라이언트에서 재시도 로직을 구현합니다. 이 로직을 구현하는 코드 예제는 설명서의 AWS Lambda Amazon Neptune 함수 예제에서 확인할 수 있습니다.

여러 데이터베이스 엔진에 적용되는 일반적인 백업 요구 사항이 있는 경우 AWS Backup을 사용하는 방법을 고려합니다.