기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
인스턴스를 시작하거나 규모를 조정할 IP 주소가 충분하지 않은 경우
참고
퍼블릭 서비스의 경우 App Runner는에 탄력적 네트워크 인터페이스(ENI)를 생성하지 VPCs않으므로 퍼블릭 서비스는이 변경의 영향을 받지 않습니다.
이 가이드는 발신 트래픽에 대한 VPC 액세스가 활성화된 App Runner 서비스에서 발생할 수 있는 IP 소진 오류를 해결하는 데 도움이 됩니다.
App Runner는 VPC 커넥터와 연결된 서브넷에서 인스턴스를 시작합니다. App Runner는 인스턴스가 시작되는 서브넷에서 인스턴스ENI당 1개를 생성합니다. 각는 해당 서브넷에서 프라이빗 IP를 ENI 사용합니다. 서브넷에는 해당 서브넷과 연결된 CIDR 블록에 따라 사용 IPs 가능한 고정된 수의 서브넷이 있습니다. App Runner가를 생성하기IPs에 충분한 서브넷(들)을 찾을 수 없는 경우 App Runner 서비스에 대한 새 인스턴스를 시작ENI하지 못합니다. 이로 인해 서비스 확장에 문제가 발생할 수 있습니다. 이 경우 App Runner 이벤트 로그가 표시되며, 이는 App Runner가 사용 가능한가 있는 서브넷을 찾을 수 없음을 나타냅니다IPs. 아래 지침에 따라 서비스를 업데이트하여 이러한 오류를 해결할 수 있습니다.
더 많은 서비스를 사용할 수 있도록 서비스를 업데이트하는 방법 IPs
서브넷에서 사용할 수 있는 IP 주소 수는 해당 서브넷과 연결된 CIDR 블록을 기반으로 합니다. 서브넷과 연결된 CIDR 블록은 생성 후 업데이트할 수 없습니다. App Runner VPC 커넥터는 생성된 후에는 업데이트할 수 없습니다. IPs App Runner 서비스에 발신 트래픽에 대한 VPC 액세스 권한을 더 제공하려면 다음을 수행합니다.
-
CIDR 블록이 더 큰 새 서브넷(들)을 생성합니다.
-
새 서브넷(들)을 사용하여 새 VPC 커넥터를 생성합니다.
-
새 VPC 커넥터를 사용하도록 App Runner 서비스를 업데이트합니다.
서비스에 IPs 필요한 계산
더 큰 CIDR 블록으로 새 서브넷(들)을 생성하려고 하기 전에 App Runner 서비스 전체에서 IPs 필요한 수를 결정합니다. 다음과 같이 커넥터에 IPs 필요한 수를 계산하는 것이 좋습니다.
-
발신 트래픽에 대한 VPC 액세스가 활성화된 각 서비스에 대해 Auto Scaling 구성의 최대 크기(최대 인스턴스)를 기록해 둡니다.
-
모든 서비스에서 값을 합산합니다.
-
블루 그린 배포 중에 시작된 새 인스턴스를 설명하려면이 합계를 두 배로 늘립니다.
예제
동일한 VPC 커넥터를 사용하여 두 서비스 A와 B를 고려합니다.
-
서비스 A의 최대 크기는 25로 구성됩니다.
-
서비스 B의 최대 크기는 15로 구성됩니다.
필수 IPs = 2 × (25 + 15) = 80
서브넷에 사용 가능한 IPs 조합이 80개 이상 있는지 확인합니다.
새 서브넷(들) 생성
-
이 공식을 IPv4 사용하는 데 필요한 CIDR 블록 크기를 결정합니다(5IPs는 서브넷 AWS 크기 조정에서 예약됨).
Number of available IP addresses = 2^(32 - prefix length) - 5
Example : For 192.168.1.0/24: Prefix length is 24 Number of available IP addresses = 2^(32 - 24) - 5 = 2^8-5 = 251 IP addresses For 10.0.0.0/16: Prefix length is 16 Number of available IP addresses = 2^(32 - 16) - 5 = 2^16-5 = 65,531 IP addresses Quick reference: /24 = 251 IP addresses /16 = 65,531 IP addresses
-
를 사용하여 새 서브넷을 생성합니다AWSEC2CLI.
aws ec2 create-subnet --vpc-id <my-vpc-id> --cidr-block <cidr-block>
예제(4,096 로 서브넷 생성IPs):
aws ec2 create-subnet --vpc-id my-vpc-id --cidr-block 10.0.0.0/20
-
새 VPC 커넥터를 생성합니다. : VPC 액세스 관리 참조
-
이 새 VPC 커넥터를 사용하도록에서 송신 트래픽이 VPC 활성화된 상태로 서비스를 업데이트합니다. 서비스가 업데이트되면 App Runner가 새 서브넷 사용을 시작합니다.
참고
VPCs 또한 CIDR 블록별로 서브넷에 할당할 수 IPs 있는 사용 가능한 수로 제한됩니다. CIDR 블록이 더 큰 서브넷을 생성할 수 없는 경우 새 서브넷(들)을 생성하기 전에 보조 CIDR 블록VPC으로를 업데이트해야 할 수 있습니다.
에 보조 CIDR 블록 연결 VPC
보조 CIDR 블록을이에 연결합니다VPC.
aws ec2 associate-vpc-cidr-block --vpc-id <my-vpc-id> --cidr-block <cidr-block>
예 :
aws ec2 associate-vpc-cidr-block --vpc-id my-vpc-id --cidr-block 10.1.0.0/16
확인
서비스를 업데이트한 후 다음을 사용하여 수정 사항을 확인할 수 있습니다.
-
이벤트 로그 모니터링 : App Runner 서비스 이벤트 로그를 모니터링하여 새 IP 또는 ENI 비가용성 오류가 표시되지 않는지 확인합니다.
-
서비스 크기 조정 확인:
-
Autoscaling 구성에서 최소 인스턴스 수를 변경하여 서비스를 완전히 확장합니다.
-
모든 새 인스턴스가 IP 관련 오류 없이 시작되었는지 확인
-
여러 조정 이벤트를 통해 모니터링하여 일관된 성능 보장
-
-
콘솔 배너: AWS 관리 콘솔을 사용하는 경우 App Runner가 더 이상 부족에 대한 배너 경고를 표시하지 않는지 확인합니다IPs.
-
VPC 및 서브넷 IP 사용률:
-
VPC 대시보드 또는 CLI 명령을 사용하여 새 서브넷의 IP 주소 사용률을 확인합니다.
-
서비스가 스케일 업된 IPs 후에도 여전히 사용 가능한 정상 마진이 있는지 확인합니다.
-
일반적인 함정
App Runner 서비스에서 IP 소진을 해결할 때 다음과 같은 잠재적 문제를 염두에 두세요.
-
부적절한 IP 주소 계획: 향후 IP 요구 사항을 과소평가하면 반복적인 소진 문제가 발생할 수 있습니다. 잠재적 서비스 증가 및 사용량이 가장 많은 시나리오를 고려하여 철저한 용량 계획을 수행합니다.
-
VPC전체 IP 사용량 검토: 동일한 내의 다른 AWS 서비스VPC도 IP 주소를 사용한다는 점에 유의하세요. VPC 및 서브넷 구성을 계획할 때 모든 서비스의 IP 요구 사항을 고려합니다.
-
서비스 업데이트 무시: 새 서브넷 또는 VPC 커넥터를 생성한 후 새 구성을 사용하도록 App Runner 서비스를 업데이트해야 합니다. 이렇게 하지 않으면 소진된 IP 범위가 계속 사용됩니다.
-
CIDR 블록 오버랩의 오해:에 보조 CIDR 블록을 추가할 때 기존 블록과 겹치지 않도록 VPC합니다. CIDR 블록을 중첩하면 라우팅 충돌과 IP 주소 모호성이 발생할 수 있습니다.
-
VPC 한도 초과: 에는 최대 5개의 CIDR 블록(기본 블록 1개 및 보조 블록 4개)이 있을 VPC 수 있습니다. 이러한 제약 내에서 IP 주소 공간 확장을 계획합니다.
-
서브넷 AZ 배포 무시: 새 서브넷을 생성할 때 고가용성과 내결함성을 위해 여러 가용 영역에 분산되어 있는지 확인합니다.
-
한도 초과ENI: 인스턴스에 연결할 수 ENIs 있는 수에는 제한이 있습니다. AWS 계정 제한이 계획된 네트워크 인터페이스 사용량과 일치하는지 확인합니다.
이러한 위험을 인식하면 VPC 리소스를 더 효과적으로 관리하고 App Runner 서비스의 IP 소진 문제를 방지할 수 있습니다.
추가 리소스
용어집
-
ENI:Elastic Network Interface,의 가상 네트워크 인터페이스AWS.
-
CIDR:Classless 도메인 간 라우팅, IP 주소 할당 방법.
-
VPC 커넥터: App Runner가에 연결할 수 있게 해주는 리소스입니다VPC.