AWS SnapStart - 부분 Lambda 계층을 사용하여 Java로 콜드 및 웜 스타트 측정(2)

소개

Java 21 Lambda 함수용 레이어 생성, 게시 및 사용 방법 블로그 게시물에서 Java 21을 사용하여 첫 번째 Lambda 레이어를 게시하는 방법을 설명했습니다. 기사에서 Lambda 레이어를 사용하여 Java 21의 콜드 스타트 ​​및 웜 스타트 측정(1) 이 Lambda 계층을 사용하여 애플리케이션을 생성한 다음 SnapStart를 활성화하지 않고 SnapStart를 활성화한 상태에서 콜드 및 웜 시작 시간을 측정하고 DynamoDB 호출 프라이밍 최적화를 적용하고 Lambda 계층을 사용하지 않고 POM 파일에 모든 종속성을 제공하지 않고 결과를 측정값과 비교합니다. 다양한 Lambda 메모리 설정을 사용하여 Java 21의 콜드 및 웜 스타트 측정 기사에서 이 작업을 수행했습니다. 이 기사에서는 모든 종속성을 포함하는 또 다른 Lambda 레이어를 생성하고 애플리케이션에서 이 레이어를 사용하여 동일한 측정을 수행하고 결과를 이전 실험과 비교할 것입니다.

모든 종속성이 있는 Lambda 계층을 사용하여 Java 21로 콜드 및 웜 스타트 측정

탐색을 위해 샘플 Lambda 계층을 사용하여 모든 종속성을 계층에 패키징하는 Java 21 런타임으로 Lambda 계층을 생성합니다.

• 다이나모드
• 람다
• 아파치 클라이언트
• aws-lambda-java-코어
• aws-lambda-java-이벤트
• org-crac
• slf4j-간단
• jackson-dataformat-xml

샘플 애플리케이션도 사용할 예정입니다. 기본적으로 AWS SAM 템플릿에는 API 게이트웨이 요청에 응답하고 DynamoDB의 API 게이트웨이에서 받은 ID로 제품을 검색하는 2개의 Lambda 함수가 정의되어 있습니다. 하나의 Lambda 함수 GetProductByIdWithPureJava21LambdaWithAllLayer는 SnapStart 유무에 관계없이 사용할 수 있으며 두 번째 함수 GetProductByIdWithPureJava21LambdaAndPrimingWithAllLayer는 SnapStart 및 DynamoDB 요청 호출 프라이밍을 사용합니다.

AWS SAM 템플릿의 Lambda 함수에 대해 이전에 생성된 모든 종속성과 함께 Lambda 계층을 사용하려면 다음과 같이 Lambda 함수에 Layers 매개변수를 추가해야 합니다.

    Type: AWS::Serverless::Function
    Properties:
      FunctionName: GetProductByIdWithPureJava21LambdaWithAllLayer
      AutoPublishAlias: liveVersion
      Layers:
        - !Sub arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:layer:aws-pure-java-21-common-lambda-layer:1
      Handler: software.amazonaws.example.product.handler.GetProductByIdHandler::handleRequest

계층 ARN(버전 포함)을 게시 계층 명령(awslambdaPublish-layer-version)의 출력인 자체 ARN으로 바꾸십시오.

pom.xml에서는 제공(첨부된 Lambda 레이어에 의해) 범위의 모든 종속성을 볼 수 있습니다.

아래 실험 결과는 약 1시간 동안 진행된 실험으로 100번 이상의 콜드 스타트와 약 100,000번의 웜 스타트를 재현한 결과입니다. 이를 위해(및 이전 기사의 실험) 부하 테스트 도구를 사용했지만 Serverless-artillery 또는 Postman과 같이 원하는 도구를 사용할 수 있습니다.
저는 Lambda 함수에 1024MB 메모리를 제공하고 환경 변수를 통해 다음 컴파일 옵션을 전달하여 이 모든 실험을 실행했습니다. JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1"(프로파일링 없이 클라이언트 컴파일).

