Amazon ElastiCache의 Well-Architected Lens 신뢰성 요소 - Amazon ElastiCache

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

Amazon ElastiCache의 Well-Architected Lens 신뢰성 요소

신뢰성 요소는 의도한 기능을 수행하는 워크로드와 수요를 충족하기 위해 실패에서 빠르게 복구하는 방법에 중점을 둡니다. 주요 주제에는 분산 시스템 설계, 복구 계획 및 변화하는 요구 사항에 대한 적응이 포함됩니다.

REL 1: 고가용성(HA) 아키텍처 배포를 어떻게 지원하고 있나요?

질문 수준의 소개: Amazon ElastiCache의 고가용성 아키텍처를 이해하면 가용성 이벤트 발생 시에도 탄력적인 상태로 운영할 수 있습니다.

질문 수준의 이점: 장애에 대한 복원력을 갖추도록 ElastiCache 클러스터를 설계하면 ElastiCache 배포의 가용성을 높일 수 있습니다.

  • [필수] ElastiCache 클러스터에 필요한 신뢰성 수준을 결정합니다. 완전히 일시적인 워크로드부터 미션 크리티컬 워크로드까지 워크로드마다 복원력에 대한 표준이 다릅니다. 개발, 테스트, 프로덕션 등 운영 환경의 각 유형에 대한 요구 사항을 정의합니다.

    캐싱 엔진: Memcached용 ElastiCache와 Valkey 및 Redis OSS용 ElastiCache

    1. ElastiCache for Memcached는 복제 메커니즘을 제공하지 않으며 주로 임시 워크로드에 사용됩니다.

    2. ElastiCache for Valkey 및 Redis OSS는 아래에 설명된 HA 기능을 제공합니다.

  • [가장 좋음] HA가 필요한 워크로드의 경우 샤드당 최소 2개의 복제본이 있는 클러스터 모드에서 ElastiCache를 사용하세요. 샤드가 하나만 필요한 처리량이 적은 워크로드도 마찬가지입니다.

    1. 클러스터 모드를 활성화하면 다중 AZ가 자동으로 활성화됩니다.

      다중 AZ는 계획되거나 계획되지 않은 유지 관리 시 기본 노드에서 복제본으로 자동 장애 조치를 수행하고 AZ 장애를 완화하여 가동 중지 시간을 최소화합니다.

    2. Valkey 또는 Redis OSS Cluster Protocol에서는 쿼럼을 달성하기 위해 대부분의 프라이머리 노드를 사용할 수 있어야 하므로 샤딩된 워크로드의 경우 최소 3개의 샤드가 장애 조치 이벤트 시 더 빠른 복구를 제공합니다.

    3. 가용성 전체에서 두 개 이상의 복제본을 설정합니다.

      복제본이 두 개 있으면 읽기 확장성이 향상되고 하나의 복제본이 유지 관리되는 시나리오에서도 읽기 가용성이 향상됩니다.

    4. Graviton2 기반 노드 유형(대부분 리전의 기본 노드)을 사용합니다.

      ElastiCache는 이러한 노드에서 최적화된 성능을 추가했습니다. 따라서 복제 및 동기화 성능이 향상되어 전반적인 가용성이 향상됩니다.

    5. 예상 트래픽 피크를 처리하기 위해 모니터링 및 적절한 크기 조정: 과부하 시 엔진이 응답하지 않아 가용성에 영향을 미칠 수 있습니다. BytesUsedForCache DatabaseMemoryUsagePercentage는 메모리 사용량을 나타내는 좋은 지표인 반면, ReplicationLag는 쓰기 속도에 따른 복제 상태를 나타내는 지표입니다. 이러한 지표를 사용하여 클러스터 규모 조정을 트리거할 수 있습니다.

    6. 프로덕션 장애 조치 이벤트 전에 장애 조치 API로 테스트하여 클라이언트 측 복원력을 보장합니다.

    [리소스]:

REL 2: ElastiCache를 사용하여 Recovery Point Objective(RPO)를 어떻게 달성하고 있나요?

질문 수준의 소개: 워크로드 RPO를 이해하여 ElastiCache 백업 및 복구 전략에 대한 의사 결정을 내립니다.

