중요합니다
Azure Cache for Redis는 모든 SKU에 대한 사용 중지 타임라인을 발표했습니다. 가능한 한 빨리 기존 Azure Cache for Redis 인스턴스를 Azure Managed Redis 로 이동하는 것이 좋습니다.
사용 중지에 대한 자세한 내용은 다음과 같습니다.
명령 다시 시도
지수 백오프를 사용하여 명령을 다시 시도하도록 클라이언트 연결을 구성합니다. 자세한 내용은 재시도 지침을 참조하세요.
복원력 테스트
다시 부팅을 사용하여 연결 중단에 대한 시스템의 복원력을 테스트하여 패치를 시뮬레이션합니다. 성능 테스트에 대한 자세한 내용은 성능 테스트를 참조하세요.
Linux 호스팅 클라이언트 애플리케이션에 대한 TCP 설정
일부 Linux 버전의 기본 TCP 설정으로 인해 Redis 서버 연결이 13분 이상 실패할 수 있습니다. 기본 설정은 클라이언트 애플리케이션이 닫힌 연결을 검색하고 연결이 정상적으로 닫혀 있지 않은 경우 자동으로 복원하지 못하게 할 수 있습니다.
연결 다시 설정 실패는 네트워크 연결이 중단되거나 Redis 서버가 계획되지 않은 유지 관리를 위해 오프라인으로 전환되는 경우에 발생할 수 있습니다.
다음 TCP 설정을 사용하는 것이 좋습니다.
| Setting | 가치 |
|---|---|
net.ipv4.tcp_retries2 |
5 |
시나리오에 대한 자세한 내용은 Linux에서 실행할 때 연결이 15분 동안 다시 설정되지 않음을 참조하세요. 이 설명은 StackExchange.Redis 라이브러리에 관한 것이지만 Linux에서 실행되는 다른 클라이언트 라이브러리도 영향을 받습니다. 설명은 여전히 유용하며 다른 라이브러리로 일반화할 수 있습니다.
StackExchange.Redis에서 ForceReconnect 사용
드문 경우이지만 연결이 끊긴 후 StackExchange.Redis 가 다시 연결되지 않습니다. 이러한 경우 클라이언트를 다시 시작하거나 새 ConnectionMultiplexer 클라이언트를 만들면 문제가 해결됩니다. 앱이 정기적으로 다시 연결을 강제할 수 있도록 하면서 싱글톤 ConnectionMultiplexer 패턴을 사용하는 것이 좋습니다. 애플리케이션에서 사용하는 프레임워크 및 플랫폼과 가장 일치하는 빠른 시작 샘플 프로젝트를 살펴보세요.
빠른 시작에서 이 코드 패턴의 예를 볼 수 있습니다.
ConnectionMultiplexer 사용자는 이전 오류를 삭제한 결과로 발생할 수 있는 모든 ObjectDisposedException 오류를 처리해야 합니다.
ForceReconnectAsync()를 RedisConnectionExceptions 및 RedisSocketExceptions 위해 호출하십시오. 당신은 또한 ForceReconnectAsync()을(를) RedisTimeoutExceptions으로 호출할 수 있습니다. 그러나 ReconnectMinInterval과(와) ReconnectErrorThreshold을(를) 충분히 사용하는 경우에만 가능합니다. 그렇지 않으면 새 연결을 설정하면 이미 오버로드되어 시간이 초과된 서버에서 연속 오류가 발생할 수 있습니다.
ASP.NET 애플리케이션에서는 StackExchange.Redis 패키지를 직접 사용하는 대신 Microsoft.Extensions.Caching.StackExchangeRedis 패키지에서 통합 구현을 사용할 수 있습니다. ASP.NET 애플리케이션에서 StackExchange.Redis를 직접 사용하는 대신 Microsoft.Extensions.Caching.StackExchangeRedis를 사용하는 경우, UseForceReconnect 속성을 true로 설정할 수 있습니다.
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
적절한 시간 제한 구성
연결 복원력에는 연결 시간 제한 과 명령 시간 제한이라는 두 가지 시간 제한 값을 고려해야 합니다.
Connect timeout
connect timeout 클라이언트가 Redis 서버와의 연결을 설정하기 위해 대기하는 시간입니다. 클라이언트 라이브러리를 5초 동안 사용하도록 connect timeout 구성하여 더 높은 CPU 조건에서도 시스템에 연결할 수 있는 충분한 시간을 제공합니다.
값이 작connection timeout다고 해서 해당 시간 내에 연결이 보장되지는 않습니다. 문제가 발생하는 경우(높은 클라이언트 CPU, 높은 서버 CPU 등) 짧은 connection timeout 값으로 인해 연결 시도가 실패합니다. 이 동작은 종종 나쁜 상황을 악화시킬 수 있습니다. 도움이 되는 대신, 짧은 시간 제한은 시스템이 다시 연결하려고 시도하는 프로세스를 다시 시작하도록 강요하여 문제를 악화시킵니다. 이로 인해 연결 - 실패 ->> 다시 시도 루프가 발생할 수 있습니다.
명령 시간 제한
대부분의 클라이언트 라이브러리에는 클라이언트가 Redis 서버의 응답을 기다리는 시간인 다른 시간 제한 구성 command timeouts이 있습니다. 5초 미만의 초기 설정을 권장하지만 시나리오 및 캐시에 저장된 값의 크기에 따라 더 높거나 낮은 값을 설정하는 command timeout 것이 좋습니다.
command timeout 너무 작으면 연결이 불안정해 보일 수 있습니다. 그러나 command timeout이 너무 크면 애플리케이션이 명령 시간 초과 여부를 확인하기 위해 오랜 시간을 기다려야 할 수 있습니다.
클라이언트 연결 급증 방지
연결이 끊긴 후 다시 연결할 때 동시에 많은 연결을 만들지 마세요. 짧은 연결 시간 제한으로 인해 더 긴 중단이 발생할 수 있는 방식과 마찬가지로, 동시에 많은 다시 연결 시도를 시작하면 서버 부하가 증가하고 모든 클라이언트가 성공적으로 다시 연결하는 데 걸리는 시간을 연장할 수 있습니다.
많은 클라이언트 인스턴스를 다시 연결하는 경우, 연결된 클라이언트 수의 급격한 증가를 피하기 위해 새 연결을 순차적으로 고려하는 것이 좋습니다.
비고
StackExchange.Redis 클라이언트 라이브러리를 사용할 때, 연결 문자열에서 abortConnect을 false로 설정하세요.
ConnectionMultiplexer가 재연결을 처리하도록 하는 것을 권장합니다. 자세한 내용은 StackExchange.Redis 모범 사례를 참조하세요.
남은 연결 방지
캐시에는 캐시 계층당 클라이언트 연결 수에 제한이 있습니다. 클라이언트 애플리케이션이 연결을 다시 만들 때 이전 연결을 닫고 제거해야 합니다.
사전 유지 관리 알림
알림을 사용하여 예정된 유지 관리에 대해 알아봅니다. 자세한 내용은 계획된 유지 관리 전에 알림을 받을 수 있나요?
유지 관리 창 예약
유지 관리를 수용하도록 캐시 설정을 조정합니다. 캐시에 대한 부정적인 영향을 줄이기 위해 유지 관리 기간을 만드는 방법에 대한 자세한 내용은 업데이트 채널 및 업데이트 예약을 참조하세요.
복원력을 위한 추가 디자인 패턴
복원력을 위해 디자인 패턴을 적용합니다. 자세한 내용은 애플리케이션의 복원력을 높이는 방법을 참조하세요.
유휴 상태 시간 제한
Azure Cache for Redis에는 유휴 연결에 대한 10분 제한 시간이 있습니다. 10분 시간 제한을 사용하면 서버가 클라이언트 애플리케이션에 의해 분리된 연결 또는 누수 연결을 자동으로 정리할 수 있습니다. 대부분의 Redis 클라이언트 라이브러리에는 클라이언트 애플리케이션의 요청이 없더라도 연결을 닫지 않도록 주기적으로 보내거나 heartbeat 명령을 보내는 keepalive 기본 제공 기능이 있습니다.
연결이 10분 동안 유휴 상태일 위험이 있는 경우 간격을 10분 미만의 값으로 구성 keepalive 합니다. 애플리케이션에서 keepalive 기능을 기본적으로 지원하지 않는 클라이언트 라이브러리를 사용하는 경우, 주기적으로 PING 명령을 전송함으로써 애플리케이션에서 해당 기능을 구현할 수 있습니다.