소개

Java용 AWS SDK가 포함된 Amazon Aurora Serverless v2용 데이터 API 시리즈 7부 - 데이터 API와 SnapStart의 만남에서는 Data를 사용하여 Amazon Aurora Serverless v2 PostgreSQL 데이터베이스에 연결하는 Lambda 함수의 콜드 시작 및 웜 시작 시간을 측정했습니다. 3가지 사용 사례에 대한 API:

• Lambda 함수에서 SnapStart가 활성화되지 않은 경우
• Lambda 함수에서 SnapStart를 활성화했지만 프라이밍 최적화는 사용하지 않음
• Lambda 함수에서 SnapStart가 활성화되고 프라이밍 최적화(PostgreSQL 데이터베이스에서 SQL 문 실행 전 준비)가 포함됩니다.

이 기사에서는 이러한 측정값을 Amazon Aurora Serverless v2용 데이터 API 대신 DynamoDB를 사용한 측정값과 비교하고 싶습니다.

Lambda 콜드 스타트와 웜 스타트 비교: Amazon Aurora Serverless v2와 DynamoDB용 데이터 API

Lambda SnapStart에 관한 기사 시리즈에서 우리는 이미 유사한 애플리케이션에 대해 이러한 측정을 수행했지만 다른 Lambda 메모리 설정을 사용하여 Java 21로 웜 스타트 측정 기사에서 설명했습니다.

Amazon Aurora Serverless v2와 DynamoDB용 두 애플리케이션 데이터 API는 매우 유사합니다.

• 데이터베이스에서 제품을 저장하고 검색하는 논리를 제공합니다.
• 두 프로젝트의 Lambda 함수에는 1024MB 메모리 설정이 있습니다.
• 배포 아티팩트 크기는 둘 다 약 18MB입니다.
• 두 프로젝트의 Lambda 함수는 기본 동기 HTTP Apache 클라이언트를 사용하여 데이터베이스와 통신합니다.
• 두 프로젝트의 Lambda 함수는 x86_64 아키텍처를 사용합니다.

이제 모든 측정값을 종합해 보겠습니다.

콜드(c) 및 웜(m) 시작 시간(ms):

결론

이 기사에서는 3가지 사용 사례에 대해 Data API를 사용하여 Amazon Aurora Serverless v2 PostgreSQL 데이터베이스에 연결하는 것과 DynamoDB 데이터베이스에 연결하는 Lambda 함수의 콜드 시작 및 웜 시작 시간 측정값을 비교했습니다.

• Lambda 함수에서 SnapStart가 활성화되지 않은 경우
• Lambda 함수에서 SnapStart를 활성화했지만 프라이밍 최적화는 사용하지 않음
• Lambda 함수에서 SnapStart를 활성화하고 데이터베이스 요청 프라이밍을 통해

우리가 관찰한 바에 따르면 Lambda 기능에서 SnapStart를 활성화하지 않은 콜드 스타트 ​​시간은 두 가지 모두 상당히 유사합니다. SnapStart가 활성화된 경우(특히 프라이밍 없이) Amazon Aurora Serverless v2용 데이터 API는 특히 백분위수가 90보다 큰 경우 콜드 스타트 ​​시간이 훨씬 더 높습니다. 이 차이를 이해하려면 더 깊이 파고들어야 합니다. 특히 프라이밍이 적용된 경우에는 그 정도가 클 것으로 예상됩니다. 아마도 그 이유는 DynamoDB와 같은 AWS 기본 서비스가 SnapStart를 더 잘 인식하여 연결 재개를 더 잘 처리할 수 있기 때문일 것입니다.

DynamoDB가 한 자릿수 또는 두 자릿수 밀리초의 응답 시간으로 알려져 있기 때문에 DynamoDB에 비해 Amazon Aurora Serverless v2용 데이터 API의 웜 스타트(실행) 시간이 지속적으로 훨씬 더 높았습니다.