Configuração do acesso à VPC para que aplicações do EMR Sem Servidor se conectem aos dados
Você pode configurar aplicações do EMR Sem Servidor para se conectar aos seus armazenamentos de dados na VPC, como clusters do Amazon Redshift, bancos de dados do Amazon RDS ou buckets do Amazon S3 com endpoints da VPC. A aplicação do EMR Sem Servidor tem conectividade de saída com os armazenamentos de dados na VPC. Por padrão, o EMR Sem Servidor bloqueia o acesso de entrada às aplicações para melhorar a segurança.
nota
Você deve configurar o acesso à VPC se quiser usar um banco de dados externo do Hive Metastore para a aplicação. Para obter informações sobre como configurar uma metastore externa do Hive, Metastore configuration.
Criar aplicativo
Na página Criar aplicação, você pode escolher configurações personalizadas e especificar a VPC, as sub-redes e os grupos de segurança que as aplicações do EMR Sem Servidor podem usar.
VPCs
Escolha o nome da nuvem privada virtual (VPC) que contém os armazenamentos de dados. A página Criação de aplicações lista todas as VPCs da sua Região da AWS.
Sub-redes
Escolha as sub-redes na VPC que contém seu armazenamento de dados. A página Criação de aplicações lista todas as sub-redes dos armazenamentos de dados na VPC.
As sub-redes selecionadas devem ser sub-redes privadas. Isso significa que as tabelas de rotas associadas às sub-redes não devem ter gateways da Internet.
Para conectividade de saída com a Internet, as sub-redes devem ter rotas de saída usando um gateway NAT. Para configurar um gateway NAT, consulte Trabalhar com gateways NAT.
Para conectividade com o Amazon S3, as sub-redes devem ter um gateway NAT ou um endpoint da VPC configurado. Para configurar um endpoint da VPC do S3, consulte Criar um endpoint do gateway.
Para conectividade com outros Serviços da AWS fora da VPC, como o Amazon DynamoDB, você deve configurar os endpoints da VPC ou um gateway NAT. Para configurar endpoints da VPC de Serviços da AWS, consulte Work with VPC endpoints.
Os trabalhadores podem se conectar aos armazenamentos de dados na sua VPC por meio do tráfego de saída. Por padrão, o EMR Sem Servidor bloqueia o acesso de entrada aos trabalhadores para melhorar a segurança.
Quando você usa AWS Config, o EMR Sem Servidor cria um registro de item da interface de rede elástica para cada trabalhador. Para evitar custos relacionados a esse recurso, considere desligar AWS::EC2::NetworkInterface no AWS Config.
nota
Recomendamos selecionar várias sub-redes entre várias zonas de disponibilidade. Isso ocorre porque as sub-redes que você escolhe determinam as zonas de disponibilidade que estão disponíveis para a inicialização de uma aplicação do EMR Sem Servidor. Cada trabalhador consumirá um endereço IP na sub-rede em que é iniciado. Certifique-se de que as sub-redes especificadas tenham endereços IP suficientes para o número de trabalhadores que você planeja iniciar. Para obter mais informações sobre o planejamento de sub-redes, consulte Práticas recomendadas do planejamento de sub-redes.
Grupos de segurança
Escolha um ou mais grupos de segurança que possam se comunicar com seus armazenamentos de dados. A página Criação de aplicações lista todos os grupos de segurança na sua VPC. O EMR Sem Servidor associa esses grupos de segurança a interfaces de rede elástica anexadas às sub-redes da VPC.
nota
Recomendamos criar um grupo de segurança separado para aplicações do EMR Sem Servidor. Isso torna o isolamento e o gerenciamento das regras de rede mais eficientes. Por exemplo, para se comunicar com os clusters do Amazon Redshift, você pode definir as regras de tráfego entre os grupos de segurança do Redshift e do EMR Sem Servidor, conforme demonstrado no exemplo abaixo.
exemplo Exemplo: comunicação com clusters do Amazon Redshift
-
Adicione uma regra para tráfego de entrada ao grupo de segurança do Amazon Redshift em um dos grupos de segurança do EMR Sem Servidor.
Tipo Protocolo Intervalo de portas Origem Todos os TCP
TCP
5439
emr-serverless-security-group -
Adicione uma regra para o tráfego de saída em um dos grupos de segurança do EMR Sem Servidor. É possível fazer isso de duas formas. Primeiro, você pode abrir o tráfego de saída para todas as portas.
Tipo Protocolo Intervalo de portas Destination (Destino) Todo o tráfego
TCP
ALL
0.0.0.0/0
Como alternativa, você pode restringir o tráfego de saída para os clusters do Amazon Redshift. Isso é útil somente quando a aplicação precisa se comunicar com os clusters do Amazon Redshift e nada mais.
Tipo Protocolo Intervalo de portas Origem Todos os TCP
TCP
5439
redshift-security-group
Configuração de aplicações
Você pode alterar a configuração da rede de uma aplicação do EMR Sem Servidor existente na página Configuração de aplicações.
Exibição dos detalhes da execução do trabalho
Na página de Detalhes da execução do trabalho, você pode exibir a sub-rede usada pelo seu trabalho para uma execução específica. Observe que um trabalho é executado somente em uma sub-rede selecionada das sub-redes especificadas.
Práticas recomendadas do planejamento de sub-redes
Os recursos da AWS são criados em uma sub-rede que é um subconjunto de endereços IP disponíveis em uma Amazon VPC. Por exemplo, uma VPC com uma máscara de rede /16 tem até 65.536 endereços IP disponíveis que podem ser divididos em várias redes menores usando máscaras de sub-rede. Como exemplo, você pode dividir esse intervalo em duas sub-redes, cada uma usando a máscara /17 e 32.768 endereços IP disponíveis. Uma sub-rede reside dentro de uma zona de disponibilidade e não pode abranger várias zonas.
As sub-redes devem ser projetadas tendo em mente os limites de ajuste de escala da aplicação do EMR Sem Servidor. Por exemplo, se você tiver uma aplicação solicitando 4 trabalhadores de vCPU e puder aumentar a escala verticalmente para até 4.000 vCPUs, sua aplicação precisará de no máximo 1.000 trabalhadores para um total de 1.000 interfaces de rede. Recomendamos criar sub-redes em várias zonas de disponibilidade. Isso permite que o EMR Sem Servidor tente novamente seu trabalho ou provisione a capacidade pré-inicializada em uma zona de disponibilidade diferente em um evento improvável quando uma zona de disponibilidade falhar. Portanto, cada sub-rede em pelo menos duas zonas de disponibilidade deve ter mais de 1.000 endereços IP disponíveis.
Você precisa de sub-redes com tamanho de máscara menor ou igual a 22 para provisionar 1.000 interfaces de rede. Qualquer máscara maior que 22 não atenderá ao requisito. Por exemplo, uma máscara de sub-rede de /23 fornece 512 endereços IP, enquanto uma máscara de /22 fornece 1.024 e uma máscara de /21 fornece 2.048 endereços IP. Abaixo está um exemplo de 4 sub-redes com máscara de /22 em uma VPC de máscara de rede de /16 que podem ser alocadas para diferentes zonas de disponibilidade. Há uma diferença de cinco entre endereços IP disponíveis e utilizáveis porque os primeiros quatro endereços IP e o último endereço IP em cada sub-rede são reservados pela AWS.
| ID da sub-rede | Endereço de sub-rede | Máscara de sub-rede | Intervalo de endereços IP | Endereços IP disponíveis | Endereços IP utilizáveis |
|---|---|---|---|---|---|
|
1 |
10.0.0.0 |
255.255.252.0/22 |
De 10.0.0.0 a 10.0.3.255 |
1,024 |
1.019 |
|
2 |
10.0.4.0 |
255.255.252.0/22 |
De 10.0.4.0 a 10.0.7.255 |
1,024 |
1.019 |
|
3 |
10.0.8.0 |
255.255.252.0/22 |
De 10.0.4.0 a 10.0.7.255 |
1,024 |
1.019 |
|
4 |
10.0.12.0 |
255.255.252.0/22 |
De 10.0.12.0 a 10.0.15.255 |
1,024 |
1.019 |
Você deve avaliar se a workload é mais adequada para trabalhadores maiores. Usar trabalhadores maiores requer menos interfaces de rede. Por exemplo, usar trabalhadores de 16 vCPUs com um limite de ajuste de escala de aplicações de 4.000 vCPUs exigirá no máximo 250 trabalhadores para um total de 250 endereços IP disponíveis para provisionar interfaces de rede. Você precisa de sub-redes em várias zonas de disponibilidade com tamanho de máscara menor ou igual a 24 para provisionar 250 interfaces de rede. Qualquer tamanho de máscara maior que 24 oferece menos de 250 endereços IP.
Se você compartilha sub-redes em várias aplicações, cada sub-rede deve ser projetada tendo em mente os limites de ajuste de escala coletivo de todas as aplicações. Por exemplo, se você tiver 3 aplicações solicitando 4 trabalhadores de vCPU e cada um puder aumentar a escala verticalmente para até 4.000 vCPUs com uma cota baseada em serviço em nível de conta de 12.000 vCPUs, cada sub-rede exigirá 3.000 endereços IP disponíveis. Se a VPC que você deseja utilizar não tiver uma quantidade suficiente de endereços IP, tente aumentar a quantidade de endereços IP disponíveis. É possível fazer isso associando blocos de Encaminhamento Entre Domínios Sem Classificação (CIDR) com sua VPC. Para obter mais informações, consulte Associate additional IPv4 CIDR blocks with your VPC no Guia do usuário da Amazon VPC.
Você pode usar uma das muitas ferramentas disponíveis on-line para gerar rapidamente definições de sub-rede e analisar o intervalo disponível de endereços IP.
