¡Hola! Soy Jayeon.

Hoy voy a explicar los criterios para configurar la caché. Como es una publicación que escribo a partir de mi experiencia laboral personal, considero que se debe usar como referencia ㅎㅎ

¿Qué es la caché?

La caché significa guardar previamente el resultado de una solicitud para que pueda ser servida rápidamente. Es decir, se guarda el resultado previamente, y cuando llega una solicitud, la solicitud se maneja accediendo a la caché en lugar de consultar la base de datos o la API. El concepto de caché se basa en la ley de Pareto.

La ley de Pareto establece que el 80% de los resultados se deben al 20% de las causas. ¡Creo que sería bueno que consultaras la siguiente imagen!

En otras palabras, la caché no necesita guardar todos los resultados y solo guardar el 20% que se usa con más frecuencia al prestar el servicio puede aumentar la eficiencia general.

¿Qué datos se deben guardar en caché?

Según la ley de Pareto, no se deben guardar en caché todos los datos, sino solo los datos que sean realmente necesarios. Entonces, ¿qué datos se deben guardar en caché?

Datos que deben leerse con frecuencia pero que rara vez se escriben

Mucha gente dice que se debe guardar en caché “los datos que se deben leer con frecuencia pero que rara vez se escriben” de forma teórica, pero los criterios de “leer con frecuencia” y “escribir poco” eran bastante vagos.

Por eso, investigo los datos que deben guardarse en caché de la siguiente manera.

• Compruebo los TOP 5 de los registros de llamada de consultas a RDB mediante un APM como DataDog.
• Entre ellos, busco consultas de búsqueda y compruebo desde qué tabla se están obteniendo.
• Compruebo cuántas veces se ejecuta la consulta de actualización de la tabla correspondiente.

Al realizar este proceso, se verifica si hay muchas consultas de búsqueda pero pocas actualizaciones. Verifiqué una tabla en la que las consultas de búsqueda se producían 1,74 millones de veces al día, mientras que las actualizaciones solo se producían unas 500 veces. Esto es una condición ideal para la caché. ㅎㅎ

Datos sensibles a la actualización

Los datos sensibles a la actualización significan que la inconsistencia entre RDB y la caché debe ser corta. Por ejemplo, la información relacionada con el pago es muy sensible a la actualización, por lo que, incluso si cumple con las condiciones de caché anteriores, debe considerarse su aplicación.

Tuve que guardar en caché una tabla relacionada con el pago que cumpliera con estas dos características. Por lo tanto, no apliqué la caché a toda la lógica que usa la tabla relacionada con el pago, sino que decidí aplicar la caché de forma parcial a la lógica relativamente segura en la que no se produce el pago real.

Caché local vs. caché global

Ahora que hemos definido más o menos los datos que se deben guardar en caché y el ámbito de la caché, debemos pensar en “dónde” se deben guardar los datos de caché. En general, se pueden guardar en la memoria local o en un servidor separado como Redis.

Caché local

La caché local es un método para guardar datos de caché en la memoria del servidor de aplicaciones y, en general, se utilizan mucho Guava cache o Caffeine cache.

Ventajas

• La velocidad es rápida porque se puede buscar la caché en la memoria del mismo servidor durante la ejecución de la lógica de la aplicación.
• Es fácil de implementar.

Desventajas

• Si hay varias instancias, surgen varios problemas.
  • No se pueden propagar los cambios de caché de una instancia a otra. Sin embargo, también hay bibliotecas de caché local que propagan los cambios a otras instancias.
  • La caché se guarda en cada instancia, por lo que es necesario agregar una nueva caché cuando se inicia una nueva instancia. Esto puede provocar muchos errores de caché y la instancia puede morir debido a que no puede soportar el tráfico.

Caché global

La caché global es un método que utiliza un servidor separado como Redis para guardar los datos de caché.

Ventajas

• Al compartir la caché entre instancias, todas las instancias pueden obtener el mismo valor de caché incluso si se modifica la caché en una instancia.
• Incluso si se inicia una nueva instancia, solo necesita mirar el almacén de caché existente, por lo que no es necesario realizar la acción de completar la caché.

