지금까지는 arm64 아키텍처의 일부 사용 사례(예: DynamoDB 요청 생성)에 대해 Java 21 런타임을 사용하여 Lambda 함수의 성능(웜 스타트 및 콜드 스타트 시간)을 측정하지 않았습니다. 왜냐하면 SnapStart를 지원하지 않기 때문입니다. SnapStart가 활성화된 x86_64 아키텍처를 갖춘 Java 21 런타임을 사용하는 Lambda는 arm64 아키텍처를 사용하는 Lambda보다 성능이 뛰어납니다(추가 프라이밍 최적화를 사용하면 더욱 그렇습니다). 그러나 2024년 7월 18일, AWS는 AWS Lambda가 이제 ARM64 아키텍처를 사용하는 Java 기능용 SnapStart를 지원한다고 발표했습니다. 이제 Lambda 함수의 아키텍처 선택을 고려하여 콜드 및 웜 시작 시간을 측정하기 시작하는 것이 합리적입니다. 현재 AWS Lambda 요금 메모리 설정 및 실행 기간을 기준으로 arm64 아키텍처를 사용하는 Lambda는 대략 100% 정도인 것으로 알려져 있습니다. x86_64 아키텍처를 사용하는 Lambda보다 25% 저렴합니다.
저는 이에 대해 별도의 기사 시리즈를 만들기로 결정했고, 점점 늘어나는 AWS Lambda SnapStart 시리즈에 이 주제를 추가하지 않기로 결정했습니다.
실험에서는 AWS Lambda SnapStart - Java 21 Lambda 콜드 스타트 측정 문서에 소개된 애플리케이션을 재사용하겠습니다. 다음은 샘플 애플리케이션의 코드입니다. 기본적으로 API Gateway 요청에 응답하여 지정된 ID(PutProductFunction Lambda 함수 참조)로 제품을 생성하고 지정된 ID(GetProductByIdFunction Lambda 함수 참조)로 제품을 검색하는 2개의 기본 Lambda 함수가 있습니다. SnapStart를 활성화하거나 활성화하지 않고 Lambda 함수를 모두 사용할 수 있습니다. SnapStart 지원 Lambda 함수에 대한 DynamoDB 요청 프라이밍 효과를 독립적으로 측정하기 위해 작성한 추가 Lambda 함수 GetProductByIdWithPrimingFunction이 있습니다. 내 기사 AWS Lambda SnapStart - 프라이밍, 엔드 투 엔드 지연 시간 및 배포 시간 측정에서 프라이밍 효과에 대해 자세히 알아볼 수 있습니다.
모든 Lambda 함수에서 SnapStart를 활성화하려면 SAM 템플릿에서 다음 주석을 제거하십시오.
Globals: Function: CodeUri: target/aws-pure-lambda-snap-start-21-1.0.0-SNAPSHOT.jar ... SnapStart: ApplyOn: PublishedVersions ...
모든 Lambda 함수가 아닌 개인에 대해서만 SnapStart를 사용하려면 전역 함수 수준이 아닌 Lambda 함수 수준에서 이 SnapStart 정의를 적용해야 합니다.
모든 Lambda 함수의 시작점은 다음과 같습니다.
SAM 템플릿에서 다음과 같이 전역 Lambda 함수 섹션에 Lambda 아키텍처를 정의할 수 있는 기능을 추가했습니다.
Globals: Function: CodeUri: target/aws-pure-lambda-snap-start-21-1.0.0-SNAPSHOT.jar ... Architectures: #- arm64 - x86_64
Lambda 함수에 사용하려는 아키텍처의 주석 처리를 제거하세요.
Java가 "한 번 작성하면 어디에서나 실행 가능"하더라도 이전에 설치한 Graviton 프로세서(arm64/aarch64 아키텍처 기반)가 있는 t4g AWS EC2 인스턴스에서 arm64 측정을 위한 애플리케이션 jar 파일을 컴파일하고 빌드했습니다. Linux aarch64용 Amazon Corretto 21. 이 항아리는 여기서 찾을 수 있습니다.
또한 x86_64 아키텍처에 대한 모든 것을 다시 한 번 재측정하여 측정 당시 Java 21.v17이었던 동일한 Corretto Java 21 최신 런타임 버전을 사용하여 비슷한 결과를 얻었습니다.
아래 실험 결과는 100번 이상의 콜드 스타트와 약 100,000번의 웜 스타트를 재현한 결과입니다. 이를 위해(및 이전 기사의 실험) 부하 테스트 도구를 사용했지만 Serverless-artillery 또는 Postman과 같이 원하는 도구를 사용할 수 있습니다. 또한 애플리케이션의 새로운 소스 코드를 (재) 배포한 직후에 측정을 시작했다는 점을 아는 것도 중요합니다. 스냅샷 계층형 캐시가 콜드 스타트에 미치는 영향도 있습니다. 이 경우 첫 번째 호출은 일반적으로 느려지고 후속 호출은 특정 호출 수에 도달할 때까지 더 빨라집니다.
이제 "기존 ID로 제품 가져오기"(SnapStart 활성화 및 프라이밍 측정을 위한 Lambda 함수 GetProductByIdFunction 및 GetProductByIdWithPrimingFunction) 사례에 대한 모든 측정값을 함께 모아 보겠습니다.
콜드(c) 및 웜(m) 시작 시간(ms):
Approach | c p50 | c p75 | c p90 | c p99 | c p99.9 | c max | w p50 | w p75 | w p90 | w p99 | w p99.9 | w max |
---|---|---|---|---|---|---|---|---|---|---|---|---|
x86_64, no SnapStart enabled | 3554.30 | 3615.21 | 3666.15 | 3800.47 | 4108.61 | 4111.78 | 5.42 | 6.01 | 6.88 | 14.09 | 40.98 | 1654.59 |
arm64, no SnapStart enabled | 3834.81 | 3904.42 | 3983.26 | 4047.47 | 4332.13 | 4335.74 | 5.96 | 6.66 | 7.69 | 16.01 | 43.68 | 1844.54 |
x86_64, SnapStart enabled without priming | 1794.09 | 1846.86 | 2090.54 | 2204.27 | 2239.80 | 2240.08 | 5.37 | 5.96 | 6.93 | 15.88 | 51.64 | 1578.34 |
arm64, SnapStart enabled without priming | 1845.01 | 1953.18 | 2591.70 | 2762.91 | 2793.45 | 2795.8 | 5.91 | 6.56 | 7.63 | 16.75 | 63.52 | 1779.14 |
x86_64, SnapStart enabled with DynamoDB request priming | 803.18 | 870.18 | 1103.78 | 1258.19 | 1439.95 | 1440.67 | 5.55 | 6.25 | 7.45 | 15.50 | 63.52 | 448.85 |
arm64, SnapStart enabled with DynamoDB request priming | 910.14 | 1001.79 | 1376.62 | 1623.44 | 1684.60 | 1686.19 | 6.05 | 6.72 | 7.81 | 16.66 | 74.68 | 550.59 |
이 기사에서는 3가지 사용 사례에 대해 DynamoDB 데이터베이스에 연결하는 Lambda 함수의 콜드 시작 및 웜 시작 시간 측정값을 비교했습니다.
x86_64 아키텍처를 사용하면 arm64 아키텍처에 비해 콜드 및 웜 시작 시간이 모두 단축되는 것을 확인했습니다. 그러나 arm64 아키텍처 Lambda 가격은 x86_64 아키텍처보다 25% 저렴 매우 흥미로운 비용 대비 성능 균형을 도입합니다.
3가지 사용 사례 모두에 대한 측정:
따라서 arm64 아키텍처를 선택한 것은 이 샘플 애플리케이션에 매우 합리적입니다. arm64 아키텍처에 대한 SnapStart 지원은 최근에야 도입되었으므로 앞으로 성능이 어느 정도 향상될 것으로 기대합니다. 사용 사례에 맞게 직접 측정해 보세요!
이 기사의 다음 부분에서는 동일한 성능 측정을 수행하지만 Lambda 메모리를 256MB와 2048MB 사이의 다른 값으로 설정하고 결과를 비교할 것입니다.
위 내용은 Java xvs arm을 사용한 AWS Lambda 성능 - 부분 초기 측정의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!