제2장 EJB 엔진

본 장에서는 EJB 엔진에 대한 기초적인 사항과 JEUS EJB의 최상위 레벨의 개념인 구조, 설정, 운영, 모니터링과 튜닝에 대해 설명한다.

2.1. 개요

EJB 엔진은 EJB의 운영 환경을 제공한다. 본 안내서에서 사용한 EJB 엔진은 EJB 표준에서 사용하는 EJB 컨테이너라는 용어와 동일한 개념이다. EJB 모듈, EJB deploy에 대한 상세한 정보는 각각 “제3장 EJB 모듈”과 “제4장 EJB의 공통 특성”을 참고한다.

2.2. 주요 기능

다음은 EJB 엔진의 주요 기능에 대한 설명이다.

EJB 엔진과 Managed Server(MS)

하나의 MS에는 하나의 EJB 엔진이 존재한다. 그러나 하나의 도메인에는 여러 개의 MS가 존재할 수 있기 때문에 하나의 도메인에 여러 개의 EJB 엔진이 존재할 수 있다.

일반적으로 여러 개의 머신이나 CPU 위에 여러 개의 MS에 EJB 엔진이 설정되고, Master에 의해 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 화면에 출력된다.

참고

그 외에 사용자가 생성한 사용자 핸들러를 등록할 수 있다. 자세한 설명은 “JEUS Server 안내서”의 “제8장 Logging”을 참고한다.
Active Management

Active Management는 EJB 모듈에 문제가 발생한 경우에 EJB 엔진이 자체적으로 이메일(e-mail)로 통지를 보내주는 기능이다.

예를 들어 Bean 클래스의 잘못된 구현으로 인해서 무한 루프에 빠지거나 Deadlock과 같은 심각한 오류가 발생했을 때 EJB 엔진이 이를 감지하여 통지를 보내주도록 되어 있다. 부가적으로 오류 처리 정책을 설정할 수 있어서 비정상적인 현상이 발생한 경우에 이메일 통지뿐만 아니라 해당 EJB 엔진이 동작하는 MS를 재시작할 수 있도록 권고메세지를 출력할 수 있다. Active Management에 대한 자세한 설정은 “2.4. EJB 엔진 설정”을 참고한다.
HTTP Invoke

원격 클라이언트가 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 환경설정”을 참고한다.

2.3. EJB 엔진 디렉터리 구조

다음은 EJB 엔진을 관리할 때 사용하게 되는 디렉터리와 파일의 목록이다.

{JEUS_HOME}
    |--bin
    |   |--[01]appcompiler
    |   |--[01]jeusadmin
    |--domains
    |     |--<domain_name>
    |           |--config
    |           |    |--[X]domain.xml
    |           |--servers
    |                |--<server_name>
    |                       |--logs
    |                            |--[T]error.log
    |--lib
        |--schemas
             |--javaee
             |--jeus

* Legend
- [01]: binary or executable file
- [X] : XML document
- [J] : JAR file
- [T] : Text file
- [C] : Class file
- [V] : jaba source file
- [DD] : deployment dexcriptor

기본 디렉터리에 대한 내용은 “1.3.1. 디렉터리 구조”와 동일하고, 다음은 EJB 엔진에서 주로 사용하는 디렉터리에 대한 설명이다.

bin

EJB 엔진을 관리하는 툴이 위치한 디렉터리이다.

EJB 엔진 관리 툴	설명
appcompiler	EJB를 deploy하기 위해 필요한 클래스를 생성하고 컴파일해서 Fast Deploy를 수행한다.
jeusadmin	EJB 엔진을 제어하고 모니터링하기 위해 사용된다.

domains/<doamin name>/servers/<server name>/logs

EJB 엔진의 로그 파일이 위치한 디렉터리이다. EJB 로그의 파일 핸들러를 별도로 지정한 경우 별도의 파일로 생성된다. 핸들러가 없는 경우에는 서버의 로그 설정을 따르게 된다.

2.4. EJB 엔진 설정

본 절에서는 WebAdmin을 사용하여 EJB 엔진을 설정하는 방법을 설명한다.

WebAdmin을 통한 EJB 엔진 설정은 크게 다음의 3가지 설정으로 나눌 수 있다. WebAdmin을 사용하여 설정된 내용은 JEUS_HOME/domains/<domain name>/config에 위치한 domain.xml 파일에 저장된다.

