Estoy ejecutando el comando sync para transferir datos entre mi instancia de EC2 y mi bucket de S3, pero la transferencia es lenta. ¿Cómo lo soluciono?

Descripción corta

El comando sync de la interfaz de la línea de comandos de AWS (AWS CLI) es un comando de alto nivel que incluye las llamadas a la API ListObjectsV2, HeadObject, GetObject y PutObject. Utiliza las siguientes secciones para identificar las causas de la transferencia lenta.

Resolución

Revisión de la arquitectura del caso práctico

Antes de probar la conectividad de la red, las velocidades de transferencia y las cargas de recursos, ten en cuenta los siguientes factores de arquitectura que pueden influir en la velocidad de transferencia:

• ¿Qué tipo de instancia de Amazon EC2 utilizas? Para este caso práctico de transferencia, se recomienda usar una instancia que tenga un rendimiento mínimo de 10 Gbps.
• ¿La instancia de EC2 y el bucket de S3 se encuentran en la misma región de AWS? Se recomienda desplegar la instancia y el bucket en la misma región. También se recomienda adjuntar un punto de enlace de VPC para Amazon S3 a la VPC en la que está desplegada la instancia.
• En el caso de las instancias y los buckets que se encuentran en la misma región, ¿la AWS CLI está configurada para usar el punto de enlace de la aceleración de transferencias de Amazon S3? Se recomienda no utilizar el punto de enlace de aceleración de transferencias si los recursos están en la misma región.
• ¿Cuál es la naturaleza del conjunto de datos de origen que deseas transferir? Por ejemplo, ¿estás transfiriendo muchos archivos pequeños o unos pocos archivos grandes a Amazon S3? Para obtener más información sobre el uso de la AWS CLI para transferir diferentes conjuntos de datos de origen a Amazon S3, consulta Getting the most out of the Amazon S3 CLI (Cómo aprovechar al máximo la CLI de Amazon S3).
• ¿Qué versión de la AWS CLI utilizas? Además, asegúrate de utilizar la versión más reciente de la AWS CLI.
• ¿Cuál es tu configuración de la AWS CLI?

Si sigues experimentando transferencias lentas después de seguir las prácticas recomendadas, comprueba la conectividad de la red, las velocidades de transferencia y la carga de recursos.

Comprobación de la conectividad de la red

Ejecuta el comando dig en el bucket de S3 y revisa el tiempo de respuesta a la consulta devuelto en el campo Tiempo de consulta. En el siguiente ejemplo, el tiempo de consulta es de 0 ms:

Bash

$ dig +nocomments +stats +nocmd awsexamplebucket.s3.amazonaws.com

;awsexamplebucket.s3.amazonaws.com. IN	A
awsexamplebucket.s3.amazonaws.com. 2400 IN CNAME	s3-3-w.amazonaws.com.
s3-3-w.amazonaws.com.	2	IN	A	52.218.24.66
;; Query time: 0 msec
;; SERVER: 172.31.0.2#53(172.31.0.2)
;; WHEN: Fri Dec 06 09:30:47 UTC 2019
;; MSG SIZE  rcvd: 87

Los tiempos de respuesta más prolongados para que las consultas de resolución del sistema de nombres de dominio (DNS) devuelvan una dirección IP pueden afectar al rendimiento. Si obtienes un tiempo de respuesta a la consulta más largo, prueba a cambiar los servidores DNS de tu instancia. Como otra prueba de conectividad de red, ejecuta traceroute o mtr mediante TCP para el nombre de host de estilo virtual y el punto de enlace regional de S3 de tu bucket. La solicitud del siguiente ejemplo de mtr se enruta a través de un punto de enlace de VPC para Amazon S3 que está adjunto a la VPC de la instancia:

Bash

$ mtr -r --tcp --aslookup  --port 443 -c50  awsexamplebucket.s3.eu-west-1.amazonaws.com
Start: 2019-12-06T10:03:30+0000
HOST: ip-172-31-4-38.eu-west-1.co Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    ???                 100.0    50    0.0   0.0   0.0   0.0   0.0
  2. AS???    ???                 100.0    50    0.0   0.0   0.0   0.0   0.0
  3. AS???    ???                 100.0    50    0.0   0.0   0.0   0.0   0.0
  4. AS???    ???                 100.0    50    0.0   0.0   0.0   0.0   0.0
  5. AS???    ???                 100.0    50    0.0   0.0   0.0   0.0   0.0
  6. AS???    ???                 100.0    50    0.0   0.0   0.0   0.0   0.0
  7. AS16509  s3-eu-west-1-r-w.am 62.0%    50    0.3   0.2   0.2   0.4   0.0

Prueba de la velocidad de carga y descarga desde Amazon S3

1.    Crea cinco archivos de prueba que contengan 2 GB de contenido:

Bash

$ seq -w 1 5 | xargs -n1 -P 5 -I % dd if=/dev/urandom of=bigfile.% bs=1024k count=2048

$ ls -l
total 10244
-rw-rw-r-- 1 ec2-user ec2-user 2097152 Nov 8 08:14 bigfile.1
-rw-rw-r-- 1 ec2-user ec2-user 2097152 Nov 8 08:14 bigfile.2
-rw-rw-r-- 1 ec2-user ec2-user 2097152 Nov 8 08:14 bigfile.3
-rw-rw-r-- 1 ec2-user ec2-user 2097152 Nov 8 08:14 bigfile.4
-rw-rw-r-- 1 ec2-user ec2-user 2097152 Nov 8 08:14 bigfile.5