아래 표에서는 다른 Lambda 메모리를 사용하여 Java 21의 콜드 및 웜 스타트 측정 문서에서 수행한 Lambda 레이어를 사용하지 않고(그리고 POM 파일에 모든 종속성 제공) 측정 결과를 제공할 것입니다. 일반 Lambda 레이어를 사용할 때의 설정과 측정값을 직접 비교해보세요.
약어 c는 Cold Start, w는 Warm Start를 의미합니다.

SnapStart가 없는 콜드(c) 및 웜(w) 시작 시간(ms):

프라이밍 없이 SnapStart를 사용한 콜드(c) 및 웜(w) 시작 시간(ms):

SnapStart 및 DynamoDB 호출 프라이밍(ms)을 사용한 콜드(c) 및 웜(w) 시작 시간:

결론

이 기사에서는 모든 종속성이 포함된 Lambda 계층을 사용하여 애플리케이션을 생성한 다음 SnapStart를 활성화하지 않고 SnapStart를 활성화한 상태에서 콜드 및 웜 스타트 시간을 측정하고 DynamoDB 호출 프라이밍 최적화를 적용한 후 결과를 Lambda를 사용하지 않고 측정값과 비교했습니다. 다양한 Lambda 메모리 설정과 공통 Lambda 계층을 사용하여 Java 21의 콜드 및 웜 스타트 측정 문서에서 수행한 계층(및 POM 파일에 모든 종속성 제공)을 수행했습니다.

결과에 약간의 편차가 있었지만 모든 종속성을 포함하는 Lambda 레이어를 사용하여 여러 번 측정한 후에도 추세는 항상 동일했습니다.

• SnapStart를 활성화하지 않았을 때 이 Lambda 레이어를 사용한 콜드 스타트는 최대 p90의 백분위수에 대해 Lambda 레이어를 사용하지 않은 것보다 최대 수백 밀리초 더 낮았습니다(놀랐습니다).
• SnapStart를 활성화했지만 DynamoDB 요청의 프라이밍을 사용하지 않는 경우 콜드 스타트는 모든 종속성이 있는 Lambda 계층을 선호하거나 백분위수에 따라 Lambda 계층을 전혀 사용하지 않는 Lambda를 선호하도록 다양합니다.
• DynamoDB 요청 프라이밍과 함께 SnapStart를 사용할 때 콜드 스타트는 두 사용 사례 모두에서 최대 p99까지의 백분위수에 대해 종료되었고 그 다음에는 모든 종속성이 있는 Lambda 계층을 사용할 때 p99.9 이상에 대해 더 높았습니다. 따라서 각 사용 사례에 따라 결과가 많이 달라졌습니다. 제가 항상 관찰한 것은 모든 종속성을 포함하는 Lambda 레이어를 사용할 때 모든 측정에서 결과의 범위가 상당히 컸고(p50과 최대 값 사이의 800-900ms 차이), Lambda 레이어를 전혀 사용하지 않을 때 동일한 범위가 훨씬 더 낮았다는 것입니다.
• 이 문서의 측정값을 일반 Lambda 레이어의 측정값과 비교할 때 처음 2번의 실험에서 Lambda 레이어의 모든 종속성을 사용하여 콜드 스타트가 더 낮았다는 것을 확인했습니다(SnapStart가 활성화되지 않고 SnapStart가 활성화되었지만 프라이밍이 적용되지 않음). SnapStart가 활성화되고 DynamoDB 호출이 준비된 경우.
• Lambda 함수의 웜 스타트/실행 시간은 모든 사용 사례에서 매우 가까웠습니다.

따라서 Lambda 레이어를 사용하면(여기에 무엇을 입력하고 무엇을 애플리케이션에 종속성으로 제공하는지에 따라) 예측 불가능성이 추가되므로 항상 직접 측정해야 합니다!

위 내용은 AWS SnapStart - 부분 Lambda 계층을 사용하여 Java로 콜드 및 웜 스타트 측정(2)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!