질문 수준의 이점: RPO 전략을 수립하면 재해 복구 시나리오 발생 시 비즈니스 연속성을 개선할 수 있습니다. 백업 및 복원 정책을 설계하면 ElastiCache 데이터에 대한 Recovery Point Objective(RPO)를 달성하는 데 도움이 될 수 있습니다. ElastiCache는 구성 가능한 보존 정책과 함께 Amazon S3에 저장된 스냅샷 기능을 제공합니다. 이러한 스냅샷은 정의된 백업 기간 동안 생성되며 서비스에서 자동으로 처리됩니다. 워크로드에 추가적인 백업 세분화가 필요한 경우, 하루에 최대 20개의 수동 백업을 생성할 수 있습니다. 수동으로 생성한 백업에는 서비스 보존 정책이 없으며 무기한으로 보관할 수 있습니다.

  • [필수] ElastiCache 배포의 RPO를 이해하고 문서화합니다.

    • Memcached는 백업 프로세스를 제공하지 않는다는 점에 유의하시기 바랍니다.

    • ElastiCache 백업 및 복원 기능을 검토합니다.

  • [가장 좋음] 클러스터를 백업하기 위해 소통과 합의를 통해 프로세스를 마련합니다.

    • 필요에 따라 수동 백업을 시작합니다.

    • 자동 백업에 대한 보존 정책을 검토합니다.

    • 수동 백업은 무기한으로 보존된다는 점에 유의하시기 바랍니다.

    • 사용량이 적은 시간대에 자동 백업을 예약하세요.

    • 읽기 전용 복제본에 대해 백업 작업을 수행하여 클러스터 성능에 미치는 영향을 최소화합니다.

  • [좋음] ElastiCache의 예약 백업 기능을 활용하여 지정된 기간 동안 데이터를 정기적으로 백업합니다.

    • 백업에서 정기적으로 복원을 테스트합니다.

  • [리소스]:

REL 3: 재해 복구(DR) 요구 사항을 어떻게 지원하나요?

질문 수준의 소개: 재해 복구는 모든 워크로드 계획에서 중요한 측면입니다. ElastiCache는 워크로드 복원력 요구 사항에 따라 재해 복구를 구현할 수 있는 몇 가지 옵션을 제공합니다. Amazon ElastiCache Global Datastore를 사용하면 한 리전의 클러스터에 쓸 수 있으며 다른 두 리전 간 복제본 클러스터에서 데이터를 읽을 수 있으므로 리전 간 지연 시간이 짧은 읽기 및 재해 복구가 가능합니다.

질문 수준의 이점: 다양한 재해 시나리오를 이해하고 계획하면 비즈니스 연속성을 보장할 수 있습니다. DR 전략은 비용, 성능에 미치는 영향 및 데이터 손실 가능성 사이에서 균형을 맞춰야 합니다.

  • [필수] 워크로드 요구 사항을 기반으로 모든 ElastiCache 구성 요소에 대한 DR 전략을 개발하고 문서화합니다. ElastiCache가 독특한 점은 일부 사용 사례는 완전히 일시적이어서 DR 전략이 필요하지 않은 반면, 어떤 사용 사례는 스펙트럼의 반대편에 있어서 매우 강력한 DR 전략이 필요하다는 점입니다. 모든 옵션은 비용 최적화와 비교하여 평가해야 합니다. 복원력을 높이려면 더 많은 양의 인프라가 필요합니다.

    리전 수준 및 다중 리전 수준에서 사용할 수 있는 DR 옵션을 이해합니다.

    • AZ 장애를 방지하려면 다중 AZ 배포를 권장합니다. 최소 3개의 AZ를 사용할 수 있는 다중 AZ 아키텍처에서 클러스터 모드를 활성화하여 배포해야 합니다.

    • 리전 장애를 방지하려면 글로벌 데이터 스토어를 사용하는 것이 좋습니다.

  • [가장 좋음] 리전 수준의 복원력이 필요한 워크로드에 글로벌 데이터 스토어를 활성화합니다.

    • 기본 리전에서 성능 저하가 발생할 경우 보조 리전으로 장애 조치를 수행할 계획을 세웁니다.

    • 프로덕션 환경에서 장애 조치를 수행하기 전에 다중 리전 장애 조치 프로세스를 테스트합니다.

    • ReplicationLag 지표를 모니터링하여 장애 조치 이벤트 중 데이터 손실의 잠재적 영향을 파악합니다.

  • [리소스]:

REL 4: 장애 조치를 어떻게 효과적으로 계획하나요?

질문 수준의 소개: 자동 장애 조치가 포함된 다중 AZ를 활성화하는 것이 ElastiCache의 모범 사례입니다. 경우에 따라 ElastiCache for Valkey 및 Redis OSS는 서비스 작업의 일부로 기본 노드를 대체합니다. 예를 들면 계획된 유지 관리 이벤트 및 드물지만 노드 장애나 가용 영역 문제가 발생하는 경우가 포함됩니다. 성공적인 장애 조치는 ElastiCache와 클라이언트 라이브러리 구성에 달려 있습니다.