참고

하나의 MS에는 하나의 EJB 엔진이 존재한다. MS를 추가하는 방법에 대한 자세한 내용은 “JEUS Server 안내서”의 “제2장 JEUS 설정”을 참고한다.

2.4.1. Basic 설정

WebAdmin을 사용한 EJB 엔진의 Basic 설정 과정은 다음과 같다.

WebAdmin 메인 화면에서 Master Server를 선택한 후 JEUS Master 화면 상단 메뉴에서 [서버]를 선택한다.
서버 목록에서 서버를 선택한 후 기본 설정화면에서 [Engine] > [Ejb Engine] > [Basic] 메뉴를 선택한다.

EJB Engine 화면에서 [수정] 버튼을 클릭해서 수정모드로 변경한 후 EJB 엔진에 대한 기본적인 항목을 설정하고 [저장] 버튼을 클릭한다.

[그림 2.1] EJB 엔진 설정 - Basic 설정

다음은 기본 정보 및 고급 선택사항의 영역별 설정 항목에 대한 설명이다.

기본 정보

항목	설명
Use Dynamic Proxy For Ejb2	기존 RMI Stub 방식 대신 Dynamic Proxy 방식을 사용한다.
Resolution	Active Management의 체크 주기와 Passivation 체크 주기를 설정한다. 즉, block된 스레드를 감지하는 주기와 Passivation 타임아웃 동안 클라이언트로부터 요청을 받지 않은 Bean을 감지하는 주기이다.

고급 선택사항

Ejb Engine

항목	설명
Enable User Notify	옵션을 설정하면 EJB Exception이 서버에 설정한 user log에 남게 된다. user log에 대한 설명은 “JEUS Server 안내서”의 “제8장 Logging”을 참고한다.

Async Service

Asynchronous Invocation Service를 위한 설정이다.

항목	설명
Thread Min	유지할 스레드 개수의 최솟값을 설정한다.
Thread Max	유지할 스레드 개수 최댓값을 설정한다.
Access Timeout	Async 메소드가 수행이 완료된 후 일정 시간이 지나도 클라이언트에서 get을 하지 않으면 Future 객체를 삭제하는 시간이다. 이는 클라이언트의 실수로 get을 하지 않는 경우 Memory Leak의 발생을 방지하기 위한 설정이다.

항목

설명

Thread Min

유지할 스레드 개수의 최솟값을 설정한다.

Thread Max

유지할 스레드 개수 최댓값을 설정한다.

Access Timeout

Async 메소드가 수행이 완료된 후 일정 시간이 지나도 클라이언트에서 get을 하지 않으면 Future 객체를 삭제하는 시간이다.

이는 클라이언트의 실수로 get을 하지 않는 경우 Memory Leak의 발생을 방지하기 위한 설정이다.

Invoke Http

EJB RMI Stub이 RMI 런타임 포트를 접근할 수 없는 상황일 경우에 설정한다.

항목	설명
Http Port	HTTP-RMI 요청을 받을 포트 번호를 설정한다. 웹 서버 및 웹 엔진에는 반드시 RMI 핸들러 서블릿이 deploy되어 실행되고 있어야 한다.
Url	RMI Stub으로부터 호출되는 RMI 핸들러 서블릿의 URI를 입력한다. URI에는 프로토콜, IP 주소, 포트를 제외한 서블릿 요청 경로만을 넣는다. 즉, rmiHandlerServlet.war의 jeus-web-dd.xml에 설정한 <contex-path>와 web.xml에 설정한 <url-pattern>을 이어서 입력한다. jeus-web-dd.xml을 별도로 생성하지 않으면 <contex-path>의 기본값인 war 이름으로 예에서는 rmiHandlerServlet이 된다. 프로토콜은 "HTTP"로 IP는 RMI 런타임과 동일한 주소로 간주된다. HTTP-RMI 요청을 받은 웹 서버와 웹 엔진이 RMI 런타임과 같은 머신에 있어야 한다. 그러면 RMI 런타임의 주소는 RMI Stub에게 알려지게 된다. 웹 서버의 포트는 반드시 다음 <http-port>에 설정해야 한다. JEUS에서 제공하는 rmiHandlerServlet.war에는 jeus-web-dd.xml이 포함되어 있지 않다. 따라서 기본적으로 컨텍스트는 모듈 이름과 같은 rmiHadlerServlet을 사용하게 된다. 또한 web.xml에는 <url-pattern>이 서블릿 핸들러가 설정되어 있다. 기본값 외의 설정을 사용하고 싶은 경우에는 jeus-web-dd.xml을 생성하고 web.xml를 수정한 후 rmiHandlerServlet.war를 deploy한다.

