기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Amazon ElastiCache Well-Architected 렌즈 신뢰성 기둥
신뢰성 요소는 의도한 기능을 수행하는 워크로드와 수요를 충족하기 위해 실패에서 빠르게 복구하는 방법에 중점을 둡니다. 주요 주제에는 분산 시스템 설계, 복구 계획 및 변화하는 요구 사항에 대한 적응이 포함됩니다.
주제
REL 1: 고가용성(HA) 아키텍처 배포를 어떻게 지원하고 있습니까?
질문 수준 소개: Amazon의 고가용성 아키텍처를 이해하면 가용성 이벤트 중에 복원력 있는 상태로 운영할 ElastiCache 수 있습니다.
질문 수준의 이점: 장애에 대한 복원력을 갖도록 ElastiCache 클러스터를 설계하면 ElastiCache 배포의 가용성을 높일 수 있습니다.
-
[필수] ElastiCache 클러스터에 필요한 신뢰성 수준을 결정합니다. 완전히 일시적인 워크로드부터 미션 크리티컬 워크로드까지 워크로드마다 복원력에 대한 표준이 다릅니다. 개발, 테스트, 프로덕션 등 운영 환경의 각 유형에 대한 요구 사항을 정의합니다.
캐싱 엔진: ElastiCache (Memcached) 대 ElastiCache (Redis OSS)
-
ElastiCache (Memcached)는 복제 메커니즘을 제공하지 않으며 주로 임시 워크로드에 사용됩니다.
-
ElastiCache (Redis OSS)는 아래에 설명된 HA 기능을 제공합니다.
-
-
[최고] HA가 필요한 워크로드의 경우 샤드당 복제본이 최소 2개 이상 있는 클러스터 모드에서 ElastiCache (Redis OSS)를 사용합니다. 단 하나의 샤드만 필요한 처리량이 적은 워크로드의 경우에도 마찬가지입니다.
-
클러스터 모드를 활성화하면 다중 AZ가 자동으로 활성화됩니다.
다중 AZ는 계획되거나 계획되지 않은 유지 관리 시 기본 노드에서 복제본으로 자동 장애 조치를 수행하고 AZ 장애를 완화하여 가동 중지 시간을 최소화합니다.
-
샤딩된 워크로드의 경우 Valkey 또는 Redis OSS 클러스터 프로토콜에 따라 쿼럼을 달성하기 위해 대부분의 프라이머리 노드를 사용할 수 있어야 하므로 최소 3개의 샤드가 장애 조치 이벤트 중에 더 빠른 복구를 제공합니다.
-
가용성 전체에서 두 개 이상의 복제본을 설정합니다.
복제본이 두 개 있으면 읽기 확장성이 향상되고 하나의 복제본이 유지 관리되는 시나리오에서도 읽기 가용성이 향상됩니다.
-
Graviton2 기반 노드 유형(대부분 리전의 기본 노드)을 사용합니다.
ElastiCache (Redis OSS)는 이러한 노드에서 최적화된 성능을 추가했습니다. 따라서 복제 및 동기화 성능이 향상되어 전반적인 가용성이 향상됩니다.
-
예상 트래픽 피크를 처리하기 위해 모니터링 및 적절한 크기: 과부하 시 ElastiCache (Redis OSS) 엔진이 응답하지 않아 가용성에 영향을 미칠 수 있습니다.
BytesUsedForCache
DatabaseMemoryUsagePercentage
는 메모리 사용량을 나타내는 좋은 지표인 반면ReplicationLag
는 쓰기 속도를 기반으로 하는 복제 상태를 나타내는 지표입니다. 이러한 지표를 사용하여 클러스터 규모 조정을 트리거할 수 있습니다. -
프로덕션 장애 조치 이벤트 API 전에 장애 조치
로 테스트하여 클라이언트 측 복원력을 확인합니다.
[리소스]:
-
REL 2: 를 사용하여 복구 시점 목표(RPOs)를 어떻게 충족하고 있나요ElastiCache?
질문 수준 소개: 워크로드를 이해RPO하여 ElastiCache 백업 및 복구 전략에 대한 결정에 정보를 제공합니다.
질문 수준의 이점: 현재 위치 RPO 전략을 사용하면 재해 복구 시나리오 발생 시 비즈니스 연속성을 개선할 수 있습니다. 백업 및 복원 정책을 설계하면 ElastiCache 데이터의 복구 시점 목표(RPO)를 충족하는 데 도움이 될 수 있습니다. ElastiCache (Redis OSS)는 구성 가능한 보존 정책과 함께 Amazon S3에 저장되는 스냅샷 기능을 제공합니다. 이러한 스냅샷은 정의된 백업 기간 동안 생성되며 서비스에서 자동으로 처리됩니다. 워크로드에 추가적인 백업 세분화가 필요한 경우, 하루에 최대 20개의 수동 백업을 생성할 수 있습니다. 수동으로 생성한 백업에는 서비스 보존 정책이 없으며 무기한으로 보관할 수 있습니다.
-
[필수] ElastiCache 배포RPO의 를 이해하고 문서화합니다.
-
Memcached는 백업 프로세스를 제공하지 않는다는 점에 유의하시기 바랍니다.
-
ElastiCache 백업 및 복원 기능의 기능을 검토합니다.
-
-
[가장 좋음] 클러스터를 백업하기 위해 소통과 합의를 통해 프로세스를 마련합니다.
-
필요에 따라 수동 백업을 시작합니다.
-
자동 백업에 대한 보존 정책을 검토합니다.
-
수동 백업은 무기한으로 보존된다는 점에 유의하시기 바랍니다.
-
사용량이 적은 시간대에 자동 백업을 예약하세요.
-
읽기 전용 복제본에 대해 백업 작업을 수행하여 클러스터 성능에 미치는 영향을 최소화합니다.
-
-
[좋음] 의 예약된 백업 기능을 활용하여 정의된 기간 동안 데이터를 ElastiCache 정기적으로 백업합니다.
-
백업에서 정기적으로 복원을 테스트합니다.
-
-
[리소스]:
REL 3: 재해 복구(DR) 요구 사항을 어떻게 지원하나요?
질문 수준 소개: 재해 복구는 모든 워크로드 계획의 중요한 요소입니다. ElastiCache (Redis OSS)는 워크로드 복원력 요구 사항에 따라 재해 복구를 구현할 수 있는 여러 옵션을 제공합니다. Amazon ElastiCache Global Datastore를 사용하면 한 리전의 ElastiCache (Redis OSS) 클러스터에 쓸 수 있고 다른 두 리전 간 복제본 클러스터에서 데이터를 읽을 수 있으므로 리전 간 지연 시간이 짧은 읽기 및 재해 복구가 가능합니다.
질문 수준의 이점: 다양한 재해 시나리오를 이해하고 계획하면 비즈니스 연속성을 보장할 수 있습니다. DR 전략은 비용, 성능에 미치는 영향 및 데이터 손실 가능성 사이에서 균형을 맞춰야 합니다.
-
[필수] 워크로드 요구 사항에 따라 모든 ElastiCache 구성 요소에 대한 DR 전략을 개발하고 문서화합니다. ElastiCache 는 일부 사용 사례가 전적으로 임시적이고 DR 전략이 필요하지 않은 반면, 다른 사용 사례는 스펙트럼의 반대편에 있으며 매우 강력한 DR 전략이 필요하다는 점에서 고유합니다. 모든 옵션은 비용 최적화와 비교하여 평가해야 합니다. 복원력을 높이려면 더 많은 양의 인프라가 필요합니다.
리전 수준 및 다중 리전 수준에서 사용할 수 있는 DR 옵션을 이해합니다.
-
AZ 장애를 방지하려면 다중 AZ 배포를 권장합니다. 다중 AZ 아키텍처에서 클러스터 모드가 활성화된 상태에서 최소 3개를 사용할 AZs 수 있는 상태로 배포해야 합니다.
-
리전 장애를 방지하려면 글로벌 데이터 스토어를 사용하는 것이 좋습니다.
-
-
[가장 좋음] 리전 수준의 복원력이 필요한 워크로드에 글로벌 데이터 스토어를 활성화합니다.
-
기본 리전에서 성능 저하가 발생할 경우 보조 리전으로 장애 조치를 수행할 계획을 세웁니다.
-
프로덕션 환경에서 장애 조치를 수행하기 전에 다중 리전 장애 조치 프로세스를 테스트합니다.
-
ReplicationLag
지표를 모니터링하여 장애 조치 이벤트 중 데이터 손실의 잠재적 영향을 파악합니다.
-
-
[리소스]:
REL 4: 장애 조치를 효과적으로 계획하려면 어떻게 해야 하나요?
질문 수준 소개: 자동 장애 조치로 다중 AZ를 활성화하는 것이 ElastiCache 모범 사례입니다. 경우에 따라 ElastiCache (Redis OSS)가 서비스 작업의 일부로 기본 노드를 대체합니다. 예를 들면 계획된 유지 관리 이벤트 및 드물지만 노드 장애나 가용 영역 문제가 발생하는 경우가 포함됩니다. 성공적인 장애 조치는 ElastiCache 및 클라이언트 라이브러리 구성 모두에 의존합니다.
질문 수준 이점: 특정 ElastiCache (Redis OSS) 클라이언트 라이브러리와 함께 ElastiCache 장애 조치에 대한 모범 사례를 따르면 장애 조치 이벤트 중에 발생할 수 있는 가동 중지 시간을 최소화하는 데 도움이 됩니다.
-
[필수] 클러스터 모드가 비활성화된 경우, 클라이언트가 이전 프라이머리 노드와의 연결을 끊고 업데이트된 기본 엔드포인트 IP 주소를 사용하여 새 프라이머리 노드에 다시 연결해야 하는지 감지하도록 제한 시간을 사용합니다. 클러스터 모드가 활성화된 경우, 클라이언트 라이브러리가 기본 클러스터 토폴로지의 변경 사항을 감지합니다. 이는 ElastiCache (Redis OSS) 클라이언트 라이브러리의 구성 설정에 의해 가장 자주 수행되며, 이를 통해 빈도와 새로 고침 방법을 구성할 수도 있습니다. 각 클라이언트 라이브러리는 자체 설정을 제공하며 자세한 내용은 해당 설명서에서 확인할 수 있습니다.
[리소스]:
-
ElastiCache (Redis OSS) 클라이언트 라이브러리의 모범 사례를 검토합니다.
-
[필수] 성공적인 장애 조치는 프라이머리 노드와 복제본 노드 간의 정상적인 복제 환경에 달려 있습니다. Valkey 및 Redis OSS 복제의 비동기 특성과 기본 노드와 복제 노드 간의 복제 지연을 보고하는 데 사용할 수 있는 CloudWatch 지표를 검토하고 이해합니다. 데이터 안전이 더 필요한 사용 사례의 경우 WAIT 명령을 활용하여 연결된 클라이언트에 응답하기 전에 복제본이 쓰기를 승인하도록 강제합니다.
[리소스]:
-
[최고] 장애 조치 테스트 를 사용하여 ElastiCache 장애 조치 중에 애플리케이션의 응답성을 정기적으로 검증합니다API.
[리소스]:
REL 5: 구성 ElastiCache 요소가 확장되도록 설계되었습니까?
질문 수준 소개: 확장 기능과 사용 가능한 배포 토폴로지를 이해하면 구성 요소는 변화하는 워크로드 요구 사항을 충족하도록 시간이 지남에 따라 조정할 수 있습니다 ElastiCache. ElastiCache 는 인/아웃(수평) 및 업/다운(수직)의 4방향 확장을 제공합니다.
질문 수준의 이점: ElastiCache 배포 모범 사례를 따르면 최대의 조정 유연성을 제공할 뿐만 아니라 장애의 영향을 최소화하기 위해 Well Architected 수평 조정 원칙을 충족할 수 있습니다.
-
[필수] 클러스터 모드 활성화 토폴로지와 클러스터 모드 비활성화 토폴로지의 차이점을 이해합니다. 클러스터 모드를 활성화하면 시간이 지남에 따라 확장성 향상이 가능하므로 대부분의 경우에 클러스터 모드를 활성화하여 배포하는 것이 좋습니다. 클러스터 모드가 비활성화된 구성 요소는 읽기 전용 복제본을 추가하여 수평적으로 확장할 수 있는 기능이 제한됩니다.
-
[필수] 규모 조정 시기 및 방법을 이해합니다.
-
자세한 내용READIOPS: 복제본 추가
-
자세한 내용WRITEOPS: 샤드 추가(스케일 아웃)
-
네트워크 I/O 향상: 네트워크에 최적화된 인스턴스 사용, 스케일 업
-
-
[최고] 클러스터 모드가 활성화된 구성 ElastiCache 요소를 배포합니다. 더 적고 더 큰 노드가 아닌 더 크고 작은 노드에 편향됩니다. 이는 노드 장애가 영향을 미치는 범위를 효과적으로 제한합니다.
-
[가장 좋음] 규모 조정 이벤트 시 응답성을 높이기 위해 클러스터에 복제본을 포함합니다.
-
[좋음] 클러스터 모드가 비활성화된 경우 읽기 전용 복제본을 활용하여 전체 읽기 용량을 늘립니다. ElastiCache 는 클러스터 모드가 비활성화된 상태에서 최대 5개의 읽기 전용 복제본과 수직 조정을 지원합니다.
-
[리소스]: