AWS에서는 패치와 업그레이드를 통해 Amazon ElastiCache 제품군을 자주 업그레이드하며 이러한 업그레이드는 인스턴스에 원활하게 적용됩니다. 하지만 때로는 필수 OS 업데이트를 기본 호스트에 적용하기 위해 ElastiCache 노드를 다시 시작해야 합니다. 보안, 안정성, 운영 성능 향상을 위해 업그레이드를 적용하려면 이러한 교체가 필요합니다.

또한, 예약된 유지 관리 기간 전에 언제든지 이러한 교체를 직접 관리할 수도 있습니다. 교체를 직접 관리하는 경우, 노드를 다시 시작할 때 인스턴스에서 OS 업데이트를 수신하게 되며 예약된 유지 관리 기간은 취소됩니다.

Q: 서비스 업데이트 기능을 사용하여 사용 가능한 업데이트를 적용하고 ElastiCache 서비스 유지 관리를 옵트아웃할 수 있습니까?

아니요. 서비스 업데이트 기능을 사용하면 Redis 플릿에 특정 업데이트를 적용할 수 있습니다. Amazon ElastiCache 서비스에서는 유지 관리 기간 동안 필요에 따라 보안, 안정성 및 운영 성능을 강화하는 업그레이드를 계속 적용합니다.

 

Q: 노드 교체에는 시간이 얼마나 걸립니까?

교체는 보통 몇 분 이내에 완료됩니다. 특정 인스턴스 구성 및 트래픽 패턴에서는 교체하는 데 더 오래 걸릴 수 있습니다. 예를 들어 Redis 기본 노드에 사용 가능한 메모리가 부족할 수 있고 쓰기 트래픽 양이 많을 수도 있습니다. 빈 복제본이 이 기본 노드에서 동기화되면, 기본 노드가 수신되는 쓰기 작업을 처리하면서 복제본을 동기화하려고 시도함에 따라 메모리가 부족해질 수 있습니다. 이러한 경우 마스터 노드가 복제본의 연결을 해제하고 동기화 프로세스를 다시 시작합니다. 복제본이 성공적으로 동기화되기 위해서는 여러 번 시도해야 할 수 있습니다. 또한, 계속해서 많은 양의 쓰기 트래픽이 수신되는 경우 복제본이 절대로 동기화되지 않을 수도 있습니다.

Memcached 노드는 교체 동안 동기화할 필요가 없고 노드 크기와 관계없이 항상 빠르게 교체됩니다.

 

Q: 노드 교체는 내 애플리케이션에 어떤 영향을 줍니까?

Redis 노드의 경우, 교체 프로세스는 가능한 한 기존 데이터를 유지하도록 설계되었으며 이를 위해서는 성공적인 Redis 복제가 필요합니다. 단일 노드 Redis 클러스터의 경우, ElastiCache에서 동적으로 복제본을 구동하고, 데이터를 복제한 후, 복제본으로 장애 조치합니다. 여러 개의 노드로 구성된 복제 그룹의 경우, ElastiCache 기존 복제본을 교체하고 기본 노드에서 새 복제본으로 데이터를 동기화합니다. 다중 AZ 자동 장애 조치가 활성화된 경우, 기본 노드를 교체하면 읽기 전용 복제본으로 장애 조치가 트리거됩니다. Redis 클러스터 클라이언트를 사용하도록 설정된 Redis 클러스터 구성과 자동 장애 조치가 활성화된 비 클러스터 구성의 경우 클러스터가 수신되는 쓰기 요청을 처리하는 동안 계획된 노드 교체가 완료됩니다. 다중 AZ가 비활성화된 경우, ElastiCache에서 기본 노드를 교체한 다음 읽기 전용 복제본으로부터 데이터를 동기화합니다. 이 시간 동안 기본 노드를 사용할 수 없게 되어 쓰기 중단 시간이 더 길어집니다.

