Amazon ElastiCache 관리형 유지 관리 및 서비스 업데이트 도움말 페이지

Q: Amazon ElastiCache의 서비스 업데이트란 무엇입니까?

서비스 업데이트는 특정 서비스 업데이트를 고객의 재량에 따라 적용할 수 있도록 하는 Amazon ElastiCache의 기능입니다. 이러한 업데이트는 보안 패치 또는 부 소프트웨어 업데이트라는 유형 중 하나로 제공될 수 있습니다. 이러한 업데이트는 클러스터의 보안, 안정성 및 운영 성능을 강화하는 데 도움이 됩니다.

서비스 업데이트의 가치는 업데이트를 적용할 시기를 고객이 제어할 수 있다는 데 있습니다. 예를 들어 ElastiCache 클러스터의 24x7 가용성이 요구되는 중요한 비즈니스 이벤트가 있는 경우 서비스 업데이트의 적용을 늦출 수 있습니다.

각 서비스 업데이트에 대한 세부 정보는 ‘업데이트 설명’ 속성을 참조하세요. 

Q: 사용 가능한 ElastiCache 서비스 업데이트에 대한 알림은 어떻게 제공됩니까?

Memcached 또는 Redis 클러스터에 적용 가능한 서비스 업데이트를 사용할 수 있게 되면 Amazon ElastiCache 콘솔, 이메일, Amazon Simple Notification Service(SNS), AWS Personal Health Dashboard 및 Amazon CloudWatch Events와 같은 여러 채널을 통해 알려드립니다.

Q: 서비스 업데이트와 다른 유지 관리 기간에는 업데이트가 어떻게 적용됩니까?

지속적인 관리형 유지 관리를 통해 제공되는 업데이트는 서비스를 업데이트를 통해 제공되는 업데이트와 별개입니다. 지속적인 관리형 유지 관리를 통해 적용되는 업데이트는 해당하는 유지 관리 기간에 직접 예약되며 고객 측에서 따로 수행해야 할 작업은 없습니다. 서비스 업데이트는 한시적이며 고객은 “Recommended Apply by Date(권장되는 적용 날짜)”까지 적용할 시기를 제어할 수 있습니다. 이 날짜까지 적용되지 않는 경우 ElastiCache는 이러한 업데이트를 고객의 해당하는 유지 관리 기간에 예약할 수 있습니다.

Q: 사용 가능한 서비스 업데이트를 적용해야 하는지 여부를 확인하려면 어떻게 해야 합니까?

ElastiCache Redis 클러스터에서 HIPAA, PCI 또는 FedRAMP 규정 준수 프로그램에 참여하는 경우 규정 준수를 유지하려면 “Recommended Apply by Date(권장되는 적용 날짜)”까지 서비스 업데이트를 반드시 적용해야 합니다. 자세한 내용은 규정 준수를 위한 셀프 서비스 보안 업데이트를 참조하세요.

다른 클러스터의 경우 비즈니스 케이던스에 따라 서비스를 업데이트를 적용하는 것이 좋습니다. “Recommended Apply by Date(권장되는 적용 날짜)”까지 서비스 업데이트를 적용할 수 없는 경우 “Update Expiration Date(업데이트 만료 날짜)”까지 적용할 수 있습니다. 그러나 “Update Expiration Date(업데이트 만료 날짜)”는 새 업데이트의 제공 시기에 따라 언제든지 변경될 수 있습니다.

Q: ElastiCache for Redis 클러스터에 서비스 업데이트를 적용할 때의 영향은 무엇입니까? 데이터가 손실되거나 클러스터의 연결이 끊깁니까?

사용자 또는 Amazon ElastiCache가 서비스 업데이트를 하나 이상의 Redis 클러스터에 적용하는 경우 업데이트는 모든 선택된 클러스터가 업데이트될 때까지 각 샤드 내에서 한 번에 하나의 노드에만 적용됩니다. 나머지 Redis 클러스터가 계속 트래픽을 처리하는 동안 업데이트된 노드에는 몇 초 정도 다운타임이 발생합니다.

• 클러스터 구성은 변경되지 않습니다.
• CloudWatch 지표가 지연되지만 가능한 빨리 제 속도로 돌아옵니다.

서비스 업데이트는 ‘지속적인 관리형 유지 관리 업데이트’와 같이 노드 교체 방식으로 적용됩니다. 업데이트가 적용되는 방법과 사용자의 애플리케이션에 끼치는 영향을 최소화하는 방법에 대한 자세한 내용은 이 페이지의 지속적인 관리형 유지 관리 업데이트 단원에서 다음 질문을 참조하세요.

• 노드 교체는 내 애플리케이션에 어떤 영향을 줍니까?
  
