다음을 통해 공유

개발

  • 아티클

연결 복원력 및 서버 부하

클라이언트 애플리케이션을 개발할 때 연결 복원력 및 서버 부하 관리와 관련된 모범 사례를 고려합니다.

더 많은 키와 더 작은 값 고려

Azure Cache for 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**)

이 요청/응답은 측정하기 어렵습니다. 크기가 큰 요청 및 응답을 추적하도록 클라이언트 코드를 계측할 수 있습니다.

크기가 큰 응답 문제를 해결하는 방법은 다음과 같이 다양합니다.

  • 적은 수의 큰 값이 아니라 많은 수의 작은 값에 대해 애플리케이션을 최적화합니다.
  • 더 높은 대역폭 기능을 얻기 위해 VM(가상 머신) 크기를 늘림
    • 클라이언트 또는 서버 VM의 대역폭이 증가하면 크기가 큰 응답의 데이터 전송 시간을 줄일 수 있습니다.
    • 두 머신의 현재 네트워크 사용량과 현재 VM 크기 한도를 비교해 보세요. 서버에서만 또는 클라이언트에서만 대역폭이 증가하는 것으로는 충분하지 않을 수 있습니다.
  • 애플리케이션에서 사용하는 연결 개체 수를 늘립니다.
    • 라운드 로빈 방식을 사용하여 여러 연결 개체에 대한 요청을 수행할 수 있습니다.

키 배포

Redis 클러스터링을 사용할 계획이라면 먼저 키를 사용한 Redis 클러스터링 모범 사례를 읽으세요.

파이프라인 사용

Redis 파이프라인을 지원하는 Redis 클라이언트를 선택해 보세요. 파이프라인은 네트워크를 효율적으로 사용하고 가능한 최상의 처리량을 얻는 데 도움이 됩니다.

비용이 많이 드는 작업 방지

KEYS 명령과 같은 일부 Redis 작업은 비용이 많이 들기 때문에 피해야 합니다. 장기 실행 명령에 대한 몇 가지 고려 사항은 장기 실행 명령을 참조하세요.

적절한 계층 선택

프로덕션 시스템에 표준, 프리미엄, 엔터프라이즈 또는 엔터프라이즈 플래시 계층을 사용합니다. 프로덕션에서 기본 계층을 사용하지 마세요. 기본 계층은 데이터 복제 및 SLA가 없는 단일 노드 시스템입니다. 또한 C1 이상의 캐시를 사용합니다. C0 캐시는 다음과 같은 이유로 단순한 개발/테스트 시나리오에만 사용됩니다.

  • CPU 코어 공유
  • 적은 메모리 사용
  • 노이지 네이버 문제가 발생하기 쉬움

성능 테스트를 통해 올바른 계층을 선택하고 연결 설정의 유효성을 검사하는 것이 좋습니다. 자세한 내용은 성능 테스트를 참조하세요.

캐시와 동일한 지역의 클라이언트

캐시 인스턴스와 애플리케이션을 항상 동일한 지역에 배치합니다. 다른 지역의 캐시에 연결하면 대기 시간이 크게 증가하고 안정성이 떨어질 수 있습니다.

Azure 외부에서 연결할 수 있지만 권장되지 않으며, 특히 Redis를 캐시로 사용하지 않는 것이 좋습니다. Redis 서버를 키/값 저장소로만 사용하는 경우에는 대기 시간이 중요하지 않을 수 있습니다.

공용 IP 주소가 아닌 호스트 이름에 의존

캐시에 할당된 공용 IP 주소는 크기 조정 작업 또는 백 엔드 개선의 결과로 변경될 수 있습니다. 명시적 공용 IP 주소 대신 호스트 이름을 사용하는 것이 좋습니다. 다양한 계층에 권장되는 양식은 다음과 같습니다.

서비스 계층 양식
Basic, Standard, Premium <cachename>.redis.cache.windows.net
Enterprise, Enterprise Flash <DNS name>.<Azure region>.redisenterprise.cache.azure.net.

적절한 Redis 버전 선택

캐시를 만들 때 사용되는 Redis의 기본 버전은 시간이 지남에 따라 변경될 수 있습니다. Azure Cache for Redis는 새 버전의 오픈 소스 Redis가 릴리스될 때 새 버전을 채택할 수 있습니다. 애플리케이션에 특정 버전의 Redis가 필요한 경우 캐시를 만들 때 Redis 버전을 명시적으로 선택하는 것이 좋습니다.

TLS 암호화 사용

Azure Cache for Redis에는 기본적으로 TLS 암호화 통신이 필요합니다. 현재 TLS 버전 1.0, 1.1 및 1.2가 지원됩니다. 그러나 TLS 1.0 및 1.1은 업계 전반에서 사용이 중단되는 과정에 있으므로 가능하면 1.2를 사용합니다.

클라이언트 라이브러리 또는 도구에서 TLS를 지원하지 않는 경우 Azure Portal 또는 관리 API를 통해 암호화되지 않은 연결을 사용하도록 설정할 수 있습니다. 암호화된 연결을 사용할 수 없는 경우에는 캐시 및 클라이언트 애플리케이션을 가상 네트워크에 배치하는 것이 좋습니다. 가상 네트워크 캐시 시나리오에서 사용되는 포트에 대한 자세한 내용은 다음 표를 참조하세요.