Memcached 노드의 경우, 교체 프로세스에서 빈 새 노드를 가져오고 현재 노드를 종료합니다. 전환 중에는 짧은 기간 동안 새 노드를 사용할 수 없게 됩니다. 전환이 완료되면 빈 새 노드가 캐시 데이터로 채워지는 동안 애플리케이션에 성능 저하가 발생할 수 있습니다.

 

Q:순조롭게 교체하고 데이터 손실을 최소화하려면 어떤 모범 사례를 따라야 합니까?

Redis 노드의 경우, 교체 프로세스는 가능한 한 기존 데이터를 유지하도록 설계되었으며 이를 위해서는 성공적인 Redis 복제가 필요합니다. AWS에서는 클러스터를 안정적으로 유지하기 위해 동일한 클러스터에서 한 번에 필요한 만큼의 노드만 교체하려고 노력합니다. 서로 다른 가용 영역에 기본 및 읽기 전용 복제본을 프로비저닝할 수 있습니다. 이 경우 노드가 교체되면 다른 가용 영역의 피어 노드에서 데이터가 동기화됩니다. 단일 노드 Redis 클러스터의 경우, 여기에 설명된 바와 같이 Redis에 충분한 메모리를 제공하는 것이 좋습니다. 여러 개의 노드로 구성된 Redis 복제 그룹의 경우, 수신되는 쓰기 트래픽이 적은 기간에 교체 일정을 예약하는 것이 좋습니다.

Memcached 노드의 경우, 수신되는 쓰기 트래픽이 적은 기간에 교체 일정을 예약하고 애플리케이션에 대한 장애 조치를 테스트하고 ElastiCache에서 제공한 "더 똑똑한" 클라이언트를 사용합니다. Memcached는 데이터를 메모리에만 유지하므로 데이터 손실을 회피할 수 없습니다.

 

Q: 유지 관리 동안 애플리케이션 중단을 최소화하려면 어떤 클라이언트 구성 모범 사례를 따라야 합니까?

Redis의 경우 클러스터 모드 구성은 관리형 또는 비관리형 작업 중에 최상의 가용성을 가지며, 항상 클러스터 검색 엔드포인트에 연결되는 클러스터 모드 지원 클라이언트를 사용할 것을 권장합니다. 클러스터 모드가 비활성화된 경우 모든 쓰기 작업에 대해 항상 기본 엔드포인트를 사용하는 것이 좋습니다. 복제본 노드의 개별 노드 엔드포인트는 모든 읽기 작업에 사용할 수 있습니다. 클러스터에서 자동 장애 조치가 활성화된 경우 기본 노드가 변경될 수 있으므로 애플리케이션이 노드의 역할을 확인하고 모든 읽기 엔드포인트를 업데이트하여 마스터에 큰 로드를 초래하지 않도록 해야 합니다. 자동 장애 조치가 비활성화되면 노드의 역할은 변경되지 않지만 자동 장애 조치가 활성화된 클러스터에 비해 관리형 또는 비관리형 작업의 중단 시간이 더 길어집니다. 읽기 요청을 읽기 전용 복제본으로만 보내지 마십시오. 읽기 전용 복제본으로만 읽기 요청을 보내도록 클라이언트를 구성하는 경우, 유지 관리 중 읽기 중단이 발생하지 않도록 적어도 두 개의 읽기 복제본이 있어야 합니다.

 

Q: 노드 교체를 직접 관리하려면 어떻게 해야 합니까?

ElastiCache가 예약된 유지 관리 기간에 자동으로 노드 교체를 관리하도록 하는 것이 좋습니다. ElastiCache 클러스터를 생성할 때 주간 유지 관리 기간을 통해 기본 교체 시간을 지정할 수 있습니다. 나중에 유지 관리 기간을 좀 더 편리한 시간으로 변경하려면 ModifyCacheCluster API를 사용하거나 ElastiCache 관리 콘솔에서 [Modify]를 클릭하면 됩니다.

교체를 직접 관리하려는 경우 사용 사례와 클러스터 구성에 따라 다양한 조치를 취할 수 있습니다.

이러한 옵션에 대한 자세한 지침은 노드 교체를 예약한 경우 취할 수 있는 조치 페이지를 참조하십시오.

