Header Ads Widget

Ticker

6/recent/ticker-posts

Técnicas generales para un almacenamiento en caché de API adecuado



El almacenamiento en caché es una solución excelente para garantizar que los datos se entreguen donde deben ser servidos y con un nivel de eficiencia que sea mejor para el cliente y el servidor. Dicho esto, el almacenamiento en caché a menudo se considera una solución mágica que puede ofrecer una mayor eficiencia y reducir los costos generales de datos tanto para los clientes como para los servidores. Esto es engañoso; es solo la aplicación adecuada del almacenamiento en caché lo que le brinda estos beneficios.

Hoy, veremos algunas de las mejores prácticas generales para el almacenamiento en caché. Tenga en cuenta que una mejor práctica es completamente subjetiva: lo que puede ser la mejor práctica en una implementación específica puede no ser apropiado en otra. Dicho esto, si sigue estas pautas generales, obtendrá la mayor parte del camino hacia un flujo de almacenamiento en caché preciso, eficaz y útil.

Calcule los costos con precisión

Uno de los primeros y más importantes pasos que debe tomar cualquier desarrollador al implementar un sistema de almacenamiento en caché es asegurarse de que se consideren los costos estimados de almacenamiento en caché. El valor en este sentido no es monetario, sino que se refiere al costo en el servidor y los impactos generales en los recursos del cliente y del servidor colectivamente.

Cada caché requiere algún tipo de almacenamiento local. El contenido debe cargarse en algún tipo de memoria y, por lo tanto, esta memoria no se puede utilizar para otros procesos, necesidades y funciones. Incluso una pequeña cantidad de datos elegidos para el almacenamiento en caché puede dar lugar a que se consuman grandes bloques de memoria, ya que este contenido en caché se almacena en caché en todo el ecosistema de microservicios, API y proveedores.

Si bien esto es un problema menor para el contenido que no cambia de estado con mucha frecuencia, esto también se puede magnificar por los datos que sí cambian de estado. Con el cambio de estado constante que se traslada a la caché y un "objetivo en movimiento" para la precisión, el almacenamiento en caché podría ser muy costoso. En consecuencia, calcule lo que realmente necesita almacenarse en caché y evalúe el impacto en los recursos en su extremo más lógico.

Asignar la caché de forma adecuada

Hemos hablado de esto en profundidad anteriormente , pero vale la pena repetirlo. Una vez que se han identificado los datos almacenados en caché, debe considerar dónde deben residir esos datos.

Funcionalmente, hay dos tipos diferentes de caché: el almacenamiento en caché del cliente , donde los datos se almacenan localmente, y el almacenamiento en caché del servidor , donde los datos se almacenan en el servidor. Existe una solución de almacenamiento en caché híbrida, pero esto agrega complejidad y sobrecarga al sistema de almacenamiento en caché en su conjunto. El lugar donde se coloca la memoria caché en la práctica importa casi tanto como lo que se almacena en la memoria caché.

El almacenamiento en caché del cliente , donde los datos se almacenan localmente para el cliente, sirve para limitar el costo de datos en el que incurre el usuario. Todo lo que el usuario pueda necesitar que sea referenciado de manera rutinaria y sea apropiado para la caché se puede guardar localmente, reduciendo la necesidad de llamadas adicionales. Si bien esto obviamente aumenta la eficiencia para el usuario, también hay un impulso para el servidor, ya que el contenido se solicita con menos frecuencia.

El almacenamiento en caché del servidor también reduce el costo incurrido, pero se centra principalmente en el costo del servidor. Al almacenar las llamadas en una caché, la API en sí no se ve afectada por las llamadas repetidas: no se debe realizar ningún procesamiento, ni manipulación, ni transformación; está todo listo en una forma para uso general. A diferencia del almacenamiento en caché del cliente, el almacenamiento en caché del servidor reduce el costo para el servidor, pero no para el cliente; el tiempo de espera puede reducirse ya que no es necesario realizar ningún cálculo, pero aún así debe realizarse una llamada.

Hybrid es lo mejor de ambos mundos, pero también trae una reducción en el ahorro de costos para ambas partes. También está el hecho de que un cliente puede no tener la mayor cantidad de espacio para una caché local, especialmente cuando se utilizan clientes ligeros. En los casos en que los datos almacenados en caché son grandes, el almacenamiento en caché del cliente debe tener prioridad.

Garantice la seguridad y la precisión

Al almacenar en caché, una de las cosas más importantes a considerar es la privacidad y seguridad tanto del código base como de los usuarios dentro del código base. El simple hecho es que no todo lo que se puede almacenar en caché debe almacenarse en caché, y un almacenamiento en caché incorrecto puede provocar algunos problemas importantes. Algo tan menor como elegir almacenar en caché las credenciales en el lado del cliente para los administradores puede resultar en que ese cliente se rompa y, a través de la exposición, esas credenciales se usen para atacar el servidor.

