[Web Application Server] JEUS7 HotSwap 정의서

본 포스팅은 JEUS의 HotSwap 가이드입니다.

---

HotSwap은 개발자들이 Java EE 애플리케이션, 특히 웹 애플리케이션을 개발 할 때 서블릿 등의 클래스를 수정하는 경우가 많습니다. 이러한 개발 과정을 신속하게 수행하기 위해 많은 노력들이 진행되어져 왔고, Weblogic10.3에서는 FastSwap을 이용하여 이러한 재배포 과정을 줄이기 위한 기능을 제공합니다.

HotSwap에 대한 개요부터 살펴보겠습니다.

- JEUS HotSwap에 대해 정의 해보겠습니다. 

JEUS7에서는 기존의 클래스로더의 Reloading이 필요한 동적 반영(Auto Reload)을 포함하여, JDK Instrumentation Package를 이용합니다. 클래스로더의 Reloading 없이 Java 클래스의 재정의가 가능한 향상 된 클래스 동적 반영(Auto Reload) 기능입니다.

- JEUS HotSwap의 효율성은 다음과 같습니다.

어플리케이션 기능 변경 시, 전체 클래스를 리로드할 필요 없이 변경된 클래스만 재정의하여 개발 생산성을 획기적으로 향상시키는 기능입니다. 클래스 생성자 추가 및 제거, 메소드 바디 변경에 효과적으로 활용 가능합니다.

- JEUS6 이하 클래스 동적 반영 방법은 다음과 같습니다.

현재 JEUS6까지는 클래스를 수정한 뒤 수정된 클래스를 적용하려면 애플리케이션을 Redeploy를 하거나, Auto Reload 기능을 통해서 주기적 체크 또는 요청에 따라 클래스로더를 새로 생성하여 기존의 클래스 로더와 교체됩니다.

- JEUS6 이하 클래스 동적 반영의 문제점은 다음과 같습니다.

Redeploy 할 경우 애플리케이션의 크기가 크면 상당한 시간이 걸리는 작업이고, Auto Reload 기능 또한 클래스로더를 재 작성하기 때문에 redeploy 할 때 만큼 많은 부하 발생 합니다.

- 제약조건은 아래와 같습니다.

웹 애플리케이션의 클래스들만 한정하여 지원합니다. 

- 기존 Java EE의 제약조건은 다음과 같습니다.

이는 기존 jeus6이하에서 제공되지 못한 이유와 같습니다.

Java EE 5에서는 운영 중에 클래스로더를 내리거나 인스턴스를 종료하지 않고도 클래스를 재정의 하는 기능이 소개 되었지만 선언된 필드와 메소드의 변경은 불가능한 제약사항을 가지고 있었습니다.

JEUS HotSwap이 실제 동작 방식입니다.

설정 상 제약사항은 다음과 같습니다.

JEUS7 에서 domain.xml 의 <production-mode>true</production-mode> 설정하여 운영모드로 사용할 경우,  운영의 안정성을 위하여 auto-reload, hot swap 같은 기능이 제공되지 않습니다.

Production mode & Development mode의 비교를 잠시 다루고 넘어가겠습니다.

도메인을 어떻게 운영할지를 두 가지 모드를 통해 설정할 수 있습니다.

도메인 설정 파일에 운영 모드(Production mode)와 개발 모드(Development mode) 중 한가지 모드로 설정할 수 있습니다.

운영모드는 실제 운영환경에 적합한 모드로, 웹 애플리케이션의 auto-reload나 hot-swap과 같은 기능은 제공하지 않습니다.

애플리케이션 변경이 빈번하게 일어날 수 있는 개발단계에서는 개발모드로 설정해서 사용할 것을 권장하고, 실 운영계에서는 운영모드로 설정해서 사용할 것을 권장합니다.

모드 설정은 WebAdmin 이나 jeusadmin을 통해 설정변경이 지원되지 않는다. 따라서 도메인 설정파일을 직접 수정해야 합니다.

도메인 설정파일인 domain.xml에 production-mode 라는 항목을 true로 설정하면 운영모드로 동작하고, false로 설정하면 개발모드로 동작합니다.

이 설정을 변경하고 난 뒤에는 도메인에 운영중인 서버를 모두 내리고 재기동 해주어야 합니다.

설치 시 development를 선택하였을 경우 false를 기본 Setting 되며, Production Mode를 선택하였을 경우 domain.xml 파일을 직접 수정한 후 모든 서버를 재기동 해 주어야 합니다.

- 서버 설정 변경 사항입니다.

시스템 옵션으로 -Djeus.server.useHotSwapAgent=true 설정이 반영되어야 동작합합니다.

Auto Reload 기능을 설정하여 개발을 진행하고, 개발이 완료되면 위에서 설정한 옵션을 제거하여 운영할 때 이 기능을 사용하지 않도록 권고 합니다.

- 애플리케이션 설정 변경 사항입니다.

jeus-web-dd.xml 파일에 <auto-reload><use-jvm-hotswap>true</use-jvm-hotswap></auto-reload> 설정이 추가되어 야 합니다.

- 동작 방식입니다.

JEUS의 Auto Reload는 처음 애플리케이션이 배포된 후 클래스 수정이 발생한 기점을 기준으로 동작합니다.

<enable-reload>

Auto Reload 기능의 사용여부를 결정한다. <enable-reload>는 true로 설정되어 있어야 합니다. 

<use-jvm-hotswap>

