Azure Managed Redis를 사용한 개발(미리 보기)
연결 복원력 및 서버 부하
클라이언트 애플리케이션을 개발할 때 연결 복원력 및 서버 부하 관리와 관련된 모범 사례를 고려합니다.
더 많은 키와 더 작은 값 고려
Azure Managed Redis(미리 보기)는 더 작은 값에서 가장 잘 작동합니다. 여러 키에 데이터를 분산하려면 큰 데이터 청크를 작은 청크로 나누는 것이 좋습니다. 이상적인 값 크기에 대한 자세한 내용은 이 문서를 참조하세요.
크기가 큰 요청 또는 응답
큰 요청/응답으로 시간 초과가 발생할 수 있습니다. 예를 들어 클라이언트에 구성된 시간 제한 값이 1초라고 가정하겠습니다. 애플리케이션이 동시에 2개의 키(예: 'A' 및 'B')를 요청합니다(동일한 실제 네트워크 연결 사용). 대부분의 클라이언트에서는 요청 ‘A’와 ‘B’가 둘 다 응답을 기다리지 않고 연달아 전송되는 요청 파이프라인을 지원합니다. 서버는 응답을 동일한 순서로 전송합니다. 응답 ‘A’의 크기가 크면 후속 요청을 위한 시간 제한에서 대부분의 시간을 사용할 수 있습니다.
다음 예제에서는 요청 ‘A’와 ‘B’가 서버로 신속하게 전송됩니다. 서버는 신속하게 응답 ‘A’와 ‘B’를 전송하기 시작합니다. 데이터 전송 시간 때문에 응답 ‘B’는 서버가 신속하게 응답하는 경우에도 응답 ‘A’의 시간 제한이 종료될 때까지 기다려야 합니다.
|-------- 1 Second Timeout (A)----------|
|-Request A-|
|-------- 1 Second Timeout (B) ----------|
|-Request B-|
|- Read Response A --------|
|- Read Response B-| (**TIMEOUT**)
이 요청/응답은 측정하기 어렵습니다. 크기가 큰 요청 및 응답을 추적하도록 클라이언트 코드를 계측할 수 있습니다.
크기가 큰 응답 문제를 해결하는 방법은 다음과 같이 다양합니다.
- 적은 수의 큰 값이 아니라 많은 수의 작은 값에 대해 애플리케이션을 최적화합니다.
- 선호하는 해결 방법은 데이터를 더 작은 값으로 분할하는 것입니다.
- 더 작은 값을 권장하는 이유에 대한 자세한 내용은 redis에 이상적인 값 크기 범위는 무엇인가요? 100KB는 너무 큰가요? 게시물을 참조하세요.
- 더 높은 대역폭 기능을 얻기 위해 VM(가상 머신) 크기를 늘림
- 클라이언트 또는 서버 VM의 대역폭이 증가하면 크기가 큰 응답의 데이터 전송 시간을 줄일 수 있습니다.
- 두 머신의 현재 네트워크 사용량과 현재 VM 크기 한도를 비교해 보세요. 서버에서만 또는 클라이언트에서만 대역폭이 증가하는 것으로는 충분하지 않을 수 있습니다.
- 애플리케이션에서 사용하는 연결 개체 수를 늘립니다.
- 라운드 로빈 방식을 사용하여 여러 연결 개체에 대한 요청을 수행할 수 있습니다.
파이프라인 사용
Redis 파이프라인을 지원하는 Redis 클라이언트를 선택해 보세요. 파이프라인은 네트워크를 효율적으로 사용하고 가능한 최상의 처리량을 얻는 데 도움이 됩니다.
비용이 많이 드는 작업 방지
KEYS 명령과 같은 일부 Redis 작업은 비용이 많이 들기 때문에 피해야 합니다. 장기 실행 명령에 대한 몇 가지 고려 사항은 장기 실행 명령을 참조하세요.
적절한 계층 선택
Azure Managed Redis는 메모리 최적화, 분산, 컴퓨팅 최적화 및 플래시 최적화 계층을 제공합니다. 계층 을 선택하는 방법에 대한 자세한 내용은 여기를 참조하세요. 성능 테스트를 통해 올바른 계층을 선택하고 연결 설정의 유효성을 검사하는 것이 좋습니다. 자세한 내용은 성능 테스트를 참조하세요.
적절한 가용성 모드 선택
Azure Managed Redis는 고가용성 구성을 사용하거나 사용하지 않도록 설정하는 옵션을 제공합니다. 고가용성 모드를 사용하지 않도록 설정하면 AMR 인스턴스의 데이터가 복제되지 않으므로 유지 관리 중에 Redis 인스턴스를 사용할 수 없습니다. 계획되거나 계획되지 않은 유지 관리 시 AMR 인스턴스의 모든 데이터도 손실됩니다. 개발 또는 테스트 워크로드에 대해서만 고가용성을 사용하지 않도록 설정하는 것이 좋습니다. 주 및 복제본 데이터 분할 간에 중요한 분산 부하인 데이터 복제가 부족하여 고가용성이 있는 Redis 인스턴스의 성능도 낮아질 수 있습니다.
Redis 인스턴스와 동일한 지역에 있는 클라이언트
동일한 지역에서 Redis 인스턴스 및 애플리케이션을 찾습니다. 다른 지역의 Redis에 연결하면 대기 시간이 크게 증가하고 안정성이 저하될 수 있습니다.
Azure 외부에서 연결할 수 있지만, 특히 애플리케이션 또는 데이터베이스 성능을 가속화하기 위해 Redis를 사용하는 경우 권장되지 않습니다. Redis 서버를 키/값 저장소로만 사용하는 경우에는 대기 시간이 중요하지 않을 수 있습니다.
공용 IP 주소가 아닌 호스트 이름에 의존
크기 조정 작업 또는 백 엔드 개선의 결과로 AMR 인스턴스에 할당된 공용 IP 주소가 변경될 수 있습니다. 명시적 공용 IP 주소 대신 호스트 이름을 사용하는 것이 좋습니다.
TLS 암호화 사용
Azure Managed Redis에는 기본적으로 TLS 암호화 통신이 필요합니다. TLS 버전 1.2 및 1.3은 현재 지원됩니다. 클라이언트 라이브러리 또는 도구가 TLS를 지원하지 않는 경우 암호화되지 않은 연결을 사용하도록 설정할 수 있습니다.
메모리 사용량, CPU 사용량 메트릭, 클라이언트 연결 및 네트워크 대역폭 모니터링
프로덕션 환경에서 Azure Managed Redis 인스턴스를 사용하는 경우 "사용된 메모리 비율", "CPU" 메트릭, "연결된 클라이언트"에 대한 경고를 설정하는 것이 좋습니다. 이러한 메트릭이 지속적으로 75%를 초과하는 경우 인스턴스를 더 큰 메모리 또는 더 나은 처리량 계층으로 확장하는 것이 좋습니다. 자세한 내용은 크기 조정 시기를 참조하세요.
데이터 지속성 또는 데이터 백업을 사용하도록 설정하는 것이 좋습니다.
Redis는 기본적으로 임시 데이터를 위해 설계되었습니다. 즉, 드물게 유지 관리 또는 중단과 같은 다양한 상황으로 인해 데이터가 손실될 수 있습니다. 애플리케이션이 데이터 손실에 민감한 경우 데이터 내보내기 작업을 사용하여 데이터 지속성 또는 정기적인 데이터 백업을 사용하도록 설정하는 것이 좋습니다.
데이터 지속성 기능은 캐시가 다운되면 데이터에 대한 빠른 복구 지점을 자동으로 제공하도록 설계되었습니다. 캐시 인스턴스에 탑재된 관리 디스크에 RDB 또는 AOF 파일을 저장하여 빠른 복구를 가능하게 합니다. 디스크의 지속성 파일은 사용자가 액세스할 수 없거나 다른 AMR 인스턴스에서 사용할 수 없습니다.
많은 고객이 지속성을 사용하여 캐시에 있는 데이터를 주기적으로 백업하려고 합니다. 이러한 방식으로 데이터 지속성을 사용하지 않는 것이 좋습니다. 대신 Import/Export 기능을 사용합니다. RDB 형식의 데이터 복사본을 선택한 스토리지 계정으로 직접 내보내고 필요한 만큼 자주 데이터 내보내기를 트리거할 수 있습니다. 그러면 내보낸 이 데이터를 모든 Redis 인스턴스로 가져올 수 있습니다. 내보내기는 포털에서 또는 CLI, PowerShell 또는 SDK 도구를 사용하여 트리거할 수 있습니다.
클라이언트 라이브러리 관련 참고 자료
자세한 내용은 Azure Managed Redis 클라이언트 라이브러리를 참조 하세요.