이 페이지에서는 Redis용 Memorystore 클러스터가 인스턴스에서 유지보수를 수행하는 방법을 설명합니다. 또한 Memorystore for Redis Cluster의 제로 다운타임 유지보수 설계를 활용하기 위해 클라이언트 애플리케이션이 알아야 하는 정보와 구성 권장사항도 제공합니다. 이 권장사항은 가용성이 높은 클러스터와 복제본이 없는 클러스터 모두에 적용됩니다. 그러나 모든 프로덕션 사용 사례에서는 고가용성 구성을 사용하는 것이 좋습니다.
Redis용 Memorystore 클러스터는 정기적으로 인스턴스를 업데이트하여 서비스의 안정성, 성능, 보안, 최신성을 보장합니다. 이러한 업데이트를 유지보수라고 합니다. 유지보수는 서비스에서 완전하게 관리하며 다운타임에 영향을 주지 않도록 설계되었습니다.
유지보수는 일반적으로 다음 카테고리로 분류됩니다.
- Memorystore 기능. 일부 기능을 실행하려면 Memorystore에 유지보수 업데이트가 필요합니다.
- 운영체제 패치. Google은 운영체제에서 새로 발견된 보안 취약점을 지속적으로 모니터링합니다. 취약점을 발견하면 새로운 위험으로부터 사용자를 보호하기 위해 운영체제 패치를 출시합니다.
- 데이터베이스 패치. 인스턴스 보안, 성능, 안정성 특성을 OSS Redis에서 제공하는 수준 이상으로 개선하기 위한 Redis 업데이트가 유지보수에 포함될 수 있습니다.
클라이언트 애플리케이션 구성
유지보수 기간 중 최상의 성능 및 가용성을 제공하도록 클라이언트 애플리케이션을 구성하려면 다음 단계를 따르세요.
- 예약된 유지보수가 클라이언트 애플리케이션에 영향을 주지 않도록 Redis 클라이언트 권장사항의 안내에 따라 OSS Redis 클러스터 클라이언트를 사용 및 구성합니다. Google의 권장 클라이언트 구성을 사용하면 정기적인 인라인 토폴로지 새로고침과 백그라운드 연결 순환을 통한 연결 재설정을 방지할 수 있습니다.
- 기본 및 복제본 노드에서 대표 워크로드를 실행하고 클라이언트 영향을 모니터링하면서 일련의 업데이트 작업(예: 수평 축소 또는 확장, 복제본 수 변경)으로 클라이언트 애플리케이션을 테스트합니다. 이러한 업데이트는 클라이언트의 인라인 토폴로지 새로고침 로직, 전체 동기화 영향, 새로운 노드 검색, 기존 노드 삭제 기능을 테스트합니다. 테스트를 통해 OSS Redis 클러스터 클라이언트가 올바르게 구성되었는지 확인하여 애플리케이션에 부정적인 영향을 미치지 않도록 할 수 있습니다.
예약된 유지보수
Memorystore for Redis 클러스터는 점진적 배포와 폐기 전 생성 수명 주기 전략을 활용하여 유지보수로 인한 다운타임 영향을 방지합니다. OSS Redis 클러스터 프로토콜의 요청 리디렉션 기능을 다음 Memorystore 메커니즘과 함께 사용하면 제로 다운타임 유지보수가 가능합니다.
- 데이터 손실이 없는 조정식 장애 조치
- 클라이언트가 가용성에 영향을 주지 않고 클러스터 토폴로지 업데이트를 따라잡을 수 있게 해주는 단계적 노드 삭제
- 클러스터의 Private Service Connect 엔드포인트는 유지보수의 영향을 받지 않습니다. 이러한 엔드포인트에 대한 자세한 내용은 클러스터 엔드포인트를 참고하세요.
다음 섹션에 설명된 서비스 동작은 예약된 유지보수에만 적용됩니다. 하드웨어 고장과 같은 계획되지 않은 이벤트가 미치는 영향에 대한 자세한 내용은 계획되지 않은 장애 조치 중 클라이언트 동작을 참조하세요.
점진적 배포 전략
Memorystore for Redis Cluster 유지보수 배포는 점진적으로 범위를 확대하면서 초기에 장애를 감지할 수 있을 만큼의 속도로 수행되므로 영향을 완화하고 안정성 신뢰도를 확보할 수 있습니다. 베이킹 시간 (성공으로 간주하고 계속 진행하기 전에 업데이트가 적용 및 모니터링되는 시간)은 서비스 규모의 Memorystore 클러스터 Fleet 전체에 통합됩니다. 또한 베이킹 시간이 한 리전의 영역 (여러 결함 도메인)에 있는 클러스터 내에 통합되어 영향의 범위를 줄일 수 있습니다.
고가용성으로 구성된 클러스터의 경우 업데이트 기간 동안 기본 항목 및 복제본 항목을 포함한 클러스터 샤드가 고가용성을 유지하도록 항상 최대 1개의 결함 도메인/영역이 업데이트됩니다. 또한 특정 시점에 몇 개의 Redis 노드만 업데이트됩니다. 업데이트에서는 폐기 전 생성 수명 주기 메커니즘을 사용하여 클러스터 안정성을 극대화합니다. 이 전략은 다수의 샤드로 클러스터를 업데이트할 때 가장 많은 이점을 제공합니다. 특정 시점에 전체 사용자 키스페이스의 극히 일부에만 업데이트를 적용하면 데이터 가용성이 극대화됩니다.
폐기 전 생성 수명 주기 전략
Redis 클러스터에는 샤드가 여러 개 있습니다. 각 샤드에는 하나의 기본 노드와 0개 이상의 복제본 노드가 있습니다. Memorystore는 다음 프로세스를 사용하여 샤드의 기존 기본 또는 복제본 Redis 노드를 업데이트합니다.
- Memorystore for Redis Cluster는 먼저 최신 소프트웨어 업데이트가 포함된 완전히 새로운 복제본을 샤드에 추가합니다. Memorystore는 기존 노드를 업데이트하는 대신 완전히 새로운 노드를 만들어 예기치 않은 부트스트랩 오류가 발생할 경우 프로비저닝된 용량이 유지되도록 합니다.
- 업데이트할 샤드 내의 노드가 기본 노드이면 삭제하기 전에 먼저 조정식 장애 조치를 사용하여 복제본으로 변환됩니다.
- 다음 Memorystore는 이전 버전의 소프트웨어를 사용하는 복제본을 삭제합니다.
- 이 프로세스는 클러스터의 각 노드에 대해 반복됩니다.
폐기 전 생성 전략은 현재 위치에서 업데이트되는 일반적인 순차적 배포와 비교할 때 클러스터의 프로비저닝된 용량을 유지하는 데 도움이 되지만 클라이언트 애플리케이션의 가용성 중단 (경우에 따라 데이터 손실)이 발생합니다. 복제본이 없는 샤드의 경우에도 Memorystore for Redis Cluster는 새 복제본을 먼저 프로비저닝하고 장애 조치를 조정한 후 마지막으로 샤드의 기존 기본 노드를 교체합니다.
1단계: Redis 복제본 추가
폐기 전 생성 메커니즘의 첫 번째 단계는 전체 동기화 OSS Redis 메커니즘을 사용하여 최신 소프트웨어로 복제본 노드를 추가하여 기본 노드에서 복제본 노드로 데이터를 복사하는 것입니다. 이렇게 하려면 하위 프로세스를 포크하고 디스크 없는 복제를 활용하여 복제본을 부트스트랩합니다.
더 많은 수의 샤드를 프로비저닝하여 노드 내 키스페이스 크기를 줄이면 클러스터의 수평 확장 아키텍처를 가장 잘 활용할 수 있습니다. 노드당 데이터 세트가 작아지면 전체 동기화 작업의 포크 지연 시간 영향을 줄이는 데 도움이 됩니다. 또한 노드 간 데이터 복사 속도도 빨라집니다.
2단계: 조정식 기본 장애 조치
업데이트해야 하는 Redis 노드가 기본 노드이면 Memorystore가 먼저 새로 추가된 복제본 노드로 조정식 장애 조치를 실행한 후 노드 삭제를 진행합니다. 조정식 장애 조치 중에 클라이언트와 Redis 노드는 함께 작동하고 다음 전략을 사용하여 애플리케이션의 다운타임을 방지합니다.
- 기본 노드에서 수신되는 클라이언트 요청이 일시적으로 차단되어 기존 복제본을 기본 노드와 100% 동기화할 수 있는 시간이 확보됩니다.
- 복제본은 선택 프로세스를 완료하여 기본 역할을 인계합니다.
- 이제 이전 기본 노드가 복제본이 되어 기존 요청을 차단 해제하고 OSS Redis 클러스터 프로토콜을 사용하여 새로 선택된 기본 노드로 리디렉션합니다. 이전의 복제본 노드로 전송된 새 요청은 계속 새 기본 노드로 리디렉션됩니다.
- Redis 클러스터 친화적인 클라이언트는 인메모리 토폴로지를 새로고침합니다. 새 기본 엔드포인트의 주소를 학습하며 더 이상 리디렉션이 필요하지 않습니다.
조정식 장애 조치는 일반적으로 수십 밀리초가 걸립니다. 하지만 총 클러스터 크기로 인해 장애 조치 지연 시간이 늘어날 수 있습니다. 복제본에 플러시되기를 기다리는 전송 중인 데이터도 마찬가지입니다. 클러스터 크기는 기본 노드 간의 수렴에 영향을 미쳐 새 기본 노드를 선택할 때 의사 결정에 영향을 줄 수 있습니다.
3단계: Redis 복제본 삭제
폐기 전 생성 메커니즘의 마지막 단계는 이전 버전의 소프트웨어에서 복제본 노드를 삭제하는 것입니다. 클라이언트가 엔드포인트 정보와 클러스터 토폴로지를 캐시하기 때문에 노드가 갑자기 삭제되면 클라이언트 애플리케이션이 영향을 받습니다. Memorystore for Redis Cluster는 하드 노드 종료가 발생하기 전에 클라이언트 애플리케이션이 토폴로지를 새로고침할 수 있도록 Redis 복제본 삭제가 단계적으로 진행되도록 설계되었습니다. 이 토폴로지는 클라이언트가 새 복제본을 학습할 수 있도록 맞춤설정되어 있습니다. 또한 토폴로지는 삭제되기 전에 삭제될 복제본을 잊어버립니다.
이전 버전의 소프트웨어를 실행하는 복제본 노드는 특정 드레이닝 기간(일반적으로 몇 분) 동안 유지되며, 이 기간 동안 수신되는 읽기 요청을 샤드의 기본 노드로 리디렉션하기 시작합니다. 따라서 OSS Redis 클러스터 클라이언트가 클러스터 토폴로지를 새로고침하고 새 복제본 엔드포인트를 학습할 수 있습니다. 클라이언트가 드레이닝 기간이 지난 후 삭제된 노드에 도달하려고 시도하면 이러한 시도가 실패하므로 클러스터 클라이언트에서 클러스터 토폴로지 새로고침이 트리거되어 복제본 변경사항을 학습할 수 있습니다. 클러스터 토폴로지를 새로고침해도 삭제할 복제본 노드가 표시되지 않습니다.
유지보수 설정
Memorystore를 사용하면 애플리케이션의 요구사항에 맞게 유지보수 일정을 맞춤설정하고 중단을 최소화할 수 있습니다. 클러스터의 유지보수 기간을 구성하면 됩니다.
유지보수 기간은 Memorystore 클러스터별로 설정되며 다음 구성 옵션을 허용합니다.
- 요일. 유지보수를 수행할 요일을 지정합니다.
- 시작 시간. 유지보수가 시작되는 시간입니다.
유지보수 기간은 1시간입니다. 경우에 따라 선택한 기간을 넘어 유지보수가 진행될 수 있습니다.
클러스터 인스턴스에 유지보수 기간이 구성되면 향후 자동 유지보수가 유지보수 기간에 설정된 환경설정에 따라 예약됩니다.
기본 유지보수 기간
유지보수 기간을 설정하지 않으면 Memorystore에서 클러스터의 시간대에 따라 다음 시간대 중 하나에 클러스터를 업데이트합니다.
평일 기간 (월요일~금요일) 오후 10시~오전 6시
주말 기간 금요일 오후 10시~월요일 오전 6시
유지보수 예시
소매업체에서 장바구니 서비스를 관리하는 개발자는 Redis용 Memorystore 클러스터 인스턴스가 포함된 프로덕션 환경을 감독해야 합니다. 유지보수 중에 최적의 성능을 보장하기 위해 클러스터의 트래픽이 최소화되는 시간(일반적으로 일요일 자정)에 유지보수를 예약하려고 합니다.
이 경우 프로덕션 클러스터의 유지보수 기간을 다음과 같이 설정할 수 있습니다.
- 요일. 일요일
- 시작 시간. 오전 1시.
예정된 유지보수 알림
클러스터의 유지보수 이벤트에 대한 정보를 계속 받으려면 예정된 유지보수 최소 1주일 전에 예정된 유지보수에 관한 이메일 알림을 설정하세요. 이러한 알림의 제목은 "Upcoming maintenance for your Cloud Memorystore instance [your-cluster-name]"입니다.
클러스터의 유지보수가 시작될 때도 알림이 전송됩니다. 이메일 제목은 "Maintenance
is undergoing for your Cloud Memorystore instance [your-cluster-name]"입니다.
유지보수가 완료되면 완료 알림이 전송됩니다. 이메일 제목은 "Completed Maintenance
for your Cloud Memorystore instance [your-cluster-name]"입니다.
Memorystore에서 유지보수를 다시 예약하면 취소된 유지보수를 알리는 이메일이 전송됩니다. 이 이메일의 제목은 "Canceled maintenance for your Cloud Memorystore instance [your-cluster-name]"입니다.
이러한 유지보수 알림을 수신하려면 수신 동의해야 합니다. 유지보수 알림을 신청하려면 아래 단계를 따르세요.
Memorystore에서 유지보수 알림을 받으려면 인스턴스의 예약된 유지보수 업데이트가 있기 최소 1주일 전에 위의 단계를 완료해야 합니다. 그렇게 하지 않으면 시스템에서 예정된 유지보수를 알릴 시간이 충분하지 않습니다.
알림은 Google 계정과 연결된 이메일 주소로 전송됩니다. 커스텀 이메일 별칭 (예: 팀 이메일 별칭)을 구성할 수 없습니다. 현재 다른 이메일 주소로 알림을 전송하는 기능은 지원되지 않습니다.
유지보수 알림을 구독하면 지정된 프로젝트 내에서 유지보수가 예약된 모든 Memorystore 클러스터에 대한 알림을 받게 됩니다. 구독한 경우 클러스터별로 별도의 알림이 전송됩니다.
예약된 유지보수를 확인하는 방법은 예약된 유지보수 찾기를 참조하세요.
유지보수 재예약
클러스터에 유지보수 기간이 구성된 시나리오에서 이 섹션에서는 유지보수 일정을 변경하는 방법을 안내합니다. 예를 들어 현재 유지보수 기간 중에 새 서비스가 출시될 예정인 경우 출시 후 며칠까지 유지보수 기간을 연기할 수 있습니다.
원래 예약된 시간으로부터 2주일 이내에 원하는 만큼 유지보수 일정을 변경할 수 있습니다. 일정을 다시 예약하는 동안 다음 옵션 중 하나를 선택할 수 있습니다.
- 지금 업데이트. 예약된 유지보수 기간을 기다리지 않고 클러스터에 즉시 업데이트를 적용할 수 있습니다.
- 요일과 시간 맞춤 조정. 이렇게 하면 원래 예약된 유지보수 시간으로부터 2주일 이내의 특정 시간을 선택할 수 있습니다.
유지보수 일정을 변경할 때는 다음 제한사항이 적용됩니다.
- 현재 예약된 유지보수 시간까지 남은 시간이 1시간 미만이면 유지보수 일정을 변경할 수 없습니다.
- 일정 변경이 완료되면 이전 유지보수가 취소되었음을 확인하는 이메일이 전송되고 업데이트된 일정과 함께 새로운 예정된 유지보수 알림이 전송됩니다.
유지보수 일정 변경에 대한 안내는 유지보수 일정 변경을 참고하세요.
FAQ
다음은 Memorystore for Redis 클러스터의 유지보수 정책에 대해 자주 묻는 질문(FAQ)입니다.
클러스터 유지보수가 언제 예약되어 있는지 어떻게 알 수 있나요?
인스턴스에 유지보수가 예약되는 시점을 알 수 있도록 알림을 구독하고 유지보수 기간을 구성하는 것이 좋습니다. 예약된 유지보수 찾기를 사용하여 응답에 maintenance_schedule 필드가 설정되어 있는지 수동으로 확인할 수도 있습니다.
향후 유지보수에 대한 알림을 언제 받나요?
유지보수 알림을 구독하고 유지보수 기간을 설정했으면 유지보수 이벤트 최소 1주일 전에 이메일로 알림이 전송됩니다.
유지보수를 얼마나 오래 연기할 수 있나요?
클러스터 유지보수가 예약되면 인스턴스를 즉시 업데이트하거나 원래 예약된 유지보수 시간으로부터 최대 2주까지 업데이트를 연기할 수 있습니다. 예를 들어 유지보수가 10월 11일 오후 11시 15분에 예약된 경우 10월 25일 오후 11시 15분까지 연기할 수 있습니다. 따로 조치를 취하지 않으면 예약된 시간에 유지보수가 적용됩니다.
자세한 내용은 유지보수 재예약을 참조하세요.
원활한 유지보수 업데이트 환경을 위해 따라야 하는 권장사항
원활한 유지보수 업데이트 환경이 보장되도록 다음 작업을 수행하는 것이 좋습니다.
- 클라이언트 애플리케이션 구성 안내를 따르세요.
- Redis 사용량이 많은 시간에 유지보수가 적용되지 않도록 유지보수 기간을 설정해야 합니다.
- 인스턴스에 유지보수 업데이트가 예약되기 최소 7일 전에 이메일 알림을 수신하도록 유지보수 알림을 수신 동의해야 합니다.
- 애플리케이션 사용에 미치는 영향이 적거나 영향이 없는 시간이 없는 경우 권장사항이 포함된 점진적 출시의 서비스 기본값을 사용하는 것이 좋습니다. 자세한 내용은 정기 유지보수를 참고하세요.
언제 유지보수를 즉시 적용해야 하나요?
유지보수 업데이트를 즉시 적용할 수 있는 시나리오 중 하나는 테스트 클러스터에서 애플리케이션에 미치는 영향을 확인하는 것입니다. 이를 통해 미치는 영향을 관찰할 수 있고 필요에 따라/허용된 프로덕션 클러스터의 유지보수를 연기할 수 있습니다.
현재 시간이 클러스터에 적합하고 향후 클러스터에 높은 부하가 예상되는 경우 즉시 유지보수를 예약할 수도 있습니다.
유지보수 업데이트가 항상 유지보수 기간 내에 완료되나요?
업데이트는 지정한 유지보수 기간 내에 시작됩니다. 일반적으로 업데이트는 이 기간 내에 완료되지만 이를 보장하지 않습니다.
먼저 특정 클러스터에 대한 유지보수를 선택 해제하거나 유지보수를 예약할 수 있나요?
아니요. 클러스터의 유지보수를 선택 해제하거나 유지보수 순서를 제어할 수 없습니다. 하지만 초기 유지보수 알림을 받은 후 최대 2주까지 연기되도록 유지보수를 재예약할 수 있습니다.
다음 단계
- Redis 클러스터의 유지보수 기간을 관리하는 데 필요한 권한 확인