2.    Ejecuta el comando sync con la AWS CLI para cargar los cinco archivos de prueba. Para obtener la hora de transferencia, inserta el comando time (de la documentación de Linux) al principio del comando sync:

Nota: Asegúrate de anotar también la velocidad de procesamiento mientras el comando de sincronización está en curso.

Bash

$ time aws s3 sync . s3://awsexamplebucket/test_bigfiles/ --region eu-west-1

Completed 8.0 GiB/10.2 GiB (87.8MiB/s) with 3 file(s) remaining

real 2m14.402s
user 2m6.254s
sys 2m22.314s

Puedes usar los resultados de estas pruebas como referencia para compararlos con la hora de la sincronización real en tu caso práctico.

Revisión de la carga de la red y los recursos mientras se ejecuta la sincronización como un proceso en segundo plano

1.    Añade & al final del comando sync para ejecutar el comando en segundo plano:

Nota: También puedes agregar un operador de transmisión (>) para escribir la salida en un archivo de texto que podrás revisar más adelante.

Bash

$ time aws s3 sync . s3://awsexamplebucket/test_bigfiles/ --region eu-west-1 \
> ~/upload.log &
[1] 4262
$

2.    Mientras el comando sync se ejecuta en segundo plano, ejecuta el comando mpstat (de la documentación de Linux) para comprobar el uso de la CPU. El siguiente ejemplo muestra que se están utilizando 4 CPU y que se utilizan alrededor del 20 %:

Bash

$ mpstat -P ALL 10
Average:     CPU    %usr   %nice    %sys   %iowait   %irq   %soft  %steal  %guest  %gnice  %idle
Average:     all   21.21    0.00   23.12    0.00    0.00    2.91    0.00    0.00    0.00   52.77
Average:       0   21.82    0.00   21.71    0.00    0.00    3.52    0.00    0.00    0.00   52.95
Average:       1   21.32    0.00   23.76    0.00    0.00    2.66    0.00    0.00    0.00   52.26
Average:       2   20.73    0.00   22.76    0.00    0.00    2.64    0.00    0.00    0.00   53.88
Average:       3   21.03    0.00   24.07    0.00    0.00    2.87    0.00    0.00    0.00   52.03

En este caso, la CPU no es el cuello de botella. Si ves porcentajes de utilización iguales o superiores al 90 %, intenta iniciar una instancia que tenga CPU adicionales. También puedes ejecutar el comando top para revisar los porcentajes de utilización de CPU más altos que se están ejecutando. Intenta detener esos procesos primero y, a continuación, vuelve a ejecutar el comando de sincronización.

3.    Mientras el comando sync se ejecuta en segundo plano, ejecuta el comando lsof (de la documentación de Linux). Esto comprueba cuántas conexiones TCP están abiertas a Amazon S3 en el puerto 443:

Nota: Si max_concurrent_requests se establece en 20 para el perfil de usuario en el archivo de configuración de la AWS CLI, espera ver un máximo de 20 conexiones TCP establecidas.

Bash

$ lsof -i tcp:443
COMMAND  PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
aws     4311 ec2-user    3u  IPv4  44652      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:33156->52.218.36.91:https (CLOSE_WAIT)
aws     4311 ec2-user    4u  IPv4  44654      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39240->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user    5u  IPv4  44655      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39242->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user    6u  IPv4  47528      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39244->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user    7u  IPv4  44656      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39246->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user    8u  IPv4  45671      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39248->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user   13u  IPv4  46367      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39254->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user   14u  IPv4  44657      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39252->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user   15u  IPv4  45673      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39250->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user   32u  IPv4  47530      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39258->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user   33u  IPv4  45676      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39256->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user   34u  IPv4  44660      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39266->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user   35u  IPv4  45678      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39260->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user   36u  IPv4  45679      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39262->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user   37u  IPv4  45680      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39268->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user   38u  IPv4  45681      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39264->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user   39u  IPv4  45683      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39272->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user   40u  IPv4  47533      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39270->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user   41u  IPv4  44662      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39276->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user   42u  IPv4  44661      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39274->52.216.162.179:https (ESTABLISHED)
aws     4311 ec2-user   43u  IPv4  44663      0t0  TCP ip-172-31-4-38.eu-west-1.compute.internal:39278->52.216.162.179:https (ESTABLISHED)

Si ves otras conexiones TCP en el puerto 443, intenta detenerlas antes de volver a ejecutar el comando sync.

Para obtener un recuento de las conexiones TCP, ejecuta este comando:

$ lsof -i tcp:443 | tail -n +2 | wc -l
21

4.    Una vez optimizado el proceso de sincronización único, puedes ejecutar varios procesos de sincronización en paralelo. Esto evita cargas más lentas en un solo proceso cuando hay un gran ancho de banda de la red disponible, pero solo se utiliza la mitad del ancho de banda de la red. Cuando ejecutes procesos de sincronización en paralelo, selecciona distintos prefijos para obtener el rendimiento deseado.

Para obtener más información, consulta ¿Cómo puedo optimizar el rendimiento al cargar grandes cantidades de datos a Amazon S3?