이 페이지에서는 Memorystore for Valkey를 최적으로 사용하는 방법을 안내합니다. 이 페이지에서는 방지할 수 있는 잠재적 문제도 다룹니다.
메모리 관리 권장사항
이 섹션에서는 Memorystore for Valkey가 애플리케이션에서 효율적으로 작동하도록 인스턴스 메모리를 관리하는 전략을 설명합니다.
메모리 관리 개념
쓰기 부하 - Valkey 인스턴스에서 키를 추가하거나 업데이트하는 양과 속도입니다. 쓰기 부하는 Valkey 사용 사례와 애플리케이션 사용 패턴에 따라 보통에서 매우 높을 수 있습니다.
제거 정책 - Memorystore for Valkey는
volatile-lru
제거 정책을 사용합니다. EXPIRE 명령어와 같은 Valkey 명령어를 사용하여 키의 제거를 설정할 수 있습니다.
쓰기 부하가 보통인 인스턴스 모니터링
/instance/cpu/maximum_utilization
측정항목을 봅니다. /instance/cpu/maximum_utilization
이 100% 이하이면 Valkey 인스턴스는 보통의 쓰기 부하를 사용할 때 잘 작동합니다.
그러나 메모리 사용량이 100%에 근접하고 데이터 사용량이 증가할 것으로 예상되면 새 데이터를 위한 공간을 확보하기 위해 인스턴스 크기를 수직 확장해야 합니다.
쓰기 부하가 높은 인스턴스 모니터링
/instance/memory/maximum_utilization
측정항목을 봅니다. 높은 쓰기 부하의 심각도에 따라 다음 기준에서 인스턴스에 성능 문제가 발생할 수 있습니다.
쓰기 부하가 매우 높으면
/instance/memory/maximum_utilization
이 65% 이상에 도달할 경우 문제가 발생할 수 있습니다.쓰기 부하가 다소 높으면
/instance/memory/maximum_utilization
이 85% 이상에 도달할 경우 문제가 발생할 수 있습니다.
이러한 시나리오에서는 성능을 개선하기 위해 인스턴스 크기를 수직 확장해야 합니다.
문제가 발생하거나 인스턴스의 쓰기 부하가 높은 것이 우려되는 경우 Google Cloud 지원팀에 문의하세요.
샤드 확장
인스턴스의 샤드 수를 확장할 때는 쓰기가 적은 기간 동안 확장해야 합니다. 쓰기 부하가 높은 기간 동안 확장하면 복제 또는 슬롯 마이그레이션으로 인한 메모리 오버헤드로 인해 인스턴스에 메모리 부족이 발생할 수 있습니다.
Valkey 사용 사례에서 키 제거가 사용되는 경우 더 작은 인스턴스 크기로 확장하면 캐시 적중률이 감소할 수 있습니다. 하지만 이 경우에는 키 제거가 예상되므로 데이터 손실에 대해 걱정할 필요가 없습니다.
키를 잃지 않으려는 Valkey 사용 사례의 경우 데이터를 저장할 공간이 충분한 더 작은 인스턴스로만 축소해야 합니다. 새로운 대상 샤드 수는 데이터에서 사용하는 메모리의 최소 1.5배를 허용해야 합니다. 즉, 현재 인스턴스에 있는 데이터 양의 1.5배에 해당하는 충분한 샤드를 프로비저닝해야 합니다. /instance/memory/total_used_memory
측정항목을 사용하여 인스턴스에 저장된 데이터의 양을 확인할 수 있습니다.
CPU 사용량 권장사항
예기치 않은 영역 서비스 중단이 발생하면 사용할 수 없는 영역의 노드에서 용량이 손실되어 인스턴스의 CPU 리소스가 감소합니다. 가용성이 높은 인스턴스를 사용하는 것이 좋습니다. 샤드당 복제본 1개가 아닌 샤드당 복제본 2개를 사용하면 서비스 중단 시 추가 CPU 리소스가 제공됩니다. 또한 예기치 않은 영역 서비스 중단이 발생할 경우 손실된 용량으로 인한 추가 트래픽을 처리할 수 있을 만큼 노드에 CPU 오버헤드가 충분하도록 노드 CPU 사용량을 관리하는 것이 좋습니다. 기본 스레드 CPU 초 /instance/cpu/maximum_utilization
측정항목을 사용하여 기본 및 복제본의 CPU 사용량을 모니터링해야 합니다.
노드당 프로비저닝하는 복제본 수에 따라 다음 /instance/cpu/maximum_utilization
CPU 사용량 목표를 사용하는 것이 좋습니다.
- 노드당 복제본이 1개인 인스턴스의 경우 기본과 복제본에
/instance/cpu/maximum_utilization
값을 0.5초로 타겟팅해야 합니다. - 노드당 복제본이 2개인 인스턴스의 경우 기본은 0.9초, 복제본은 0.5초로
/instance/cpu/maximum_utilization
값을 타겟팅해야 합니다.
측정항목 값이 이 권장사항을 초과하면 인스턴스의 샤드 또는 복제본 수를 수직 확장하는 것이 좋습니다.
CPU가 많이 소모되는 Valkey 명령어
다양한 이유로 실행하는 데 비용이 많이 드는 Valkey 명령어는 피해야 합니다. 이 섹션에서는 일부 명령어가 비용이 많이 드는 이유의 예시를 제공하지만 이 목록에는 일부만 나와 있습니다.
전체 키스페이스에서 작동하는 명령어
- KEYS
가변 길이 키 세트에서 작동하는 명령어
- LRANGE
- ZRANGE
- HGETALL
스크립트 실행 시 차단되는 명령어
- EVAL
- EVALSHA
고비용 명령어 사용의 위험
- 긴 지연 시간 및 클라이언트 제한 시간
- 메모리 사용량을 늘리는 명령어로 인한 메모리 부족
- Valkey 기본 스레드 차단으로 인해 노드 복제 및 동기화 중 데이터 손실
- 상태 점검, 관측 가능성, 복제 부족
Valkey 클라이언트 권장사항
애플리케이션은 Memorystore for Valkey 인스턴스에 연결할 때 클러스터 인식 Valkey 클라이언트를 사용해야 합니다. 클러스터 인식 클라이언트 및 샘플 구성의 예시는 클라이언트 라이브러리 코드 샘플을 참조하세요. 클라이언트는 올바른 노드로 요청을 전송하고 리디렉션으로 인한 성능 오버헤드를 방지하기 위해 인스턴스의 해당 노드에 대한 해시 슬롯 매핑을 유지해야 합니다.
클라이언트 매핑
클라이언트는 다음과 같은 상황에서 슬롯과 매핑된 노드의 전체 목록을 가져와야 합니다.
클라이언트가 초기화되는 경우 노드 매핑에 대한 초기 슬롯을 채워야 합니다.
이전 기본 노드에서 제공하는 모든 슬롯이 복제본으로 점유되는 장애 조치 상황 또는 슬롯이 소스 기본 노드에서 대상 기본 노드로 이동하는 재샤딩 등 서버에서
MOVED
리디렉션이 수신되는 경우서버에서
CLUSTERDOWN
오류가 수신되거나 특정 서버에 대한 연결에서 지속적으로 시간 제한이 발생하는 경우서버에서
READONLY
오류가 수신되는 경우로, 이는 기본이 복제본으로 강등될 때 발생할 수 있습니다.또한 클라이언트는 주기적으로 토폴로지를 새로고침하여 클라이언트를 변경사항에 맞게 준비하고 새 복제본 노드가 추가되는 경우와 같이 서버에서 리디렉션/오류가 발생하지 않을 수 있는 변경사항을 학습해야 합니다. 명령어 런타임 중에 실패한 연결을 처리할 필요가 없도록 토폴로지 새로고침 중에 비활성 연결도 닫아야 합니다.
클라이언트 검색
클라이언트 검색은 일반적으로 SLOTS
, NODES
또는 CLUSTER SHARDS
명령어를 Valkey 서버에 실행하여 수행됩니다. CLUSTER SHARDS
명령어를 사용하는 것이 좋습니다. CLUSTER SHARDS
는 인스턴스의 보다 효율적이고 확장 가능한 표현을 제공하여 SLOTS
명령어(지원 중단됨)를 대체합니다.
클라이언트 검색 명령어의 응답 크기는 인스턴스 크기와 토폴로지에 따라 다를 수 있습니다. 노드가 더 많은 대규모 인스턴스는 더 큰 응답을 생성합니다. 따라서 노드 토폴로지 검색을 실행하는 클라이언트 수가 무한대로 늘어나지 않도록 하는 것이 중요합니다.
이러한 노드 토폴로지 새로고침은 Valkey 서버에서 비용이 많이 들지만 애플리케이션 가용성에도 중요합니다. 따라서 각 클라이언트가 특정 시점에 단일 검색 요청을 실행하고 결과를 메모리에 캐시해야 하며 요청을 실행하는 클라이언트 수를 제한하여 서버에 과부하가 발생하지 않도록 해야 합니다.
예를 들어 클라이언트 애플리케이션이 시작되거나 서버에서 연결이 끊어진 후 노드 검색을 수행해야 하는 경우 한 가지 일반적인 실수는 클라이언트 애플리케이션이 재시도 시 지수 백오프를 추가하지 않고 여러 번 재연결 및 검색 요청을 실행하는 것입니다. 이로 인해 Valkey 서버가 장시간 응답하지 않아 CPU 사용률이 매우 높아질 수 있습니다.
Valkey에서 탐색 과부하 방지
연결 및 검색 요청의 갑작스러운 증가로 인한 영향을 완화하려면 다음을 수행하는 것이 좋습니다.
클라이언트 애플리케이션에서 동시에 수신되는 연결 수를 제한하기 위해 유한하고 작은 크기로 클라이언트 연결 풀을 구현합니다.
클라이언트가 시간 제한으로 인해 서버에서 연결 해제되면 지터가 있는 지수 백오프로 다시 시도합니다. 이렇게 하면 여러 클라이언트가 동시에 서버에 과부하를 일으키는 것을 방지할 수 있습니다.
Memorystore for Valkey 검색 엔드포인트를 사용하여 노드 검색을 실행합니다. 검색 엔드포인트는 가용성이 높으며 인스턴스의 모든 노드에 걸쳐 부하가 분산됩니다. 또한 검색 엔드포인트는 노드 검색 요청을 최신 토폴로지 뷰가 있는 노드로 라우팅하려고 시도합니다.
지속성 권장사항
이 섹션에서는 지속성에 관한 권장사항을 설명합니다.
RDB 지속성
RDB 스냅샷으로 인스턴스를 백업할 때 최상의 결과를 얻으려면 다음 권장사항을 따라야 합니다.
메모리 관리
RDB 스냅샷은 프로세스 포크 및 'copy-on-write' 메커니즘을 사용하여 노드 데이터 스냅샷을 작성합니다. 노드에 대한 쓰기 패턴에 따라 쓰기의 영향을 받는 페이지가 복사될 때 노드의 사용된 메모리가 증가합니다. 최악의 경우 메모리 공간이 노드에 있는 데이터 크기의 두 배로 증가할 수 있습니다.
스냅샷을 완료하는 데 충분한 메모리가 노드에 포함되도록 하려면 maxmemory
를 노드 용량의 80%로 유지하거나 설정하여 20%가 오버헤드를 위해 예약되도록 해야 합니다. 자세한 내용은 쓰기 부하가 높은 인스턴스 모니터링을 참조하세요. 스냅샷 모니터링 외에도 이러한 메모리 오버헤드는 스냅샷 성공을 위해 워크로드를 관리하는 데 도움이 됩니다.
오래된 스냅샷
오래된 스냅샷에서 노드를 복구하면 스키마 변경과 같이 많은 양의 오래된 키 또는 기타 변경사항을 데이터베이스에 대해 조정하려고 시도하기 때문에 애플리케이션에 성능 문제가 발생할 수 있습니다. 오래된 스냅샷에서 복구하는 것이 우려되는 경우 RDB 지속성 기능을 사용 중지할 수 있습니다. 지속성을 다시 사용 설정하면 스냅샷이 예약된 다음 스냅샷 간격으로 생성됩니다.
RDB 스냅샷의 성능 영향
워크로드 패턴에 따라 RDB 스냅샷은 인스턴스 성능에 영향을 줄 수 있고 애플리케이션의 지연 시간을 늘릴 수 있습니다. 스냅샷 빈도를 줄이는 것이 괜찮다면 인스턴스 트래픽이 낮은 기간 중에 실행되도록 예약함으로써 RDB 스냅샷으로 인한 성능 영향을 최소화할 수 있습니다.
예를 들어 오전 1시부터 오전 4시까지 인스턴스의 트래픽이 적은 경우 시작 시간을 오전 3시로 설정하고 간격을 24시간으로 설정할 수 있습니다.
시스템 부하가 일정하고 스냅샷이 자주 필요한 경우에는 성능 영향을 신중하게 평가하고 워크로드에 RDB 스냅샷을 사용할 때의 장점과 단점을 파악해야 합니다.
인스턴스에서 복제본을 사용하지 않는 경우 단일 영역 인스턴스 선택
복제본이 없는 인스턴스를 구성할 때는 안정성을 높이기 위해 단일 영역 아키텍처를 사용하는 것이 좋습니다. 그 이유는 다음과 같습니다.
서비스 중단 영향 최소화
영역 서비스 중단은 인스턴스에 영향을 줄 가능성이 낮습니다. 모든 노드를 단일 영역에 배치하면 서버에 영향을 미치는 영역 서비스 중단이 발생할 가능성이 100%에서 33%로 줄어듭니다. 사용할 수 없는 영역에 있는 노드가 영향을 받을 가능성이 100%인 것과 달리 인스턴스가 위치한 영역이 다운될 가능성은 33%이기 때문입니다.
신속한 복구
영역 서비스 중단이 발생하면 복구가 간소화됩니다. 작동하는 영역에 새 인스턴스를 빠르게 프로비저닝하고 애플리케이션을 리디렉션하여 작업 중단을 최소화할 수 있습니다.