Graceful Redeploy 사용을 위한 전제 조건은 다음과 같다.

Graceful Redeploy를 수행할 때 다음의 사항을 반드시 고려해야 한다.

Graceful Redeploy는 redeploy 명령으로 사용 가능하다. 사용 방법은 실제 서비스 중에 발생할 수 있는 상황을 예로 들어서 설명한다.

먼저 다음과 같이 패키징된 WAR 파일들이 있다고 가정한다.

서비스 제공자는 2012년 5월 25일 오전에 지난 9일에 패키징해서 deploy했던 myservice.war에 문제점이 있다는 것을 발견했다. 그래서 이를 수정하여 오전 11시에 새로 패키징을 했다. 하지만 이미 myservice.war를 사용 중인 고객들이 있어서 JEUS를 중단시킬 수 없으므로 Graceful Redeploy를 사용하기로 결정했다.

이러한 상황에서 서비스 제공자는 콘솔 툴을 통해서 다음과 같은 명령을 수행한다.

redeploy myservice_war -path /path_to_new_application/myservice.war

redeploy 명령에 특별한 옵션을 주는 것이 아니라 META-INF/MANIFEST.MF 파일의 필드와 패키징 시간으로 JEUS에서 Graceful Redeploy 여부를 판단한다. 만약 2012년 5월 9일 오후 1시에 패키징한 애플리케이션의 META-INF/MANIFEST.MF 파일에 전제 조건에서 설명한 필드가 없거나 false로 지정되어 있다면 Normal Redeploy를 수행한다.

이전 버전 애플리케이션을 강제로 undeploy하는 방법

Graceful Redeploy가 성공적으로 완료된 시점을 기준으로 새로운 서비스 사용자(고객)는 새로운 myservice.war를 사용하게 된다. 기존 서비스 사용자는 계속 이전 버전 myservice.war를 사용한다. 기존 서비스 사용자와 새로운 서비스 사용자를 구분하는 기본적인 기준은 커넥션(소켓 연결)이다. 웹 애플리케이션의 경우에는 HTTP Session도 그 기준에 포함된다.

Graceful Redeploy의 기본 목적은 기존 서비스 사용자가 서비스 중단을 경험하지 않도록 하는 것이다. 따라서 이전 버전 myservice.war에 접근한 커넥션이나 그것을 통해 생성된 HTTP Session이 모두 사라질 때까지 이전 버전 myservice.war는 계속 undeploy되지 않는다. 만약 HTTP Session Timeout이 너무 길어서 일부 HTTP Session에 의해서 undeploy되지 않고 남아 있을 경우에는 서비스 관리자가 다음과 같이 undeply 명령을 수행해서 강제로 undeploy할 수 있다.

undeploy -old myservice_war

이전 버전 애플리케이션을 일정 시간이 지난 뒤 자동으로 undeploy하는 방법

이전 버전 myservice.war가 일정 시간 이상 지나면 자동으로 undeploy되게 할 수도 있다. redeploy 명령을 내릴 때 timeout 옵션을 지정한다. timeout 값의 단위는 초이다.

redeploy -path /path_to_new_application/myservice.war -to 5

이전 버전 애플리케이션과 새로운 애플리케이션이 동시에 존재할 때 이전 버전 애플리케이션으로 rollback하는 방법

이전 버전 myservice.war가 undeploy되지 않은 상황에서 서비스 제공자가 새로운 myservice.war에 문제점이 있음을 발견하였다. 이때 새로운 myservice.war를 undeploy하면 이전 버전 myservice.war로 rollback되어 정상적으로 서비스된다.

다음과 같이 undeploy 명령을 수행한다.

undeploy -new myservice_war

새로운 애플리케이션을 distribute만 하는 방법

새로운 myservice.war가 제대로 동작하는지 확인 후 실제로 사용자에게 제공하려면 redeploy 명령을 내릴 때 distribute만 하도록 지정한다.

redeploy myservice_war -path /path_to_new_application/myservice.war -distonly

새로운 애플리케이션에 대한 서비스 동작 여부를 미리 확인하는 방법은 각 애플리케이션 타입별로 다르다. 새로운 웹 애플리케이션에 대한 동작에 대한 자세한 설명은 절 2.2.4. “새로운 웹 애플리케이션에 대한 동작 여부를 미리 확인하는 방법”을 참고한다.

동작 확인을 한 뒤에 새로운 애플리케이션을 서비스하려면 start 명령을 실행한다.

start -new myservice_war

새로운 애플리케이션에 문제가 있어서 undeploy하려면 -new 옵션을 주고 undeploy 명령을 실행한다.

undeploy -new myservice_war

이전 버전 애플리케이션과 새로운 애플리케이션 모두 undeploy하는 방법

이전 버전 애플리케이션과 새로운 애플리케이션이 동시에 존재하는 경우에는 -old 또는 -new 옵션을 이용해서 어느 애플리케이션을 undeploy할지 명시적으로 설정해야 한다. 만약 두 애플리케이션을 모두 undeploy하려면 다음과 같이 -all 옵션을 지정해서 undeploy 명령을 수행한다.

undeploy -all myservice_war

이전 애플리케이션을 무조건 교체하는 방법

Graceful Redeploy 대신 무조건 Normal Redeploy를 수행할 경우에는 다음과 같이 redeploy 명령을 수행한다.

redeploy myservice_war -path /path_to_new_application/myservice.war -force

기존 웹 컨텍스트에서 제공하는 서비스의 중단 없이 새로운 웹 컨텍스트를 redeploy하는 기능이다.

