소개

지금까지 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  
   ...

SnapStart를 개인에 대해서만 사용하고 모든 Lambda 함수를 사용하지 않으려면 전역 함수 수준이 아닌 Lambda 함수 수준에서 이 SnapStart 정의를 적용해야 합니다.

모든 Lambda 함수에는 시작점으로 다음 설정이 있습니다.

• 1024MB 메모리 설정
• DynamoDB 데이터베이스와 통신하는 데 사용되는 기본 HTTP Apache 클라이언트
• 콜드 시작 시간과 웜 시작 시간 사이에 매우 좋은 균형을 제공하는 것으로 입증된 Java 컴파일 옵션 "-XX: TieredCompilation -XX:TieredStopAtLevel=1"

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):

결론

이 기사에서는 3가지 사용 사례에 대해 DynamoDB 데이터베이스에 연결하는 Lambda 함수의 콜드 스타트 ​​및 웜 스타트 시간 측정값을 비교했습니다.

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

x86_64 아키텍처를 사용하면 arm64 아키텍처에 비해 콜드 시작 및 웜 시작 시간이 모두 짧아지는 것을 확인했습니다. 그러나 arm64 아키텍처 Lambda 가격은 x86_64 아키텍처보다 25% 저렴하므로 매우 흥미로운 비용 대비 성능 균형이 도입됩니다.

3가지 사용 사례 모두에 대한 측정:

• arm64 아키텍처를 사용한 Lambda 콜드 스타트 ​​시간은 많은 백분위수에서 x86_64 아키텍처에 비해 10~20%(매우 드문 경우에만 25~27%) 느렸습니다.
• arm64 아키텍처를 사용한 Lambda 웜 스타트 시간은 많은 백분위수에서 x86_64 아키텍처에 비해 5~10%만 느렸습니다.

따라서 이 샘플 애플리케이션에서는 arm64 아키텍처를 선택하는 것이 매우 합리적입니다. arm64 아키텍처에 대한 SnapStart 지원은 최근에야 도입되었으므로 앞으로 성능이 어느 정도 향상될 것으로 기대합니다. 사용 사례에 맞게 직접 측정해 보세요!

이 기사의 다음 부분에서는 동일한 성능 측정을 수행하지만 Lambda 메모리를 256MB와 2048MB 사이의 다른 값으로 설정하고 결과를 비교할 것입니다.