연결 복원력
다시 시도 명령
지수 백오프를 사용하여 명령을 다시 시도하도록 클라이언트 연결을 구성합니다. 자세한 내용은 재시도 지침을 참조 하세요.
테스트 복원력
다시 부팅을 사용하여 연결 중단에 대한 시스템의 복원력을 테스트하여 패치를 시뮬레이션합니다. 성능 테스트에 대한 자세한 내용은 성능 테스트를 참조하세요.
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를 사용하는 경우에만 가능합니다. 그렇지 않으면 새 연결을 설정하면 이미 오버로드되어 시간이 초과된 서버에서 연속 오류가 발생할 수 있습니다.
적절한 시간 제한 구성
연결 복원력에서는 연결 시간 제한 및 명령 시간 제한이라는 두 가지 시간 제한 값을 고려하는 것이 중요합니다.
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 사용하는 경우 연결 문자열 설정합니다 abortConnectfalse. ConnectionMultiplexer에서 다시 연결을 처리하도록 하는 것이 좋습니다. 자세한 내용은 StackExchange.Redis 모범 사례를 참조하세요.
남은 연결 방지
캐시에는 캐시 계층당 클라이언트 연결 수에 대한 제한이 있습니다. 클라이언트 애플리케이션이 연결을 다시 만들 때 기존 연결을 닫고 제거하는지 확인합니다.
고급 유지 관리 알림
알림을 사용하여 예정된 기본 테넌스에 대해 알아봅니다. 자세한 내용은 계획된 기본 테넌트 전에 알림을 받을 수 있나요?
기본 테넌트 기간 예약
유지 관리에 맞게 캐시 설정을 조정합니다. 캐시에 대한 부정적인 영향을 줄이기 위해 유지 관리 기간을 만드는 방법에 대한 자세한 내용은 채널 업데이트 및 업데이트 예약을 참조하세요.
복원력을 위한 추가 디자인 패턴
복원력을 위해 디자인 패턴을 적용합니다. 자세한 내용은 애플리케이션 복원력을 어떻게 할까요? 참조하세요.
유휴 시간 제한
Azure Cache for Redis에는 유휴 연결에 대한 10분 제한 시간이 있습니다. 10분 시간 제한을 사용하면 서버가 클라이언트 애플리케이션에 의해 분리된 새는 연결 또는 연결을 자동으로 클린 수 있습니다. 대부분의 Redis 클라이언트 라이브러리에는 클라이언트 애플리케이션의 요청이 없더라도 연결을 닫지 않도록 주기적으로 보내거나 keepalive 명령을 보내는 heartbeat 기본 제공 기능이 있습니다.
연결이 10분 동안 유휴 상태일 위험이 있는 경우 간격을 10분 미만의 값으로 구성 keepalive 합니다. 애플리케이션이 기능을 기본적으로 지원하지 않는 클라이언트 라이브러리를 keepalive 사용하는 경우 주기적으로 명령을 전송 PING 하여 애플리케이션에서 구현할 수 있습니다.