Azure Cache for Redis에 대한 데이터 지속성을 구성
Redis 지속성을 사용하면 캐시 인스턴스에 저장된 데이터를 유지할 수 있습니다. 하드웨어 오류가 있는 경우 캐시 인스턴스는 다시 온라인 상태가 되면 지속성 파일의 데이터로 리하이드레이션됩니다. 데이터를 유지하는 기능은 모든 캐시 데이터가 메모리에 저장되므로 캐시 인스턴스의 내구성을 높이는 중요한 방법입니다. 캐시 노드가 다운된 경우 오류가 발생하면 데이터 손실이 있을 수 있습니다. 지속성은 Azure Cache for Redis를 사용한 고가용성 및 재해 복구 전략의 핵심 부분이 되어야 합니다.
Warning
Premium 계층에서 지속성을 사용하는 경우 데이터 지속성 기능을 사용하기 전에 스토리지 계정에 일시 삭제를 사용하도록 설정했는지 확인합니다. 일시 삭제와 함께 데이터 지속성을 사용하면 매우 높은 스토리지 비용이 발생합니다. 자세한 내용은 일시 삭제를 사용하도록 설정해야 하나요?를 참조하세요.
Warning
Enterprise 및 Enterprise Flash 계층의 AOF 지속성에 대한 항상 쓰기 옵션은 2025년 4월 1일에 사용 중지되도록 설정됩니다. 이 옵션에는 더 이상 권장되지 않는 중요한 성능 제한이 있습니다. 대신 매 초마다 쓰기 옵션을 사용하거나 RDB 지속성을 사용하는 것이 좋습니다.
가용성 범위
서비스 계층 | 기본, 표준 | Premium | Enterprise, Enterprise Flash |
---|---|---|---|
사용 가능 | 예 | 예 | 예(미리 보기) |
Redis의 데이터 지속성 유형
Azure Cache for Redis를 사용한 지속성에는 RDB(‘Redis 데이터베이스’) 형식과 AOF(‘추가 전용 파일’) 형식의 두 가지 옵션이 있습니다.
- RDB 지속성 - RDB 지속성을 사용하는 경우 Azure Cache for Redis는 캐시의 스냅샷을 이진 형식으로 유지합니다. 스냅샷은 Azure Storage 계정에 저장됩니다. 구성 가능한 백업 빈도에 따라 스냅샷을 유지할 빈도가 결정됩니다. 중대한 이벤트가 발생하여 주 및 복제본 캐시가 모두 비활성화된 경우 가장 최근의 스냅샷을 사용하여 자동으로 캐시를 재구성합니다. RDB 지속성의 장점 및 단점에 대해 자세히 알아봅니다.
- AOF 지속성 - AOF 지속성을 사용하는 경우 Azure Cache for Redis는 모든 쓰기 작업을 로그에 저장합니다. 로그는 초당 한 번 이상 Azure Storage 계정에 저장됩니다. 중대한 이벤트가 발생하여 주 및 복제본 캐시가 모두 비활성화된 경우 저장된 쓰기 작업을 사용하여 자동으로 캐시를 재구성합니다. AOF 지속성의 장점 및 단점에 대해 자세히 알아봅니다.
Azure Cache for Redis 지속성 기능은 데이터 손실 후 자동으로 동일한 캐시에 데이터를 복원하는 데 사용됩니다. RDB/AOF 지속형 데이터 파일은 새 캐시나 기존 캐시로 가져올 수 없습니다. 캐시 간에 데이터를 이동하려면 Import/Export 기능을 사용합니다. 자세한 내용은 Azure Cache for Redis에서 데이터 가져오기 및 내보내기를 참조하세요.
새 캐시에 추가할 수 있는 데이터 백업을 생성하려면 PowerShell 또는 CLI를 사용하여 자동화된 스크립트를 작성하여 주기적으로 데이터를 내보낼 수 있습니다.
필수 구성 요소 및 제한 사항
지속성 기능은 데이터 손실 후 동일한 캐시에 데이터를 복원하는 데 사용됩니다.
- RDB/AOF 지속형 데이터 파일은 새 캐시나 기존 캐시로 가져올 수 없습니다. 대신 Import/Export 기능을 사용합니다.
- 지속성은 수동 지역 복제 또는 활성 지역 복제를 사용하는 캐시에서 지원되지 않습니다.
- Premium 계층에서 AOF 지속성은 다중 복제본에서 지원되지 않습니다.
- Premium 계층에서 데이터는 캐시 인스턴스와 동일한 지역의 스토리지 계정에 유지해야 합니다.
- 프리미엄 계층에서 관리 ID를 사용하여 스토리지 계정에 연결하는 경우 다른 구독의 스토리지 계정을 사용하여 데이터를 유지할 수 있습니다.
Premium 계층과 Enterprise 계층의 지속성 간 차이
Premium 계층에서 데이터는 사용자가 소유하고 관리하는 Azure Storage 계정에 직접 유지됩니다. Azure Storage는 데이터가 유지될 때 데이터를 자동으로 암호화하지만 암호화에 사용자 고유의 키를 사용할 수도 있습니다. 자세한 내용은 Azure Storage 암호화용 고객 관리형 키를 참조하세요.
Warning
Premium 계층에서 지속성을 사용하는 경우 데이터 지속성 기능을 사용하기 전에 스토리지 계정에 일시 삭제를 사용하도록 설정했는지 확인합니다. 일시 삭제와 함께 데이터 지속성을 사용하면 매우 높은 스토리지 비용이 발생합니다. 자세한 내용은 일시 삭제를 사용하도록 설정해야 하나요?를 참조하세요.
Enterprise 및 Enterprise Flash 계층에서 데이터는 캐시 인스턴스에 직접 연결된 관리 디스크에 유지됩니다. 이 위치를 사용자는 구성할 수도 없고 액세스할 수도 없습니다. 관리 디스크를 사용하면 지속성 성능이 향상됩니다. 디스크는 기본적으로 MMK(Microsoft 관리형 키)를 사용하여 암호화되지만 CMK(고객 관리형 키)도 사용할 수 있습니다. 자세한 내용은 데이터 암호화 관리를 참조하세요.
Azure Portal을 사용하여 데이터 지속성을 설정하는 방법
PowerShell 및 Azure CLI를 사용하여 데이터 지속성을 설정하는 방법
데이터 암호화 관리
Redis 지속성은 미사용 데이터를 생성하므로 이 데이터를 암호화하는 것은 많은 사용자에게 중요한 문제입니다. 암호화 옵션은 사용 중인 Azure Cache for Redis 계층에 따라 다릅니다.
Premium 계층을 사용하면 지속성이 시작될 때 캐시 인스턴스에서 Azure Storage로 데이터가 직접 스트리밍됩니다. Microsoft 관리형 키, 고객 관리형 키 및 고객이 제공한 키를 비롯한 다양한 암호화 방법을 Azure Storage에서 사용할 수 있습니다. 암호화 방법에 대한 자세한 내용은 미사용 데이터에 대한 Azure Storage 암호화를 참조하세요.
Enterprise 및 Enterprise Flash 계층을 사용하면 데이터가 캐시 인스턴스에 탑재된 관리 디스크에 저장됩니다. 기본적으로 지속성 데이터를 보유하는 디스크와 OS 디스크는 Microsoft 관리형 키를 사용하여 암호화됩니다. CMK(고객 관리형 키)를 사용하여 데이터 암호화를 제어할 수도 있습니다. 지침에 대해서는 Enterprise 계층 캐시의 암호화를 참조하세요.
지속성 FAQ
Azure Cache for Redis 지속성에 대해 자주 묻는 질문과 대답이 나와 있는 목록은 다음과 같습니다.
- 이전에 만든 캐시에서 지속성을 사용할 수 있나요?
- AOF 및 RDB 지속성을 동시에 사용할 수 있나요?
- 지속성은 지역 복제에서 어떻게 작동하나요?
- 어떤 지속성 모델을 선택해야 하나요?
- 다른 크기로 확장했고 크기 조정 작업 전에 만들어진 백업을 복원할 경우 어떻게 되나요?
- 서로 다른 두 캐시의 지속성에 대해 동일한 스토리지 계정을 사용할 수 있나요?
- 데이터 지속성에 사용되는 스토리지에 대한 요금이 청구되나요?
- RDB 및 AOF 지속성은 Blob에 얼마나 자주 쓰며 일시 삭제를 사용하도록 설정해야 하나요?
- 스토리지 계정에 방화벽 예외가 있으면 지속성에 영향을 줍니다.
- 내 스토리지 계정에서 일시 삭제가 사용되는지 여부를 어떻게 확인하나요?
RDB 지속성
- 캐시를 만든 후 RDB 백업 주기를 변경할 수 있나요?
- RDB 백업 주기가 60분인데 왜 백업 사이 간격이 60분 이상이 되나요?
- 새 백업을 만들면 이전 RDB 백업은 어떻게 되나요?
AOF 지속성
- 두 번째 스토리지 계정은 언제 사용해야 하나요?
- AOF 지속성이 내 캐시의 처리량, 대기 시간 또는 성능에 영향을 미치나요?
- 두 번째 스토리지 계정은 어떻게 제거할 수 있나요?
- 다시 쓰기란 무엇이며 내 캐시에 어떤 영향을 미치나요?
- AOF가 설정된 캐시의 크기를 조정하는 경우 어떻게 되나요?
- 스토리지에서 AOF 데이터는 어떤 방식으로 구성되나요?
- 둘 이상의 복제본이 있는 경우 AOF 지속성을 사용하도록 설정할 수 있나요?
이전에 만든 캐시에서 지속성을 사용할 수 있나요?
예, 지속성은 캐시를 만들 때와 기존 Premium, Enterprise 또는 Enterprise Flash 캐시에서 모두 구성할 수 있습니다.
AOF 및 RDB 지속성을 동시에 사용할 수 있나요?
아니요. RDB 또는 AOF를 사용하도록 설정할 수 있지만 동시에 둘 다 설정할 수는 없습니다.
지속성은 지역 복제에서 어떻게 작동하나요?
데이터 지속성을 사용하도록 설정하면 캐시에 지역 복제를 사용하도록 설정할 수 없습니다.
어떤 지속성 모델을 선택해야 하나요?
AOF 지속성은 모든 쓰기를 로그에 저장하여 처리량에 상당한 영향을 주며, 구성된 백업 간격에 따라 백업을 저장하고 성능에 미치는 영향을 최소화하면서 AOF를 RDB 지속성과 비교합니다. 기본 목표가 데이터 손실을 최소화하는 것이며 캐시에 대해 낮은 처리량을 처리할 수 있는 경우에는 AOF 지속성을 선택합니다. 캐시에 대해 최적의 처리량을 유지하려고 하면서도 데이터 복구 메커니즘을 계속 유지하려는 경우에는 RDB 지속성을 선택합니다.
AOF 지속성을 사용하는 경우 성능에 대한 자세한 내용은 AOF 지속성이 내 캐시의 처리량, 대기 시간 또는 성능에 영향을 미치나요?를 참조하세요.
AOF 지속성이 내 캐시의 처리량, 대기 시간 또는 성능에 영향을 미치나요?
AOF 지속성은 처리량에 영향을 미칩니다. AOF는 기본 프로세스와 복제본 프로세스 모두에서 실행되므로 AOF 지속성이 없는 동일한 캐시보다 AOF 지속성이 있는 캐시에 대한 CPU 및 서버 로드가 더 높습니다. AOF는 각 쓰기 및 삭제가 몇 초 정도 지연되면서 유지되기 때문에 메모리 데이터와 최상의 일관성을 제공합니다. 단점은 AOF가 컴퓨팅 집약적이라는 것입니다.
CPU 및 서버 로드가 모두 90% 미만인 경우 처리량은 저하되지만 캐시는 정상적으로 작동합니다. CPU 및 서버 로드가 90%를 초과하면 처리량이 훨씬 더 크게 저하될 수 있으며 캐시에서 처리하는 모든 명령의 대기 시간이 증가합니다. AOF 지속성이 기본 프로세스와 복제본 프로세스 모두에서 실행되어 사용 중인 노드에 대한 부하가 늘어나고 데이터의 중요한 경로에 지속성이 적용되기 때문에 대기 시간이 늘어납니다.
다른 크기로 확장했고 크기 조정 작업 전에 만들어진 백업을 복원할 경우 어떻게 되나요?
RDB 및 AOF 지속성:
- 크기를 더 크게 조정한 경우에는 아무 효과가 없습니다.
- 더 작은 크기를 조정했고 새 크기에 대한 데이터베이스 제한보다 사용자 지정 데이터베이스 설정이 더 크다면, 그러한 데이터베이스에 저장된 데이터는 복원되지 않습니다. 자세한 내용은 사용자 지정 데이터베이스 설정이 크기 조정 동안 영향을 받나요?
- 더 작은 크기로 확장하고 마지막 백업의 모든 데이터를 저장할 수 있는 작은 크기의 공간이 충분하지 않으면 복원 프로세스 중에 키가 제거됩니다. 일반적으로 키는 allkeys-lru 제거 정책을 사용하여 제거됩니다.
서로 다른 두 캐시의 지속성에 대해 동일한 스토리지 계정을 사용할 수 있나요?
아니요, 캐시에 따라 다른 스토리지 계정을 사용해야 합니다. 지속성을 설정하려면 각 캐시에 자체 스토리지 계정이 있어야 합니다.
Important
캐시에서 지속성을 설정하고 주기적 내보내기 작업을 수행하려면 별도의 스토리지 계정을 사용합니다.
데이터 지속성에 사용되는 스토리지에 대한 요금이 청구되나요?
- Premium 캐시의 경우 사용 중인 스토리지 계정에 대한 가격 책정 모델에 따라 사용되는 스토리지에 대한 요금이 청구됩니다.
- Enterprise 및 Enterprise Flash 캐시의 경우 관리 디스크 스토리지에 대한 요금이 청구되지 않습니다. 이미 가격에 포함되어 있습니다.
RDB 및 AOF 지속성은 Blob에 얼마나 자주 쓰며 일시 삭제를 사용하도록 설정해야 하나요?
Premium 계층에서 Azure Cache for Redis 데이터 지속성과 함께 사용하는 경우 스토리지 계정에서 일시 삭제를 사용하지 않는 것이 좋습니다. RDB 및 AOF 지속성은 1시간, 몇 분 또는 1초마다 BLOB에 자주 쓸 수 있습니다. 또한 스토리지 계정에서 일시 삭제를 사용하도록 설정하면 Azure Cache for Redis가 이전 백업 데이터를 삭제하여 스토리지 비용을 최소화할 수 없습니다.
매초 쓰기 작업도 수행하는 일시 삭제는 캐시의 일반적인 데이터 크기로 인해 비용이 빠르게 증가할 수 있습니다. 일시 삭제 비용에 대한 자세한 내용은 가격 책정 및 청구를 참조하세요.
캐시를 만든 후 RDB 백업 주기를 변경할 수 있나요?
예, Azure Portal, CLI 또는 PowerShell을 사용하여 RDB 지속성의 백업 빈도를 변경할 수 있습니다.
RDB 백업 주기가 60분인데 왜 백업 사이 간격이 60분 이상이 되나요?
RDB 지속성 백업 간격의 주기는 이전 백업 프로세스가 성공적으로 완료되어야 시작됩니다. 백업 간격이 60분이고 백업 프로세스를 완료하는 데 15분이 걸린다면 다음 백업은 이전 백업 시작 시점에서 75분까지 시작되지 않습니다.
새 백업을 만들면 이전 RDB 백업은 어떻게 되나요?
가장 최근 백업을 제외한 모든 RDB 지속성 백업은 자동으로 삭제됩니다. 즉시 삭제되지 않을 수 있으나 오래된 백업을 무한정 유지하지는 않습니다. 지속성을 위해 Premium 계층을 사용하고 있으며 스토리지 계정에 대해 일시 삭제를 설정하는 경우 일시 삭제 설정이 적용되고 기존 백업은 일시 삭제 상태로 계속 상주합니다.
두 번째 스토리지 계정은 언제 사용해야 하나요?
AOF 지속성이 캐시에 대해 예상된 설정 작업보다 더 높다고 판단되면 AOF 지속성에 대해 두 번째 스토리지 계정을 사용합니다. 보조 스토리지 계정을 설정하면 캐시가 스토리지 대역폭 제한에 도달하지 않도록 하는 데 도움이 됩니다. 이 옵션은 Premium 계층 캐시에서만 사용할 수 있습니다.
두 번째 스토리지 계정은 어떻게 제거할 수 있나요?
두 번째 스토리지 계정을 첫 번째 스토리지 계정과 동일하게 설정하여 AOF 지속성 보조 스토리지 계정을 제거할 수 있습니다. 기존 캐시의 경우 캐시의 리소스 메뉴에서 데이터 지속성에 액세스합니다. AOF 지속성을 사용하지 않도록 설정하려면 사용 안 함을 선택합니다.
다시 쓰기란 무엇이며 내 캐시에 어떤 영향을 미치나요?
AOF 파일이 충분히 커지면 다시 쓰기가 자동으로 큐에 대기됩니다. 다시 쓰기를 수행하면 현재 데이터 집합을 만드는 데 필요한 작업의 최소 집합을 사용하여 AOF 파일 크기가 다시 조정됩니다. 다시 쓰기 동안, 성능 제한에 더 빠르게 도달할 수 있으며 큰 데이터 세트를 처리할 때 특히 더 그렇습니다. AOF 파일이 더 커지면 다시 쓰기는 덜 자주 발생하지만 일단 발생하면 많은 시간이 소요됩니다.
AOF가 설정된 캐시의 크기를 조정하는 경우 어떻게 되나요?
크기 조정이 완료된 후에 파일이 다시 로드되므로 크기 조정 시 AOF 파일이 커질 경우 스케일링 작업이 예상한 것보다 더 오래 걸립니다.
크기 조정에 대한 자세한 내용은 다른 크기로 확장했고 크기 조정 작업 전에 만들어진 백업을 복원할 경우 어떻게 되나요?를 참조하세요.
스토리지에서 AOF 데이터는 어떤 방식으로 구성되나요?
프리미엄 계층을 사용하는 경우 AOF 파일에 저장된 데이터는 분할당 여러 페이지 Blob으로 나뉩니다. 기본적으로 Blob의 절반은 기본 스토리지 계정에 저장되고 절반은 보조 스토리지 계정에 저장됩니다. 여러 페이지 Blob과 두 개의 서로 다른 스토리지 계정에 데이터를 분할하면 성능이 향상됩니다.
캐시에 대한 쓰기의 최대 속도가 높지 않은 경우 이 추가 성능이 필요하지 않을 수 있습니다. 이 경우 보조 스토리지 계정 구성을 제거할 수 있습니다. 모든 AOF 파일은 단일 기본 스토리지 계정에만 저장됩니다. 다음 표에는 각 가격 책정 계층에 사용되는 총 페이지 Blob 수가 표시됩니다.
프리미엄 계층 | Blob |
---|---|
P1 | 분할당 8 |
P2 | 분할당 16 |
P3 | 분할당 32개 |
P4 | 분할당 40개 |
클러스터링을 사용하도록 설정하면 캐시의 각 분할은 이전 표에 표시된 것처럼 자체 페이지 Blob 집합을 갖습니다. 예를 들어 분할이 3개 있는 P2 캐시는 48개 페이지 Blob에 해당 AOF 파일을 분산합니다(분할된 데이터베이스당 16개 Blob, 3개 분할된 데이터베이스).
다시 쓰기 후 2개의 AOF 파일 집합이 스토리지에 존재합니다. 다시 쓰기 작업은 백그라운드에서 발생하며 첫 번째 파일 세트에 추가됩니다. 다시 쓰는 동안 캐시로 전송되는 설정 작업을 두 번째 집합에 추가합니다. 오류가 발생하는 경우 다시 쓰는 동안 백업이 일시적으로 저장됩니다. 다시 쓰기 작업이 완료되면 백업이 즉시 삭제됩니다. 스토리지 계정에 대해 일시 삭제를 켜면 일시 삭제 설정이 적용되고 기존 백업은 일시 삭제 상태로 계속 유지됩니다.
스토리지 계정에 방화벽 예외가 있으면 지속성에 영향을 주나요?
관리 ID를 사용하면 캐시 인스턴스가 신뢰할 수 있는 서비스 목록에 추가되므로 방화벽 예외를 더 쉽게 수행할 수 있습니다. 관리 ID를 사용하는 대신 키를 사용하여 스토리지 계정에 권한을 부여하는 경우 스토리지 계정에 방화벽 예외가 있으면 지속성 프로세스가 중단되는 경향이 있습니다. Premium 계층의 지속성에만 적용됩니다.
둘 이상의 복제본이 있는 경우 AOF 지속성을 사용하도록 설정할 수 있나요?
Premium 계층에서는 여러 복제본에 AOF(추가 전용 파일) 지속성을 사용할 수 없습니다. Enterprise 및 Enterprise Flash 계층에서 복제본 아키텍처는 더 복잡하지만 영역 중복 배포에서 엔터프라이즈 캐시를 사용하는 경우 AOF 지속성이 지원됩니다.
내 스토리지 계정에서 일시 삭제가 사용되는지 여부를 어떻게 확인하나요?
캐시가 지속성을 위해 사용하는 스토리지 계정을 선택합니다. 리소스 메뉴에서 데이터 보호를 선택합니다. 작업 창에서 ‘Blob에 일시 삭제 사용’ 상태를 확인합니다. Azure Storage 계정의 일시 삭제에 대한 자세한 내용은 Blob에 일시 삭제 사용을 참조하세요.
다음 단계
Azure Cache for Redis 기능에 대해 자세히 알아봅니다.