Desarrollo

Resistencia de la conexión y carga del servidor

Al desarrollar aplicaciones cliente, asegúrese de tener en cuenta los procedimientos recomendados sobre resistencia de la conexión y administración de la carga del servidor.

Consideración de más claves y valores más pequeños

Azure Cache for Redis funciona mejor con valores más pequeños. Considere la posibilidad de dividir los fragmentos de datos más grandes en otros más pequeños para repartirlos entre varias claves. Para obtener más información sobre el tamaño de valor ideal, consulte este artículo.

Tamaño de solicitud o respuesta grande

Una solicitud/respuesta grande puede provocar tiempos de espera agotados. Por ejemplo, suponga que el valor del tiempo de expiración configurado en el cliente es de 1 segundo. La aplicación solicita dos claves (por ejemplo, "A" y "B") al mismo tiempo (con la utilización de la misma conexión de red física). La mayoría de clientes admiten la "canalización" de las solicitudes, en la que ambas solicitudes, "A" y "B", se envían una tras otra sin tener que esperar las respuestas. El servidor vuelve a enviar las respuestas en el mismo orden. Si la respuesta "A" es grande, puede consumir la mayor parte del tiempo de expiración para las solicitudes posteriores.

En el ejemplo siguiente, las solicitudes "A" y "B" se envían rápidamente al servidor. El servidor empieza a enviar las respuestas "A" y "B" rápidamente. Debido a los tiempos de transferencia de datos, la respuesta "B" debe esperar a que se agote el tiempo de espera de la respuesta "A", aunque el servidor haya respondido con rapidez.

|-------- 1 Second Timeout (A)----------|
|-Request A-|
     |-------- 1 Second Timeout (B) ----------|
     |-Request B-|
            |- Read Response A --------|
                                       |- Read Response B-| (**TIMEOUT**)

Esta solicitud/respuesta es difícil de medir. Puede instrumentar el código del cliente para realizar un seguimiento de las respuestas y solicitudes grandes.

Las resoluciones para los tamaños grandes de respuesta varían, pero incluyen lo siguiente:

  • Optimización de la aplicación para un gran número de valores pequeños, en lugar de unos pocos valores grandes.
    • La mejor solución es dividir los datos en valores menores relacionados.
    • Consulte la publicación What is the ideal value size range for redis? Is 100KB too large? (¿Cuál es el intervalo de tamaño de valor ideal para Redis? ¿100 KB es demasiado grande?) para obtener detalles de por qué se recomiendan valores más pequeños.
  • Aumento del tamaño de la máquina virtual para obtener mayores capacidades de ancho de banda.
    • Un aumento de ancho de banda en la máquina virtual del cliente o servidor puede reducir los tiempos de transferencia de datos para respuestas más grandes.
    • Compare la utilización actual de la red en ambas máquinas con los límites del tamaño actual de la máquina virtual. Es posible que obtener más ancho de banda solo en el servidor o en el cliente no sea suficiente.
  • Aumente el número de objetos de conexión que usa la aplicación.
    • Use un enfoque round robin para realizar solicitudes a través de objetos de conexión distintos.

Distribución de las claves

Si planea usar una agrupación en clústeres de Redis, consulte primero Procedimientos recomendados de agrupación en clústeres de Redis con claves.

Uso de canalización

Intente elegir un cliente de Redis que admita la canalización de Redis. La canalización ayuda a hacer un uso eficaz de la red y a obtener el mejor rendimiento posible.

Evita operaciones costosas

Algunas operaciones de Redis, como el comando KEYS son muy costosas y deben evitarse. En Comandos de larga duración encontrará algunos aspectos que tener en cuenta en relación a estos comandos.

Elija un nivel apropiado:

Use los niveles Estándar, Premium, Enterprise o Enterprise Flash para los sistemas de producción. No use el nivel Básico en producción. El nivel básico es un sistema de nodo único sin replicación de datos ni Acuerdo de Nivel de Servicio. Además, utilice al menos una caché de C1. Las cachés de C0 solo están diseñadas para escenarios sencillos de desarrollo o prueba por los siguientes motivos:

  • Comparten un núcleo de CPU.
  • Usan poca memoria.
  • Son propensos a tener problemas relacionados con vecinos ruidosos.

Se recomienda realizar pruebas de rendimiento para elegir el nivel correcto y validar la configuración de conexión. Para obtener más información, consulte Pruebas de rendimiento.

Cliente en la misma región que la caché

Localice su instancia de la caché y su aplicación en la misma región. El establecimiento de una conexión con una memoria caché de otra región puede aumentar considerablemente la latencia y reducir la confiabilidad.

Si bien puede conectarse desde fuera de Azure, no es recomendable, especialmente cuando se usa Redis como caché. Si solo usa el servidor de Redis como almacén de clave/valor, es posible que la latencia no sea su principal preocupación.

Confiar en el nombre de host, no en la dirección IP pública

La dirección IP pública asignada a la caché puede cambiar como consecuencia de una operación de escalado o una mejora del back-end. Se recomienda confiar en el nombre de host en lugar de en una dirección IP pública explícita. Estos son los formularios recomendados para los distintos niveles:

Nivel Form
Básico, Estándar, Premium <cachename>.redis.cache.windows.net
Enterprise o Enterprise Flash <DNS name>.<Azure region>.redisenterprise.cache.azure.net.

Elección de una versión adecuada de Redis

La versión predeterminada de Redis que se usa al crear una caché puede cambiar con el tiempo. Azure Cache for Redis puede adoptar una nueva versión cuando se publica una nueva versión de Redis de código abierto. Si necesita una versión específica de Redis para la aplicación, se recomienda elegir la versión de Redis expresamente al crear la memoria caché.