질문 수준 이점: 특정 ElastiCache 클라이언트 라이브러리와 함께 ElastiCache 장애 조치에 대한 모범 사례를 따르면 장애 조치 이벤트 중 잠재적 가동 중지 시간을 최소화하는 데 도움이 됩니다.

  • [필수] 클러스터 모드가 비활성화된 경우, 클라이언트가 이전 프라이머리 노드와의 연결을 끊고 업데이트된 기본 엔드포인트 IP 주소를 사용하여 새 프라이머리 노드에 다시 연결해야 하는지 감지하도록 제한 시간을 사용합니다. 클러스터 모드가 활성화된 경우, 클라이언트 라이브러리가 기본 클러스터 토폴로지의 변경 사항을 감지합니다. 이는 ElastiCache 클라이언트 라이브러리의 구성 설정에 의해 가장 자주 수행되며, 이를 통해 빈도와 새로 고침 방법을 구성할 수도 있습니다. 각 클라이언트 라이브러리는 자체 설정을 제공하며 자세한 내용은 해당 설명서에서 확인할 수 있습니다.

    [리소스]:

  • [필수] 성공적인 장애 조치는 프라이머리 노드와 복제본 노드 간의 정상적인 복제 환경에 달려 있습니다. Valkey 또는 Redis OSS 복제의 비동기적 특성 및 프라이머리 노드와 복제본 노드 간의 복제 지연을 보고하는 데 사용할 수 있는 CloudWatch 지표를 검토하고 이해합니다. 더 높은 데이터 안전성이 필요한 사용 사례의 경우 WAIT 명령을 활용하여 연결된 클라이언트에 응답하기 전에 복제본이 쓰기를 강제로 확인하도록 합니다.

    [리소스]:

  • [가장 좋음] ElastiCache 테스트 장애 조치 API를 사용하여 장애 조치 중에 애플리케이션의 응답성을 정기적으로 검증합니다.

    [리소스]:

REL 5: ElastiCache 구성 요소가 규모를 조정하도록 설계되었나요?

질문 수준의 소개: 규모 조정 기능과 사용 가능한 배포 토폴로지를 이해하면 변화하는 워크로드 요구 사항에 맞게 ElastiCache 구성 요소를 시간이 지남에 따라 조정할 수 있습니다. ElastiCache는 스케일 인/아웃(수평)과 스케일 업/다운(수직)의 4방향 규모 조정을 제공합니다.

질문 수준의 이점: ElastiCache 배포의 모범 사례를 따르면 규모 조정의 유연성이 극대화될 뿐만 아니라 수평적 규모 조정이라는 Well-Architected 원칙을 충족하여 장애의 영향을 최소화할 수 있습니다.

  • [필수] 클러스터 모드 활성화 토폴로지와 클러스터 모드 비활성화 토폴로지의 차이점을 이해합니다. 클러스터 모드를 활성화하면 시간이 지남에 따라 확장성 향상이 가능하므로 대부분의 경우에 클러스터 모드를 활성화하여 배포하는 것이 좋습니다. 클러스터 모드가 비활성화된 구성 요소는 읽기 전용 복제본을 추가하여 수평적으로 확장할 수 있는 기능이 제한됩니다.

  • [필수] 규모 조정 시기 및 방법을 이해합니다.

    • READIOPS 향상: 복제본 추가

    • WRITEOPS 향상: 샤드 추가(스케일 아웃)

    • 네트워크 I/O 향상: 네트워크에 최적화된 인스턴스 사용, 스케일 업

  • [가장 좋음] 클러스터 모드를 활성화한 상태로 ElastiCache 구성 요소를 배포합니다. 더 적은 수의 더 큰 노드보다는 더 많은 수의 더 작 은 노드를 사용합니다. 이는 노드 장애가 영향을 미치는 범위를 효과적으로 제한합니다.

  • [가장 좋음] 규모 조정 이벤트 시 응답성을 높이기 위해 클러스터에 복제본을 포함합니다.

  • [좋음] 클러스터 모드가 비활성화된 경우, 읽기 전용 복제본을 활용하여 전체 읽기 용량을 늘립니다. ElastiCache는 클러스터 모드가 비활성화된 상태에서 최대 5개의 읽기 전용 복제본과 수직적 규모 조정을 지원합니다.

  • [리소스]: