JVM Checkpoint Restore

The Spring Framework는 JVM과 함께 Spring 기반 Java 애플리케이션의 startup과 warmup 시간을 줄일 수 있는 시스템을 구현할 수 있도록 Project CRaC가 구현한 checkpoint/restore와 통합됩니다.

이 기능을 사용하려면 다음이 필요합니다:

• checkpoint/restore가 활성화된 JVM(현재는 Linux만 해당).
• classpath에 org.crac:crac 라이브러리(1.4.0 이상 버전이 지원됨)가 존재해야 합니다.
• -XX:CRaCCheckpointTo=PATH 또는 -XX:CRaCRestoreFrom=PATH와 같은 필요한 java 커맨드라인 매개변수를 지정해야 합니다.

주의

checkpoint가 요청될 때 -XX:CRaCCheckpointTo=PATH로 지정된 path에 생성되는 파일에는 실행 중인 JVM의 메모리 표현이 포함되어 있으며, 여기에는 secrets 및 기타 민감한 데이터가 포함될 수 있습니다. 이 기능을 사용할 때는 environment에서 오는 설정 프로퍼티와 같이 JVM이 "본" 모든 값이 해당 CRaC 파일에 저장된다고 가정해야 합니다. 그 결과, 이러한 파일이 생성, 저장 및 액세스되는 위치와 방식에 대한 보안 영향은 신중하게 평가해야 합니다.

개념적으로, checkpoint와 restore는 개별 beans에 대한 Spring Lifecycle contract와 일치합니다.

On-demand checkpoint/restore of a running application

예를 들어 jcmd application.jar JDK.checkpoint와 같은 커맨드를 사용하여 on demand로 checkpoint를 생성할 수 있습니다. checkpoint 생성 전에 Spring은 실행 중인 모든 beans를 중지하여, Lifecycle.stop을 구현함으로써 필요한 경우 리소스를 닫을 수 있는 기회를 제공합니다.

restore 이후에는 동일한 beans가 다시 시작되며, Lifecycle.start는 beans가 관련이 있을 때 리소스를 다시 열 수 있도록 합니다. Spring에 의존하지 않는 라이브러리의 경우, org.crac.Resource를 구현하고 관련 인스턴스를 등록하여 커스텀 checkpoint/restore 통합을 제공할 수 있습니다.

참고

실행 중인 애플리케이션의 checkpoint/restore를 활용하려면 일반적으로 파일이나 소켓과 같은 리소스를 사용하여 정상적으로 중지하고 시작하며, active 스레드를 중지하기 위한 추가 lifecycle 관리가 필요합니다.

참고

예를 들어 @Scheduled(fixedRate = 5000)과 같은 어노테이션으로 고정 주기로 스케줄링 작업을 정의할 때, on-demand checkpoint/restore로 JVM이 restore될 때 checkpoint와 restore 사이에 누락된 모든 실행이 수행된다는 점에 유의하십시오. 이것이 원하는 동작이 아니라면, 고정 지연(예: @Scheduled(fixedDelay = 5000))으로 작업을 스케줄링하거나, 매 작업 실행 이후에 계산되는 cron 표현식을 사용하는 것이 좋습니다.

참고

checkpoint가 warmed-up JVM에서 생성되면, restore된 JVM도 동일하게 warmed-up 상태가 되어 잠재적으로 즉시 peak 성능을 제공할 수 있습니다. 이 방법은 일반적으로 remote 서비스에 대한 액세스가 필요하므로, 일정 수준의 플랫폼 통합이 필요합니다.

Automatic checkpoint/restore at startup

-Dspring.context.checkpoint=onRefresh JVM 시스템 프로퍼티가 설정되면, startup 시 LifecycleProcessor.onRefresh phase 동안 checkpoint가 자동으로 생성됩니다. 이 phase가 완료된 후에는 모든 non-lazy initialized 싱글톤이 인스턴스화되고, InitializingBean#afterPropertiesSet 콜백이 호출되었지만, lifecycle은 시작되지 않았으며 ContextRefreshedEvent는 아직 publish되지 않은 상태입니다.

테스트 목적을 위해 -Dspring.context.exit=onRefresh JVM 시스템 프로퍼티를 활용할 수도 있는데, 이는 유사한 동작을 trigger하지만 checkpoint를 생성하는 대신 동일한 lifecycle phase에서 Project CraC 의존성/JVM이나 Linux 없이 Spring 애플리케이션을 종료합니다. 이는 beans가 시작되지 않았을 때 remote 서비스에 대한 커넥션이 필요한지 여부를 확인하고, 이를 피하기 위해 설정을 개선하는 데 유용할 수 있습니다.

주의

위에서 언급했듯이, 특히 CRaC 파일이 배포 가능한 아티팩트(예: 컨테이너 이미지)의 일부로 제공되는 use case에서는 JVM이 "본" 모든 민감한 데이터가 CRaC 파일에 저장된다고 가정하고, 관련 보안 영향을 신중하게 평가해야 합니다.

참고

Automatic checkpoint/restore는 application context가 시작되기 직전 phase까지 애플리케이션의 startup을 "fast-forward"하는 방법이지만, 완전히 warmed-up된 JVM을 제공하지는 않습니다.