Amazon Web Services 한국 블로그

AWS Lambda 함수의 VPC 기능 개선 – 함수 구동 속도 향상 및 효율적 ENI 사용

AWS Lambda 기능이 Amazon VPC 네트워크에서 작동하는 방식을 크게 개선했습니다. 오늘부터 함수 구동 성능이 향상되고 탄력적 네트워크 인터페이스(Elastic Network Interfaces)를 효율적으로 사용 가능합니다. 이러한 개선 사항은 추가 비용 없이 모든 기존 및 새로운 VPC 기능에 적용됩니다. 모든 리전에 걸쳐 향후 몇 개월 동안 점차적으로 사용 가능해 질 것입니다.AWS Lambda는 2016 년 2 월에 처음으로 VPC를 지원하여 AWS Direct Connect 링크를 사용하여 VPC 또는 온 프레미스 시스템의 리소스에 접근할 수 있습니다. 그 이후 많은 고객이 VPC 연결을 광범위하게 사용해 아래와 같은 서비스를 활용했습니다.

  • Amazon RDS와 같은 관계형 데이터베이스
  • Redis 용 Amazon ElastiCache 또는 Amazon Elasticsearch Service와 같은 데이터 스토어
  • Amazon EC2 또는 Amazon ECS에서 실행되는 다른 서비스

이제 AWS Lambda와 VPC 간의 연결 방식이 새롭게 바뀝니다.

Lambda와 VPC 이전 연결 모델

아래 그림은 Lambda와의 기존 네트워킹 작동 방식에 대한 몇 가지 기본 사항을 이해하는 데 도움이됩니다. 현재는 Lambda의 모든 컴퓨팅 인프라는 서비스가 소유 한 VPC 내에서 실행됩니다.Lambda runs in a VPC controlled by the service

호출 소스 및 실행 모델 (동기, 비동기 또는 Poll 기반)에서 Lambda 함수를 호출하면 Lambda API를 통해 발생합니다. 함수가 실행되는 실행 환경에 대한 직접적인 네트워크 액세스는 없습니다.Invoke access only through the Lambda API

기본적으로 Lambda 함수가 자신의 VPC에 연결되도록 구성되어 있지 않으면, 각 함수는 다른 AWS 서비스, API의 HTTPS 엔드 포인트 또는 AWS 외부의 서비스 및 엔드 포인트와 같은 퍼블릭 인터넷에서 사용 가능한 모든 것에 접근할 수 있습니다. 이러한 Lambda 함수는 VPC 내부의 개인 리소스에 연결할 수 없습니다.

Lambda 함수를 자신의 VPC에 연결하도록 구성하면 VPC에 탄력적 네트워크 인터페이스가 생성되고 계정 간 연결이 수행됩니다. 이러한 네트워크 인터페이스를 통해 Lambda 함수에서 개인 리소스로 네트워크에 접근할 수 있습니다. 이러한 Lambda 함수는 Lambda 서비스의 VPC 내에서 계속 실행되며 이제 VPC를 통해 네트워크를 통해서만 리소스에 액세스 할 수 있습니다.

함수에 대한 모든 호출은 Lambda 서비스의 API에서 계속 발생하며 여전히 실행 환경에 대한 직접 네트워크 액세스 권한이 없습니다. 연결된 네트워크 인터페이스는 계정 내에 존재하며 해당 리전의 계정에 존재하는 한도에 포함됩니다.

lambda mapped to a customer eni이 모델에서는 여러 가지 문제에 직면 할 수 있습니다. 예를 들어, 새로운 네트워크 인터페이스를 생성하고 연결하는 데 걸리는 시간으로 인해 콜드 스타트(Cold-start) 시간이 길어질 수 있으며 코드를 호출하기 전에 새로운 실행 환경을 가동하는 데 걸리는 시간이 늘어납니다.

요청 증가를 처리하기 위해 함수의 실행 환경이 확장됨에 따라 더 많은 네트워크 인터페이스가 생성되어 Lambda 인프라에 연결됩니다. 작성 및 연결된 네트워크 인터페이스의 정확한 수는 기능 구성 및 동시성의 요인입니다.

many ENIs mapped to Lambda environments해당 함수를 위해 생성 된 모든 네트워크 인터페이스는 VPC 서브넷의 IP 주소와 연결되어 IP 주소를 사용합니다. 계정 수준의 네트워크 인터페이스 최대 한도에 포함됩니다.

람다 함수가 확장됨에 따라 몇 가지 문제를 염두에 두어야합니다.

  • 서브넷에서 IP 주소 공간 관리
  • 계정 레벨 네트워크 인터페이스 한계에 도달
  • 새로운 네트워크 인터페이스 생성시 API 속도 제한에 도달 할 가능성

새로운 네트워크 모델

이제 Lambda 함수를 VPC에 연결되는 방식을 변경하였습니다. AWS Hyperplane은 Network Load Balancer 및 NAT 게이트웨이에 사용되는 Network Function Virtualization 플랫폼으로서, AWS PrivateLink와 같은 제품에 대한 VPC 간 연결을 지원했으며, Lambda VPC에서 고객 VPC에 이르는 NAT 기능을 제공합니다.

Hyperplane ENI는 Lambda 서비스가 제어하는 관리 네트워크 리소스이므로 여러 실행 환경에서 계정의 VPC 내부 리소스에 안전하게 액세스 할 수 있습니다. VPC의 네트워크 인터페이스를 Lambda 실행 환경에 직접 매핑하는 이전 솔루션 대신 VPC의 네트워크 인터페이스가 Hyperplane ENI에 매핑되고 이를 사용하여 함수를 연결하게 됩니다.VPC to VPC NAT