항목

설명

Http Port

HTTP-RMI 요청을 받을 포트 번호를 설정한다. 웹 서버 및 웹 엔진에는 반드시 RMI 핸들러 서블릿이 deploy되어 실행되고 있어야 한다.

Url

RMI Stub으로부터 호출되는 RMI 핸들러 서블릿의 URI를 입력한다.

URI에는 프로토콜, IP 주소, 포트를 제외한 서블릿 요청 경로만을 넣는다. 즉, rmiHandlerServlet.war의 jeus-web-dd.xml에 설정한 <contex-path>와 web.xml에 설정한 <url-pattern>을 이어서 입력한다. jeus-web-dd.xml을 별도로 생성하지 않으면 <contex-path>의 기본값인 war 이름으로 예에서는 rmiHandlerServlet이 된다.
프로토콜은 "HTTP"로 IP는 RMI 런타임과 동일한 주소로 간주된다. HTTP-RMI 요청을 받은 웹 서버와 웹 엔진이 RMI 런타임과 같은 머신에 있어야 한다. 그러면 RMI 런타임의 주소는 RMI Stub에게 알려지게 된다. 웹 서버의 포트는 반드시 다음 <http-port>에 설정해야 한다.
JEUS에서 제공하는 rmiHandlerServlet.war에는 jeus-web-dd.xml이 포함되어 있지 않다. 따라서 기본적으로 컨텍스트는 모듈 이름과 같은 rmiHadlerServlet을 사용하게 된다. 또한 web.xml에는 <url-pattern>이 서블릿 핸들러가 설정되어 있다. 기본값 외의 설정을 사용하고 싶은 경우에는 jeus-web-dd.xml을 생성하고 web.xml를 수정한 후 rmiHandlerServlet.war를 deploy한다.

2.4.2. Active Management 설정

Active Management 설정은 엔진 재시작 조건들과 이메일 통보 기능으로 나누어진다. 엔진 재시작 조건은 EJB 엔진이 재시작하기 전까지의 허용 가능한 최대 block된 EJB 스레드 수로 결정된다.

WebAdmin을 사용한 EJB 엔진의 Active Management 설정 과정은 다음과 같다.

WebAdmin 메인 화면에서 Master Server를 선택한 후 JEUS Master 화면 상단 메뉴에서 [서버]를 선택한다.
서버 목록에서 서버를 선택한 후 기본 설정화면에서 [Engine] > [Ejb Engine] > [Active Management] 메뉴를 선택한다.

Active Management 화면 에서 [수정] 버튼을 클릭해서 수정모드로 변경한 후 EJB 엔진에 대한 기본적인 항목을 설정하고 [저장] 버튼을 클릭한다.

[그림 2.2] EJB 엔진 설정 - Active Management 설정

figure 5 ejb engine config active management

다음은 기본 정보 및 고급 선택사항의 영역별 설정 항목에 대한 설명이다.

기본 정보

항목	설명
Max Blocked Thread	EJB 엔진이 재시작 권고하기 전까지 허용할 수 있는 block된 EJB 스레드의 최대 개수이다. 이 값이 작게 설정되어 있다면 EJB 엔진 재시작 권고가 너무 자주 될 수도 있기 때문에 주의해야 한다. 기본값으로 설정하면 block된 스레드 개수에 대한 제한이 없음을 의미한다. 즉, 기본적으로 EJB 엔진은 block된 스레드 때문에 재시작 권고를 하지 않는다.
Max Idle Time	지정된 시간 동안 스레드가 block된 상태로 요청을 받지 않고 Idle 상태에 있으면 "block된 스레드 리스트"로 추가된다. 이 설정은 엔진에서 block된 스레드로 판단하는 기준이 된다.

항목

설명

Max Blocked Thread

EJB 엔진이 재시작 권고하기 전까지 허용할 수 있는 block된 EJB 스레드의 최대 개수이다. 이 값이 작게 설정되어 있다면 EJB 엔진 재시작 권고가 너무 자주 될 수도 있기 때문에 주의해야 한다.

