La bomba de tiempo de seis meses: cuando EFS se quedó sin créditos de ráfaga

Durante casi seis meses, todo pareció funcionar a la perfección. Esa calma prolongada era la parte peligrosa.

Una aplicación web utilizaba Amazon Elastic File System (EFS) como almacenamiento compartido. Varias instancias de la aplicación podían acceder a los mismos archivos, el despliegue era sencillo y no había ningún motivo obvio para cuestionar la arquitectura.

Entonces, aparentemente sin previo aviso, el sitio web pasó a ser extremadamente lento y, finalmente, pareció dejar de funcionar por completo. La carga del servidor era inusualmente alta, se agotó el tiempo de espera de las solicitudes y los procesos de solicitud empezaron a acumularse.

A primera vista, parecía un problema informático. No lo era. La verdadera causa fue el agotamiento del saldo crediticio del EFS.

Por qué el fallo parecía un problema de CPU

Uno de los síntomas engañosos era la alta media de carga de Linux. Una media de carga alta no significa necesariamente que las CPU se utilicen al máximo. También incluye los procesos en espera en un estado ininterrumpible, que suele ocurrir cuando los procesos están bloqueados en la E/S del almacenamiento.

Los trabajadores de la solicitud estaban esperando a que finalizaran las operaciones de EFS. Seguían llegando nuevas solicitudes, se bloqueaban más trabajadores y la cola de solicitudes crecía:

1. El rendimiento del EFS pasó a ser limitado.
2. Las operaciones de archivos tardaron más.
3. Los trabajadores de aplicaciones seguían ocupados esperando la E/S.
4. Solicitudes entrantes acumuladas.
5. La carga del sistema aumentó.
6. Con el tiempo, el sitio web prácticamente dejó de estar disponible.

Añadir capacidad de CPU no habría resuelto el problema subyacente.

Por qué tardó seis meses en fallar

El sistema de archivos EFS estaba configurado para usar Rendimiento a rabiar modo. En este modo, el rendimiento de referencia sostenible está relacionado con la cantidad de datos almacenados en la clase de almacenamiento EFS Standard. Cuando la carga de trabajo se mantiene por debajo de esa base, el sistema de archivos acumula créditos de ráfaga. Cuando el rendimiento supera la línea base, esos créditos se consumen.

Esto crea una situación potencialmente engañosa para los sistemas de archivos relativamente pequeños:

• El volumen de datos almacenados se traduce en un rendimiento de referencia bajo y sostenible.
• Un saldo crediticio existente permite temporalmente un rendimiento mucho mayor.
• La aplicación funciona con normalidad a pesar de que su carga de trabajo a largo plazo supera la línea de base sostenible.
• El desequilibrio permanece oculto mientras haya créditos disponibles.
• Cuando el saldo llega a cero, el rendimiento cae drásticamente.

En este caso, los créditos acumulados duraron aproximadamente seis meses. La arquitectura ya estaba infravalorada desde el punto de vista del rendimiento, pero el saldo crediticio ocultaba el problema. Era un problema de capacidad lento, una bomba de relojería que hacía tictac de seis meses.

El rendimiento en ráfagas temporales nunca debe confundirse con un rendimiento sostenible.

Elegir el modo de rendimiento de EFS adecuado

Rendimiento a rabiar

El rendimiento a raudales puede ser apropiado cuando el rendimiento aumenta de forma natural con la cantidad de datos almacenados y los períodos de alta actividad van seguidos de períodos más tranquilos. Requiere una vigilancia cuidadosa. La disminución continua del saldo crediticio demuestra que la carga de trabajo no es sostenible en este modo.

Rendimiento elástico

Por lo general, Elastic Throughput se adapta mejor a cargas de trabajo impredecibles o con grandes fluctuaciones. El rendimiento se ajusta automáticamente con la demanda, por lo que la solicitud no depende de un saldo finito de crédito por ráfaga. Esto mejora la resiliencia operativa, aunque su coste basado en el uso debe evaluarse para las cargas de trabajo con un rendimiento alto y constante.

Rendimiento aprovisionado

El rendimiento aprovisionado es útil cuando se conoce el rendimiento requerido y es superior al que admitiría el volumen de datos almacenados de otro modo. Proporciona una capacidad predecible independientemente del tamaño del sistema de archivos, pero el nivel configurado debe revisarse a medida que cambie la demanda.

También es importante no confundir la EFS modo de rendimiento con su modo actuación. Los modos de rendimiento determinan la forma en que se suministra la capacidad de rendimiento; los modos de rendimiento se refieren a características como la latencia y el paralelismo.

Monitoreando eso debería haber estado en marcha

La métrica más importante de CloudWatch para un sistema de archivos EFS que utiliza Bursting Throughput es BurstCreditBalance. Una base de seguimiento útil también debería incluir:

• BurstCreditBalance para detectar un agotamiento crediticio sostenido
• PercentIOLimit para identificar cuando el sistema de archivos se acerca a su límite de E/S
• PermittedThroughput para entender el rendimiento disponible actualmente
• MeteredIOBytes y TotalIOBytes observar el consumo de E/S
• latencia de las aplicaciones, duración de las solicitudes, tiempos de espera y tasas de error
• procesos en espera de E/S, correlacionados con la carga y el uso real de la CPU

Supervisar solo los códigos de estado de la CPU, la memoria y el HTTP es insuficiente. El almacenamiento compartido es una dependencia fundamental de las aplicaciones y debe supervisarse como parte del servicio, no solo como un componente de infraestructura.

La alarma debería activarse mucho antes de que el saldo crediticio llegue a cero. Y lo que es más importante, hay que evaluar la tendencia. Un saldo que cae de forma constante a lo largo de varias semanas ya demuestra un déficit de rendimiento estructural, aunque el saldo absoluto siga pareciendo cómodo.

Qué haría de otra manera

1. Estime el rendimiento sostenible durante la fase de diseño.
2. Elija el modo de rendimiento en función del patrón de acceso real.
3. Trate los créditos de ráfaga como margen de maniobra temporal, no como capacidad normal.
4. Cree alarmas de CloudWatch para el saldo crediticio y los límites de E/S.
5. Supervise el ritmo al que se consumen los créditos.
6. Incluya el rendimiento y la latencia del EFS en las pruebas de carga.
7. Correlacione la carga de Linux con el uso de la CPU y la espera de E/S.
8. Compruebe si los archivos a los que se accede con frecuencia realmente requieren almacenamiento en red compartido.
9. Pruebe el comportamiento de las aplicaciones con limitaciones de almacenamiento y latencia elevada.
10. Documente el procedimiento operativo para cambiar los modos de rendimiento.

Última comida para llevar

EFS puede ser una excelente solución de almacenamiento compartido, pero su comportamiento depende en gran medida del modo de rendimiento y del perfil de carga de trabajo seleccionados.

La parte peligrosa de este incidente no fue simplemente la degradación del rendimiento. Lo peligroso era que el sistema funcionó bien durante seis meses antes de degradarse. La explosión del saldo crediticio retrasó el fracaso visible lo suficiente como para crear confianza en una arquitectura que no era sostenible.

La mejor defensa no es aumentar el saldo crediticio. Se trata de seleccionar el modo de rendimiento correcto, entender el rendimiento sostenible y supervisar las métricas que revelan un desequilibrio creciente antes de que los usuarios se den cuenta.

Referencias

• Documentación de rendimiento de Amazon EFS
• Métricas de Amazon EFS CloudWatch