저는 싱가포르의 2 개의 가용 영역에서 AWS로드 밸런싱과 여러 웹 서버를 사용하고 있습니다.탄성 천창 및 가용 대역
가용성 영역에 탄성 캐시 노드를 배치하려고합니다. 다른 가용성 영역에서 탄성 캐시 노드에 액세스하는 웹 서버로 인한 대기 시간 문제가 있는지 알고 싶습니까?
업데이트 - 사실 더 많은 조사가 끝나면 탄성 캐시 클러스터는 하나의 가용성 영역에만 존재할 수 있습니다. 따라서 가용성 영역 중단을 처리하는 최상의 솔루션은 무엇입니까?
ElasticCache에서는 다중 가용성 영역 기능이 아직 지원되지 않는다는 것이 맞습니다. 그러나 일반적으로 AZ 사이의 1ms의 낮은 지연으로 큰 문제는 아닙니다.
캐시의 목적은 메모리에서 길고 빈번한 SQL 쿼리를 제공하는 것입니다. 그것은 300ms SQL 쿼리 대신 단일 메모리 조회로 처리 할 수 있습니다. 1ms 네트워크 대기 시간과 비교하면 문제가되지 않습니다.
캐시의 두 번째 속성 인 ElasticCache는 데이터베이스의 실제 데이터로 워밍업 상태를 유지하면서 따뜻하게 유지한다는 것입니다. 백그라운드의 데이터가 항상 바뀌고 있기 때문에 캐시가 현재 상태가 될 것으로 예상해서는 안됩니다. 클러스터에서 캐시 노드를 잃어 버리는 것은 시스템이 새로 생성 된 캐시 노드를 오히려 빠르게 워밍업시켜야하기 때문에 (대형 시스템에서의 다른 모든 장애와 마찬가지로) 예상됩니다. ElasticCache가 실패한 노드를 대체하지만 캐시 데이터로 다시 채워야합니다. 당신은 AWS description 확인할 수 있습니다 가용성 영역 사이의 중복에 관한
: 다른 가용 영역에서 중복 캐시 클러스터를 설정
는
아마존 ElastiCache는 캐시 노드의 상태를 모니터링하고 이벤트에서 그들을 대체 네트워크 파티셔닝, 호스트 하드웨어 또는 소프트웨어 오류. 그러나 캐시의 일시적인 특성을 고려하면 캐시 노드 교체가 비어 있고 ("콜드"라고도 함) 워크로드 패턴에 따라 이 시작되고 데이터로 다시 채워지는 시간이 ("워밍업 "). 또한 Amazon ElastiCache에서 제공하는 자동 대체 기능은 이며 단일 가용성 영역으로 제한됩니다. 응용 프로그램이 장애 복구 또는 캐시 노드의 "예열"시간에 민감한 이거나 가용성 영역 수준 장애에 대한 향상된 내결함성을 원할 경우 다른 가용 영역에 중복 된 ElastiCache 클러스터 을 배포 할 수 있습니다.
데이터 중복을 관리하는 방법 중 하나는 응용 프로그램에 이 모든 가용 영역에서 캐시 노드에 모든 캐시 쓰기를 적용하는 것입니다. 1 차 가용성 영역의 캐시 노드 중 하나 이상에 장애가 발생하면 의 보조 캐시를 해당 캐시 노드로 보내고 Amazon ElastiCache는 기본 캐시 영역에 캐시 노드를 복원합니다. 존.
일반적으로 가용 영역 간의 대기 시간은 약 2ms이므로 일반적으로 문제가되지 않습니다.
질문의 두 번째 부분을 처리하는 방법에 대해 더 많이 알고 싶습니다. 단지 캐싱 계층이기 때문에 AWS가 문제를 해결하거나 사용자 개입을 수동으로 수행 할 때까지 응용 프로그램을 성능 저하 모드로 자주 실행할 수 있습니다. 또는 응용 프로그램이 다른 가용성 영역의 두 번째 클러스터로 자동 장애 조치되도록 설계 될 수 있습니다. 이 경우 캐시는 영구 데이터 스토어에서 다시 빌드해야합니다. 캐시 미스가 발생하도록하거나 응용 프로그램이 캐시 미스를 사용하기 전에 프라이밍을 수행 할 수 있습니다.
지원되는 Elasticache 엔진으로 최근에 Redis가 추가되어 이제 Redis에 마스터/슬레이브 복제를 사용할 수 있습니다. 슬레이브는 마스터가 아닌 다른 AZ에있을 수 있습니다. – j0nes