기본값으로 설정하면 block된 스레드 개수에 대한 제한이 없음을 의미한다. 즉, 기본적으로 EJB 엔진은 block된 스레드 때문에 재시작 권고를 하지 않는다.

Max Idle Time

지정된 시간 동안 스레드가 block된 상태로 요청을 받지 않고 Idle 상태에 있으면 "block된 스레드 리스트"로 추가된다.

이 설정은 엔진에서 block된 스레드로 판단하는 기준이 된다.

고급 선택사항

Email Notify

재시작 권고 조건에 따라 EJB 엔진이 시작될 경우에 이메일 통보를 보내기 위한 정보를 설정한다.

항목	설명
Smtp Host Address	메시지를 전송할 때 사용할 SMTP의 주소로 이 주소는 호스트 이름이나 IP 주소로 설정해야 한다.
Sender Id	SMTP 주소를 통해 인증 받을 ID를 설정한다.
Sender Password	SMTP 주소를 통해 인증 받을 ID의 암호를 설정한다.
From Address	메일 송신자의 주소를 설정한다.
To Address	메일 수신자의 주소를 설정한다.
Cc Address	메일을 참조로 받을 수신자의 주소를 설정한다.
Bcc Address	메일을 숨은 참조로 받을 수신자의 주소를 설정한다.
Property	기본적인 SMTP property 외에 추가로 필요한 property가 있다면 key, value의 형태로 설정한다.

2.4.3. Timer Service 설정

EJB Timer Service는 EJB가 특정한 시간 또는 주기적으로 callback을 받을 수 있도록 하는 서비스이다. 기본적인 사용 방법은 EJB 스펙에 설명되어 있으므로 JEUS EJB에서 제공하는 Timer Service와 이를 사용하기 위한 설정에 대해서만 설명한다. 자세한 내용은 “제10장 EJB Timer Service”를 참고한다.

2.5. 시스템 로그 설정

EJB 엔진의 System Logging과 User Logging은 WebAdmin의 다음 메뉴에서 설정할 수 있다.

System Logging 설정

WebAdmin 메인 화면에서 Master Server를 선택한 후 JEUS Master 화면 상단 메뉴에서 [서버]를 선택한다. 서버 목록에서 서버를 선택한 후 기본 설정화면에서 [Basic] > [System Logging] 메뉴에서 설정한다.
User Logging 설정

WebAdmin 메인 화면에서 Master Server를 선택한 후 JEUS Master 화면 상단 메뉴에서 [서버]를 선택한다. 서버 목록에서 서버를 선택한 후 기본 설정화면에서 [Basic] > [User Logging] 메뉴에서 설정한다.

System Logging 설정은 EJB 엔진뿐만 아니라 다른 모든 엔진에도 적용되는 공통적인 설정이므로 자세한 내용은 “JEUS Server 안내서”의 “제8장 Logging”을 참고한다.

2.6. EJB 엔진 제어 및 모니터링

EJB 엔진을 제어하는 것은 다른 JEUS 엔진(서블릿 또는 JMS)을 제어하는 것과 유사하다.

WebAdmin 및 콘솔 툴을 사용하여 EJB 엔진의 실행 환경 정보와 상태 정보를 모니터링할 수 있다. WebAdmin을 사용한 EJB 엔진의 제어 및 모니터링 방법은 다음과 같다.

EJB 엔진 제어

WebAdmin 메인 화면에서 Master Server를 선택한 후 JEUS Master 화면 상단 메뉴에서 [서버]를 선택한다. 서버 목록에서 서버를 선택한 후 기본 설정화면에서 [Engine] > [Ejb Engine]을 선택한다.
EJB 엔진 모니터링

WebAdmin 메인 화면에서 Master Server를 선택한 후 JEUS Master 화면 상단 메뉴에서 [서버]를 선택한다. 모니터링할 EJB 엔진을 선택한다.

참고

EJB 엔진에 대한 모니터링은 WebAdmin이 콘솔 툴에 비해 자세하고 완벽한 엔진 상태 정보를 제공하므로 WebAdmin을 사용할 것을 권장한다. WebAdmin에 대한 자세한 내용은 "JEUS WebAdmin 안내서"를 참고한다.
콘솔 툴을 통해 기본적인 실행환경 정보를 조회할 수 있다. 자세한 내용은 “JEUS Reference 안내서”의 “4.2.7. EJB 엔진 관련 명령어”를 참고한다.