• 순조롭게 교체하고 데이터 손실을 최소화하려면 어떤 모범 사례를 따라야 합니까?
• 유지 관리 동안 애플리케이션 중단을 최소화하려면 어떤 클라이언트 구성 모범 사례를 따라야 합니까?
  

Q: ElastiCache for Memcached 클러스터에 업데이트를 적용하는 것과 관련된 다운타임이 있습니까?

예. 이 노드는 새 빈 노드로 교체됩니다. 캐시 콘텐츠는 더 이상 존재하지 않으며 새롭게 시작됩니다.

Q: 서비스 업데이트에서 옵트아웃할 수 있나요?

‘Auto-Update after Due Date(기한 후 자동 업데이트)’ 속성 값을 확인하여 서비스 업데이트를 옵트아웃할 수 있는지 여부를 결정할 수 있습니다. 서비스 업데이트의 ‘Auto-Update after Due Date(기한 후 자동 업데이트)’ 속성 값이 ‘no(아니요)’인 경우 이 서비스 업데이트를 옵트아웃할 수 있습니다. 예. 그러나 서비스 업데이트의 ‘Auto-Update after Due Date(기한 후 자동 업데이트)’ 속성 값이 ‘yes(예)’이고 권장되는 ‘Apply by Date(적용 날짜)’가 지난 경우 ElastiCache는 다음 유지 관리 기간에 남은 클러스터에 대한 서비스 업데이트를 예약합니다. 이 자동 서비스 업데이트는 ‘Update expiration date(업데이트 만료일)’ 이전에 예약되며 업데이트 일주일 전에 예약 시간이 포함된 알림이 전송됩니다. 옵트아웃할 수 있더라도 보안 업데이트를 적용하는 것이 좋습니다.  유지 관리 기간 이전에 남은 클러스터에 서비스 업데이트를 적용하는 경우 ElastiCache는 유지 관리 기간에 서비스 업데이트를 다시 적용하지 않습니다.

Q: 유지 관리 기간에 ElastiCache를 통해 서비스 업데이트를 직접 적용할 수 없는 이유는 무엇인가요?

서비스 업데이트의 목적은 고객에게 적용 시기를 선택할 수 있는 유연성을 제공하는 것입니다. ElastiCache 지원 규정 준수 프로그램에 참여하지 않는 클러스터에서는 이러한 업데이트를 적용하지 않거나 1년 동안 낮은 빈도로 적용하도록 선택할 수 있습니다. 이는 서비스 업데이트의 “Auto-Update after Due Date(기한 후 자동 업데이트)” 속성 값이 “no(아니요)”인 경우에만 해당합니다. 자세한 내용은 서비스 업데이트에서 옵트아웃할 수 있습니까?를 참조하십시오.

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

아니요. 서비스 업데이트는 클러스터의 유지 관리 기간 중에 Amazon ElastiCache를 통해 직접 적용되는 지속적인 관리형 유지 관리 업데이트와 상호 배타적입니다.

Q: 모든 서비스 업데이트 속성의 목록은 어디에 있습니까?

속성 및 설명에 대한 전체 목록은 셀프 서비스 업데이트 적용에서 확인할 수 있습니다.

Q: 모든 서비스 업데이트의 적용 일정은 동일합니까?

“Severity(심각도)” 서비스 업데이트 속성을 참조하여 제공되는 서비스 업데이트의 적용 시기를 확인할 수 있습니다. 이 속성의 값은 다음과 같습니다(우선 순위 순서).

1. critical(심각): 즉시 적용이 권장됨(14일 이내)
2. important(중요): 비즈니스 흐름이 허용하는 대로 곧 적용하는 것이 권장됨(30일 이내)
3. medium(보통): 60일 이내 적용이 권장됨
4. low(낮음): 90일 이내 적용이 권장됨

자세한 내용은 AWS의 공개 설명서에서 업데이트 적용을 참조하세요.

Q: 서비스 업데이트는 얼마나 자주 릴리스됩니까?

릴리스 일정은 서비스 업데이트의 중요도에 따라 다릅니다.

Q: "Service Update SLA Met(서비스 업데이트 SLA 충족)" 속성은 무엇입니까?

이 속성은 클러스터가 “Recommended Apply by Date(권장되는 적용 날짜)”까지 업데이트되었는지 여부를 반영합니다. 서비스 업데이트가 “Recommended Apply by Date(권장되는 적용 날짜)” 후에 적용된 경우 “Service Update SLA Met(서비스 업데이트 SLA 충족)” 속성이 “no(아니요)”로 설정됩니다.

이 정보는 HIPAA, PCI 및 FedRAMP 규정 준수 프로그램에 참여하는 Amazon ElastiCache Redis 클러스터와 관련된 정보입니다. 자세한 내용은 규정 준수를 위한 셀프 서비스 보안 업데이트를 참조하세요.

