최근 Redis 기술 파트너 프로그램(Redis Technical Partner Program) 온보딩 과정의 일환으로 Cohesity 팀과 협력하여 Helios와 Redis Enterprise 간의 통합을 검증할 기회를 가졌습니다. Helios 위에서 실행되는 서비스인 Cohesity SmartFiles는 데이터가 어디에 저장되어 있든 구조화되지 않은 데이터(unstructured data)에 대한 단일 뷰와 글로벌 관리 기능을 제공합니다. Redis Enterprise 환경에서 SmartFiles는 데이터베이스 스냅샷에 대한 단일 뷰를 제공합니다.
그렇다면 왜 지속성(persistence)과 백업에 신경을 써야 할까요? Redis를 단순 캐시로 사용하고 백엔드 데이터베이스에서 시스템에 미치는 영향을 최소화하면서 데이터를 다시 불러올(rehydrate) 수 있다면, 지속성이나 백업은 굳이 필요하지 않습니다. 하지만 반대로 Redis를 운영 데이터베이스로 사용해 느린 데이터에 대한 빠른 접근을 제공하는 경우(예: 거래 내역, 재고 수량, 고객 조회)를 생각해 보세요. 이런 환경에서는 Redis 데이터베이스가 하드웨어 문제는 물론, 다른 데이터센터로의 페일오버(failover) 상황에서도 빠르게 복구될 수 있어야 합니다.
지속성(Persistence)
Redis 데이터베이스의 모든 데이터는 RAM 또는 RAM + 플래시 메모리(Redis on Flash)에만 저장되고 관리되므로, 프로세스나 서버 장애가 발생하면 데이터가 손실될 위험에 노출됩니다. 이러한 위험을 완화하기 위해 활용할 수 있는 전략은 여러 가지가 있습니다. 프라이머리(primary)와 세컨더리(secondary) 데이터 샤드를 갖춘 고가용성(HA) 데이터베이스, 지리적으로 분산된 액티브-액티브(active-active) 데이터베이스, 그리고 디스크 기반 지속성이 대표적입니다.
성능 관점에서는 프라이머리 데이터베이스 샤드에서 동기화된 세컨더리 샤드로 페일오버하는 것이 항상 가장 좋으며, Redis Enterprise도 바로 이 방식으로 작동합니다. 프라이머리와 세컨더리 샤드가 모두 손실된 경우에만 디스크에서 데이터베이스를 복원합니다. 마찬가지로 데이터센터 전체에 장애가 발생했을 때도, 디스크에서 복구하는 것보다 다른 데이터센터에 있는 동기화된 액티브-액티브 데이터베이스로 페일오버하는 것이 훨씬 빠릅니다.
지속성 방식과 관련해 Redis는 두 가지 옵션을 지원합니다. 더 나은 내구성을 제공하지만 더 많은 리소스가 필요한 AOF(Append-Only File) 방식과, 내구성은 상대적으로 낮지만 리소스 소모가 적은 스냅샷(RDB) 방식입니다. 모든 기술 선택이 그렇듯 여기에도 트레이드오프가 존재하며, 자세한 내용은 Redis Enterprise 문서에서 확인할 수 있습니다. 이 글에서는 더 나은 내구성을 위해 AOF를 사용한다고 가정하겠습니다.
백업(Backup)
Redis Enterprise는 프라이머리와 세컨더리 데이터베이스 샤드가 모두 손실된 경우 지속성 메커니즘에 의존해 복구를 수행합니다. 그러나 액티브-액티브 구성을 사용하지 않는 상황에서 데이터베이스가 있는 랙(rack)과 연결된 스토리지까지 함께 잃게 되면, 남은 선택지는 백업으로부터 복원하는 것뿐입니다. Redis Enterprise에서 백업은 항상 스냅샷 형태이며, AOF 지속성과 결합하면 탄력적이고 내구성 있는 데이터 플랫폼을 구축할 수 있습니다.
바로 이 지점에서 Cohesity SmartFiles가 중요한 역할을 합니다. Redis Enterprise는 SmartFiles가 제공하는 S3 호환 엔드포인트를 활용하여 클라우드 전반에 걸친 관리형 백업을 손쉽게 수행할 수 있습니다. 아래 설정에서는 Redis Enterprise REST API를 사용하며, 다음과 같은 환경 변수가 이미 설정되어 있다고 가정합니다.
- $S3_IP: Cohesity S3 오브젝트 스토어의 IP 주소 / $BUCKET: 버킷 이름
- $USER 및 $PASS: Redis Enterprise 관리자 계정의 사용자 이름과 비밀번호
- $ACCESS_KEY 및 $SECRET_KEY: S3 오브젝트 스토어의 액세스 키와 시크릿 키
데이터베이스 지속성을 활성화합니다.
curl -s -k -u $USER:$PASS -H content-type:application/json -XPUT
https://localhost:9443/v1/bdbs/1 -d '{"data_persistence": "aof"}'
클러스터가 S3 오브젝트 스토어를 사용하도록 S3 URL을 설정합니다. 이때 버킷 이름은 S3 URL에 포함되지 않는다는 점에 유의하세요.
curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT
https://localhost:9443/v1/cluster -d '{"s3_url": '"$S3_IP"'}'
S3 인증서 검증을 비활성화하여 클러스터의 S3 백업을 구성합니다.
curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT
https://localhost:9443/v1/cluster -d
'{"s3_certificate_verification":false}'
백업 위치를 검증합니다. 성공 시 반환되는 유일한 응답은 HTTP 200 OK입니다.
curl -s -k -u $USER:$PASS -H content-type:application/json -X POST
https://localhost:9443/v1/bdbs/actions/validate_backup_location -d
'{"backup_location": {"type": "s3", "bucket_name": '"$BUCKET"',
"subdir": "","access_key_id": '"$ACCESS_KEY"', "secret_access_key":
'"$SECRET_KEY"'}}'
백업을 생성합니다. 성공 시 반환되는 유일한 응답은 HTTP 200 OK입니다.
curl -s -k -u $USER:$PASS -H content-type:application/json -X POST
https://localhost:9443/v1/bdbs/1/actions/export -d
'{"export_location": {"type": "s3", "bucket_name": '"$BUCKET"',
"subdir": "", "access_key_id": '"$ACCESS_KEY"', "secret_access_key":
'"$SECRET_KEY"'}}'
30분마다 반복 실행되는 정기 백업을 구성합니다. 성공 시 반환되는 유일한 응답은 HTTP 200 OK입니다.
curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT
https://localhost:9443/v1/bdbs/1 -d '{"backup":true,
"backup_interval":1800, "backup_interval_offset":360,
"backup_location": {"type": "s3", "bucket_name": '"$BUCKET"',
"subdir": "", "access_key_id": '"$ACCESS_KEY"', "secret_access_key":
'"$SECRET_KEY"'}}'
마무리 생각
마찰 없는 이상적인 세계라면 HA와 액티브-액티브로 구성된 Redis Enterprise 덕분에 지속성과 백업을 걱정할 필요가 없겠지만, 현실은 그렇지 않습니다. Redis가 시스템 장애로부터 복구해야 하는 환경이라면 지속성과 백업(HA와 함께)이 모두 필요합니다. Dell EMC, NetApp, Pure Storage와 같은 업체의 어플라이언스 제품군에서 확인할 수 있듯이, S3 백업 엔드포인트를 활용하는 것은 이미 업계의 일반적인 관행입니다. 다행히 Cohesity SmartFiles와의 검증된 통합을 통해 이 엔드포인트를 손쉽게 활용하고, 운영 전략에 백업을 자연스럽게 포함시킬 수 있습니다.