연결 복원력
다시 시도 명령
지수 백오프로 명령을 다시 시도하도록 클라이언트 연결을 구성합니다. 자세한 내용은 다시 시도 참고 자료를 참조하세요.
복원력 테스트
다시 부팅을 사용하여 연결 중단에 대한 시스템의 복원력을 테스트하여 패치를 시뮬레이션합니다. 성능 테스트에 대한 자세한 내용은 성능 테스트를 참조하세요.
Linux 호스팅 클라이언트 애플리케이션에 대한 TCP 설정
일부 Linux 버전의 기본 TCP 설정으로 인해 Redis 서버 연결이 13분 이상 실패할 수 있습니다. 기본 설정은 클라이언트 애플리케이션이 닫힌 연결을 검색하고 연결이 정상적으로 닫혀 있지 않은 경우 자동으로 복원하는 것을 방지할 수 있습니다.
연결 다시 설정 실패는 네트워크 연결이 중단되거나 Redis 서버가 계획되지 않은 유지 관리를 위해 오프라인 상태가 되는 경우에 발생할 수 있습니다.
이러한 TCP 설정을 사용하는 것이 좋습니다.
| 설정 | 값 |
|---|---|
net.ipv4.tcp_retries2 |
5 |
이 시나리오에 대한 자세한 내용은 Linux에서 실행할 때 연결이 15분 동안 다시 설정되지 않음을 참조하세요. 이 설명은 StackExchange.Redis 라이브러리에 대한 것이지만 Linux에서 실행되는 다른 클라이언트 라이브러리도 영향을 받습니다. 설명은 여전히 유용하며 다른 라이브러리로 일반화할 수 있습니다.
StackExchange.Redis와 함께 ForceReconnect 사용
드문 경우이지만 연결이 끊긴 후 StackExchange.Redis가 다시 연결되지 않습니다. 이러한 경우 클라이언트를 다시 시작하거나 새 ConnectionMultiplexer를 만들면 문제가 해결됩니다. 앱에서 주기적으로 다시 연결을 강제할 수 있도록 하면서 싱글톤 ConnectionMultiplexer 패턴을 사용하는 것이 좋습니다. 애플리케이션에서 사용하는 프레임워크 및 플랫폼과 가장 일치하는 빠른 시작 샘플 프로젝트를 살펴보세요. 이 코드 패턴의 예제는 빠른 시작에서 확인할 수 있습니다.
ConnectionMultiplexer의 사용자는 이전 오류를 삭제한 결과로 발생할 수 있는 모든 ObjectDisposedException 오류를 처리해야 합니다.
RedisConnectionExceptions 및 RedisSocketExceptions에 대해 ForceReconnectAsync()를 호출합니다. RedisTimeoutExceptions에 대해 ForceReconnectAsync()를 호출할 수도 있지만 넉넉한 ReconnectMinInterval 및 ReconnectErrorThreshold를 사용하는 경우에만 가능합니다. 그렇지 않으면 새 연결을 설정하면 이미 오버로드되어 시간이 초과된 서버에서 연속 오류가 발생할 수 있습니다.
ASP.NET 애플리케이션에서는 StackExchange.Redis 패키지를 직접 사용하는 대신 Microsoft.Extensions.Caching.StackExchangeRedis 패키지의 통합 구현을 사용할 수 있습니다. StackExchange.Redis를 직접 사용하는 대신 ASP.NET 애플리케이션에서 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분 동안 유휴 상태가 될 위험이 있는 경우 keepalive 간격을 10분 미만의 값으로 구성합니다. 애플리케이션이 keepalive 기능을 기본적으로 지원하지 않는 클라이언트 라이브러리를 사용하는 경우 주기적으로 PING 명령을 전송하여 애플리케이션에서 구현할 수 있습니다.