Q: 하나 이상의 서비스 업데이트를 놓친 경우 나중에 적용할 수 있습니까?

예. 서비스 업데이트의 “Description(설명)” 속성에 달리 명시되지 않은 한 서비스 업데이트는 항상 누적됩니다. “Update Expiration Date(업데이트 만료 날짜)”까지 적용하지 못한 경우 다음 서비스 업데이트에 포함됩니다. 유형이 “security(보안)”인 서비스 업데이트는 이 누적 범주에 포함됩니다.

Q: ElastiCache 클러스터의 특정 노드에 서비스 업데이트를 적용하도록 선택할 수 있습니까?

아니요. 서비스 업데이트는 클러스터 수준에서 적용됩니다. 진행 중인 업데이트를 취소하는 경우 클러스터의 일부 노드는 업데이트되고 다른 노드는 업데이트되지 않을 수 있습니다. 이 경우 클러스터는 서비스 업데이트를 적용할 클러스터 목록에 계속 표시됩니다. 클러스터는 계속 정상적으로 작동합니다.

Q: ElastiCache 클러스터의 하나 이상의 노드에 대한 업데이트 상태가 서비스 업데이트를 적용하지 않았음에도 불구하고 “not-applied(적용되지 않음)”에서 “complete(완료)”로 변경된 이유는 무엇입니까?

이 문제가 발생할 수 있는 경우는 두 가지입니다.

(a) 선택 사항인 서비스 업데이트를 적용하지 못했고 이 업데이트의 현재 상태가 “expired(만료됨)”입니다. 규정 준수 프로그램에 참여하는 클러스터에서는 항상 모든 서비스 업데이트를 적용해야 합니다.
(b) 어떠한 이유(예: 예정된 유지 관리 이벤트 또는 노드 장애 조치)로 노드가 교체된 경우 Amazon ElastiCache는 최신 서비스 업데이트가 포함된 새 노드를 프로비저닝합니다.

두 경우 모두 클러스터는 계속 정상적으로 작동합니다.

Q: 만료된 서비스 업데이트를 노드에 적용하려면 어떻게 해야 합니까? 다음 서비스 업데이트를 기다려야 합니까?

새 노드에는 해당하는 모든 서비스 업데이트가 포함되므로 업데이트되지 않은 기존 노드를 수동으로 교체하여 최신 업데이트를 받을 수 있습니다.

Q: 서비스 업데이트는 엔진별로 다릅니까?

예. 서비스 업데이트는 Redis 전용, Memcached 전용 또는 Redis와 Memcached용으로 제공될 수 있습니다. ‘엔진’ 및 ‘엔진 버전’ 서비스 업데이트 속성을 조회하여 각 업데이트의 범위를 확인할 수 있습니다.

Q: 예약된 서비스 업데이트를 좀 더 적당한 시간으로 변경할 수 있습니까? 유지 관리 기간을 변경하면 예약된 업데이트는 어떻게 됩니까?

예, 유지 관리 기간을 변경해서 서비스 업데이트를 연기할 수 있습니다. 예약된 업데이트는 예약된 날짜가 클러스터의 유지 관리 기간과 일치하는 클러스터에만 적용됩니다. 유지 관리 기간을 변경하고 예약된 날짜가 지나면 서비스 업데이트는 그 다음 주의 새로 지정된 기간으로 재예약됩니다. 바뀐 날짜가 되기 1주일 전에 새로운 알림을 받게 됩니다.

AWS의 보안은 공동 책임입니다. 업데이트를 가능한 빨리 적용하는 것이 좋습니다.

Q: 왜 같은 클러스터에서 여러 개의 업데이트 알림을 받게 됩니까? 모두 적용해야 합니까?

사용자의 클러스터가 서로 다른 서비스 업데이트의 일부일 수 있습니다. 대부분의 업데이트는 별도로 적용할 필요가 없습니다. 클러스터에 업데이트 하나를 적용하면 해당하는 모든 다른 업데이트도 완료된 것으로 표시될 것입니다. 상태가 자동으로 ‘완료됨’으로 변경되지 않는다면 동일한 클러스터에 여러 업데이트를 별도로 적용해야 할 수도 있습니다.

Q: ‘권장되는 적용 날짜’ 이후에 서비스 업데이트는 어떻게 예약하고 적용합니까?

만약 ‘만료 날짜 이후 자동 업데이트’ 속성이 ‘예’’라면 ElastiCache는 ‘권장되는 적용 날짜’ 이후에 남은 클러스터에 서비스 업데이트를 예약합니다. 업데이트는 클러스터의 유지 관리 기간 내에 예약되며 업데이트가 적용되기 전 예약된 날짜보다 1주일 전에 새로운 알림을 받게 됩니다.

