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