true : 클래스 로더를 교체하지 않고, 변경된 클래스를 재정의(redefinition)하거나 클래스 재변환(retransformation)을 통해 변경 사항을 적용합니다. 만약 변경된 클래스들의 재정의 또는 재변환 시도 중 불가능한 클래스가 존재한다면 JEUS HotSwap 과정을 더 진행하지 않고, 기존의 Auto Reload 과정을 수행하여 변경 사항을 반영합니다.

false : JEUS HotSwap을 사용하지 않고, 애플리케이션의 클래스 로더를 교체하여 변경된 클래스를 적용합니다. 

<check-on-demand>

true : 요청이 들어왔을 때 바로 해당 애플리케이션의 클래스 로더를 기준으로 클래스의 마지막 수정시간을 검사하여 변경된 파일을 찾아내야 합니다. 파일을 검사하여 변경된 클래스가 존재할 경우 <use-jvm-hotswap>의 설정 여부에 따라 Auto Reload가 수행되야 합니다.

false : 'Check Class Reload' 설정에 따라 일정 주기마다(기본적으로 300초) 해당 애플리케이션 클래스 로더를 기준으로 클래스의 마지막 수정시간을 검사하여 변경된 파일을 찾아내야 합니다.

파일을 검사한 후 변경된 클래스가 존재하면 <use-jvm-hotswap>의 설정 여부에 따라 Auto Reload가 수행되야 합니다.

다음으로 테스트 방법에 대한 설명입니다.

더미 클래스를 3개 생성합니다.

이는 각각 Grand Parent, Parent, Child로 구성합니다.

Child은 Parent를 extend하고, Parent는 Grand Parent를 extend합니다. 

 

a. HotSwap False 시연 방법입니다.

- JEUS7에 생성한 application을 DEPLOY한다.

- 상단에 명시한 설정을 반영하지 않은 기본 상태로 클래스로더를 적용한다.

 

b. HotSwap True 시연 방법입니다.

- JEUS7에 생성한 application을 DEPLOY한다.

- 상단에 명시한 설정을 반영한 후 클래스로더를 적용한다.

 

c. 위 2가지 Case에 대한 비교 진행합니다.

- 소스 파일을 덮어 쓸 수 있는 백업 본을 준비한다.

- 첨부한 ClassInfo.jsp 를 활용하여 각각 클래스의 클래스로더가 변경되었는지 여부를 확인한다.

- 각각 LOG 비교한다.

- ClassInfo.jsp를 활용한 클래스로더 주소값을 비교한다.

- 테스트 진행 결과입니다.

1) ClassInfo.jsp를 활용한 클래스로더의 주소값 비교입니다.

jeus.server.userHotSwapAgent가 false 인 경우입니다.

-  ClassLoader의 Class 위치를 확인할 수 있는 JSP를 호출합니다.

-  Child 위치 확인한다. Child의 위치와 클래스로더의 주소 값을 확인할 수 있다.

현재 ContextLoader의 주소 값은 (15146334) 다음과 같습니다.

-  Child 클래스를 덮어 쓰고 다시 호출을 수행합니다.

-  Child 위치를 위와 같이 다시 확인한다.

Child의 위치와 클래스로더의 변경 된 주소 값을 확인할 수 있다.

변경 된 ContextLoader의 주소 값은 (16971202) 다음과 같습니다.

-  클래스로더의 주소 값이 변경 된 것은 클래스로더가 변경 된 것을 의미하므로 설정이 반영되지 않은 상황에서는 ClassLoader가 변경되는 것을 확인할 수 있습니다.

jeus.server.userHotSwapAgent가 true 인 경우입니다.

-  ClassLoader의 Class 위치를 확인할 수 있는 JSP를 호출합니다.

-  Child 위치 확인한다. Child의 위치와 클래스로더의 주소 값을 확인할 수 있다.

현재 ContextLoader의 주소 값은 (16618296) 다음과 같습니다.

-  Child 클래스를 덮어 쓰고 다시 호출을 수행합니다.

-  Child 위치를 위와 같이 다시 확인한다.

Child의 위치와 클래스로더의 변경 된 주소 값을 확인할 수 있다. 

변경 된 ContextLoader의 주소 값은 (16618296) 다음과 같습니다.

- 클래스로더의 주소 값이 변경되지 않고 유지 된것으로 보아 변경된 Class의 결과가 호출 되고 이와 동시에 Loader의 변경없이 유지 되는 것을 확인할 수 있습니다.

마지막으로 결론입니다. 지금까지 살펴본 사항을 정리해 보겠습니다.

- HotSwap을 활용하면 어플리케이션 기능 변경 시, 전체 클래스를 리로드할 필요 없이 변경된 클래스만 재정의하여 개발 생산성을 획기적으로 향상시키는 기능이 있다. 또한 클래스 생성자 추가 및 제거, 메소드 바디 변경에 효과적으로 활용 가능하다.
- 이러한 유용한 기능을 사용하기 위해서는 jeus-web-dd.xml, startDomainAdminServer, startManagedServer에 HotSwap을 사용하기 위한 옵션을 반영해야 한다.
- 정상 반영이 되었는지 여부를 확인하기 위해서는 LOG와 클래스로더의 주소값을 활용하여 확인이 가능하다.
- LOG를 통해 확인하기 위해서는 LOG LEVEL을 FINEST를 반영해야 확인이 가능하다.
- webadmin의 start-server를 활용하여 ms를 구동하였을 경우 useHotSwap 옵션이 반영되지 않는다.

고맙습니다.