Azure TLS 인증서 변경

Microsoft는 다른 CA(인증 기관) 집합의 TLS 서버 인증서를 사용하도록 Azure 서비스를 업데이트하고 있습니다. 이 변경은 2020년 8월 13일부터 2020년 10월 26일(예상)까지부터 단계적으로 배포됩니다. 현재 CA 인증서가 CA/브라우저 포럼 기준 요구 사항 중 하나가 아니기 때문에 Azure에서 이 변경을 수행합니다. 이 문제는 2020년 7월 1일에 보고되었으며, 전 세계적으로 인기 있는 여러 PKI(공개 키 인프라) 공급자에게 적용됩니다. 현재 Azure 서비스에서 사용하는 대부분의 TLS 인증서는 Baltimore CyberTrust Root PKI에서 제공됩니다. Azure Cache for Redis 서비스는 Baltimore CyberTrust Root에 계속 연결됩니다. 그러나 2020년 10월 12일부터는 새로운 ICA(중간 인증 기관)가 해당 TLS 서버 인증서를 발급합니다.

참고 항목

이 변경은 퍼블릭 Azure 지역의 서비스로 제한됩니다. 소버린(예: 중국) 또는 정부 클라우드는 제외됩니다.

이 변경이 내게 영향을 주나요?

대부분의 Azure Cache for Redis 고객은 변경의 영향을 받지 않습니다. 허용되는 인증서 목록을 명시적으로 지정하는 경우(인증서 고정이라고 알려진 관행) 애플리케이션이 영향을 받을 수도 있습니다. Baltimore CyberTrust Root 대신 중간 또는 리프 인증서에 고정된 경우에는 즉시 작업을 수행하여 인증서 구성을 변경해야 합니다.

Azure Cache for Redis는 OCSP 스테이플링을 지원하지 않습니다.

다음 표에서는 배포되는 인증서에 대한 정보를 제공합니다. 애플리케이션에서 사용하는 인증서에 따라 Azure Cache for Redis 인스턴스에 대한 연결 끊김을 방지하기 위해 업데이트해야 할 수도 있습니다.

CA 유형 현재 배포(2020년 10월 12일) 이후 작업
루트 지문: d4de20d05e66fc53fe1a50882c78db2852cae474

만료: 2025년 5월 12일 월요일 오후 4:59:00

주체 이름:
CN = Baltimore CyberTrust Root
OU = CyberTrust
O = Baltimore
C = IE		 변경되지 않음 없음
중간 지문:
CN = Microsoft IT TLS CA 1
지문: 417e225037fbfaa4f95761d5ae729e1aea7e3a42

CN = Microsoft IT TLS CA 2
지문: 54d9d20239080c32316ed9ff980a48988f4adf2d

CN = Microsoft IT TLS CA 4
지문: 8a38755d0996823fe8fa3116a277ce446eac4e99

CN = Microsoft IT TLS CA 5
지문: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7

만료: 2024년 5월 20일 금요일 오전 5:52:38

주체 이름:
OU = Microsoft IT
O = Microsoft Corporation
L = Redmond
S = Washington
C = US
 지문:
CN = Microsoft RSA TLS CA 01
지문: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
지문: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

만료: 2024년 10월 8일 화요일 오전 12:00:00

주체 이름:
O = Microsoft Corporation
C = US
 Required

어떤 작업을 수행해야 하나요?

애플리케이션에서 운영 체제 인증서 저장소를 사용하거나 다른 인증서 중에서 Baltimore 루트를 고정하는 경우에는 아무 작업도 필요하지 않습니다.

애플리케이션에서 중간 또는 리프 TLS 인증서를 고정하는 경우 다음 루트를 고정하는 것이 좋습니다.

인증서 Thumbprint
Baltimore Root CA d4de20d05e66fc53fe1a50882c78db2852cae474
Microsoft RSA Root Certificate Authority 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Digicert Global Root G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4

팁

중간 및 리프 인증서는 둘 다 자주 변경될 것으로 예상됩니다. 두 인증서에 의존하지 않는 것이 좋습니다. 대신, 배포 빈도가 더 낮은 루트 인증서에 애플리케이션을 고정합니다.

중간 인증서를 계속 고정하려면 고정된 중간 인증서 목록에 다음 항목을 추가합니다. 향후 변경을 최소화하기 위해 추가 항목은 목록에 몇 가지 더 포함됩니다.

CA의 일반 이름 Thumbprint
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75
Microsoft Azure TLS Issuing CA 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS Issuing CA 02 e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS Issuing CA 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS Issuing CA 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

애플리케이션에서 코드를 통해 인증서 유효성을 검사하는 경우 새로 고정된 인증서의 속성(예: 발급자, 지문)을 인식하도록 수정해야 합니다. 미래 경쟁력을 보장하기 위해 고정된 모든 인증서에 이 추가 확인을 적용해야 합니다.

클라이언트 라이브러리 관련 참고 자료

자세한 내용은 클라이언트 라이브러리를 참조하세요.

다음 단계