일반적인 redeploy는 기존 웹 컨텍스트를 undeploy하기 때문에 그 과정에서 서비스 이용자가 웹 브라우저에서 에러 페이지를 보게 될 수 있다. 하지만 Graceful Redeploy는 기존 웹 컨텍스트에 대한 서비스 이용자가 있으면 이를 undeploy하지 않고 그대로 유지한 상태에서 새로운 웹 컨텍스트를 deploy한다. 일시적으로 기존 웹 컨텍스트와 새로운 웹 컨텍스트가 동시에 존재하게 된다.

기존 웹 컨텍스트의 서비스 이용자를 판별하는 기준은 현재 진행 중인 요청 존재 여부와 HTTP Session 존재 여부이다. 현재 진행 중인 요청들의 경우 DB 지연 문제나 오랫동안 수행하는 Async Processing이 아니라면 시간이 오래 걸릴 만한 사항이 없을 것이다. 하지만 HTTP Session의 경우 최소한 유후 tmeout만큼 남아있기 때문에 기존 웹 컨텍스트는 그 동안 undeploy되지 않는다. redeploy 수행자는 이런 점을 고려하여 기존 웹 컨텍스트에 대한 Undeploy Timeout을 줄 수 있으며, 명령을 통해서 강제로 undeploy할 수도 있다.

새로운 웹 컨텍스트가 성공적으로 서비스를 시작하면 새로운 요청은 더 이상 기존 웹 컨텍스트로 전달되지 않는다. 기존 웹 컨텍스트의 서비스 이용자는 Graceful Redeploy가 성공적으로 끝나기 이전에 접속한 클라이언트들이다.

새로운 웹 애플리케이션에 대한 동작 여부를 미리 확인하는 방법

JEUS에서는 새로운 웹 애플리케이션을 distribute만 해놓고 제대로 동작하는지 확인할 수 있는 방법을 제공한다. 새로운 웹 애플리케이션을 distribute만 하는 방법은 절 2.2.3. “새로운 애플리케이션을 distribute만 하는 방법”을 참고한다.

예제와 같이 myservice.war의 context path가 '/myservice'일 경우 웹 브라우저를 통해서 새로운 웹 애플리케이션을 distribute한 서버의 기본 포트로 HTTP 요청을 보내면 된다. 새로운 myservice.war를 distribute만 수행한 서버의 호스트 이름이 'host1'이고 기본 포트가 '9736'인 경우로 가정한다.

http://host1:9736/myservice/

EJB 애플리케이션의 Graceful Redeploy는 기존의 EJB 요청에 대한 처리를 보장하면서 새로운 EJB를 redeploy하는 기능이다. Graceful Undeploy와 마찬가지로 Session Bean에 대해서만 기능이 제공된다. 따라서 JAR 형식의 애플리케이션을 Graceful Redeploy하려면 해당 JAR는 Session Bean들로만 구성되어 있어야 한다.

Graceful Redeploy 시점을 기준으로 새로운 클라이언트는 새로운 EJB를 Lookup해서 사용하고, 기존 EJB를 사용하던 클라이언트는 사용자가 설정한 Timeout 동안은 요청 처리를 보장받는다. 또한 기존 EJB에 대한 요청 처리가 없다고 판단되면 Timeout 이전이라도 기존 EJB에 대한 Undeploy가 이루어진다.

요청 처리에 대한 판단 기준은 EJB의 종류에 따라 달라진다. Stateless Session Bean의 경우는 현재 진행 중인 요청을 기준으로 하고, Stateful Session Bean의 경우는 세션의 존재 여부로 판단한다. 즉, Stateful Session Bean의 경우에는 모든 세션이 destroy됐을 때 더 이상의 추가 요청이 없을 것이라고 판단하고 undeploy가 진행된다.

현재 JEUS에서는 성능 향상을 위해 내부적으로 클라이언트에 Home Stub과 EJB Object Stub을 캐시해서 사용하고 있다. 따라서 기존 EJB에 대한 정보를 캐시하고 있는 클라이언트의 경우 Graceful Redeploy 완료 시점 이후에는 기존의 캐시를 삭제하고 새로운 EJB에 대한 정보를 다시 받아와야 한다. EJB 3.x 의 경우에는 별도의 설정 없이도 자동으로 변경되지만 EJB 2.x의 경우에는 <use-dynamic-proxy-for-ejb2>가 true로 설정되어 있여야 정상 동작한다. (<use-dynamic-proxy-for-ejb2>의 기본값은 true이다.)

EAR 애플리케이션의 경우 EAR 안에 속한 WEB, EJB 모듈의 Graceful Redeploy를 보장한다. Standalone 모듈의 Graceful Redeploy와 마찬가지로 기본적으로 웹 모듈의 경우에는 컨텍스트의 세션이 만료될 때까지 이전 서비스를 보장해주고, 이전 Stateless Session Bean의 요청 처리와 Stateful Session Bean의 세션 만료시간까지의 이전 요청 처리를 보장해준다.

단, EAR 애플리케이션은 하나의 애플리케이션이기 때문에 EAR에 속한 하나의 EJB 모듈이 기존 요청 처리를 완료해도 다른 모듈의 이전 요청 처리가 진행 중이면 EJB 모듈을 내릴 수 없다. Graceful Undeploy와 마찬가지로 요청 처리가 끝나지 않은 이전 모듈 안에서 EJB 모듈로 요청할 수 있기 때문에 EAR 애플리케이션의 모든 요청이 정상적으로 처리되는 것을 보장해주려면 하나의 EJB 모듈이나 WEB 모듈만 내리는 것은 불가능하다. EAR 애플리케이션에 속한 모든 웹 모듈이나 EJB 모듈의 요청 처리가 완료되어야 이전 EAR 애플리케이션이 undeploy될 수 있다.