소개

8부에서는 Spring Cloud 기능의 개념을 소개하고 9부에서는 Java 21 및 Spring Boot 3.2를 사용하여 Spring Cloud Function으로 AWS Lambda를 개발하는 방법을 시연했습니다. 이 시리즈 기사에서는 Lambda 함수에서 SnapStart를 활성화하는 것뿐만 아니라 DynamoDB 호출 프라이밍 및 네트워크를 통하지 않고 전체 API 게이트웨이 요청 프라이밍(프록시)과 같은 다양한 프라이밍 기술을 적용하는 것을 포함하여 콜드 및 웜 스타트 시간을 측정합니다. . 측정을 위해 Spring Boot 3.2 샘플 애플리케이션을 사용하고 모든 Lambda 함수에 대해 JAVA_TOOL_OPTIONS: "-XX: TieredCompilation -XX:TieredStopAtLevel=1"을 사용하고 Lambda 1024MB 메모리를 제공합니다.

Spring Cloud Function과 Java 21 및 Spring Boot 3.2를 사용하여 콜드 스타트 ​​및 웜 타임 측정

가장 큰 Lambda 성능(특히 콜드 스타트 ​​시간) 최적화 잠재력을 제공하는 Lambda 함수에서 AWS SnapStart를 활성화하는 방법부터 설명하겠습니다. 단지 구성 문제일 뿐입니다:

SnapStart:
  ApplyOn: PublishedVersions 

는 Lambda 함수 속성 또는 SAM 템플릿의 전역 함수 섹션에 적용됩니다. 우리 사용 사례에 맞게 SnpaStart 외에 다양한 프라이밍 기술을 사용하는 방법에 대해 더 자세히 알아보고 싶습니다. 내 기사 AWS Lambda SnapStart - 프라이밍 측정, 종단 간 지연 시간 및 배포 시간

1) DynamoDB 요청 프라이밍 코드는 여기에서 찾을 수 있습니다.

이 클래스는 CraC 프로젝트의 import org.crac.Resource 인터페이스를 추가로 구현합니다.

이 호출로

Core.getGlobalContext().register(this);

GetProductByIdWithDynamoDBRequestPrimingHandler 클래스는 자신을 CRaC 리소스로 등록합니다.

CRaC API의 beforeCheckpoint 메서드를 구현하여 DynamoDB 호출을 추가로 준비합니다.

      @Override
      public void beforeCheckpoint(org.crac.Context extends Resource> context) throws Exception {
             productDao.getProduct("0");
      }

Lambda 기능의 배포 단계와 Firecracker microVM 스냅샷이 생성되기 전에 호출됩니다.

2) 전체 API Gateway 요청에 대한 프라이밍 코드는 여기에서 확인할 수 있습니다.

이 클래스는 위의 예와 같이 import org.crac.Resource 인터페이스도 추가로 구현합니다.
우리는 내 기사 AWS Lambda SnapStart - Part 6 Priming the request invocation for Java 11 and Micronaut, Quarkus and Spring Boot Frameworks에서 설명한 추악한 기술을 다시 사용할 것입니다. 프로덕션에서는 이 기술을 사용하지 않는 것이 좋습니다. 그러나 Spring Boot와 Spring Cloud 함수 모델 및 DynamoDB도 수행하는 Lambda 모델 간의 매핑을 미리 로드하여 전체 API 게이트웨이 요청의 프라이밍을 사용하여 콜드 스타트를 줄일 수 있는 추가 가능성을 보여줍니다. 호출 프라이밍.

ID가 0인 /products/{id}의 API 게이트웨이 요청 구성 API 게이트웨이 JSON 요청은 다음과 같습니다.

      private static String getAPIGatewayRequestMultiLine () {
             return  """
                        {
                      "resource": "/products/{id}",
                      "path":  "/products/0",
                      "httpMethod": "GET",
                      "pathParameters": {
                            "id": "0" 
                        },
                       "requestContext": {
                          "identity": {
                        "apiKey": "blabla"
                      }
                      }
                    }
           """;
      }

beforeCheckpoint API의 입력 스트림을 전달하여 handlerRequest 메소드를 호출하는 Spring Cloud Function FunctionInvoker 클래스를 사용하여 네트워크를 거치지 않고 전체 API 게이트웨이 요청을 프라이밍(프록시)하는 경우 위와 같이 구성된 게이트웨이 JSON 요청:

@Override
public void beforeCheckpoint(org.crac.Context extends Resource> context) throws Exception {
            
new FunctionInvoker().handleRequest( 
  new ByteArrayInputStream(getAPIGatewayRequestMultiLine().
  getBytes(StandardCharsets.UTF_8)),
  new ByteArrayOutputStream(), new MockLambdaContext());
}

아래 실험 결과는 1시간 동안 1024MB 메모리 설정으로 Lambda 함수를 사용하여 100회 이상의 콜드 스타트와 약 100,000회 이상의 웜 스타트를 재현한 결과입니다. 이를 위해 부하 테스트 도구를 사용했지만 Serverless-artillery 또는 Postman과 같이 원하는 도구를 사용할 수 있습니다.

4가지 시나리오로 모든 실험을 실행했습니다.

1) SnapStart가 활성화되지 않았습니다.

template.yaml에서 다음 구성을 사용합니다.

    Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest    
      #SnapStart:
         #ApplyOn: PublishedVersions      

그리고 GetProductByIdHandler Lambda 핸들러 Java 클래스에 매핑된 GetProductByIdWithSpringBoot32SCF라는 이름으로 Lambda 함수를 호출해야 합니다.

2) SnapStart가 활성화되었지만 프라이밍이 적용되지 않았습니다.

template.yaml에서 다음 구성을 사용합니다.

    Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest 
    SnapStart:
      ApplyOn: PublishedVersions 

그리고 GetProductByIdHandler Lambda 핸들러 Java 클래스에 매핑된 GetProductByIdWithSpringBoot32SCF라는 이름으로 동일한 Lambda 함수를 호출해야 합니다.
3) DynamoDB 호출 프라이밍을 통해 SnapStart 활성화

template.yaml에서 다음 구성을 사용합니다.

    Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest    
    SnapStart:
      ApplyOn: PublishedVersions      

그리고 GetProductByIdWithDynamoDBRequestPrimingHandler Lambda 핸들러 Java 클래스에 매핑된 GetProductByIdWithSpringBoot32SCFAndDynamoDBRequestPriming 이름을 사용하여 Lambda 함수를 호출해야 합니다.

4) API Gateway 요청 호출 프라이밍/프록시로 SnapStart 활성화

template.yaml에서 다음 구성을 사용합니다.

    Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest
    SnapStart:
      ApplyOn: PublishedVersions      

그리고 이름이 있는 Lambda 함수를 호출해야 합니다
GetProductByIdWithWebRequestPrimingHandler Lambda 핸들러 Java 클래스에 매핑되는 GetProductByIdWithSpringBoot32SCFAndWebRequestPriming.

약어 c는 콜드 스타트를 나타내고 w는 웜 스타트를 나타냅니다.

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

결론

Lambda 함수에서만 SnapStart를 활성화하면 Lambda 함수의 콜드 스타트 ​​시간이 크게 단축됩니다. DynamoDB 호출 프라이밍을 추가로 사용하면 내 기사 AWS SnapStart - 순수 Lambda에 대한 콜드 및 웜 스타트를 측정한 다양한 메모리 설정을 사용하여 Java 21의 콜드 및 웜 스타트 측정에 설명된 콜드 스타트보다 약간 높은 콜드 스타트를 달성할 수 있습니다. 우리 시나리오와 같이 1024MB 메모리 설정을 포함한 프레임워크를 사용하지 않고도 작동합니다.

AWS 서버리스 Java 컨테이너로 콜드 및 웜 스타트 측정 및 AWS Lambda Web Adapter로 콜드 및 웜 스타트 측정 문서에서 AWS 서버리스 Java 컨테이너로 측정한 콜드 및 웜 스타트 시간을 비교하면 Spring Cloud 함수가 더 높은 콜드를 제공하는 것으로 나타났습니다. 시작 시간은 AWS Lambda Web Adapter와 비슷하지만 콜드 시작 시간은 AWS Serverless Java Container와 상당히 유사합니다(결과는 백분위수에 따라 약간 다름). 웜 스타트/실행 시간 측면에서 세 가지 접근 방식 모두 특히 99.9 미만의 백분위수를 조사할 때 상당히 비슷한 결과를 나타냅니다.