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. Para repartir datos entre varias claves, considere la posibilidad de dividir los fragmentos de datos más grandes en otros más pequeños. 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 (VM) 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. Más ancho de banda solo en el servidor o solo en el cliente puede no ser 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. Para más información, consulte Procedimientos recomendados para los niveles Enterprise y Enterprise Flash.
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?
La mayoría de los clientes de Azure Cache for Redis no se ven afectados 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.