신뢰성 요소 - AWS 권장 가이드

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

신뢰성 요소

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

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

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

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

  • 변경 관리

  • 장애 관리

Neptune 서비스 할당량 이해

AWS 계정에는 각에 대한 기본 할당량(이전에는 제한이라고 함)이 있습니다 AWS 서비스. 다르게 표시되지 않는 한 리전별로 각 할당량이 적용됩니다. 모든 할당량이 아닌 일부 할당량에 대해 증가를 요청할 수 있습니다.

Neptune Analytics의 할당량을 찾으려면 Service Quotas 콘솔을 엽니다. 탐색 창에서 AWS 서비스를 선택한 다음 Amazon Neptune Analytics를 선택합니다. 그래프 및 스냅샷 수, 그래프에 대해 프로비저닝된 최대 메모리, API 요청 속도에 대한 할당량에 주의하십시오.

최대 프로비저닝 메모리가 데이터 세트에 충분하지 않은 경우 의도한 분석 사용에 필요한 노드 및 엣지 유형을 평가합니다. 허용되는 프로비저닝된 용량 내에서 분석이 가능하도록 데이터의 하위 집합을 로드합니다. 많은 분석 워크로드, 특히 그래프 알고리즘을 실행하는 워크로드에는 전체 트랜잭션 그래프 대신 제한된 속성 집합이 있는 토폴로지만 필요합니다. (트랜잭션 워크로드와 분석 워크로드의 차이점에 대한 설명은 성능 효율성 원칙 섹션을 참조하세요.)

최대 그래프 수가 의도한 용도에 충분하지 않은 경우:

  • 비슷한 용도의 그래프를 결합하는 것이 좋습니다.

  • 지정된 시간에 실행해야 하는 그래프 수를 평가합니다. 임시 분석 사용 사례가 있는 경우 그래프가 더 이상 필요하지 않을 때 그래프를 스냅샷 처리하고 삭제합니다. 이렇게 하면 할당량에 대한 그래프 수가 줄어듭니다.

  • 그래프를 다른 로 프로비저닝하는 것이 좋습니다 AWS 계정.

Neptune 배포 패턴 이해

Neptune Analytics 그래프를 배포할 때 다음 결정 사항을 이해합니다.

  • 시드: Amazon S3, 기존 Neptune 데이터베이스 클러스터 또는 기존 Neptune 데이터베이스 스냅샷의 데이터를 사용하여 생성 시 빈 그래프를 생성할지 아니면 여기에 데이터를 로드할지 결정합니다.

    권장 사항: 소스가 Neptune 클러스터 또는 스냅샷인 경우 그래프 생성 시 해당 데이터를 로드해야 합니다. 소스가 Amazon S3인 경우 데이터를 로드하는 작업이 중요하고 인프라 프로비저닝 활동으로 가장 잘 수행되는 경우 생성 시 데이터를 로드합니다. 데이터를 데이터 엔지니어링 또는 애플리케이션 활동으로 로드하려면 나중에 빈 그래프를 생성하고 Amazon S3에서 데이터를 로드합니다.

  • 용량: 데이터 크기와 예상 애플리케이션 사용량을 고려하여 그래프에 필요한 프로비저닝된 용량을 추정합니다.

    권장 사항: 생성 시 그래프 크기를 제한할 최대 프로비저닝 메모리를 지정합니다. 이 설정은 필수입니다. 필요한 경우 나중에 용량을 변경할 수 있습니다.

  • 가용성 및 내결함성: 가용성을 위해 복제본이 필요한지 여부를 결정합니다. 복제본은 그래프 실패 시 복구를 위한 웜 스탠바이 역할을 합니다. 복제본이 있는 그래프는 복제본이 없는 그래프보다 빠르게 복구됩니다. 또한 그래프가 얼마나 오래 필요한지, 임시 분석 전용인지 여부, 필요한 경우 언제 제거되는지도 고려합니다.

    권장 사항: 그래프를 생성하기 전에 그래프를 사용할 수 없는 시간 및 제거할 수 있는 시기와 같은 가용성 요구 사항을 결정합니다.

  • 네트워킹 및 보안: 퍼블릭 연결, 프라이빗 연결 또는 둘 다 필요한지 여부와 데이터를 암호화할지 여부를 결정합니다.

    권장 사항: 그래프를 생성하기 전에 퍼블릭 연결이 허용되는지 여부, 그래프 클라이언트 애플리케이션이 배포될 위치 등 조직의 요구 사항을 이해합니다.

  • 백업 및 복구: 스냅샷을 생성해야 하는지 여부와 생성해야 하는 경우 언제 또는 어떤 조건에서 생성해야 하는지 결정합니다. 조직에 재해 복구(DR) 요구 사항이 있는지 고려합니다.

    권장 사항: 스냅샷 생성은 수동 활동입니다. 그래프를 생성하기 전에 스냅샷을 생성할 시기를 결정하고 DR 요구 사항을 고려합니다.