2.7. EJB 엔진 튜닝

EJB 엔진의 전체적인 성능 향상을 위해 설정을 변경할 수 있다. 본 절에서는 EJB 엔진의 성능 관련 설정을 간략하게 설명한다.

튜닝을 위해 필요한 사항은 다음과 같다.

Resolution 설정 튜닝
Fast Deploy 기능 사용
최대 성능을 위한 시스템 로그 설정
Active Management 사용하지 않기
HTTP Invoke 모드 사용

참고

EJB 엔진의 정보나 팁에 대해서는 "JEUS XML Reference"의 "11. domain.xml EJB 엔진 설정"을 참고한다. XML/Schema 중 "P"라고 표시된 것은 성능과 관련된 것이다.

2.7.1. Resolution 설정 튜닝

Resolution은 EJB 엔진의 상태를 체크하는 주기로 2가지 주기로 사용된다.

block된 스레드 개수가 몇 개인지 검사한 후 EJB 엔진을 재시작하는 Active Management의 체크 주기를 나타낸다.
모든 하위 컴포넌트들(예: Bean pool)을 점검하고, 각 Bean이 비활성화 대상인지 검사하는 passivation의 체크 주기를 나타낸다.

Resolution 값이 클수록 시스템 메모리나 기타 리소스의 회수 주기가 길어져 자원 활용률은 떨어지지만 이에 대한 작업 수행이 덜 발생하므로 엔진의 성능은 향상된다. 이 값을 작게 하면 엔진은 최신 상태를 유지하겠지만 전체적인 성능은 저하된다. 따라서 메모리 크기나 용도에 따라서 Resolution 값을 적절하게 설정하는 것이 매우 중요하다.

참고

Resolution 값의 설정에 따라 <passivation-timeout>이나 <disconnect-timeout>이 원하는 때에 발생하지 않을 수 있으므로 주의해야 한다.

2.7.2. Fast Deploy

Fast Deploy 옵션은 EJB에 설정하지 않고 애플리케이션별로 설정하는 것이지만 성능에 큰 영향을 미친다. 엔진이 기동될 때 deploy되어야 할 EJB 모듈들이 이미 컴파일되어 RMI Stub과 Skeleton이 있다면 deploy 명령어를 사용할 때 –fast 옵션을 추가한다. 이는 엔진이 EJB 모듈을 deploy할 때 RMI 클래스를 생성하지 않도록 하는 것이다. EJB 모듈과 deploy에 대한 자세한 내용은 “제3장 EJB 모듈”을 참고한다.

2.7.3. 최대 성능을 위한 시스템 로그 설정

시스템 로그는 성능 개선을 위해 3가지 방법으로 조정 가능하다.

가능하면 파일 핸들러를 사용해서 Logging이 빠르게 이루어지도록 하는게 좋다.
파일 핸들러의 버퍼 크기를 크게 설정한다.
로그 레벨을 'SEVERE'로 설정한다.

주의

위의 제안은 안정적인 운영 환경에서만 적용되어야 한다. 개발 환경에서는 "반대"의 값들이 설정되어야 한다. 즉, 콘솔 핸들러를 사용하고, 작은 버퍼 크기를 사용하고, 'FINE' 로그 레벨을 사용하는 것이 개발을 용이하게 한다.

2.7.4. Active Management 사용하지 않기

EJB 엔진 레벨에 Active Management의 사용이 반드시 필요한 것은 아니다. 설정에 따라 성능 저하를 가져올 수 있기 때문에 기본적으로는 사용하지 않는다. 대신 서블릿 엔진에 정의된 Active Management를 사용하는 것이 편리하다. 그러므로 일반적으로 Active Management 설정은 생략하는 경우가 많다.

2.7.5. HTTP Invoke 모드 사용

클라이언트가 많은 경우 HTTP Invoke 모드를 사용하면 성능 향상 효과가 나타난다. 웹 서버가 JEUS로의 요청을 일정하게 조절해주기 때문에 클라이언트의 요청대로 스레드를 생성시키는 RMI에 비해 connection의 개수가 적게 생성된다. 그러나 보통의 경우에 HTTP 프로토콜로 변화하는 것은 오히려 성능 저하를 가져올 수 있다는 것을 고려해야 한다.