BERND KUHLENTodas las notas ↗Un problema con Amazon EFS puede estar presente mucho antes de que se haga visible. Un sistema de archivos pequeño puede gestionar una carga de trabajo correctamente durante semanas o meses y, al mismo tiempo, consumir una reserva finita de créditos de ráfaga. La aplicación tiene un buen aspecto, los paneles se mantienen ecológicos y la arquitectura se gana la confianza. Entonces, la reserva llega a cero y la misma carga de trabajo se encuentra con un límite de rendimiento sostenible mucho más bajo.
Este retraso hace que el fallo parezca repentino. Operacionalmente, es cualquier cosa menos repentino.
El desajuste oculto
Con Bursting Throughput, el rendimiento de referencia crece con la cantidad de datos almacenados en la clase de almacenamiento EFS Standard. AWS documenta una tasa base de 50 KB/s por GiB, y cada sistema de archivos recibe al menos 1 MiB/s de rendimiento medido. El trabajo realizado por debajo de la línea de base genera créditos; el trabajo por encima de él los consume.
El patrón peligroso es una carga de trabajo cuya media a largo plazo está ligeramente por encima de esa base. Puede que no genere un incidente inmediato porque los créditos acumulados anteriormente pagan la diferencia. Sin embargo, la balanza tiende a la baja todos los días.
Por qué los síntomas van en la dirección equivocada
Cuando las llamadas de almacenamiento tardan más, los trabajadores de aplicaciones esperan. En Linux, los procesos bloqueados en la espera ininterrumpida de E/S contribuyen a la media de carga, por lo que un cuello de botella de almacenamiento puede parecerse a un problema de capacidad de cálculo. Las solicitudes hacen cola, los grupos de trabajadores se llenan y los tiempos de espera se distribuyen por el servicio, incluso cuando el uso de la CPU no es la causa principal.
Añadir instancias puede empeorar la situación si cada nuevo trabajador genera más solicitudes contra el mismo sistema de archivos compartidos restringido. El cuello de botella es compartido, mientras que la simultaneidad adicional aumenta la presión sobre él.
Por qué seis meses de salud resultan muy poco
Un período prolongado sin fallos solo valida la combinación de la demanda, el rendimiento de referencia y los créditos restantes durante ese período. No demuestra que la carga de trabajo sea sostenible una vez agotados los créditos. Un declive BurstCreditBalance Por lo tanto, no es solo un detalle de capacidad, sino una señal de fiabilidad temprana.
Las pruebas de carga deben cubrir el estado estacionario, no solo una prueba de pico corta. Una prueba de diez minutos puede demostrar que el techo roto es lo suficientemente alto. Dice poco de un déficit que se acumula a lo largo de miles de horas.
Una secuencia de investigación mejor
- Compare la utilización de la CPU con la media de carga y la espera de E/S.
- Inspeccionar EFS
BurstCreditBalancedurante semanas o meses. - Comparar
MeteredIOBytesconPermittedThroughput. - Correlacione las restricciones de almacenamiento con la latencia de las aplicaciones y la saturación de los trabajadores.
- Compruebe cuántos datos hay realmente en la clase de almacenamiento estándar, porque eso impulsa la línea base de Bursting.
- Decida si la carga de trabajo depende del rendimiento por ráfagas, elástico o aprovisionado.
La lección de ingeniería
La capacidad de ráfaga es un búfer, no un plan de capacidad. Cualquier servicio basado en créditos debe evaluarse según la dirección y el tipo de su saldo, no solo según si el valor actual está por encima de cero. El artículo anterior de esta serie describe detalladamente el patrón real de los incidentes; el siguiente convierte esa lección en un diseño concreto de monitorización de CloudWatch.