Configuración del acceso a la VPC para que las aplicaciones EMR sin servidor se conecten a los datos
Puede configurar las aplicaciones EMR sin servidor para que se conecten a los almacenes de datos de su VPC, como los clústeres de Amazon Redshift, las bases de datos de Amazon RDS o los buckets de Amazon S3 con puntos de conexión de VPC. Su aplicación EMR sin servidor tiene conectividad saliente con los almacenes de datos de su VPC. De forma predeterminada, EMR sin servidor bloquea el acceso entrante a sus aplicaciones para mejorar la seguridad.
nota
Debe configurar el acceso a la VPC si quiere utilizar una base de datos externa de un metaalmacén de Hive externo para su aplicación. Para obtener información sobre cómo configurar un metaalmacén de Hive externo, consulte Configuración de metaalmacén.
Crear aplicación
En la página Crear aplicación, puede elegir una configuración personalizada y especificar la VPC, las subredes y los grupos de seguridad que pueden usar las aplicaciones EMR sin servidor.
VPC
Seleccione el nombre de la nube privada virtual (VPC) que contenga los almacenes de datos. La página Crear aplicación enumera todas las VPC que haya elegido Región de AWS
Subredes
Seleccione las subredes dentro de la VPC que contenga el almacén de datos. La página Crear aplicación enumera todas las subredes de los almacenes de datos de la VPC.
Las subredes seleccionadas deben ser subredes privadas. Esto significa que las tablas de enrutamiento asociadas a las subredes no deben tener puertas de enlace de Internet.
Para la conectividad saliente a Internet, las subredes deben tener rutas salientes que utilicen una puerta de enlace NAT. Para configurar una puerta de enlace NAT, consulte Trabajar con puertas de enlace NAT.
Para la conectividad de Amazon S3, las subredes deben tener una puerta de enlace NAT o un punto de conexión de VPC configurado. Para configurar un punto de conexión de VPC de S3, consulte Crear un punto de conexión de puerta de enlace.
Para conectarse a otros Servicios de AWS externos a la VPC, como Amazon DynamoDB, debe configurar los puntos de conexión de la VPC o una puerta de enlace NAT. Para configurar puntos de conexión de VPCServicios de AWS, consulte Trabajar con puntos de conexión de VPC.
Los trabajadores pueden conectarse a los almacenes de datos de su VPC a través del tráfico saliente. De forma predeterminada, EMR sin servidor bloquea el acceso entrante a sus trabajadores para mejorar la seguridad.
Cuando usaAWS Config, EMR sin servidor crea un registro de elementos de la interfaz de red elástica para cada trabajador. Para evitar los costos relacionados con este recurso, considere la posibilidad de desactivar AWS::EC2::NetworkInterface en AWS Config.
nota
Recomendamos seleccionar varias subredes entre varias zonas de disponibilidad. Esto se debe a que las subredes que elija determinan las zonas de disponibilidad que están disponibles para que se lance una aplicación EMR sin servidor. Cada trabajador consumirá una dirección IP de la subred en la que se lance. Asegúrese de que las subredes especificadas tengan direcciones IP suficientes para la cantidad de trabajadores que planea lanzar. Para obtener más información sobre la planificación de subredes, consulte Prácticas recomendadas para la planificación de subredes.
Grupos de seguridad
Elija uno o varios grupos de seguridad que puedan comunicarse con sus almacenes de datos. La página Crear aplicación enumera todos los grupos de seguridad de la VPC. EMR sin servidor asocia estos grupos de seguridad con interfaces de red elástica que se asocian a sus subredes de VPC.
nota
Recomendamos crear un grupo de seguridad independiente para las aplicaciones EMR sin servidor. Esto hace que el aislamiento y la administración de las reglas de red sean más eficientes. Por ejemplo, para comunicarse con los clústeres de Amazon Redshift, puede definir las reglas de tráfico entre los grupos de seguridad Redshift y EMR sin servidor, como se muestra en el siguiente ejemplo.
ejemplo Ejemplo: comunicación con clústeres de Amazon Redshift
-
Agregue una regla para el tráfico entrante al grupo de seguridad de Amazon Redshift desde uno de los grupos de seguridad de EMR sin servidor.
Tipo Protocolo Intervalo de puertos Origen Todos los TCP
TCP
5439
emr-serverless-security-group -
Agregue una regla para el tráfico saliente desde uno de los grupos de seguridad de EMR sin servidor. Puede hacerlo de dos formas. En primer lugar, puede abrir el tráfico saliente a todos los puertos.
Tipo Protocolo Intervalo de puertos Destino Todo el tráfico
TCP
ALL
0.0.0.0/0
Como alternativa, puede restringir el tráfico saliente a los clústeres de Amazon Redshift. Esto solo resulta útil cuando la aplicación debe comunicarse con los clústeres de Amazon Redshift y nada más.
Tipo Protocolo Intervalo de puertos Origen Todos los TCP
TCP
5439
redshift-security-group
Configurar aplicación
Puede cambiar la configuración de red de una aplicación EMR sin servidor existente desde la página Configurar aplicación.
Ver los detalles de la ejecución del trabajo
En la página de Detalles de la ejecución del trabajo, puede ver la subred utilizada por el trabajo para una ejecución específica. Tenga en cuenta que un trabajo solo se ejecuta en una subred seleccionada desde las subredes especificadas.
Prácticas recomendadas para la planificación de subredes
Los recursos de AWS se crean en una subred que es un subconjunto de direcciones IP disponibles en una Amazon VPC. Por ejemplo, una VPC con una máscara de red /16 tiene hasta 65 536 direcciones IP disponibles que se pueden dividir en varias redes más pequeñas mediante máscaras de subred. Por ejemplo, puede dividir este rango en dos subredes, con cada una de las cuales usando una máscara /17 y 32 768 direcciones IP disponibles. Una subred reside en una zona de disponibilidad y no puede abarcar otras zonas.
Las subredes deben diseñarse teniendo en cuenta los límites de escalado de las aplicaciones EMR sin servidor. Por ejemplo, si tiene una aplicación que requiere 4 trabajadores de vCPU y puede escalarse hasta 4000 vCPU, su aplicación necesitará como máximo 1000 trabajadores para un total de 1000 interfaces de red. Recomendamos crear varias subredes entre varias zonas de disponibilidad. Esto permite a EMR sin servidor volver a intentar su trabajo o aprovisionar la capacidad preinicializada en una zona de disponibilidad diferente en el improbable caso de producirse un error en una zona de disponibilidad. Por lo tanto, cada subred de al menos dos zonas de disponibilidad debe tener más de 1000 direcciones IP disponibles.
Necesita subredes con un tamaño de máscara inferior o igual a 22 para aprovisionar 1000 interfaces de red. Cualquier máscara superior a 22 no cumplirá el requisito. Por ejemplo, una máscara de subred de /23 proporciona 512 direcciones IP, mientras que una máscara de /22 proporciona 1024 y una máscara de /21 proporciona 2048 direcciones IP. A continuación, se muestra un ejemplo de 4 subredes con una máscara de /22 en una VPC de máscara de red /16 que se puede asignar a diferentes zonas de disponibilidad. Hay una diferencia de cinco entre las direcciones IP disponibles y las utilizables porque las cuatro primeras direcciones IP y la última dirección IP de cada subred están reservadas por AWS.
| ID de subred | Dirección de subred | Máscara de subred | Rangos de direcciones IP | Direcciones IP disponibles | Direcciones IP utilizables |
|---|---|---|---|---|---|
|
1 |
10.0.0.0 |
255.255.252.0/22 |
10.0.0.0-10.0.3.255 |
1024 |
1019 |
|
2 |
10.0.4.0 |
255.255.252.0/22 |
10.0.4.0-10.0.7.255 |
1024 |
1019 |
|
3 |
10.0.8.0 |
255.255.252.0/22 |
10.0.4.0-10.0.7.255 |
1024 |
1019 |
|
4 |
10.0.12.0 |
255.255.252.0/22 |
10.0.12.0-10.0.15.255 |
1024 |
1019 |
Debe evaluar si su carga de trabajo es la más adecuada para trabajadores de mayor tamaño. El uso de trabajadores de mayor tamaño requiere menos interfaces de red. Por ejemplo, el uso de 16 trabajadores de vCPU con un límite de escalado de aplicaciones de 4000 vCPU requerirá como máximo 250 trabajadores para un total de 250 direcciones IP disponibles para aprovisionar las interfaces de red. Necesita subredes en varias zonas de disponibilidad con un tamaño de máscara inferior o igual a 24 para aprovisionar 250 interfaces de red. Cualquier tamaño de máscara superior a 24 ofrece menos de 250 direcciones IP.
Si comparte subredes entre varias aplicaciones, cada subred debe diseñarse teniendo en cuenta los límites de escalado colectivos de todas sus aplicaciones. Por ejemplo, si tiene 3 aplicaciones que solicitan 4 trabajadores de vCPU y cada una puede ampliarse hasta 4000 vCPU con una cuota basada en el servicio a nivel de cuenta de 12 000 vCPU, cada subred necesitará 3000 direcciones IP disponibles. Si la VPC que desea utilizar no tiene un número suficiente de direcciones IP, intente aumentar el número de direcciones IP disponibles. Puede hacerlo asociando bloques adicionales de enrutamiento entre dominios sin clase (CIDR) con su VPC. Para obtener más información, consulte Asociar bloques de CIDR IPv4 adicionales a su VPC en la Guía del usuario de Amazon VPC.
Puede utilizar una de las numerosas herramientas disponibles en línea para generar rápidamente definiciones de subredes y revisar su rango disponible de direcciones IP.