Parece un caso simplista, pero incluso hay casos de aplicaciones que introducen tokens de API y demás en un caché y luego vierten esa información en informes de errores. Compartir ese informe de error podría exponer mucho sobre el servicio y disminuir la seguridad general del sistema.

También existe el hecho de que la seguridad y la precisión pueden ir de la mano cuando hay una mala elección de almacenamiento en caché. Una fuente de verdad es fundamental para garantizar tanto el funcionamiento seguro y coherente de una aplicación como la eficacia de su implementación.

Por ejemplo, considere una base de código en la que se utiliza un directorio para hacer referencia a los datos del cliente. Si la información almacenada en caché sobre el paradero de esos datos se desactualiza o es incorrecta por alguna razón, no solo está exponiendo la seguridad de la aplicación, sino que también está rompiendo clientes que pueden depender de esos datos. Es posible que una experiencia tan importante no siempre sea obvia: el usuario final puede creer que no hay clientes o que no hay datos de pedidos porque la aplicación del cliente puede no presentarse como una falla y puede sugerir que los datos no existen.

Este es un aspecto tan monumentalmente importante del almacenamiento en caché que Roy Fielding, el padre del paradigma RESTful, ha hablado tanto de la importancia del almacenamiento en caché en REST (es obligatorio) como de la importancia de garantizar la precisión de ese caché :

“La ventaja de agregar restricciones de caché es que tienen el potencial de eliminar parcial o completamente algunas interacciones, mejorando la eficiencia, la escalabilidad y el rendimiento percibido por el usuario al reducir la latencia promedio de una serie de interacciones. Sin embargo, la compensación es que una caché puede disminuir la confiabilidad si los datos obsoletos dentro de la caché difieren significativamente de los datos que se habrían obtenido si la solicitud se hubiera enviado directamente al servidor ".

Asegúrese de que el costo valga la pena

Todo en un sistema en caché tiene un costo. Más allá de la ubicación real del caché, tenemos que preguntarnos si el caché cumple o no el propósito para el que fue diseñado. A menudo es bastante fácil tener la mentalidad de que el cliente o el servidor quieren algo que no quieren; codificar en una caché en esos casos puede no hacer más que complicar demasiado los sistemas subyacentes y agregar complejidad a las interacciones con el código base.

Por ejemplo, puede parecer sensato almacenar en caché el estado del pedido del cliente en el nivel del servidor. Después de todo, ¿con qué frecuencia cambia esa información? Sin embargo, si seguimos la lógica, veríamos que almacenar en caché ese tipo de datos no es útil: el estado del pedido no solo es dinámico en contenido, es dinámico en cantidad. Puede ser cierto que el estado de los pedidos no cambia rápidamente en promedio, pero ¿qué ocurre durante los ciclos estacionales en los que pueden estar activos diez o quince pedidos a la vez? ¿Qué sucede si un pedido se retrasa? ¿Actualiza el estado o deja el estado abierto? ¿Con qué frecuencia el usuario verifica el estado del pedido en lugar de simplemente esperar una actualización en una aplicación?

En última instancia, esos aspectos deben tenerse en cuenta y debe hacerse la pregunta: ¿vale la pena el costo almacenar esta información, donde sea que la guardemos en caché? Si no vale la pena el costo, no lo guarde en caché.

Tampoco siempre es obvio: algunos casos no son tan sencillos. ¿Qué pasa con una identificación de usuario? A primera vista, tendría sentido que un servidor almacene en caché el ID de usuario de los clientes conectados. Sin embargo, en el diseño RESTful, no hay ningún estado: almacenar en caché la ID de usuario durante la sesión y utilizarla para establecer una relación durante la conexión del cliente es similar a crear un estado, que va en contra del concepto de diseño RESTful.

Esto es especialmente cierto si el cliente ya está enviando la ID de usuario con cada solicitud; si los datos están ingresando y el servidor está verificando esos datos con la caché y arrojándolos si no han cambiado, entonces, ¿cuál es el punto de almacenarlos de todos modos? ¿No es básicamente el mismo flujo que no tener los datos almacenados en caché, pero con la sobrecarga adicional que el caché agrega intrínsecamente?

Microsoft ha ofrecido algunos conocimientos sobre este tema en su documentación de Azure. Si bien esta es en gran medida la opinión de Microsoft, representa una práctica decente para la mayoría de las aplicaciones; no todas las implementaciones tendrán los mismos requisitos, pero la mayor parte de las aplicaciones sí. Microsoft sugiere utilizar tanto un caché como un sistema para el almacenamiento de datos persistentes:

“Considere almacenar en caché los datos que se leen con frecuencia pero que se modifican con poca frecuencia (por ejemplo, datos que tienen una mayor proporción de operaciones de lectura que de operaciones de escritura). Sin embargo, no recomendamos que utilice la caché como el almacén autorizado de información crítica. En su lugar, asegúrese de que todos los cambios que su aplicación no puede permitirse perder siempre se guarden en un almacén de datos persistentes. Esto significa que si el caché no está disponible, su aplicación aún puede continuar funcionando utilizando el almacén de datos y no perderá información importante ".

Establecer reglas basadas en la complejidad y la utilidad

Gran parte del problema del almacenamiento en caché se reduce a lidiar con tipos de contenido. Hay una escala variable entre "esto se puede almacenar en caché" y "esto no se puede almacenar en caché" que se ve afectada tanto por quién posee la caché como por cuál es el propósito de esa caché. Por ejemplo, algo como CSS del sitio es absolutamente almacenable en caché y debería almacenarse en caché. De hecho, gran parte de la experiencia del sitio se puede almacenar en caché con un enfoque híbrido: los archivos en caché local pueden almacenar información básica sobre el usuario que luego se puede usar en solicitudes, y la caché del servidor puede almacenar CSS, HTML, etc. para el servicio.

Donde nos metemos en el almacenamiento en caché más complejo es cuando comenzamos a considerar el contenido que es dinámico, pero solo durante un largo período de tiempo. El estado de la API es algo que, idealmente, siempre es un valor. Si bien hay casos en los que la API puede estar inactiva o actualizarse, esas son las situaciones más poco comunes en comparación con la API que simplemente está activa y, como tal, el estado se puede almacenar en caché fácilmente.

Luego hay cosas que no deberían almacenarse en caché por ningún motivo. Cosas como las contraseñas no deben almacenarse en caché en el servidor. El mapeo del servidor (es decir, las ubicaciones mapeadas de datos más allá de los puntos finales públicos) nunca debería existir en el cliente. Las suposiciones básicas de sentido común para la capacidad de almacenamiento en caché deben probarse, validarse o rechazarse constantemente.

Una vez que esto sucede a escala, podemos comenzar a ver un conjunto de reglas que se establecen con respecto a nuestro contenido en caché. Esto va más allá de simplemente ver si algo debe almacenarse en caché o cuál es el costo relativo: una vez que tenemos una idea sólida de dónde está realmente "la línea" para el almacenamiento en caché, podemos aplicar esas reglas globalmente y comenzar a crear una especie de marco para auditar nuestra caché.

Audite su caché

Este es quizás el paso "final" más importante en la implementación del almacenamiento en caché. Es una buena práctica revisar y auditar constantemente su marco de caché, suposiciones e implementaciones prácticas. Lo que tenía sentido para una base de código hace un año puede que no lo tenga hoy, y ciertamente no lo tendrá dentro de cinco años. Esto es especialmente importante en las múltiples evoluciones de la base de código, ya que el almacenamiento en caché de contenido que ya ni siquiera existe puede suponer una enorme sobrecarga de procesamiento, independientemente del hecho de que finalmente no se almacenen datos.

Considere una situación en la que un microservicio almacena en caché el estado de envío de cada pedido. Con el fin de reducir el costo del servidor, el desarrollador ha pasado a utilizar una API externa proporcionada por el servicio de mensajería para consultar el estado del envío. El caché funcionaba originalmente comprobando primero el caché, probando el estado del pedido en una tabla de estado de pedido obsoleta y luego devolviendo este estado al cliente. En el nuevo flujo de trabajo, la solicitud del usuario se reenvía a la API externa, que captura los datos y luego los devuelve al cliente, que almacena el contenido en caché localmente.

¿Qué pasó con los datos almacenados en caché antiguos para el estado del pedido? ¿Qué pasó con el código que consultó la tabla ahora obsoleta? Si todavía existe, tenemos un problema: la base de código se vuelve más compleja y es posible llamar al punto final, a pesar de que los datos ya no son útiles. Más concretamente, si no eliminamos el almacenamiento en caché del servicio, es posible que los datos se retengan hasta algún punto de terminación de datos arbitrario, ya que no hay nada que le diga que los datos ya no son útiles. En varios miles de pedidos, esto puede sumar un enorme costo operativo diario que simplemente no aporta nada de valor.

Conclusión

El almacenamiento en caché parece relativamente sencillo, pero definitivamente hay cosas que deben tenerse en cuenta al implementar el almacenamiento en caché en una relación servidor-cliente. La estimación adecuada del costo mediante la identificación de la necesidad, la utilidad y la idoneidad puede ahorrar recursos de cliente y servidor, brindar una experiencia de usuario óptima y, en general, cumplir la promesa que aporta la memoria caché.

¿Qué opinas de estas mejores prácticas? ¿Qué debemos agregar a esta lista? ¡Háganos saber en los comentarios a continuación!

Publicar un comentario

0 Comentarios