Memcached의 경우 클러스터를 삭제하고 다시 생성하기만 하면 됩니다. 교체 후에는 예약된 이벤트가 더는 인스턴스에 연결되어 있지 않습니다.

 

Q: 예약된 교체 일정을 확인하려면 어떻게 해야 합니까?

노드 교체를 예약하기 전에 ElastiCache에서 이메일 알림을 보내 줍니다. ElastiCache 관리 콘솔의 [Cache Events] 섹션을 사용하거나 describe-events API를 사용하여 진행 예정인 ElastiCache:NodeReplacementScheduled 이벤트를 확인할 수 있습니다. 마지막으로 여기에 제공된 정보를 사용하여 Redis에서 이 이벤트에 대한 Amazon SNS 알림을 설정할 수 있습니다.

Memcached에서 SNS 알림을 설정하려면 여기에 제공된 정보를 사용하십시오.

 

Q: 예약된 유지 관리 일정을 좀 더 적당한 시간으로 변경할 수 있습니까?

예. 클러스터의 유지 관리 기간을 변경할 수 있습니다. 나중에 유지 관리 기간을 좀 더 편리한 시간으로 변경하려면 API(ModifyCacheCluster 또는 ModifyReplicationGroup)를 사용하거나 ElastiCache 관리 콘솔에서 [Modify]를 클릭하면 됩니다.

유지 관리 기간을 변경하면, ElastiCache 서비스가 새롭게 지정된 기간으로 노드의 유지 관리 일정을 예약합니다. 아래에서 변경 사항이 어떻게 적용되는지 예제를 참조하십시오.

예를 들어

오늘이 11월 9일 목요일 오후 3시고 다음 유지 관리 기간은 11월 10일 금요일 오후 5시라고 가정해 보겠습니다. 다음을 각 가정의 결과를 보여주는 3가지 시나리오입니다.

  • 유지 관리 기간을 금요일 오후 4시로 변경합니다(현재 날짜 시간 이후이며 예약된 다음 유지 관리 기간 이전). 그러면 이 노드는 11월 10일 금요일 오후 4시에 교체됩니다.
  • 유지 관리 기간을 토요일 오후 4시로 변경합니다(현재 날짜 시간 이후이며 예약된 다음 유지 관리 기간 이후). 그러면 이 노드는 11월 11일 토요일 오후 4시에 교체됩니다.
  • 유지 관리 기간을 수요일 오후 4시로 변경합니다(현재 날짜 시간보다 더 빠른 요일). 그러면 이 노드는 다음 주 수요일인 11월 15일 오후 4시에 교체됩니다.

 

Q: 이러한 노드 교체가 필요한 이유는 무엇입니까?

필수 소프트웨어 업데이트를 기본 호스트에 적용하기 위해서는 이러한 교체가 필요합니다. 업데이트는 보안, 안정성 및 운영 성능을 강화하는 데 도움이 됩니다.

 

Q: 이러한 교체가 다중 가용 영역에 있는 내 노드에 동시에 영향을 줍니까?

AWS에서는 클러스터 구성에 따라 클러스터 안정성을 유지하면서 같은 클러스터에서 여러 노드를 교체할 수 있습니다. Redis 샤딩된 클러스터의 경우 같은 샤드에서 한 번에 여러 개의 노드를 교체하지 않으려고 노력합니다. 또한, 모든 샤드에 걸쳐 클러스터에서 다수의 마스터 노드를 교체하지 않으려고 노력합니다.

샤딩이 안 된 클러스터의 경우, 최대한 클러스터 안정성을 계속 유지할 수 있도록 유지 관리 기간에 노드 교체에 시차를 두려고 노력합니다.

 

Q: 서로 다른 리전의 서로 다른 클러스터에 있는 노드를 동시에 교체할 수 있습니까?

예. 해당 클러스터의 유지 관리 기간이 같은 시간에 구성되는 경우 이러한 노드를 동시에 교체하는 것이 가능합니다.