기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
데이터에 연결하도록 EMR Serverless 애플리케이션에 대한 VPC 액세스 구성
Amazon Redshift 클러스터, Amazon RDS 데이터베이스 또는 VPC 엔드포인트가 있는 Amazon S3 버킷과 같은 VPC 내 데이터 저장소에 연결하도록 EMR Serverless 애플리케이션을 구성할 수 있습니다. EMR Serverless 애플리케이션에는 VPC 내 데이터 저장소에 대한 아웃바운드 연결이 있습니다. 기본적으로 EMR Serverless는 보안을 개선하기 위해 애플리케이션에 대한 인바운드 액세스를 차단합니다.
참고
애플리케이션에 외부 Hive 메타스토어 데이터베이스를 사용하려는 경우 VPC 액세스를 구성해야 합니다. 외부 Hive 메타스토어를 구성하는 방법에 대한 자세한 내용은 메타스토어 구성을 참조하세요.
애플리케이션 생성
애플리케이션 생성 페이지에서 사용자 지정 설정을 선택하고 EMR Serverless 애플리케이션에서 사용할 수 있는 VPC, 서브넷 및 보안 그룹을 지정할 수 있습니다.
VPC
데이터 저장소를 포함한 가상 프라이빗 클라우드(VPC) 이름을 선택합니다. 애플리케이션 생성 페이지에는 선택한 AWS 리전에 대한 모든 VPC가 나열됩니다.
서브넷
데이터 저장소를 포함하는 VPC 내 서브넷을 선택합니다. 애플리케이션 생성 페이지에는 VPC에 있는 데이터 저장소에 대한 모든 서브넷이 나열됩니다. 퍼블릭 서브넷과 프라이빗 서브넷이 모두 지원됩니다. 프라이빗 또는 퍼블릭 서브넷을 애플리케이션에 전달할 수 있습니다. 퍼블릭 서브넷을 사용할지 프라이빗 서브넷을 사용할지 여부를 선택할 때는 몇 가지 관련 고려 사항이 있습니다.
프라이빗 서브넷의 경우
연결된 라우팅 테이블에 인터넷 게이트웨이가 없어야 합니다.
인터넷에 대한 아웃바운드 연결의 경우 필요한 경우 NAT 게이트웨이를 사용하여 아웃바운드 경로를 구성합니다. NAT 게이트웨이를 구성하려면 NAT 게이트웨이를 참조하세요.
Amazon S3 연결의 경우 NAT 게이트웨이 또는 VPC 엔드포인트를 구성합니다. S3 VPC 엔드포인트를 구성하려면 게이트웨이 엔드포인트 생성을 참조하세요.
Amazon DynamoDB와 같이 VPC AWS 서비스 외부의 다른에 연결하려면 VPC 엔드포인트 또는 NAT 게이트웨이를 구성합니다. AWS 서비스에 대한 VPC 엔드포인트를 구성하려면 VPC 엔드포인트 작업을 참조하세요.
참고
프라이빗 서브넷에서 Amazon EMR Serverless 애플리케이션을 설정할 때는 Amazon S3에 대한 VPC 엔드포인트도 설정하는 것이 좋습니다. EMR Serverless 애플리케이션이 Amazon S3용 VPC 엔드포인트가 없는 프라이빗 서브넷에 있는 경우 S3 트래픽과 관련된 추가 NAT 게이트웨이 요금이 발생할 수 있습니다. 이는 VPC 엔드포인트가 구성되지 않은 경우 EMR 애플리케이션과 Amazon S3 간의 트래픽이 VPC 내에 유지되지 않기 때문입니다.
퍼블릭 서브넷의 경우
여기에는 Internet Gateway에 대한 경로가 있습니다.
아웃바운드 트래픽을 제어하려면 적절한 보안 그룹 구성을 보장해야 합니다.
작업자는 아웃바운드 트래픽을 통해 VPC 내 데이터 저장소에 연결할 수 있습니다. 기본적으로 EMR Serverless는 작업자에 대한 인바운드 액세스를 차단합니다. 이는 보안을 개선하기 위한 것입니다.
를 사용하면 AWS Config EMR Serverless는 모든 작업자에 대해 탄력적 네트워크 인터페이스 항목 레코드를 생성합니다. 이 리소스와 관련된 비용을 방지하려면 AWS::EC2::NetworkInterface 끄기를 고려해 보세요 AWS Config.
참고
여러 가용 영역에서 여러 서브넷을 선택하는 것이 좋습니다. 선택한 서브넷에 따라 시작할 EMR Serverless 애플리케이션에 사용할 수 있는 가용 영역이 결정되기 때문입니다. 각 작업자는 시작되는 서브넷에서 IP 주소를 사용합니다. 지정된 서브넷에 시작하려는 작업자 수에 충분한 IP 주소가 있는지 확인합니다. 서브넷 계획에 대한 자세한 내용은 서브넷 계획 모범 사례 섹션을 참조하세요.
서브넷에 대한 고려 사항 및 제한 사항
퍼블릭 서브넷이 있는 EMR Serverless는 AWS Lake Formation을 지원하지 않습니다.
퍼블릭 서브넷에는 인바운드 트래픽이 지원되지 않습니다.
보안 그룹
데이터 저장소와 통신할 수 있는 하나 이상의 보안 그룹을 선택합니다. 애플리케이션 생성 페이지에는 VPC에 있는 모든 보안 그룹이 나열됩니다. EMR Serverless는 이러한 보안 그룹을 VPC 서브넷에 연결된 탄력적 네트워크 인터페이스와 연결합니다.
참고
EMR Serverless 애플리케이션에 대해 별도의 보안 그룹을 생성하는 것이 좋습니다. 보안 그룹에 0.0.0.0/0 또는 ::/0 범위에서 퍼블릭 인터넷에 개방된 포트가 있는 경우 EMR Serverless는 애플리케이션을 생성/업데이트/시작할 수 없습니다. 이를 통해 보안 및 격리가 강화되고 네트워크 규칙 관리가 더욱 효율적입니다. 예를 들어, 이는 퍼블릭 IP 주소를 가진 작업자에 대한 예상치 못한 트래픽을 차단합니다. 예를 들어 Amazon Redshift 클러스터와 통신하려면 아래 예제와 같이 Redshift와 EMR Serverless 보안 그룹 간의 트래픽 규칙을 정의할 수 있습니다.
예제 - Amazon Redshift 클러스터와 통신
-
EMR Serverless 보안 그룹 중 하나에서 Amazon Redshift 보안 그룹에 인바운드 트래픽의 규칙을 추가합니다.
유형 프로토콜 포트 범위 소스 모든 TCP
TCP
5439
emr-serverless-security-group -
EMR Serverless 보안 그룹 중 하나의 아웃바운드 트래픽에 대한 규칙을 추가합니다. 이 작업은 두 가지 방법으로 수행할 수 있습니다. 먼저 모든 포트에 대한 아웃바운드 트래픽을 열 수 있습니다.
유형 프로토콜 포트 범위 대상 모든 트래픽
TCP
ALL
0.0.0.0/0
또는 아웃바운드 트래픽을 Amazon Redshift 클러스터로 제한할 수 있습니다. 이는 애플리케이션이 오직 Amazon Redshift 클러스터와 통신해야 하는 경우에만 유용합니다.
유형 프로토콜 포트 범위 소스 모든 TCP
TCP
5439
redshift-security-group
애플리케이션 구성
애플리케이션 구성 페이지에서 기존 EMR Serverless 애플리케이션의 네트워크 구성을 변경할 수 있습니다.
작업 실행 세부 정보 보기
작업 실행 세부 정보 페이지에서 특정 실행에 대해 작업에서 사용하는 서브넷을 볼 수 있습니다. 작업은 지정된 서브넷에서 선택한 하나의 서브넷에서만 실행됩니다.
서브넷 계획 모범 사례
AWS 리소스는 Amazon VPC에서 사용 가능한 IP 주소의 하위 집합인 서브넷에서 생성됩니다. 예를 들어, /16 넷마스크가 있는 VPC에는 서브넷 마스크를 사용하여 더 작은 여러 네트워크로 분할할 수 있는 최대 65,536개의 사용 가능한 IP 주소가 있습니다. 예를 들어, /17 마스크와 사용 가능한 IP 주소 32,768개를 사용하여 이 범위를 두 서브넷으로 분할할 수 있습니다. 서브넷은 가용 영역 내에 상주하며 여러 영역에 걸쳐 있을 수 없습니다.
서브넷은 EMR Serverless 애플리케이션 조정 제한을 염두에 두고 설계되어야 합니다. 예를 들어 vCpu 작업자 4개를 요청하는 애플리케이션이 있고 최대 4,000 개의 vCpu로 스케일 업할 수 있는 경우 애플리케이션에는 총 1,000개의 네트워크 인터페이스에 대해 최대 1,000개의 작업자가 필요합니다. 여러 가용 영역에서 서브넷을 생성하는 것이 좋습니다. 이를 통해 EMR Serverless는 가용 영역에서 장애가 발생한 경우 드물지만 다른 가용 영역에서 작업을 재시도하거나 사전 초기화된 용량을 프로비저닝할 수 있습니다. 따라서 두 개 이상의 가용 영역에 있는 각 서브넷에는 1,000개가 넘는 사용 가능한 IP 주소가 있어야 합니다.
1,000개의 네트워크 인터페이스를 프로비저닝하려면 마스크 크기가 22 이하인 서브넷이 필요합니다. 22보다 큰 마스크는 요구 사항을 충족하지 않습니다. 예를 들어 /23의 서브넷 마스크는 512개의 IP 주소를 제공하는 반면, /22의 마스크는 1,024개를 제공하고 /21의 마스크는 2,048개의 IP 주소를 제공합니다. 다음은 다른 가용 영역에 할당할 수 있는 /16 넷마스크의 VPC에 /22 마스크를 포함하는 4개의 서브넷에 대한 예제입니다. 각 서브넷의 처음 4개의 IP 주소와 마지막 IP 주소가 예약되어 있으므로 사용 가능한 IP 주소와 사용 가능한 IP 주소 간에는 5개의 차이가 있습니다 AWS.
| 서브넷 ID | 서브넷 주소 | 서브넷 마스크 | IP 주소 범위 | 사용 가능한 IP 주소 | 사용 가능한 IP 주소 |
|---|---|---|---|---|---|
|
1 |
10.0.0.0 |
255.255.252.0/22 |
10.0.0.0~10.0.3.255 |
1,024 |
1,019 |
|
2 |
10.0.4.0 |
255.255.252.0/22 |
10.0.4.0~10.0.7.255 |
1,024 |
1,019 |
|
3 |
10.0.8.0 |
255.255.252.0/22 |
10.0.4.0~10.0.7.255 |
1,024 |
1,019 |
|
4 |
10.0.12.0 |
255.255.252.0/22 |
10.0.12.0~10.0.15.255 |
1,024 |
1,019 |
더 큰 작업자 크기에 워크로드가 가장 적합한지 평가해야 합니다. 작업자 규모가 크면 필요한 네트워크 인터페이스가 더 적어집니다. 예를 들어 애플리케이션 조정 제한이 4,000개 vCpu인 16개의 vCpu 작업자를 사용하는 경우 네트워크 인터페이스를 프로비저닝하기려면 총 250개의 가용 IP 주소에 대해 최대 250개의 작업자가 필요합니다. 250개의 네트워크 인터페이스를 프로비저닝하려면 마스크 크기가 24 이하인 여러 가용 영역의 서브넷이 필요합니다. 마스크 크기가 24보다 크면 IP 주소가 250개 미만입니다.
여러 애플리케이션에서 서브넷을 공유하는 경우 각 서브넷은 모든 애플리케이션의 총 조정 제한을 염두에 두고 설계되어야 합니다. 예를 들어 vCpu 작업자 4개를 요청하는 애플리케이션이 3개이고 각각 12,000개의 vCpu 계정 수준 서비스 기반 할당량으로 최대 4,000개의 vCpu로 스케일 업할 수 있는 경우 각 서브넷에는 사용 가능한 3,000개의 IP 주소가 필요합니다. 사용하려는 VPC에 IP 주소가 충분하지 않은 경우 사용 가능한 IP 주소 수를 늘립니다. 이 작업은 해당 VPC를 통해 추가 Classless Inter-Domain Routing(CIDR) 블록을 연결하여 수행할 수 있습니다. 자세한 내용을 알아보려면 Amazon VPC 사용 설명서의 추가 IPv4 CIDR 블록을 VPC와 연결을 참조하세요.
온라인에서 사용할 수 있는 많은 도구 중 하나를 사용하여 서브넷 정의를 빠르게 생성하고 사용 가능한 IP 주소 범위를 검토할 수 있습니다.
