AWS Lambda의 Spring Boot 애플리케이션 - Spring Cloud 함수를 사용하여 콜드 및 웜 스타트 측정 부분

소개

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"
                      }
                      }
                    }
           """;
      }

API의 입력 스트림을 전달하여 HandleRequest 메소드를 호출하는 Spring Cloud Function FunctionInvoker 클래스를 사용하여 네트워크를 통하지 않고 전체 API 게이트웨이 요청을 프라이밍(프록시)하는 beforeCheckpoint 위와 같이 구성된 게이트웨이 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      

and we need to invoke Lambda function with name
GetProductByIdWithSpringBoot32SCFAndWebRequestPriming which is mapped to the GetProductByIdWithWebRequestPrimingHandler Lambda Handler Java class.

Abbreviation c is for the cold start and w is for the warm start.

Cold (c) and warm (w) start time in ms:

Scenario Number	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
No SnapStart enabled	4768.34	4850.11	4967.86	5248.61	5811.92	5813.31	7.16	8.13	9.53	21.75	62.00	1367.52
SnapStart enabled but no priming applied	2006.60	2065.61	2180.17	2604.69	2662.60	2663.54	7.45	8.40	9.92	23.09	1354.50	1496.46
SnapStart enabled with DynamoDB invocation priming	1181.40	1263.23	1384.90	1533.54	1661.20	1662.17	7.57	8.73	10.83	23.83	492.37	646.18
SnapStart enabled with API Gateway request invocation priming	855.45	953.91	1107.10	1339.97	1354.78	1355.21	8.00	9.53	12.09	26.31	163.26	547.28

Conclusion

By enabling SnapStart on the Lambda function alone, it reduces the cold start time of the Lambda function significantly. By additionally using DynamoDB invocation priming we are be able to achieve cold starts only slightly higher than cold starts described in my article AWS SnapStart -Measuring cold and warm starts with Java 21 using different memory settings where we measured cold and warm starts for the pure Lambda function without the usage of any frameworks including 1024MB memory setting like in our scenario.

Comparing the cold and warm start times we measured with AWS Serverless Java Container in the article Measuring cold and warm starts with AWS Serverless Java Container and Measuring cold and warm starts with AWS Lambda Web Adapter we observe that Spring Cloud Function offers higher cold start times than AWS Lambda Web Adapter but quite comparable cold start times to AWS Serverless Java Container (results vary slightly depending on the percentiles). In terms of warm start/execution times all 3 approaches have quite comparable results when especially looking into the percentiles below 99.9.

위 내용은 AWS Lambda의 Spring Boot 애플리케이션 - Spring Cloud 함수를 사용하여 콜드 및 웜 스타트 측정 부분의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!