Hyperplane은 VPC에 존재하는 교차 계정 연결 네트워크 인터페이스를 사용하지만, 기능은 크게 개선되었습니다.

  • Lambda 함수가 생성되거나 해당 VPC 설정이 업데이트되면, 네트워크 인터페이스가 생성됩니다. 함수가 호출되면 실행 환경은 단순히 사전 작성된 네트워크 인터페이스를 사용하여 네트워크 터널을 신속하게 설정합니다. 이는 콜드 스타트시 네트워크 인터페이스 생성 및 연결과 관련된 이전의 대기 시간을 크게 줄입니다.
  • 네트워크 인터페이스는 실행 환경에서 공유되므로 일반적으로 기능 당 소수의 네트워크 인터페이스 만 필요합니다. 계정의 여러 기능에서 고유 한 모든 security group:subnet 조합에는 고유 한 네트워크 인터페이스가 필요합니다. 계정의 여러 기능에서 조합을 공유하는 경우 여러 기능에서 동일한 네트워크 인터페이스를 재사용합니다.
  • 함수 스케일링은 더 이상 다수의 네트워크 인터페이스에 직접 연결되지 않으며 하이퍼 플레인 ENI는 수많은 동시 함수 실행을 지원하도록 스케일링 할 수 있습니다.

하이퍼 플레인 ENI는 계정의 security group:subnet 조합에 연결되어 있습니다. 동일한 security group:subnet 페어링을 공유하는 동일한 계정의 기능은 동일한 네트워크 인터페이스를 사용합니다. 이러한 방식으로 여러 기능을 갖지만 동일한 네트워크 및 보안 구성을 가진 단일 응용 프로그램은 기존 인터페이스 구성의 이점을 얻을 수 있습니다.

이 새 모델에서는 몇 가지 사항이 변경되지 않습니다.

  • Lambda 기능에는 여전히 VPC에서 네트워크 인터페이스를 생성 및 삭제하는 데 필요한 IAM 권한이 필요합니다.
  • 네트워크 인터페이스의 서브넷 및 보안 그룹 구성을 제어합니다. 일반적인 네트워크 보안 제어를 계속 적용하고 VPC 구성에 대한 모범 사례를 따를 수 있습니다.
  • 인터넷에 연결하기 위해 VPC 엔드 포인트를 사용하여 VPC 외부의 서비스에 연결하려면 NAT 장치 (예 : VPC NAT 게이트웨이)를 사용해야합니다.
  • Lambda 함수가 VPC 내부에서 액세스 할 수 있는 리소스 유형에 대해서는 아무런 변화가 없습니다.

이제 Hyperplane은 Lambda 함수를 처음 만들거나 VPC 설정을 업데이트 할 때 공유 네트워크 인터페이스를 만들어 함수 성능과 확장성을 높이게 됩니다. 이 일회성 설정은 완료하는 데 최대 90 초가 걸릴 수 있습니다. 공유 네트워크 인터페이스가 생성되는 동안 Lambda 함수가 호출되면 호출은 계속 성공하지만 콜드 스타트 ​​시간이 길어질 수 있습니다. 설정이 완료되면 Lambda 함수는 더 이상 호출시 네트워크 인터페이스를 만들 필요가 없습니다. 계정의 Lambda 함수가 연속적으로 몇 주 동안 유휴 상태 인 경우 서비스는 사용되지 않는 Hyperplane 리소스를 회수하므로 매우 자주 호출되지 않는 함수는 여전히 콜드 스타트 ​​시간이 길어질 수 있습니다.

앞에서 언급했듯 신규 기능을 직접 활성화 할 필요가 없으며 추가 비용도 발생하지 않습니다. 오늘부터 향후 몇 개월간 모든 AWS 리전에서 점진적으로이를 배포합니다.

이제 기존 VPC 구성 Lambda 워크로드가 있는 경우 곧 애플리케이션이 확장되고 새로운 호출에 보다 신속하게 대응할 수 있습니다. AWS X-Ray와 같은 Lambda 또는 APN 파트너의 모니터링 및 프로파일 링 도구를 사용하여 이러한 변경 사항을 확인할 수 있습니다.

다음 스크린 샷은 AWS X-Ray로 촬영 한 전후 예제를 보여줍니다.

첫 번째는 VPC에서 시작된 기능이며, 호출시 네트워크 인터페이스 생성으로 전체 콜드 스타트 ​​기능을 제공합니다.

이 두 번째 이미지에서는 동일한 기능이 실행되었지만, 이번에는 새로운 VPC 네트워킹 기능이있는 계정에서 실행됩니다. 함수 실행 지속 시간에서 14.8 초에서 933ms로 큰 차이를 볼 수 있습니다!

마무리

AWS Lambda 팀에서는“Simplicity”를 고객을 위한 서비스 구축에 대한 생각의 중요하게 생각하고 있습니다. Lambda를 통해 서버리스 애플리케이션을 구축 할 때 경험을 개선하고 단순화 할 수있는 방법을 지속적으로 향상하고 있습니다. VPC와의 연결 방식에 대한 이러한 변화는 고객이 Lambda 함수의 성능과 규모를 향상시키는데 도움이 되기를 바랍니다.

– Chris Munns;

이 글은 AWS Compute Blog의 Announcing improved VPC networking for AWS Lambda functions 한국어 번역입니다.