Guía específica para los niveles Enterprise

Dado que los niveles Enterprise y Enterprise Flash se basan en Redis Enterprise en lugar de Redis de código abierto, hay algunas diferencias en los procedimientos recomendados de desarrollo. Consulte Procedimientos recomendados para los niveles Enterprise y Enterprise Flash para más información.

Uso de cifrado TLS

Azure Cache for Redis requiere de manera predeterminada comunicaciones cifradas mediante TLS. Actualmente se admiten las versiones de TLS 1.0, 1.1 y 1.2. Sin embargo, TLS 1.0 y 1.1 están en proceso de desuso en todo el sector, por lo que se recomienda TLS 1.2 si es posible.

Si la biblioteca o la herramienta cliente no admiten TLS, es posible habilitar las conexiones sin cifrar mediante Azure Portal o API de administración. En casos en los que no es posible establecer conexiones cifradas, se recomienda colocar la caché y la aplicación cliente en una red virtual. Para más información sobre los puertos que se usan en el escenario de caché de la red virtual, consulte esta tabla.

Cambio en los certificados TLS de Azure

Microsoft está actualizando los servicios de Azure para que usen los certificados de servidor TLS de un conjunto diferente de entidades de certificación (CA). Este cambio se implementa en fases desde el 13 de agosto de 2020 hasta el 26 de octubre de 2020 (estimado). Azure realiza este cambio porque los certificados de entidad de certificación actuales no cumplen uno de los requisitos de la base de referencia del foro CA/Browser. El problema se comunicó el 1 de julio de 2020 y se aplica a varios proveedores populares de infraestructura de clave pública (PKI) en todo el mundo. La mayoría de los certificados TLS que utilizan los servicios de Azure actuales proceden de la PKI de Baltimore CyberTrust Root. El servicio de Azure Cache for Redis seguirá encadenado a Baltimore CyberTrust Root. Sin embargo, son sus nuevas entidades de certificación intermedias (ICA) las que emitirán los certificados de servidor TLS a partir del 12 de octubre de 2020.

Nota

Este cambio se limita a los servicios de las regiones públicas de Azure. Excluye las nubes soberanas (por ejemplo, China) o gubernamentales.

¿Me afecta este cambio?

Esperamos que la mayoría de los clientes de Azure Cache for Redis no se vea afectada por el cambio. La aplicación puede resultar afectada si especifica explícitamente una lista de certificados aceptables, una práctica conocida como "asignación de certificados". Si está asignada a un certificado intermedio o de hoja en lugar de a Baltimore CyberTrust Root, debe tomar medidas inmediatas para cambiar la configuración del certificado.

Azure Cache for Redis no admite la asociación OCSP.

En la siguiente tabla se proporciona información acerca de los certificados que se están implementando. En función del certificado que utilice la aplicación, es posible que deba actualizarlo a fin de evitar la pérdida de conectividad para la instancia de Azure Cache for Redis.

Tipo de entidad de certificación Current Tras la implementación (12 de octubre de 2020) Acción
Root Huella digital: d4de20d05e66fc53fe1a50882c78db2852cae474

Expiración: Lunes, 12 de mayo de 2025, 4:59:00 p.m.

Nombre del firmante:
CN = Baltimore CyberTrust Root
OU = CyberTrust
O = Baltimore
C = IE
Sin cambios Ninguno
Intermediarios Huellas digitales:
CN = Microsoft IT TLS CA 1
Thumbprint: 417e225037fbfaa4f95761d5ae729e1aea7e3a42

CN = Microsoft IT TLS CA 2
Thumbprint: 54d9d20239080c32316ed9ff980a48988f4adf2d

CN = Microsoft IT TLS CA 4
Thumbprint: 8a38755d0996823fe8fa3116a277ce446eac4e99

CN = Microsoft IT TLS CA 5
Thumbprint: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7

Expiración: ‎Viernes, ‎20 de ‎mayo de ‎2024 a las 5:52:38 a.m.

Nombre del firmante:
OU = Microsoft IT
O = Microsoft Corporation
L = Redmond
S = Washington
C = US
Huellas digitales:
CN = Microsoft RSA TLS CA 01
Thumbprint: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
Huella digital: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

Expiración: ‎Martes, ‎8 de ‎octubre de ‎2024 12:00:00 a.m.

Nombre del firmante:
O = Microsoft Corporation
C = US
Requerido

¿Qué medidas debo tomar?

Si la aplicación utiliza el almacén de certificados del sistema operativo o asigna la raíz de Baltimore entre otros, no es necesario realizar ninguna acción.

Si la aplicación asigna cualquier certificado TLS intermedio o de hoja, se recomienda asignar las raíces siguientes:

Certificado Huella digital
Baltimore Root CA d4de20d05e66fc53fe1a50882c78db2852cae474
Microsoft RSA Root Certificate Authority 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Digicert Global Root G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4

Sugerencia

Se espera que los certificados intermedio y de hoja cambien con frecuencia. Se recomienda no tener una dependencia con ellos. En su lugar, asigne la aplicación a un certificado raíz, ya que se implementa con menos frecuencia.

Para continuar con la asignación de certificados intermedios, agregue lo siguiente a la lista de certificados intermedios asignados, que incluye algunos más para minimizar futuros cambios:

Nombre común de la CA Huella digital
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

Si la aplicación valida el certificado en el código, tiene que modificarlo para que reconozca las propiedades (por ejemplo, emisores, huella digital) de los certificados recién asignados. Esta comprobación adicional debe cubrir todos los certificados asignados para que estén mejor preparados para el futuro.

Guía específica de bibliotecas cliente

Para obtener más información, consulte Bibliotecas de cliente.

Pasos siguientes