Azure Managed Redis는 Redis Enterprise 소프트웨어를 기반으로 메모리 내 데이터 저장소를 제공합니다. Redis Enterprise는 호환성을 유지하면서 Redis 커뮤니티 버전의 성능과 안정성을 향상시킵니다. Microsoft는 Azure에서 호스트되고 Azure 내부 또는 외부의 모든 애플리케이션에서 사용할 수 있는 서비스를 운영합니다. Azure Managed Redis를 빌드하는 방법에 대한 자세한 내용은 Azure Managed Redis 아키텍처를 참조하세요.
Azure Managed Redis는 백 엔드 데이터 저장소를 많이 사용하는 애플리케이션의 성능과 확장성을 향상시킬 수 있습니다. 서버 메모리에 자주 액세스하는 데이터를 보관하여 대량의 애플리케이션 요청을 처리할 수 있으며, 이 데이터는 빠르게 쓰고 읽을 수 있습니다.
Redis는 최신 애플리케이션에 매우 짧은 대기 시간 및 높은 처리량의 데이터 스토리지 솔루션을 제공합니다. 또한 Redis는 데이터 수집, 중복 제거, 메시징, 순위표, 의미 체계 캐싱 및 벡터 데이터베이스를 포함한 캐싱이 필요 없는 애플리케이션에 점점 더 많이 사용되고 있습니다.
Azure Managed Redis는 독립 실행형으로 배포하거나 Azure Container Apps, Azure App Service, Azure Functions, Azure SQL 또는 Azure Cosmos DB와 같은 다른 Azure 앱 또는 데이터베이스 서비스와 함께 배포할 수 있습니다.
주요 시나리오
Azure Managed Redis는 일반적인 애플리케이션 아키텍처 패턴을 지원하여 애플리케이션 성능을 향상시킵니다. 가장 일반적인 패턴의 일부는 다음과 같습니다.
| Pattern | Description |
|---|---|
| 데이터 캐시 | 데이터베이스는 너무 커서 캐시로 직접 로드할 수 없습니다. 캐시 배제 패턴을 사용하여 필요할 때만 캐시에 데이터를 로드하는 것이 일반적입니다. 시스템에서 데이터를 변경하는 경우 시스템은 바로 그때 다른 클라이언트로 배포되는 캐시를 업데이트할 수도 있습니다. 또한 시스템에서 데이터에 대한 만료 날짜를 설정하거나 제거 정책을 사용하여 데이터 업데이트를 캐시로 트리거할 수 있습니다. |
| 콘텐츠 캐시 | 헤더, 바닥글, 배너와 같은 정적 콘텐츠를 사용하는 템플릿에서 많은 웹 페이지가 생성됩니다. 이러한 정적 항목은 자주 변경되지 않습니다. 메모리 내 캐시를 사용하면 백 엔드 데이터 저장소와 비교할 때 정적 콘텐츠에 빠르게 액세스할 수 있습니다. 이 패턴은 처리 시간 및 서버 부하를 줄여 웹 서버 응답성을 높일 수 있습니다. 이를 통해 로드를 처리하는 데 필요한 서버 수를 줄일 수 있습니다. Azure Managed Redis는 ASP.NET 이 패턴을 지원하기 위해 Redis 출력 캐시 공급자를 제공합니다. |
| 세션 저장소 | 이 패턴은 일반적으로 웹 애플리케이션에서 사용자 쿠키와 연결할 수 있는 쇼핑 카트 및 다른 사용자 기록 데이터와 함께 사용됩니다. 쿠키에 너무 많이 저장하면 쿠키 크기가 증가하고 모든 요청에서 전달 및 유효성 검사가 수행되므로 성능이 저하될 수 있습니다. 일반적인 해결책은 쿠키를 키로 사용하여 데이터베이스에 데이터를 쿼리하는 것입니다. Azure Managed Redis와 같은 메모리 내 캐시를 사용하여 사용자와 정보를 연결하는 경우 전체 관계형 데이터베이스와 상호 작용하는 것보다 더 빠릅니다. |
| 벡터 유사성 검색 | 일반적인 AI 사용 사례는 LLM(큰 언어 모델)을 사용하여 벡터 포함을 생성하는 것입니다. 이러한 벡터 포함은 벡터 데이터베이스에 저장한 다음 비교하여 유사성을 확인해야 합니다. Azure Managed Redis에는 높은 처리량에서 벡터 포함을 저장하고 비교하는 기본 제공 기능이 있습니다. |
| 의미 체계 캐싱 | LLM을 사용하면 애플리케이션에 많은 대기 시간(생성 시간) 및 비용(토큰 가격 책정으로 인한 비용)이 발생하는 경우가 많습니다. 캐싱은 LLM의 과거 출력을 저장하여 신속하게 다시 검색할 수 있도록 이러한 문제를 해결하는 데 도움이 될 수 있습니다. 그러나 LLM이 자연어를 사용하기 때문에 일반적인 캐시에서 저장을 처리하기가 어려울 수 있습니다. Azure Managed Redis와 같은 의미 체계 캐시는 특정 쿼리뿐만 아니라 쿼리의 의미 체계를 캐싱할 수 있으므로 LLM에서 훨씬 더 자연스럽게 사용할 수 있습니다. |
| Deduplication | 종종 사용자 이름이 이미 사용되었는지 또는 고객에게 이미 이메일이 발송되었는지와 같이 시스템에서 어떤 작업이 이미 이루어졌는지를 확인해야 할 때가 있습니다. Azure Managed Redis에서 블룸 필터는 중복 항목을 빠르게 확인하고 문제를 방지할 수 있습니다. |
| Leaderboards | Redis는 정렬된 집합 데이터 구조를 사용하여 모든 종류의 순위표를 개발하기 위한 단순하고 강력한 지원을 제공합니다. 또한, 활성 지역 복제를 사용하면 하나의 순위표를 전 세계적으로 공유할 수 있습니다. |
| 작업 및 메시지 큐 | 애플리케이션은 요청과 연결된 작업을 실행하는 데 시간이 걸릴 때 종종 작업을 추가합니다. 오래 실행되는 작업은 종종 다른 서버에 의해 순서대로 처리되도록 큐에 대기됩니다. 이러한 작업 지연 메서드를 태스크 큐라고 합니다. Azure Managed Redis는 애플리케이션에서 이 패턴을 사용하도록 설정하는 분산 큐를 제공합니다. |
| PowerBI/분석 가속화 | Redis ODBC 드라이버를 사용하여 BI, 보고 및 분석 사용 사례에 Redis를 활용할 수 있습니다. Redis는 일반적으로 관계형 데이터베이스보다 훨씬 빠르기 때문에 이러한 방식으로 Redis를 사용하면 쿼리 응답성이 크게 향상될 수 있습니다. |
| 분산 트랜잭션 | 애플리케이션에는 단일 원자성 작업으로 실행하기 위해 백 엔드 데이터 저장소에 대한 일련의 명령이 필요할 수 있습니다. 모든 명령은 성공하거나 모두 초기 상태로 롤백되어야 합니다. Azure Managed Redis는 일괄 처리 명령을 단일 트랜잭션으로 실행하는 것을 지원합니다. |
Redis 버전
Azure Managed Redis는 Redis 버전 7.4.x를 지원합니다. 자세한 내용은 Azure Managed Redis 인스턴스의 버전을 업그레이드하는 방법을 참조하세요.
올바른 계층 선택
Azure Managed Redis에는 4가지 계층이 있으며, 각 계층마다 성능 특성과 가격 등급이 다릅니다.
계층 및 SKU 한눈에 보기
세 계층은 메모리 내 데이터를 저장합니다.
- 메모리 최적화 높은 메모리 대 vCPU 비율(8:1)이 필요하지만 가장 높은 처리량 성능은 필요하지 않은 메모리 집약적 사용 사례에 이상적입니다. 더 적은 처리 능력 혹은 처리량이 필요한 시나리오에 관해 더 낮은 가격점을 제공해 개발과 테스트 환경에 적합한 선택입니다.
- 균형(메모리 + 컴퓨팅) 균형 잡힌 메모리 대 vCPU(4:1) 비율을 제공하여 표준 워크로드에 적합합니다. 이 계층은 메모리 및 컴퓨팅 리소스의 정상 균형을 제공합니다.
- 컴퓨팅 최적화 최대 처리량이 필요하고 메모리 대 vCPU 비율(2:1)이 낮은 성능 집약적 워크로드를 위해 설계되었습니다. 가장 높은 성능을 요하는 애플리케이션에 이상적입니다.
한 계층은 메모리 내부와 디스크의 데이터를 모두 저장합니다.
- 플래시 최적화(미리 보기) Redis 클러스터가 메모리(RAM)에서 NVMe 스토리지로 덜 자주 액세스하는 데이터를 자동으로 이동할 수 있도록 합니다. 이는 성능이 저하되지만 큰 데이터 세트를 사용해 캐시를 비용 효율적으로 스케일링할 수 있습니다.
데이터 지속성 기능을 사용하여 메모리 내 계층에 대한 데이터를 디스크에 저장할 수도 있습니다. 데이터 지속성은 예기치 않은 중단이 발생하는 경우 빠른 복구를 위해 디스크에 데이터의 백업 복사본을 저장합니다. 이는 일반적인 작업을 위해 디스크에 데이터를 저장하도록 설계된 플래시 최적화 계층과 다릅니다.
플래시 최적화 계층을 사용하여 디스크에 일부 데이터를 저장해도 데이터 복원력이 증가하지는 않습니다. 플래시 최적화 계층에서도 데이터 지속성을 사용할 수 있습니다.
Note
Flash 최적화 계층을 설계하는 방법에 대한 자세한 내용은 Azure Managed Redis 아키텍처를 참조하세요.
- 계층 및 SKU 간 크기 조정 방법에 대한 지침은 Azure Managed Redis 인스턴스 크기 조정을 참조하세요.
- 가격 책정 정보는 Azure Managed Redis 가격 책정을 참조하세요.
Important
120GB 이상의 스토리지를 사용하는 모든 메모리 내 계층은 메모리 최적화 M150 이상을 포함하여 공개 미리 보기로 제공됩니다. 균형 잡힌 B150 이상; 및 컴퓨팅 최적화 X150 이상. 이러한 모든 계층 이상은 공개 미리 보기에 있습니다.
모든 플래시 최적화 계층은 공개 미리 보기로 제공됩니다.
기능 비교
다음 표는 계층별로 지원하는 기능 몇 가지를 설명하는 데 도움이 됩니다.
| 기능 설명 | Memory Optimized | Balanced | Compute Optimized | Flash Optimized |
|---|---|---|---|---|
| 크기(GB) | 12 - 1920 | 0.5 - 960 | 3 - 720 | 250 - 4500 |
| Service Level Agreement(서비스 수준 약정) | Yes | Yes | Yes | Yes |
| 전송 중 암호화 | 예(프라이빗 엔드포인트) | 예(프라이빗 엔드포인트) | 예(프라이빗 엔드포인트) | 예(프라이빗 엔드포인트) |
| 복제 및 장애 조치(failover) | Yes | Yes | Yes | Yes |
| 네트워크 격리 | Yes | Yes | Yes | Yes |
| Microsoft Entra ID 기반 인증 | Yes | Yes | Yes | Yes |
| 스케일링 | Yes | Yes | Yes | Yes |
| 데이터 지속성 | Yes | Yes | Yes | Yes |
| 영역 중복성 | Yes | Yes | Yes | Yes |
| Geo-replication | 예(활성) | 예(활성) | 예(활성) | No |
| 비클러스터형 인스턴스 | Yes | Yes | Yes | No |
| 연결 감사 로그 | 예(이벤트 기반) | 예(이벤트 기반) | 예(이벤트 기반) | 예(이벤트 기반) |
| JSON 데이터 구조(즉, Redis JSON) | Yes | Yes | Yes | Yes |
| 검색 기능(벡터 검색 포함) | Yes | Yes | Yes | No |
| 확률적 데이터 구조(즉, Redis Bloom) | Yes | Yes | Yes | Yes |
| 시계열 데이터베이스 기능(즉, Redis TimeSeries) | Yes | Yes | Yes | Yes |
| Import/Export | Yes | Yes | Yes | Yes |
Important
분산 B0 및 B1 SKU 옵션은 활성 지역 복제를 지원하지 않습니다.
Note
지원 축소는 경우에 따라 제한됩니다. 자세한 내용은 Azure Managed Redis 크기 조정의 제한 사항을 참조하세요.
네트워크 성능
높은 처리량이 필요한 워크로드가 있는 경우 네트워크 대역폭으로 인해 병목 현상이 발생할 수 있습니다. 더 높은 성능 계층으로 이동하거나 큰 인스턴스 크기로 이동하여 대역폭을 늘릴 수 있습니다. 크기가 큰 인스턴스는 캐시를 호스트하는 기본 VM으로 인해 더 많은 대역폭을 갖습니다. 대역폭 제한이 높으면 애플리케이션에서 시간 제한을 발생시키는 네트워크 포화를 방지할 수 있습니다. 대역폭 성능에 대한 자세한 내용은 성능 테스트를 참조하세요.
최대 클라이언트 연결 수
각 SKU에는 최대 클라이언트 연결 수가 있습니다. 이 제한은 더 높은 성능 계층과 더 큰 인스턴스 크기로 증가합니다. 다음 표에서는 Azure Managed Redis SKU당 허용되는 최대 클라이언트 연결을 보여 줍니다.
이 표에서는 계층 및 메모리 크기별 최대 연결을 보여 줍니다.
| 크기(GB) | Memory 최적화됨 |
Balanced | Compute 최적화됨 |
플래시 최적화됨 (프리뷰) |
|---|---|---|---|---|
| 0.5 | - | 15,000 | - | - |
| 1 | - | 15,000 | - | - |
| 3 | - | 15,000 | 30,000 | - |
| 6 | - | 15,000 | 30,000 | - |
| 12 | 15,000 | 30,000 | 75,000 | - |
| 24 | 30,000 | 75,000 | 150,000 | - |
| 60 | 75,000 | 150,000 | 200,000 | - |
| 120 | 150,000 | 200,000 | 200,000 | - |
| 180 * | 200,000 | 200,000 | 200,000 | - |
| 240 * | 200,000 | 200,000 | 200,000 | 75,000 |
| 360 * | 200,000 | 200,000 | 200,000 | - |
| 480 * | 200,000 | 200,000 | 200,000 | 150,000 |
| 720 * | 200,000 | 200,000 | 200,000 | 200,000 |
| 960 * | 200,000 | 200,000 | - | 200,000 |
| 1440 * | 200,000 | - | - | 200,000 |
| 1920 * | 200,000 | - | - | 200,000 |
| 4500 * | - | - | - | 200,000 |
* 별표가 있는 크기는 공개 미리 보기로 제공됩니다.
고가용성
Azure Managed Redis는 고가용성을 제공합니다. SLA에서는 캐시 엔드포인트에 대한 연결만 다룹니다. SLA는 데이터 손실에서 보호에는 적용되지 않습니다. SLA에 대한 자세한 내용은 SLA를 참조하세요. Azure Managed Redis 인스턴스에서 고가용성을 사용하지 않도록 설정할 수 있습니다. 이렇게 하면 가격이 낮아지지만 데이터 손실 및 가동 중지 시간이 발생합니다. 개발/테스트 시나리오에 대해서만 고가용성을 사용하지 않도록 설정하는 것이 좋습니다.
기타 가격 책정 고려 사항
Important
Azure Managed Redis Enterprise에는 각 캐시 인스턴스에 대한 IP 주소가 필요합니다. 현재 IP 주소 요금은 Azure Managed Redis에서 흡수되며 고객에게 전달되지 않습니다. 이는 나중에 변경될 수 있습니다. 자세한 내용은 IP 주소 가격 책정을 참조하세요.
Important
활성 지역 복제를 사용하면 Azure 지역 간에 데이터 전송이 생성됩니다. 이러한 대역폭 요금은 현재 Azure Managed Redis에서 흡수되며 고객에게 전달되지 않습니다. 이는 앞으로 바뀔 수도 있습니다. 자세한 내용은 대역폭 가격 책정을 참조하세요.
지역별 가용성
Azure Managed Redis는 지속적으로 새로운 지역으로 확장되고 있습니다. 지역별 사용 가능 여부를 확인하려면 지역별 사용 가능한 제품을 참조하세요.
Azure Cache for Redis에서 이동
Azure Cache for Redis에서 Azure Managed Redis로 마이그레이션하는 방법에 대한 자세한 내용은 Azure Cache for Redis에서 Azure Managed Redis로 이동을 참조하세요.