예약된 서비스 업데이트는 ‘지속적인 관리형 유지 관리 업데이트’와 같은 방식으로 클러스터에 적용됩니다. 업데이트가 어떻게 적용되고 예약된 업데이트는 어떻게 변경하는지, 예약된 업데이트의 영향을 최소화하려면 애플리케이션을 어떻게 대비해야 하는지에 대한 자세한 정보는 다음 단원을 참조하세요.

Q: 한 번의 유지 관리 기간 내에 서비스 업데이트를 전체 클러스터에 적용하지 못하면 어떻게 됩니까?

클러스터의 안정성을 유지하기 위해 ElastiCache는 각 샤드 내에서 한 번에 하나의 노드에만 업데이트를 적용합니다. 한 번의 유지 관리 기간 내에 서비스 업데이트를 전체 클러스터에 적용하지 못하면 다음 기간에 계속하도록 예약됩니다. 다음 예약된 날에 새로운 알림을 받게 되며 그에 따라 준비하면 됩니다.

Q: 서비스 업데이트를 롤백할 수 있습니까?

서비스 업데이트가 시작되면 고객은 롤백할 수 없습니다. 서비스 업데이트가 적용된 후 문제가 발생하면 AWS Support 팀에 문의하세요.

Q: 지속적인 관리형 유지 관리 업데이트란 무엇입니까?

이러한 업데이트는 필수 업데이트이며 고객 측에서 수행해야 하는 작업 없이 해당하는 유지 관리 기간에 직접 적용됩니다. 이러한 업데이트는 서비스 업데이트로 제공되는 업데이트와 별개입니다.

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

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

Memcached 노드는 동기화할 필요가 없으므로, 노드 크기와 관계없이 더 빠르게 교체할 수 있습니다.

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

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

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

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

Redis 노드의 경우, 교체 프로세스는 가능한 한 기존 데이터를 유지하도록 설계되었으며 이를 위해서는 성공적인 Redis 복제가 필요합니다. AWS에서는 클러스터를 안정적으로 유지하기 위해 동일한 클러스터에서 한 번에 필요한 만큼의 노드만 교체하려고 노력합니다. 서로 다른 가용 영역에 기본 및 읽기 전용 복제본을 프로비저닝할 수 있습니다. 이 경우 노드가 교체되면 다른 가용 영역의 피어 노드에서 데이터가 동기화됩니다. 또한 Redis 엔진 버전을 5.0.6 이상으로 업그레이드하는 것이 좋습니다. 이러한 엔진 버전은 안정성이 개선되었기 때문에 클러스터에서 자동 장애 조치를 사용한 경우 패치 적용 활동 중에도 계속해서 수신 쓰기 요청을 처리할 수 있습니다. 마지막으로 구성에 프라이머리 1개와 샤드당 단일 복제본만 포함된 경우 패치 적용 전에 추가 복제본을 추가하는 것이 좋습니다. 이렇게 하면 패치 적용 프로세스 중에 가용성 저하 및 위험이 방지됩니다. 단일 노드 Redis 클러스터의 경우, 여기에 설명된 바와 같이 Redis에 충분한 메모리를 제공하는 것이 좋습니다. 여러 개의 노드로 구성된 Redis 복제 그룹의 경우, 수신되는 쓰기 트래픽이 적은 기간에 교체 일정을 예약하는 것이 좋습니다.

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

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

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

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

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

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

• 유지 관리 기간을 변경합니다.
• 백업 및 복원 프로세스를 사용하여 Redis 인스턴스를 다시 시작합니다.
• Redis 클러스터 구성이 클러스터 모드 비활성화 상태인 경우

o 읽기 전용 복제본 교체(클러스터 모드 사용 중지) - Redis 복제 그룹에서 읽기 전용 복제본을 수동으로 교체하는 절차.
o 프라이머리 노드를 교체(클러스터 모드 사용 중지) - Redis 복제 그룹에서 기본 노드를 수동으로 교체하는 절차.
o 독립형 노드를 교체(클러스터 모드 사용 중지) - 독립형 Redis 노드를 교체하는 두 가지 절차.

• Redis 클러스터 구성이 클러스터 모드 활성화 상태인 경우

o 하나 이상의 샤드로 클러스터의 노드를 교체 - 백업 및 복원을 사용하거나 확장 후 축소하여 노드를 교체할 수 있습니다.

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

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

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

예약된 교체 이벤트와 같은 중요한 이벤트에 대해 Amazon SNS 알림을 설정하면 알림을 받아볼 수 있습니다. ElastiCache 관리 콘솔의 이벤트 섹션을 통해 또는 describe-events API를 사용하여 진행 예정인 ElastiCache:NodeReplacementScheduled 이벤트를 확인할 수 있습니다.

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: 서로 다른 리전의 서로 다른 클러스터에 있는 노드를 동시에 교체할 수 있습니까?

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