Neptune 클러스터 관리 및 확장

Neptune 분석 그래프는 메모리에 최적화된 단일 인스턴스로 구성됩니다. 인스턴스의 용량(m-NCU)은 생성 시 설정됩니다. 관리 작업을 통해 프로비저닝된 용량을 늘려 인스턴스를 수직으로 확장할 수 있으며 프로비저닝된 용량도 줄일 수 있습니다. 복제본은 수동 장애 조치 대상이므로 그래프의 크기를 늘리지 않습니다. 이와 관련하여 그래프 복제본은 애플리케이션의 읽기 작업을 처리할 수 있는 Neptune 클러스터의 활성 인스턴스인 Neptune 데이터베이스 읽기 전용 복제본과 다릅니다.

복제본에는 비용이 발생합니다. 복제본은 그래프의 m-NCU 요금으로 가격이 책정됩니다. 예를 들어 그래프가 128m-NCU에 프로비저닝되고 단일 복제본이 있는 경우 비용은 복제본이 없는 동등한 그래프의 두 배입니다.

분석에는 확장해야 하는 두 가지 주요 이유가 있습니다.

  • 분석 쿼리 및 알고리즘에 더 많은 메모리와 CPU를 제공하기 위해 개별 쿼리는 비용이 많이 들기 때문에 실행할 그래프 알고리즘은 본질적으로 복잡하며 입력 시 더 많은 리소스가 필요하거나 동시 요청 속도가 높습니다. 이러한 쿼리에 out-of-memory 오류가 발생하는 경우 스케일 업이 합리적인 해결 방법입니다.

  • 계획한 것보다 더 큰 그래프 크기를 지원합니다. 예를 들어 현재 프로비저닝된 용량이 60GB의 소스 데이터를 지원하는 128m-NCU이고 추가 40GB의 소스 데이터가 필요한 경우 256m-NCU로 늘려야 합니다.

, , NumQueuedRequestsPerSec, NumOpenCypherRequestsPerSecGraphStorageUsagePercentGraphSizeBytes,와 같은 Neptune Analytics의 CloudWatch 지표를 모니터링CPUUtilization하여 조정이 필요한지 확인합니다. 콘솔 AWS CLI또는 SDKs. (예제 및 모범 사례는 운영 우수성 원칙 섹션을 참조하세요.)

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

복제본을 사용하여 실패 시 그래프를 계속 사용할 수 있도록 합니다. 그래프는 로그 기반 지속성을 사용하여의 가용 영역 간에 변경 사항을 커밋합니다 AWS 리전. 복제본은 웜 스탠바이 역할을 하며이 데이터에 액세스할 수 있습니다. 오류가 있는 경우 그래프는 복제본에 대한 작업을 재개합니다. 애플리케이션은 동일한 엔드포인트를 계속 사용하여 그래프에 연결합니다. 실패 중 진행 중인 요청은 서비스 사용 불가 예외와 함께 오류를 생성합니다. 애플리케이션 코드에서 백오프 패턴과 함께 재시도를 사용하여 오류를 포착하고 짧은 간격 후에 다시 시도하는 것이 좋습니다. 장애 조치 중에 이루어진 새 요청은 대기열에 추가되며 지연 시간이 길어질 수 있습니다.

복제본이 구성되지 않고 그래프가 실패하면 Neptune Analytics는 내구성 있는 스토리지에서 복구되지만 Neptune이 리소스를 다시 초기화해야 하므로 복구 시간이 더 오래 걸립니다.

그래프의 스냅샷을 생성합니다. (Neptune Analytics는 자동 스냅샷을 생성하지 않습니다.) 생성 후 그래프를 정기적으로 수정하는 경우 스냅샷을 자주 생성하여 현재 상태를 캡처합니다. 이전 시점으로 복원할 필요가 없는 경우 이전 스냅샷을 삭제합니다.

스냅샷을 다른 계정 및 여러 계정과 공유할 수 있습니다 AWS 리전. DR 요구 사항이 있는 경우 스냅샷에서 다른 리전으로 그래프를 복원하는 것이 Recovery Time Objective(RTO) 및 Recovery Point Objective(RPO) 요구 사항을 충족하는지 고려합니다.