Desventajas

• Como es necesario pasar por el tráfico de red, la velocidad es más lenta que la caché local.
• Es necesario utilizar un servidor de caché separado, por lo que se incurre en costes de gestión de la infraestructura.
  • ¿Costes de gestión de la infraestructura? → Costes del servidor, tiempo dedicado a la configuración y el mantenimiento de la infraestructura, planificación de medidas de respuesta a fallos, etc.

¿Qué he elegido?

El servidor de aplicaciones de la empresa actual tiene una estructura que inicia varias instancias, pero he elegido la caché local.

Hay tres razones principales.

• Los datos de caché almacenados en RDB son aproximadamente 40.000, por lo que si se cargan todos en la memoria, son menos de 4 MB.
• Se necesitaba un buen rendimiento de búsqueda para los datos relacionados con el pago.
• Aunque Redis ya existe, guardar una nueva caché en Redis genera costes de infraestructura.

¿Cómo se actualiza la caché?

Si hay varios servidores de aplicaciones y se ha aplicado la caché local a los mismos, los valores de la caché almacenados en cada servidor de aplicaciones pueden ser diferentes. Por ejemplo, los datos de caché almacenados en el servidor A son "1", pero los datos de caché almacenados en el servidor B pueden ser "2" después de que el servidor B los modifique. En esta situación, si un usuario envía una solicitud al equilibrador de carga, el servidor A y el servidor B recibirán valores diferentes.

Por lo tanto, es necesario configurar cada instancia para que elimine la caché automáticamente y busque en RDB, y para ello se suele utilizar TTL.

¿Cuánto tiempo debe configurarse TTL?

TTL significa Time To Live y es una configuración para eliminar la caché después de que transcurra un tiempo específico. Por ejemplo, si se configura TTL en 5 segundos, los datos de caché se eliminarán automáticamente después de 5 segundos. Luego, si se produce un error de caché, se buscan los datos en RDB y se guardan.

Entonces, ¿cuánto tiempo debe configurarse TTL?

Lectura/escritura en un servidor de caché

Si la lectura/escritura se produce en un único servidor de caché global como Redis o en un único servidor de aplicaciones con caché local, el valor de TTL se puede aumentar a una unidad de tiempo o más. De todos modos, la caché se actualizará al escribir y el servidor que obtiene los datos de la caché siempre verá los datos actualizados.

En este caso, no es necesario configurar TTL y se puede configurar de forma que la caché se vacíe gradualmente mediante el algoritmo LRU a medida que el servidor de caché se llena.

Lectura/escritura en varios servidores de caché

Si la lectura/escritura se produce en varios servidores de caché global o en varios servidores de aplicaciones con caché local, es aconsejable utilizar TTL en unidades de segundos o minutos. Esto se debe a que existe la posibilidad de leer datos antiguos de un servidor de caché que aún no ha reflejado los datos modificados.

En este caso, TTL se determina en función de varios contextos. Cuanto más importante sea la actualización y mayor sea la probabilidad de que se modifique el valor, más corto debe ser el TTL, y cuanto menos importante sea la actualización y menor sea la probabilidad de que se modifique el valor, más largo se puede configurar el TTL.

¿Cómo he configurado TTL?

Los datos que voy a guardar en caché están relacionados con los pagos, y aunque no apliqué la caché a la lógica estricta en la que se produce el pago real, la actualización es importante debido a la naturaleza de los pagos. Sin embargo, como la probabilidad de actualización es baja, he configurado un TTL de 5 segundos como medida de seguridad.

Conclusión

En resumen, el método de caché que he elegido es el siguiente:

• Datos relacionados con el pago
• Se consulta con mucha frecuencia, pero apenas se modifica.
• Se aplica la caché solo a la lógica en la que se produce la búsqueda, aunque no se produce el pago real.
• Se ha aplicado la caché local y TTL se ha configurado en 5 segundos.

Lo siguiente que voy a hacer es realizar una prueba de rendimiento del método de caché que he aplicado realmente. Todavía estoy pensando cómo realizar la prueba de rendimiento, así que la escribiré en una publicación posterior.