# Prácticas recomendadas de escalado automático y administración de la capacidad de Amazon ECS
Puede ejecutar las cargas de trabajo de las aplicaciones en contenedores de todos los tamaños en Amazon ECS. Esto incluye entornos de pruebas mínimos y entornos de producción de gran tamaño que funcionan a escala global.
Con Amazon ECS, como todos los servicios de AWS, solo se paga por lo que se usa. Si diseña la aplicación de manera adecuada, puede ahorrar costos al consumir solo los recursos que necesita cuando los necesita.
Las recomendaciones siguientes le muestran cómo ejecutar las cargas de trabajo de Amazon ECS para cumplir sus objetivos de servicio y, al mismo tiempo, operar de forma rentable.
**Topics**
+ [Determinación del tamaño de las tareas para Amazon ECS](capacity-tasksize-best-practice.md)
+ [Optimización del escalado automático de servicios de Amazon ECS](capacity-autoscaling-best-practice.md)
+ [Capacidad y disponibilidad de Amazon ECS](capacity-availability-best-practice.md)
+ [Capacidad de clústeres de Amazon ECS](capacity-cluster-best-practice.md)
+ [Elección de los tamaños de las tareas de Fargate para Amazon ECS](fargate-task-size-best-practice.md)
+ [Aceleración del aprovisionamiento de capacidad de clústeres de Amazon ECS con proveedores de capacidad en Amazon EC2](capacity-cluster-speed-up-ec2-best-practice.md)
# Determinación del tamaño de las tareas para Amazon ECS
Una de las decisiones más importantes al implementar los contenedores en Amazon ECS es el tamaño de los contenedores y las tareas. El tamaño de los contenedores y las tareas es esencial para planificar el escalado y la capacidad.
Amazon ECS utiliza dos métricas de recursos para la capacidad: CPU y memoria. Amazon ECS mide las CPU en unidades de 1/1024 de una vCPU completa (donde 1024 unidades equivalen a 1 vCPU completa). Amazon ECS mide la memoria en megabytes.
En la definición de la tarea, puede declarar las reservas y los límites de los recursos.
Cuando se declara una reserva, se declara la cantidad mínima de recursos que requiere una tarea. La tarea recibe como mínimo la cantidad de recursos que se solicite. Es posible que la aplicación pueda utilizar más CPU o memoria que la reserva que se declare. Sin embargo, esto está sujeto a los límites que también se hayan declarado.
Utilizar una cantidad superior a la reserva se conoce como ampliación. La expansión significa que la aplicación utiliza más recursos que los que se han reservado, pero se mantiene dentro de los límites declarados. Amazon ECS garantiza las reservas. Por ejemplo, si utiliza las instancias de Amazon EC2 para proporcionar capacidad, Amazon ECS no coloca una tarea en una instancia en la que no pueda gestionar la reserva.
Un límite es la cantidad máxima de unidades de CPU o memoria que pueden utilizar el contenedor o la tarea. Si el contenedor intenta utilizar más CPU que este límite, Amazon ECS lo limita. Si el contenedor intenta utilizar más memoria que este límite, Amazon ECS lo detiene.
Elegir estos valores puede resultar difícil. Los valores que mejor se adaptan a la aplicación dependen en gran medida de los requisitos de recursos de esta.
Las pruebas de carga de la aplicación son la clave para planificar correctamente los requisitos de recursos. Las pruebas de carga ayudan a comprender mejor los requisitos de la aplicación.
## Aplicaciones sin estado
En el caso de las aplicaciones sin estado que se escalan horizontalmente, como una aplicación detrás de un equilibrador de carga, recomendamos primero determinar cuánta memoria consume la aplicación cuando atiende las solicitudes.
Para ello, puede utilizar herramientas tradicionales como `ps` o `top`. También puede utilizar soluciones de supervisión como Información de contenedores de CloudWatch.
Al determinar la reserva de CPU, tenga en cuenta cómo quiere escalar la aplicación para que cumpla con los requisitos de su empresa.
Puede utilizar reservas de CPU más pequeñas, como 256 unidades de CPU (o 1/4 de vCPU), para escalar horizontalmente de manera detallada y minimizar los costos. Sin embargo, es posible que no se escalen lo suficientemente rápido como para satisfacer los picos significativos de la demanda.
Puede utilizar reservas de CPU más grandes para reducir y escalar horizontalmente con mayor rapidez. Esto es útil para adaptarse a los picos de demanda con mayor rapidez. Sin embargo, las reservas de CPU más grandes cuestan más.
## Otras aplicaciones
En el caso de las aplicaciones que no se escalan horizontalmente, como los trabajos singleton o los servidores de bases de datos, las consideraciones más importantes son la capacidad disponible y el costo.
Elija cantidad de memoria y CPU en función de lo que las pruebas de carga muestran que se necesita para atender el tráfico y cumplir su objetivo de servicio. Amazon ECS garantiza que la aplicación se coloque en un host que tenga la capacidad adecuada.
# Optimización del escalado automático de servicios de Amazon ECS
Un servicio de Amazon ECS es un conjunto administrado de tareas. Cada servicio tiene una definición de tareas asociada, un recuento de tareas deseado y una estrategia de ubicación opcional.
El escalado automático del servicio de Amazon ECS se implementa mediante el servicio Application Auto Scaling. Application Auto Scaling utiliza las métricas de CloudWatch como origen para las métricas de escalado. También utiliza las alarmas de CloudWatch para establecer umbrales sobre cuándo ampliar o reducir el servicio.
Usted proporciona los umbrales para el escalado. Puede establecer un objetivo métrico, que se denomina *escalado de seguimiento de destino*. También puede especificar umbrales, lo que se denomina *escalado por pasos*.
Después de que se configura Application Auto Scaling, este calcula continuamente el recuento de tareas deseado adecuado para el servicio. También notifica a Amazon ECS cuando debe cambiar el número de tareas deseado, ya sea escalándolo o reduciéndolo horizontalmente.
Para utilizar el escalado automático del servicio de manera eficaz, debe elegir una métrica de escalado adecuada. En las siguientes secciones se describe cómo seleccionar una métrica.
## Caracterización de la aplicación
Para escalar correctamente una aplicación, es necesario conocer las condiciones en las que debe reducirla horizontalmente y cuándo debe escalarla horizontalmente.
Básicamente, debe escalar horizontalmente la aplicación si se prevé que la demanda supere la capacidad. Por el contrario, puede reducirla horizontalmente para ahorrar costos cuando los recursos superan la demanda.
### Identificación de una métrica de utilización
Para escalar de forma eficaz, debe identificar una métrica que indique la utilización o la saturación. Esta métrica debe presentar las siguientes propiedades para que sea útil a la hora de escalar.
+ La métrica debe estar correlacionada con la demanda. Cuando mantiene los recursos estables, pero la demanda cambia, el valor de la métrica también debe cambiar. La métrica debe aumentar o disminuir cuando la demanda aumenta o disminuye.
+ El valor de la métrica debe escalarse en proporción a la capacidad. Cuando la demanda se mantiene constante, la adición de más recursos debe provocar un cambio proporcional en el valor de la métrica. Por lo tanto, si se duplica el número de tareas, la métrica debería disminuir un 50 %.
La mejor forma de identificar una métrica de uso es mediante pruebas de carga en un entorno de preproducción, como un entorno de ensayo. Las soluciones de pruebas de carga comerciales y de código abierto están ampliamente disponibles. Por lo general, estas soluciones pueden generar una carga sintética o simular el tráfico de usuarios reales.
Para iniciar el proceso de pruebas de carga, primero debe crear paneles de control para las métricas de uso de la aplicación. Estas métricas incluyen el uso de la CPU, el uso de la memoria, las operaciones de E/S, la profundidad de las colas de E/S y el rendimiento de la red. Puede recopilar estas métricas con un servicio como Información de contenedores de CloudWatch. También puede recopilarlas mediante Amazon Managed Service para Prometheus junto con Amazon Managed Grafana. Durante este proceso, asegúrese de recopilar y trazar métricas para los tiempos de respuesta de su aplicación o las tasas de finalización del trabajo.
Cuando haga la prueba de carga, comience con una pequeña tasa de solicitudes o de inserción de trabajos. Mantenga esta velocidad constante durante varios minutos para permitir que la aplicación se vaya iniciando. Luego, aumente lentamente la velocidad y manténgala estable durante unos minutos. Repita este proceso y vaya aumentando la velocidad hasta que los tiempos de respuesta o finalización de la aplicación sean demasiado lentos para cumplir sus objetivos de nivel de servicio (SLO).
Cuando haga la prueba de carga, examine cada una de las métricas de utilización. Las métricas que aumentan junto con la carga son las mejores para ser sus mejores métricas de uso.
A continuación, identifique el recurso que alcanza la saturación. Al mismo tiempo, examine también las métricas de utilización para ver cuál se aplana primero en un nivel alto. O bien, examine cuál alcanza su punto máximo y, luego, bloquea primero la aplicación. Por ejemplo, si el uso de la CPU aumenta del 0 % al 70 u 80 % a medida que se agrega carga y, después, se mantiene en ese nivel después de que agregue aún más carga, se puede decir con seguridad que la CPU está saturada. Según la arquitectura de la CPU, es posible que nunca alcance el 100 %. Por ejemplo, supongamos que el uso de la memoria aumenta a medida que se agrega carga y, después, la aplicación se bloquea repentinamente cuando alcanza el límite de memoria de la tarea o de la instancia de Amazon EC2. En esta situación, es probable que la memoria se haya consumido por completo. Es posible que la aplicación consuma varios recursos. Por lo tanto, elija primero la métrica que represente el recurso que se agota.
Por último, vuelva a hacer las pruebas de carga después de que duplique el número de tareas o instancias de Amazon EC2. Suponga que la métrica clave aumenta o disminuye a la mitad del ritmo anterior. Si este es el caso, la métrica es proporcional a la capacidad. Esta es una buena métrica de uso para el escalado automático.
Consideremos ahora este escenario hipotético. Suponga que lleva a caob una prueba de carga de una aplicación y descubre que el uso de la CPU finalmente alcanza el 80 % con 100 solicitudes por segundo. Al agregar más carga, el uso de la CPU ya no aumenta. Sin embargo, hace que la aplicación responda más lentamente. A continuación, vuelva a ejecutar la prueba de carga y duplique el número de tareas, pero mantenga la velocidad en su valor máximo anterior. Si observa que el uso medio de la CPU se reduce a aproximadamente un 40 %, el uso medio de la CPU es una buena opción para una métrica de escalado. Por otro lado, si el uso de la CPU se mantiene en un 80 % después de aumentar el número de tareas, el uso medio de la CPU no es una buena métrica de escalado. En ese caso, debe investigar más para encontrar una métrica adecuada.
### Modelos de aplicación comunes y propiedades de escalado
Puede ejecutar todo tipo de software en AWS. Muchas cargas de trabajo son propias, mientras que otras se basan en el popular software de código abierto. Independientemente de dónde se originen, hemos observado algunos patrones de diseño comunes para los servicios. La forma de escalar de manera efectiva depende en gran medida del patrón.
#### El servidor eficiente conectado a la CPU
El servidor eficiente conectado a la CPU casi no utiliza recursos distintos del rendimiento de la CPU y la red. La aplicación puede gestionar cada solicitud por sí misma. Las solicitudes no dependen de otros servicios, como las bases de datos. La aplicación puede gestionar cientos de miles de solicitudes simultáneas y, para ello, puede utilizar varias CPU de forma eficiente. Cada solicitud se atiende mediante un subproceso dedicado con poca sobrecarga de memoria, o bien hay un bucle de eventos asíncrono que se ejecuta en cada CPU que atiende las solicitudes. Cada réplica de la aplicación tiene la misma capacidad de gestionar una solicitud. El único recurso que puede agotarse antes que la CPU es el ancho de banda de la red. En los servicios dependientes de la CPU, el uso de la memoria, incluso con un rendimiento máximo, es una fracción de los recursos disponibles.
Puede utilizar el escalado automático basado en CPU para este tipo de aplicación. La aplicación disfruta de la máxima flexibilidad en términos de escalado. Puede escalarla verticalmente si se le proporcionan instancias de Amazon EC2 más grandes o vCPU de Fargate. Además, también puede escalarla horizontalmente mediante la adición de más réplicas. Agregar más réplicas o duplicar el tamaño de la instancia reduce a la mitad el uso medio de la CPU en relación con la capacidad.
Si utiliza la capacidad de Amazon EC2 para esta aplicación, considere colocarla en instancias optimizadas para la computación, como la familia `c5` o `c6g`.
#### El servidor eficiente dependiente de la memoria
El servidor eficiente dependiente de la memoria asigna una cantidad significativa de memoria por solicitud. Con la máxima simultaneidad, pero no necesariamente con el rendimiento, la memoria se agota antes de que se agoten los recursos de la CPU. La memoria asociada a una solicitud se libera cuando la solicitud finaliza. Se pueden aceptar solicitudes adicionales siempre que haya memoria disponible.
Puede utilizar el escalado automático basado en memoria para este tipo de aplicación. La aplicación disfruta de la máxima flexibilidad en términos de escalado. Puede escalarla verticalmente si se le proporcionan recursos de memoria más grandes de Amazon EC2 o Fargate. Además, también puede escalarla horizontalmente mediante la adición de más réplicas. Agregar más réplicas o duplicar el tamaño de la instancia puede reducir a la mitad el uso medio de la memoria en relación con la capacidad.
Si utiliza la capacidad de Amazon EC2 para esta aplicación, considere colocarla en instancias optimizadas para memoria, como la familia `r5` o `r6g`.
Algunas aplicaciones vinculadas a la memoria no liberan la memoria asociada a una solicitud cuando finaliza, de modo que una reducción de la simultaneidad no se traduce en una reducción de la memoria utilizada. Para ello, no es recomendable que utilice el escalado basado en memoria.
#### El servidor basado en trabajadores
El servidor basado en trabajadores procesa una solicitud para cada subproceso de trabajo individual, una tras otra. Los subprocesos de trabajo pueden ser subprocesos ligeros, como los subprocesos POSIX. También pueden ser hilos más pesados, como los procesos UNIX. No importa de qué subprocesos se trate, siempre hay una simultaneidad máxima que la aplicación puede admitir. Por lo general, el límite de simultaneidad se establece proporcionalmente a los recursos de memoria disponibles. Si se alcanza el límite de simultaneidad, la aplicación coloca más solicitudes en una cola de trabajos pendientes. Si la cola de trabajos pendientes se desborda, la aplicación rechaza de inmediato las solicitudes entrantes adicionales. Entre las aplicaciones habituales que se ajustan a este patrón se incluyen el servidor web Apache y Gunicorn.
La simultaneidad de solicitudes suele ser la mejor métrica para escalar esta aplicación. Como hay un límite de simultaneidad para cada réplica, es importante escalar horizontalmente antes de alcanzar el límite medio.
La mejor forma de obtener métricas de simultaneidad de solicitudes es hacer que la aplicación las informe a CloudWatch. Cada réplica de su aplicación puede publicar el número de solicitudes simultáneas como una métrica personalizada con una frecuencia alta. Recomendamos que la frecuencia se establezca como mínimo una vez cada minuto. Tras recopilar varios informes, puede utilizar la simultaneidad media como métrica de escalado. Para calcular esta métrica, tome la simultaneidad total y divídala entre el número de réplicas. Por ejemplo, si la simultaneidad total es 1000 y el número de réplicas es 10, la simultaneidad media es 100.
Si su aplicación está detrás de un equilibrador de carga de aplicaciones, también puede usar la métrica `ActiveConnectionCount` del equilibrador de carga como un factor en la métrica de escalado. Debe dividir la métrica `ActiveConnectionCount` entre el número de réplicas para obtener un valor promedio. Debe utilizar el valor promedio para escalar, en lugar del valor de recuento sin procesar.
Para que este diseño funcione mejor, la desviación estándar de la latencia de respuesta debe ser pequeña a tasas de solicitud bajas. Recomendamos que, durante los periodos de baja demanda, la mayoría de las solicitudes se respondan en poco tiempo, y no hay muchas solicitudes que tarden mucho más tiempo que la media en responder. El tiempo de respuesta promedio debe estar cerca del percentil 95. De lo contrario, podrían producirse desbordamientos de colas como consecuencia de ello. Esto provoca errores. Le recomendamos que proporcione réplicas adicionales cuando sea necesario para mitigar el riesgo de desbordamiento.
#### El servidor de espera
El servidor de espera procesa en parte cada solicitud, pero depende en gran medida de uno o más servicios intermedios para funcionar. Las aplicaciones contenedoras suelen hacer un uso intensivo de los servicios secundarios, como las bases de datos y otros servicios de API. Estos servicios pueden tardar algún tiempo en responder, especialmente en escenarios de alta capacidad o alta simultaneidad. Esto se debe a que estas aplicaciones suelen utilizar pocos recursos de la CPU y utilizan su máxima simultaneidad en términos de memoria disponible.
El servicio de espera es adecuado tanto en el modelo de servidor limitado en memoria como en el modelo de servidor basado en el trabajador, según el diseño de la aplicación. Si la simultaneidad de la aplicación está limitada únicamente por la memoria, se debe utilizar el uso medio de la memoria como métrica de escalado. Si la simultaneidad de la aplicación se basa en un límite de trabajadores, se debe utilizar la simultaneidad media como métrica de escalado.
#### El servidor basado en Java
Si su servidor basado en Java está vinculado a la CPU y se escala proporcionalmente a los recursos de la CPU, podría ser adecuado para el patrón eficiente de servidor dependiente de la CPU. Si ese es el caso, el uso medio de la CPU podría ser adecuado como métrica de escalado. Sin embargo, muchas aplicaciones Java no dependen de la CPU, lo que dificulta su escalabilidad.
Para obtener el mejor rendimiento, le recomendamos que asigne la mayor cantidad de memoria posible al montón de máquinas virtuales de Java (JVM). Las versiones recientes de la JVM, incluida la actualización 191 o posterior de Java 8, establecen automáticamente el tamaño del montón lo más grande posible para que quepa en el contenedor. Esto significa que, en Java, el uso de la memoria rara vez es proporcional al uso de las aplicaciones. A medida que aumentan la tasa de solicitudes y la simultaneidad, el uso de la memoria permanece constante. Por este motivo, no recomendamos escalar los servidores basados en Java en función del uso de la memoria. En su lugar, solemos recomendar escalar el uso de la CPU.
En algunos casos, los servidores basados en Java sufren el agotamiento del montón antes de agotar la CPU. Si su aplicación es propensa al agotamiento del montón en alta simultaneidad, el promedio de conexiones es la mejor métrica de escalado. Si su aplicación es propensa al agotamiento del montón en alto rendimiento, la tasa media de solicitudes es la mejor métrica de escalado.
#### Servidores que utilizan otros tiempos de ejecución de recopilación de elementos no utilizados
Muchas aplicaciones de servidor se basan en tiempos de ejecución de recopilación de elementos no utilizados, como .NET y Ruby. Es posible que estas aplicaciones de servidor se ajusten a uno de los patrones descritos anteriormente. Sin embargo, al igual que con Java, no recomendamos escalar estas aplicaciones en función de la memoria, ya que su uso medio de memoria observado no suele estar correlacionado con el rendimiento o la simultaneidad.
En el caso de estas aplicaciones, se recomienda escalar el uso de la CPU si la aplicación está vinculada a esta. De lo contrario, le recomendamos que escale según el rendimiento medio o la simultaneidad media, en función de los resultados de las pruebas de carga.
#### Procesadores de tareas
Muchas cargas de trabajo implican el procesamiento asíncrono de las tareas. Incluyen aplicaciones que no reciben solicitudes en tiempo real, sino que se suscriben a una cola de tareas para recibir trabajos. Para este tipo de aplicaciones, la métrica de escalado adecuada casi siempre es la profundidad de la cola. El crecimiento de las colas indica que el trabajo pendiente supera la capacidad de procesamiento, mientras que una cola vacía indica que hay más capacidad que trabajo por hacer.
Los servicios de mensajería de AWS, como Amazon SQS y Amazon Kinesis Data Streams, proporcionan métricas de CloudWatch que se pueden utilizar para escalar. Para Amazon SQS, `ApproximateNumberOfMessagesVisible` es la mejor métrica. En Kinesis Data Streams, considere utilizar la métrica `MillisBehindLatest`, publicada por Kinesis Client Library (KCL). Esta métrica debe promediarse entre todos los consumidores antes de utilizarla para escalar.
# Capacidad y disponibilidad de Amazon ECS
La disponibilidad de las aplicaciones es fundamental para ofrecer una experiencia sin errores y minimizar la latencia de las aplicaciones. La disponibilidad depende de que los recursos sean accesibles y tengan la capacidad suficiente para satisfacer la demanda. AWS proporciona varios mecanismos para administrar la disponibilidad. En el caso de las aplicaciones que aloja en Amazon ECS, estas incluyen el escalado automático y las zonas de disponibilidad (AZ). El escalado automático administra la cantidad de tareas o instancias en función de las métricas que defina, mientras que las zonas de disponibilidad le permiten alojar la aplicación en ubicaciones aisladas pero cercanas geográficamente.
Al igual que ocurre con el tamaño de las tareas, la capacidad y la disponibilidad presentan ciertas desventajas que debe tener en cuenta. Lo ideal sería que la capacidad estuviera perfectamente alineada con la demanda. Siempre habría suficiente capacidad para atender las solicitudes y procesar los trabajos a fin de cumplir los objetivos de nivel de servicio (SLO), lo que incluye una latencia y una tasa de errores bajas. La capacidad nunca sería demasiado alta, lo que generaría un costo excesivo; tampoco sería demasiado baja, lo que generaría una latencia y una tasa de errores altas.
El escalado automático es un proceso latente. En primer lugar, CloudWatch debe recibir métricas en tiempo real. A continuación, CloudWatch debe agregarlas para su análisis, lo que puede tardar varios minutos en función de la granularidad de la métrica. CloudWatch compara las métricas con los umbrales de alarma para identificar la escasez o el exceso de recursos. Para evitar la inestabilidad, debe configurar las alarmas para que requieran que se supere el umbral establecido durante unos minutos antes de que suene la alarma. También lleva tiempo aprovisionar nuevas tareas y terminar las tareas que ya no son necesarias.
Debido a estos posibles retrasos en el sistema, debe mantener cierto margen mediante el aprovisionamiento excesivo. El sobreaprovisionamiento puede ayudar a satisfacer picos de demanda a corto plazo. Esto también ayuda a la aplicación a atender solicitudes adicionales sin saturarse. Como práctica recomendada, puede establecer su objetivo de escalado entre el 60 y el 80 % de utilización. Esto ayuda a la aplicación a gestionar mejor las ráfagas de demanda adicional mientras aún se está aprovisionando capacidad adicional.
Otro motivo por el que recomendamos aprovisionar en exceso es para poder responder rápidamente a los errores en las zonas de disponibilidad. AWS recomienda que las cargas de trabajo de producción se atiendan desde varias zonas de disponibilidad. Esto se debe a que, si se produce un error en una zona de disponibilidad, las tareas que se ejecutan en las zonas de disponibilidad restantes pueden seguir satisfaciendo la demanda. Si la aplicación se ejecuta en dos zonas de disponibilidad, debe duplicar el número normal de tareas. Esto es para que pueda proporcionar capacidad inmediata en caso de que se produzca un posible error. Si la aplicación se ejecuta en tres zonas de disponibilidad, le recomendamos que ejecute 1,5 veces el número normal de tareas. Es decir, ejecute tres tareas por cada dos que se necesiten para un servicio normal.
## Maximización de la velocidad de escalado
El escalado automático es un proceso reactivo que tarda en surtir efecto. Sin embargo, hay algunas maneras de ayudar a minimizar el tiempo necesario para escalar horizontalmente.
**Minimice el tamaño de la imagen.** Las imágenes más grandes tardan más en descargarse de un repositorio de imágenes y descomprimirse. Por lo tanto, al reducir el tamaño de las imágenes, se reduce el tiempo necesario para que se inicie un contenedor. Para reducir el tamaño de la imagen, puede seguir estas recomendaciones específicas:
+ Si puede crear un binario estático o usar Golang, cree la imagen `FROM` desde cero e incluya solo la aplicación binaria en la imagen resultante.
+ Utilice imágenes base minimizadas de proveedores de distribuciones ascendentes, como Amazon Linux o Ubuntu.
+ No incluya ningún artefacto de compilación en la imagen final. El uso de compilaciones en varias etapas puede ayudar en este sentido.
+ Comprima las etapas de `RUN` siempre que sea posible. Cada etapa de `RUN` crea una nueva capa de imagen, lo que implica un proceso adicional de ida y vuelta para descargar la capa. Una sola etapa de `RUN` que tiene varios comandos unidos por `&&` tiene menos capas que una con varias etapas de `RUN`.
+ Si desea incluir datos, como datos de inferencia de ML, en la imagen final, incluya solo los datos necesarios para iniciar y empezar a atender el tráfico. Si obtiene datos bajo demanda de Amazon S3 u otro tipo de almacenamiento sin que ello afecte al servicio, almacene los datos en esos lugares.
**Mantenga las imágenes cerca.** Cuanto más alta sea la latencia de red, mas tardará en descargarse la imagen. Aloje sus imágenes en un repositorio en la misma región de AWS en la que se encuentra su carga de trabajo. Amazon ECR es un repositorio de imágenes de alto rendimiento que está disponible en todas las regiones en las que está disponible Amazon ECS. Evite utilizar Internet o un enlace de VPN para descargar imágenes de contenedores. El alojamiento de las imágenes en la misma región mejora la fiabilidad general. Mitiga el riesgo de problemas de conectividad de red y de disponibilidad en una región diferente. Como alternativa, también puede implementar la replicación entre regiones de Amazon ECR a modo de ayuda.
**Reduzca los umbrales de comprobación de estado del equilibrador de carga.** Los equilibradores de carga realizan comprobaciones de estado antes de enviar tráfico a la aplicación. La configuración de comprobación de estado predeterminada para un grupo de destino puede tardar 90 segundos o más. Durante este proceso, el equilibrador de carga comprueba el estado y recibe las solicitudes. Reducir el intervalo de comprobación de estado y el recuento de umbrales puede hacer que la aplicación acepte el tráfico más rápido y reducir la carga de otras tareas.
**Considere el rendimiento de arranque en frío.** Algunas aplicaciones utilizan tiempos de ejecución como Java para realizar la compilación Just-In-Time (JIT). El proceso de compilación, al menos cuando se inicia, puede mostrar el rendimiento de la aplicación. Una solución alternativa consiste en reescribir las partes de la carga de trabajo que son fundamentales para la latencia en lenguajes que no supongan una penalización del rendimiento al arrancar en frío.
**Utilice políticas de escalado por pasos y escalado no centrado en el seguimiento de destino.** Dispone de varias opciones de escalado automático de aplicaciones para las tareas de Amazon ECS. El seguimiento de destinos es el modo más fácil de utilizar. Con él, todo lo que necesita hacer es establecer un valor de destino para una métrica, como la utilización media de la CPU. Luego, el escalador automático administra de forma automática la cantidad de tareas necesarias para alcanzar ese valor. Con el escalado por pasos, puede reaccionar más rápidamente a los cambios en la demanda, ya que define los umbrales específicos para sus métricas de escalado y cuántas tareas agregar o eliminar cuando se superen los umbrales. Y, lo que es más importante, puede reaccionar muy rápidamente ante los cambios en la demanda al minimizar el tiempo que una alarma supera el umbral. Para obtener más información, consulte [Servicio de escalado automático](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html) en la *Guía para desarrolladores de servicio de contenedor elástico de Amazon*.
Si utiliza instancias de Amazon EC2 para proporcionar la capacidad del clúster, considere las recomendaciones siguientes:
**Utilice instancias de Amazon EC2 más grandes y volúmenes de Amazon EBS más rápidos.** Puede mejorar las velocidades de descarga y preparación de imágenes mediante el uso de una instancia de Amazon EC2 más grande y un volumen de Amazon EBS más rápido. Dentro de una familia de instancias de Amazon EC2 determinada, el rendimiento máximo de la red y de Amazon EBS aumenta a medida que aumenta el tamaño de la instancia (por ejemplo, de `m5.xlarge` a `m5.2xlarge`). Además, también puede personalizar los volúmenes de Amazon EBS para aumentar el rendimiento y las IOPS. Por ejemplo, si utiliza volúmenes `gp2`, utilice volúmenes más grandes que ofrezcan más rendimiento de referencia. Si utiliza volúmenes `gp3`, especifique el rendimiento y las IOPS al crear el volumen.
**Utilice el modo de red bridge para las tareas que se ejecutan en las instancias de Amazon EC2.** Las tareas que utilizan el modo de red `bridge` en Amazon EC2 se inician más rápido que las tareas que utilizan el modo de red `awsvpc`. Cuando se utiliza el modo de red `awsvpc`, Amazon ECS conecta una interfaz de red elástica (ENI) a la instancia antes de lanzar la tarea. Esto introduce una latencia adicional. Sin embargo, el uso de redes bridge tiene varias desventajas. Estas tareas no tienen su propio grupo de seguridad y el equilibrio de carga tiene algunas implicaciones. Para obtener más información, consulte [Load balancer target groups](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html) en la *Guía del usuario de Elastic Load Balancing*.
## Gestión de crisis de demanda
Algunas aplicaciones experimentan grandes crisis de demanda repentinas. Esto ocurre por diversas razones: una noticia, una gran venta, un evento mediático o algún otro evento que se vuelva viral y provoque un aumento rápido y significativo del tráfico en muy poco tiempo. Si no se planifica, esto puede provocar que la demanda supere rápidamente los recursos disponibles.
La mejor manera de gestionar las crisis de demanda es anticiparse a ellas y planificar en consecuencia. Como el escalado automático puede llevar tiempo, le recomendamos que escale horizontalmente la aplicación antes de que comience la crisis de demanda. Para obtener los mejores resultados, recomendamos tener un plan empresarial que implique una estrecha colaboración entre los equipos que utilicen un calendario compartido. El equipo que planifique el evento debe trabajar en estrecha colaboración con el equipo a cargo de la aplicación con antelación. Esto le da al equipo tiempo suficiente para tener un plan de programación claro. Pueden programar el escalado horizontal de la capacidad antes del evento y la reducción horizontal después del evento. Para obtener más información, consulte [Escalado programado](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) en la *Guía del usuario de Auto Scaling de aplicaciones*.
Si tiene el plan Enterprise Support, asegúrese de trabajar también con su administrador técnico de cuentas (TAM). El TAM puede verificar sus cuotas de servicio y asegurarse de que se aumenten las cuotas necesarias antes de que comience el evento. De esta forma, no alcanza accidentalmente ninguna cuota de servicio. También puede ayudarlo con servicios de precalentamiento, como los equilibradores de carga, para garantizar que el evento se desarrolle sin problemas.
Gestionar las crisis no programadas de demanda es un problema más difícil. Las crisis no programadas, si son lo suficientemente grandes en amplitud, pueden provocar rápidamente que la demanda supere a la capacidad. También puede superar la capacidad de reacción del escalado automático. La mejor manera de prepararse para las crisis no programadas es aprovisionar recursos en exceso. Debe disponer de recursos suficientes para gestionar la máxima demanda de tráfico prevista en cualquier momento.
Mantener la máxima capacidad para anticiparse a las crisis no programadas de demanda puede resultar costoso. Para mitigar el impacto en los costos, busque un indicador, métrica o evento principal que prediga la inminencia de una gran crisis de demanda. Si la métrica o el evento avisan de forma fiable y con suficiente antelación, comience el proceso de escalado horizontal inmediatamente cuando se produzca el evento o cuando la métrica supere el umbral específico que haya establecido.
Si su aplicación es propensa a sufrir crisis repentinas y no programadas de demanda, considere la posibilidad de agregar un modo de alto rendimiento a la aplicación que sacrifique la funcionalidad no crítica pero que conserve la funcionalidad crucial para un cliente. Por ejemplo, supongamos que su aplicación puede pasar de generar costosas respuestas personalizadas a ofrecer una página de respuestas estática. En este escenario, puede aumentar el rendimiento de manera significativa sin escalar la aplicación en absoluto.
Por último, puede considerar la posibilidad de separar los servicios monolíticos para hacer frente mejor a las crisis de demanda. Si su aplicación es un servicio monolítico cuya ejecución es costosa y su escalado es lento, es posible que pueda extraer o reescribir las partes fundamentales para el rendimiento y ejecutarlas como servicios independientes. De este modo, estos nuevos servicios se pueden escalar de forma independiente de los componentes menos críticos. Disponer de la flexibilidad necesaria para escalar horizontalmente las funciones esenciales para el rendimiento de forma independiente de otras partes de la aplicación puede reducir el tiempo que se tarda en agregar capacidad y ayudar a ahorrar costos.
# Capacidad de clústeres de Amazon ECS
Puede proporcionar capacidad a un clúster de Amazon ECS de varias maneras. Por ejemplo, puede lanzar instancias de Amazon EC2 y registrarlas en el clúster al inicio mediante el agente del contenedor de Amazon ECS. Sin embargo, este método puede resultar difícil porque debe administrar el escalado por su cuenta. Por lo tanto, se recomienda utilizar proveedores de capacidad de Amazon ECS. Los proveedores de capacidad administran el escalado de los recursos por usted. Hay tres tipos de proveedores de capacidad: Amazon EC2, Fargate y Fargate Spot. Para obtener más información sobre los proveedores de capacidad de Fargate, consulte [Clústeres de Amazon ECS para cargas de trabajo de Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-capacity-providers.html) y, para cargas de trabajo de EC2, consulte [Clústeres de Amazon ECS para cargas de trabajo de EC2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html).
Los proveedores de capacidad de Fargate y Fargate Spot gestionan el ciclo de vida de las tareas de Fargate por usted. Fargate ofrece capacidad bajo demanda y Fargate Spot proporciona capacidad de Spot. Cuando lanza una tarea, Amazon ECS aprovisiona un recurso de Fargate por usted. Este recurso de Fargate incluye las unidades de memoria y CPU que corresponden directamente a los límites de nivel de tarea que declaró en la definición de la tarea. Cada tarea recibe su propio recurso de Fargate, lo que establece una relación 1:1 entre la tarea y los recursos de computación.
Las tareas que se ejecutan en Fargate Spot están sujetas a interrupciones. Las interrupciones se producen tras una advertencia de dos minutos. Se producen durante los periodos de gran demanda. Fargate Spot funciona mejor con cargas de trabajo tolerantes a las interrupciones, como los trabajos por lotes o los entornos de desarrollo o provisionales. También es adecuado para cualquier otro escenario en el que la alta disponibilidad y la baja latencia no sean un requisito.
Puede ejecutar tareas de Fargate Spot junto con las tareas de Fargate bajo demanda. Al utilizarlas juntas, dispondrá de capacidad de ampliación de aprovisionamiento a un costo menor.
Amazon ECS también puede administrar la capacidad de la instancia de Amazon EC2 para las tareas. Cada proveedor de capacidad de Amazon EC2 está asociado a un grupo de Amazon EC2 Auto Scaling especificado. Cuando utiliza el proveedor de capacidad de Amazon EC2, el escalado automático de clústeres mantiene el tamaño del grupo de Amazon EC2 Auto Scaling para garantizar que se puedan hacer todas las tareas programadas.
# Elección de los tamaños de las tareas de Fargate para Amazon ECS
En el caso de las definiciones de tareas de AWS Fargate, debe especificar la CPU y la memoria de las tareas. No es necesario tener en cuenta la sobrecarga. También puede especificar la CPU y la memoria en el nivel de contenedor para tareas de Fargate. Sin embargo, esto no es obligatorio. Los límites de los recursos deben ser superiores o iguales a las reservas que haya declarado. En la mayoría de los casos, puede establecerlos como la suma de las reservas de cada uno de los contenedores declarados en la definición de la tarea. Luego, redondee el número al tamaño de Fargate más cercano. Para más información sobre los tamaños disponibles, consulte [Memoria y CPU de tarea](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html#fargate-tasks-size).
# Aceleración del aprovisionamiento de capacidad de clústeres de Amazon ECS con proveedores de capacidad en Amazon EC2
Los clientes que ejecutan Amazon ECS en Amazon EC2 pueden aprovechar el [escalado automático de clústeres (CAS) de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html) para administrar el escalado de los grupos de Amazon EC2 Auto Scaling (ASG). Con CAS, puede configurar Amazon ECS para escalar el ASG automáticamente y centrarse únicamente en ejecutar las tareas. Amazon ECS garantizará que el ASG se reduzca o escale horizontalmente según sea necesario sin necesidad de ninguna otra intervención. Los proveedores de capacidad de Amazon ECS están acostumbrados a administrar la infraestructura del clúster al garantizar que haya instancias de contenedor suficientes para satisfacer las exigencias de la aplicación. Para obtener información sobre cómo funciona el CAS de Amazon ECS, consulte [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/).
Dado que CAS depende de una integración basada en CloudWatch con ASG para ajustar la capacidad de clústeres, tiene una latencia inherente asociada a la publicación de las métricas de CloudWatch, el tiempo que tarda la métrica `CapacityProviderReservation` en infringir las alarmas de CloudWatch (altas y bajas) y el tiempo que tarda una instancia de Amazon EC2 recién lanzada en prepararse. Puede hacer lo siguiente para que el CAS responda mejor y, de este modo, las implementaciones sean más rápidas:
## Tamaños de escalado por pasos del proveedor de capacidad
Con el tiempo, los proveedores de capacidad de Amazon ECS aumentarán o reducirán las instancias de contenedor para satisfacer las demandas de su aplicación. La cantidad mínima de instancias que Amazon ECS lanzará se establece en 1 de forma predeterminada. Esto puede agregar tiempo adicional a las implementaciones si se necesitan varias instancias para realizar las tareas pendientes. Puede aumentar el valor de [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) mediante la API de Amazon ECS para aumentar el número mínimo de instancias que Amazon ECS reduce o escala horizontalmente cada vez. Un valor de [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) demasiado bajo puede limitar el número de instancias de contenedor que se escalan o reducen horizontalmente cada vez, lo que puede ralentizar las implementaciones.
**nota**
Actualmente, esta configuración solo está disponible mediante las API [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html) o [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html).
## Periodo de preparación de instancias
El periodo de preparación de instancias es el periodo de tiempo después del que una instancia de Amazon EC2 recién lanzada puede contribuir a las métricas de CloudWatch para el grupo de escalado automático. Después de que finaliza el periodo de preparación especificado, la instancia se contabiliza para las métricas agregadas del ASG y el CAS continúa con su siguiente iteración de cálculos para estimar la cantidad de instancias necesarias.
El valor predeterminado de [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod) es de 300 segundos, que puede configurar con un valor inferior mediante las API [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html) o [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) para lograr un escalado con mayor capacidad de respuesta.
## Capacidad sobrante
Si su proveedor de capacidad no tiene instancias de contenedor disponibles para colocar tareas, debe aumentar (escalar horizontalmente) la capacidad del clúster mediante el lanzamiento de instancias de Amazon EC2 sobre la marcha y esperar a que se inicien antes de poder lanzar contenedores en ellas. Esto puede reducir considerablemente la frecuencia de lanzamiento de las tareas. Dispone de dos opciones aquí.
En este caso, disponer de capacidad sobrante de Amazon EC2 ya lanzada y lista para ejecutar tareas aumentará la frecuencia efectiva de lanzamiento de tareas. Puede usar la configuración `Target Capacity` para indicar que desea mantener la capacidad sobrante en sus clústeres. Por ejemplo, si se establece el valor de `Target Capacity` en un 80 %, indica que el clúster necesita un 20 % de capacidad sobrante en todo momento. Esta capacidad sobrante puede permitir que cualquier tarea independiente se inicie inmediatamente, lo que garantiza que el lanzamiento de las tareas no se limite. La desventaja de este enfoque es el posible aumento de los costos derivados de mantener la capacidad sobrante de los clústeres.
Un enfoque alternativo que puede considerar es agregar margen de maniobra a su servicio, no al proveedor de capacidad. Esto significa que, en lugar de reducir la configuración `Target Capacity` para lanzar la capacidad sobrante, puede aumentar la cantidad de réplicas de su servicio al modificar la métrica de escalado de seguimiento de destino o los umbrales de escalado por pasos del escalado automático del servicio. Tenga en cuenta que este enfoque solo será útil para cargas de trabajo con picos de actividad, pero no tendrá ningún efecto cuando implemente nuevos servicios y pase de 0 a N tareas por primera vez. Para más información sobre las políticas de escalado relacionadas, consulte [Políticas de escalado de seguimiento de destino](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html) o [Políticas de escalado por pasos](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-stepscaling.html)