내용 목차
본 장에서는 EJB 엔진에 대한 기초적인 사항과 JEUS EJB의 최상위 레벨의 개념인 구조, 설정, 운영, 모니터링과 튜닝에 대해 설명한다.
EJB 엔진은 EJB의 운영 환경을 제공한다. 본 안내서에서 사용한 EJB 엔진은 EJB 표준에서 사용하는 EJB 컨테이너라는 용어와 동일한 개념이다. EJB 모듈, EJB deploy에 대한 상세한 정보는 각각 “제3장 EJB 모듈”과 “제4장 EJB의 공통 특성”을 참고한다.
다음은 EJB 엔진의 주요 기능에 대한 설명이다.
하나의 MS에는 하나의 EJB 엔진이 존재한다. 그러나 하나의 도메인에는 여러 개의 MS가 존재할 수 있기 때문에 하나의 도메인에 여러 개의 EJB 엔진이 존재할 수 있다.
일반적으로 여러 개의 머신이나 CPU 위에 여러 개의 MS에 EJB 엔진이 설정되고, DAS에 의해 MS는 클러스터로 묶이는데 이러한 설정을 EJB 클러스터링이라고 한다. 이 구조는 시스템의 성능 향상과 높은 안정성 및 보안성을 유지해주는 효율적인 시스템 구조이다. EJB 클러스터링에 대한 자세한 내용은 “제6장 EJB 클러스터링”을 참고한다.
EJB 엔진 기본 설정
EJB 엔진은 domain.xml의 <ejb-engine>에서 설정한다. 자세한 내용은 “2.4. EJB 엔진 설정”을 참고한다.
EJB 엔진 Logging
domain.xml의 설정에 따라 MS에 로그를 남길 수 있지만 특별히 EJB 엔진의 로그(jeus.ejb)만 별도로 남길 수 있다. 이때 EJB 엔진 로그를 별도로 남기더라도 MS 로그에는 EJB 엔진 로그가 남는다.
Logger의 핸들러에 파일 핸들러가 지정되면 지정한 파일명으로 로그 파일이 생성된다. 또한, 콘솔 핸들러를 사용하면 모든 로그 메시지를 화면에 남길 수도 있다. 일반적으로 이런 상황에서는 로그 메시지가 파이프를 통하여 MS가 시작된 Command 화면에 출력된다.
그 외에 사용자가 생성한 사용자 핸들러를 등록할 수 있다. 자세한 설명은 ????을 참고한다.
Active Management는 EJB 모듈에 문제가 발생한 경우에 EJB 엔진이 자체적으로 이메일(e-mail)로 통지를 보내주는 기능이다.
예를 들어 Bean 클래스의 잘못된 구현으로 인해서 무한 루프에 빠지거나 Deadlock과 같은 심각한 오류가 발생했을 때 EJB 엔진이 이를 감지하여 통지를 보내주도록 되어 있다. 부가적으로 오류 처리 정책을 설정할 수 있어서 비정상적인 현상이 발생한 경우에 이메일 통지뿐만 아니라 해당 EJB 엔진이 동작하는 MS를 자동으로 재시작시킬 수도 있다. Active Management에 대한 자세한 설정은 “2.4. EJB 엔진 설정”을 참고한다.
원격 클라이언트가 JNDI 서비스를 통해서 EJB 인스턴스를 찾을 때 클라이언트는 EJB 메소드를 호출할 수 있는 RMI Stub을 받는다. 기본적으로 Stub은 RMI 런타임을 통해서 EJB와 원격 통신이 이루어지며, RMI 통신은 TCP 소켓을 기반으로 하고 있다. 이 방식은 RMI 통신 포트를 별도로 필요로 하기 때문에 방화벽이 있는 환경에서는 문제가 될 수 있다. 이 경우 특별한 통신 모드가 필요한데 이것이 HTTP Invoke 모드이다. 이 모드를 사용할 경우 원격 클라이언트의 RMI 요청을 HTTP로 감싸서 웹 엔진으로 보내고 웹 엔진은 RMI 요청을 다루는 서블릿(jeus.rmi.http.ServletHandler)으로 요청을 전달한다. 이 서블릿은 RMI 런타임으로 요청을 전달해서 실제 EJB 메소드를 호출한 뒤 그 결과를 HTTP 응답으로 감싸서 원격 클라이언트로 전달한다. HTTP Invoke 모드는 EJB 엔진 또는 EJB 컴포넌트별로 설정할 수 있다.
domain.xml의 <invoke-http>에 HTTP Invoke 모드가 설정되면 EJB 엔진 내의 모든 모듈에 적용된다. EJB 모듈의 jeus-ejb-dd.xml에서는 특정 EJB 컴포넌트에만 적용할 수 있다. 이때 jeus-ejb-dd.xml의 설정이 domain.xml의 설정보다 우선한다. domain.xml과 jeus-ejb-dd.xml의 설정에 대한 자세한 내용은 “4.2.4. HTTP Invoke 환경설정”을 참고한다.
다음은 EJB 엔진을 관리할 때 사용하게 되는 디렉터리와 파일의 목록이다.
기본 디렉터리에 대한 내용은 “1.3.1. 디렉터리 구조”와 동일하고, 다음은 EJB
엔진에서 주로 사용하는 디렉터리에 대한 설명이다.
EJB 엔진을 관리하는 툴이 위치한 디렉터리이다.
EJB 엔진 관리 툴 | 설명 |
---|---|
appcompiler | EJB를 deploy하기 위해 필요한 클래스를 생성하고 컴파일해서 Fast Deploy를 수행한다. |
jeusadmin | EJB 엔진을 제어하고 모니터링하기 위해 사용된다. |
EJB 엔진의 로그 파일이 위치한 디렉터리이다. EJB 로그의 파일 핸들러를 별도로 지정한 경우 별도의 파일로 생성된다. 핸들러가 없는 경우에는 서버의 로그 설정을 따르게 된다.
본 절에서는 WebAdmin을 사용하여 EJB 엔진을 설정하는 방법을 설명한다.
WebAdmin을 통한 EJB 엔진 설정은 크게 다음의 3가지 설정으로 나눌 수 있다. WebAdmin을 사용하여 설정된 내용은 JEUS_HOME/domains/<domain name>/config에 위치한 domain.xml 파일에 저장된다.
Basic
Active Management
Timer Service
하나의 MS에는 하나의 EJB 엔진이 존재한다. MS를 추가하는 방법에 대한 자세한 내용은 ????을 참고한다.
WebAdmin을 사용한 EJB 엔진의 Basic 설정 과정은 다음과 같다.
WebAdmin의 [Servers] 메뉴를 선택하면 서버 목록 조회 화면으로 이동한다. 서버 목록에서 실행할 서버를 선택하여, 서버 설정 화면으로 이동한 후 [Engine] > [Ejb Engine] > [Basic] 메뉴를 선택한다.
[LOCK & EDIT] 버튼을 클릭해서 설정변경 모드로 전환한다.
EJB Engine 화면에서 EJB 엔진에 대한 기본적인 항목을 설정하고 [확인] 버튼을 클릭한다.
다음은 기본 정보 및 고급 선택사항의 영역별 설정 항목에 대한 설명이다.
기본 정보
Asynchronous Invocation Service를 위한 설정이다.
EJB RMI Stub이 RMI 런타임 포트를 접근할 수 없는 상황일 경우에 설정한다.
설정 내용의 동적 반영을 위해 [Activate Changes] 버튼을 클릭한다.
Active Management 설정은 엔진 재시작 조건들과 이메일 통보 기능으로 나누어진다. 엔진 재시작 조건은 EJB 엔진이 재시작하기 전까지의 허용 가능한 최대 block된 EJB 스레드 수로 결정된다.
WebAdmin을 사용한 EJB 엔진의 Active Management 설정 과정은 다음과 같다.
WebAdmin의 [Servers] 메뉴를 선택하면 서버 목록 조회 화면으로 이동한다. 서버 목록에서 실행할 서버를 선택해서 서버 설정 화면으로 이동한 후 [Engine] > [Ejb Engine] > [Active Management] 메뉴를 선택한다.
[LOCK & EDIT] 버튼을 클릭해서 설정변경 모드로 전환한다.
Active Management 화면에서 항목을 설정하고 [확인] 버튼을 클릭한다.
다음은 기본 정보 및 고급 선택사항의 영역별 설정 항목에 대한 설명이다.
기본 정보
재시작 조건에 따라 EJB 엔진이 시작될 경우에 이메일 통보를 보내기 위한 정보를 설정한다.
다음은 하위 설정 항목에 대한 설명이다.
설정 내용의 동적 반영을 위해 [Activate Changes] 버튼을 클릭한다.
EJB Timer Service는 EJB가 특정한 시간 또는 주기적으로 callback을 받을 수 있도록 하는 서비스이다.
기본적인 사용 방법은 EJB 스펙에 설명되어 있으므로 JEUS EJB에서 제공하는 Timer Service와 이를 사용하기 위한 설정에 대해서만 설명한다. 자세한 내용은 “제10장 EJB Timer Service”를 참고한다.
EJB 엔진의 System Logging과 User Logging은 WebAdmin의 다음 메뉴에서 설정할 수 있다.
System Logging 설정
WebAdmin의 [Servers] > 서버 선택 > [Basic] > [System Logging] 메뉴에서 설정한다.
User Logging 설정
WebAdmin의 [Servers] > 서버 선택 > [Basic] > [User Logging] 메뉴에서 설정한다.
System Logging 설정은 EJB 엔진뿐만 아니라 다른 모든 엔진에도 적용되는 공통적인 설정이므로 자세한 내용은 ????을 참고한다.
EJB 엔진을 제어하는 것은 다른 JEUS 엔진(서블릿 또는 JMS)을 제어하는 것과 유사하다.
WebAdmin 및 콘솔 툴을 사용하여 EJB 엔진의 실행 환경 정보와 상태 정보를 모니터링할 수 있다. WebAdmin을 사용한 EJB 엔진의 제어 및 모니터링 방법은 다음과 같다.
EJB 엔진 제어
WebAdmin의 [Servers] 메뉴를 선택하여 나타나는 서버 목록에서 원하는 서버명을 선택한 후 [Engine] > [Ejb Engine]을 선택한다.
EJB 엔진 모니터링
WebAdmin의 [RUNTIME INFO] 버튼을 클릭한 뒤 EJB 엔진 제어를 위한 메뉴 선택과 같은 방법으로 모니터링하려는 EJB 엔진을 선택한다.
1. EJB 엔진에 대한 모니터링은 WebAdmin이 콘솔 툴에 비해 자세하고 완벽한 엔진 상태 정보를 제공하므로 WebAdmin을 사용할 것을 권장한다. WebAdmin에 대한 자세한 내용은 "JEUS WebAdmin 안내서"를 참고한다.
2. 콘솔 툴을 통해 기본적인 실행환경 정보를 조회할 수 있다. 자세한 내용은 ????를 참고한다.
EJB 엔진의 전체적인 성능 향상을 위해 설정을 변경할 수 있다. 본 절에서는 EJB 엔진의 성능 관련 설정을 간략하게 설명한다.
튜닝을 위해 필요한 사항은 다음과 같다.
Resolution 설정 튜닝
Fast Deploy 기능 사용
최대 성능을 위한 시스템 로그 설정
Active Management 사용하지 않기
HTTP Invoke 모드 사용
EJB 엔진의 정보나 팁에 대해서는 "JEUS XML Reference"의 "11. domain.xml EJB 엔진 설정"을 참고한다. XML/Schema 중 "P"라고 표시된 것은 성능과 관련된 것이다.
Resolution은 EJB 엔진의 상태를 체크하는 주기로 2가지 주기로 사용된다.
block된 스레드 개수가 몇 개인지 검사한 후 EJB 엔진을 재시작하는 Active Management의 체크 주기를 나타낸다.
모든 하위 컴포넌트들(예: Bean pool)을 점검하고, 각 Bean이 비활성화 대상인지 검사하는 passivation의 체크 주기를 나타낸다.
Resolution 값이 클수록 시스템 메모리나 기타 리소스의 회수 주기가 길어져 자원 활용률은 떨어지지만 이에 대한 작업 수행이 덜 발생하므로 엔진의 성능은 향상된다. 이 값을 작게 하면 엔진은 최신 상태를 유지하겠지만 전체적인 성능은 저하된다. 따라서 메모리 크기나 용도에 따라서 Resolution 값을 적절하게 설정하는 것이 매우 중요하다.
Resolution 값의 설정에 따라 <passivation-timeout>이나 <disconnect-timeout>이 원하는 때에 발생하지 않을 수 있으므로 주의해야 한다.
Fast Deploy 옵션은 EJB에 설정하지 않고 애플리케이션별로 설정하는 것이지만 성능에 큰 영향을 미친다.
엔진이 기동될 때 deploy되어야 할 EJB 모듈들이 이미 컴파일되어 RMI Stub과 Skeleton이 있다면 deploy 명령어를 사용할 때 –fast 옵션을 추가한다. 이는 엔진이 EJB 모듈을 deploy할 때 RMI 클래스를 생성하지 않도록 하는 것이다. EJB 모듈과 deploy에 대한 자세한 내용은 “제3장 EJB 모듈”을 참고한다.
시스템 로그는 성능 개선을 위해 3가지 방법으로 조정 가능하다.
가능하면 파일 핸들러를 사용해서 Logging이 빠르게 이루어지도록 하는게 좋다.
파일 핸들러의 버퍼 크기를 크게 설정한다.
로그 레벨을 'SEVERE'로 설정한다.
위의 제안은 안정적인 운영 환경에서만 적용되어야 한다. 개발 환경에서는 "반대"의 값들이 설정되어야 한다. 즉, 콘솔 핸들러를 사용하고, 작은 버퍼 크기를 사용하고, 'FINE' 로그 레벨을 사용하는 것이 개발을 용이하게 한다.
EJB 엔진 레벨에 Active Management의 사용이 반드시 필요한 것은 아니다. 설정에 따라 성능 저하를 가져올 수 있기 때문에 기본적으로는 사용하지 않는다. 대신 서블릿 엔진에 정의된 Active Management를 사용하는 것이 편리하다. 그러므로 일반적으로 Active Management 설정은 생략하는 경우가 많다.