신뢰성 요소

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

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

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

• 서비스 할당량 및 배포 패턴을 포함한 워크로드 아키텍처

• 변경 관리

• 장애 관리

Neptune 서비스 할당량 이해

Neptune 클러스터 볼륨은 할당량이 64TiBTiB) 크기로 증가할 수 있습니다. AWS 리전 GovCloud

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

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

각 리전 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 클러스터 관리 및 확장

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

이미 하나의 기본 라이터 인스턴스와 하나 이상의 읽기 전용 복제본 인스턴스가 있는 Neptune DB 클러스터에서만 Auto Scaling을 사용할 수 있습니다(Amazon Neptune DB 클러스터 및 인스턴스 참조). 또한 클러스터의 모든 읽기 복제본 인스턴스는 사용 가능한 상태여야 합니다. 읽기 전용 복제본이 사용 가능 상태가 아닌 경우 Neptune 자동 크기 조정은 클러스터의 모든 읽기 전용 복제본을 사용할 수 있을 때까지 아무 작업도 수행하지 않습니다.

수요가 빠르게 변하는 경우 서버리스 인스턴스를 사용하는 것이 좋습니다. 서버리스 인스턴스는 단기적으로 수직으로 확장할 수 있는 반면, 자동 크기 조정은 장기적으로 수평으로 확장됩니다. 이 구성은 서버리스 인스턴스가 수직으로 확장되는 반면 Auto Scaling은 새 읽기 전용 복제본을 인스턴스화하여 단일 서버리스 인스턴스의 최대 용량을 초과하는 워크로드를 처리하기 때문에 최적의 확장성을 제공합니다. Amazon Neptune Serverless의 용량 조정에 대한 자세한 내용은 Neptune Serverless DB 클러스터의 용량 조정을 참조하세요.

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

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

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

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

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

DB 클러스터의 Amazon Neptune 스냅샷을 생성하면 Neptune은 클러스터의 스토리지 볼륨 스냅샷을 생성하여 개별 인스턴스뿐만 아니라 모든 데이터를 백업합니다. 이 DB 클러스터 스냅샷에서 복원하여 추후 새로운 DB 클러스터를 생성할 수 있습니다. DB 클러스터를 복원할 때 복원할 DB 클러스터 스냅샷의 이름을 입력한 다음 복원에 의해 생성된 새 DB 클러스터의 이름을 제공합니다.

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

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

여러 데이터베이스 엔진에 적용되는 일반적인 백업 요구 사항이 있는 AWS Backup 경우를 사용하는 것이 좋습니다.