GC (Gabage Collector)

Sun JVM 의 Heap Memory 영역은 다음과 같은 구조를 가진다.

[ Sun MicroSystems Memory 구조도 ]

위의 그림을 보면 메모리 영역은 다음과 같이 커다랗게 3부분으로 나뉘어진다.

1. Young Area
   - Eden
   - Survivor Spaces 2 block (S0, S1)
   - Virtual
2. Tenured Area (Old Area 라고도 부른다.)
   - Tenured
   - Virtual
3. Permanent Area
   - Perm
   - Virtual

* 보통 메모리를 명확하게 java -Xms1024m -Xmx1024m -XX:MaxPermSize=128m 형식으로 할당하기 때문에
  Virtual 영역은 없다고 보면 된다.

Java 실행시 Heap Size 를 주게되는데 설정된 Heap Size 를 설정된 Ratio 별로 나누어서 할당하게된다.
(Ratio 중에는 Young : Tenured 영역 분할 Ratio, Young 중에서 Eden : Survivor 영역 Ratio 가 있다.
자세한 사항은 이번 글에서는 넘어간다. -_-;)

그럼 위의 3가지 영역을 설명하면서 GC 되는 절차를 알아보자.

1. Young Area
 보통 객체 생성시 new 라는 keyword 를 이용하는데 이때 객체가 생성되는 부분이 Young 의 Eden 부분이다.
 Eden 부분에 객체가 생성되면서 메모리를 할당받게 되고 Eden Area 의 설정된 % 이상으로 메모리가 할당되면
 Young GC 가 일어나게 된다. (GC 의 종류도 참 많다. --;)
 이때 Young GC 가 일어나면 어떤 현상이 벌어지는지 눈 똑바로 뜨고 글을 읽어라.
 
 - Young GC
 Survivor 영역은 그림에서 보면 두개로 나뉘어져 있다. 각각을 S0, S1 이라 부른다.
 Eden 의 설정치 만큼 메모리가 할당되게 되면 Young GC 가 일어나는데 Young GC 란 Eden + S0 (처음 Young GC 일때)
 의 영역을 GC 를 실행한다. 이때 GC 대상에 포함되지 않는 (즉, Reference 가 살아있는 객체) 객체는
 S1 영역으로 옮겨지고 나머지 Week Reference 객체는 GC 된다.
 그후 다시 Eden 에 객체가 생성되고 메모리가 또 차게되면 이번에는 Eden + S1 이 GC 의 대상이고 이때 동일하게
 Reference 가 살아있는 객체는 S0 영역으로 옮겨지고 나머지 Week Reference 는 GC 된다.
 
 그럼 이말을 잘 풀어서 보면, Eden 은 무조건 GC 대상이고 Survivor 의 두 Area 가 돌아가면서 GC 대상이 되는것이다.
 Young GC 가 될때는 Eden + Survivor Area 중 한곳의 메모리를 전부 비우게 되며 Refrence 가 남아있는 객체를 다른 한곳의
 Survivor Area 로 할당하게 되는것이다. 즉, Survivor Area 의 S0 or S1 둘중에 한곳은 항상 비어있다고 보면 된다.
 
 그럼 Singleton Pattern 형식처럼 항상 메모리에 상주하게 구현한 객체들은 S0 와 S1 사이를 왔다리 갔다리 한다는 말인가?
 흠... -_-;
 정답은 안그렇다.
 
 java option 에 TenuringThreshold (default 32) 값에 의해서 S0, S1 을 몇번이상 왔다리 갔다리하면 이것은 오래 남을 객체라
 판단하고 Tenured Area (Old Area) 으로 보내진다.
 또한 Eden 10M, S0 1M, S1 1M 라고 했을때 Young GC 가 Eden + S0 가 일어날때 GC 후의 값이 5M 라면 어떻게 될까?
 정답은 S1 에 1M 를 할당하고 남은것은 Tenured Area 로 보내진다.

2. Tenured Area
 Old Area 라고도 부르며 Young Area 에서 넘어온 객체들이 할당되어진다.
 Tenured Area 역시 설정된 % 이상으로 메모리가 할당되면 GC 가 일어나게 되는데 이것이 Old GC 이다.
 Old GC 가 일어나도 Old 영역이 줄어들지 않는다면 Full GC 가 일어날 수 있으며 Memory Leak 을 생각해 볼 수 있다.

3. Permanent Area
 Permanent Area 는 Class 를 Loading 하는데 사용한다. 보통 Perm Size 는 64 이며 크게 잡을경우 128 을 잡기도 한다.
 개발 환경에서는 Hot Deploy 가 편하지만 운영환경이라면 Hot Deploy 하는것이 좋지않다.
 Hot Deploy 하게되면 Permanent Area 로 Class 가 Loading 되게되며, 기존의 Loading 되어있던 Old version 이 바로 Unloading 되는것은
 아니기 때문이다. (Permanent Area 의 경우 GC 라 하지않고 Unloading 이라 부른다.)
 문제는 수행중에 필요에 의해서 Unloading 이 발생하게 되는데 수시로 Hot Deploy 가 일어나서 Permanent Area 가 Full 나게되면
 Full GC 가 일어나게 된다.
 Loading 해야될 Class 보다 적은 Permanent Size 를 할당할 경우 Full GC 도 수시로 일어나지만 OOME (Out Of Memory Error) 가
 발생하며 WAS 가 down 될 수도 있다.
 

** Full GC 란 ?
 Old GC 후에 Tenured Area 이 줄어들지 않았을 경우 발생 할 수 있으며 또한 Permanent Area 가 Full 나면 일어난다.
 Full GC 가 일어나면 보통 수초에서 수십초의 시간을 소요하게 되며, 이때 JVM 은 Full GC 이외의 일은 하지 않는다.
 즉, 일반 상용 사이트의 Web Application Server 가 Full GC 가 일어나면 수초에서 수십초간 WAS 가 정지되는
 상황에 놓이는 것이다. 그러나 사이트가 정지되는 일은 별로 일어나지 않는데 이유는 일반 상용 사이트는 HA (High Availibilty)
 구성을 해놓기 때문에 한쪽 WAS 가 먹통이 되면 L/B (Load Balancer) 가 알아서 Load Banlancing 을 하게됨으로 일반 Client 가 사용하기에는
 아무런 문제가 발생하지 않는다.

 Full GC 가 일어난다는 것은 메모리 할당이 잘못됐거나, Memory Leak 발생하거나 하는 경우이므로 튜닝 포인트를 찾아내야한다.

[출처] How to find bottleneck in J2EE application|작성자 히트

<그림 1. 일반적인 J2ee application의 구조>

<그림 2. WAS 시스템의 구조>

<그림 3-2. Thread dump>

<그림 3-3. sample code>

<그림 3-4. Thread 간에 Lock을 기다리는 형태>

<그림 3-5. Lock Contention 상황에서 Thread의 시간에 따른 진행 상태>

<그림 3-6. Lock Contention에서 Lock을 기다리고 있는 상황의 Thread Dump>

<그림 3-7. 환형 대기조건에 의한 deadlock>

<그림 3-8. Deadlock이 걸렸을때 시간 진행에 따른 Thread의 상태>

<그림 3-9. Deadlock이 걸린 IBM AIX Thread Dump>

<그림 3-10. Thread들이 IO Wait를 할때 시간에 따른 Thread Dump 상황>

<그림 3-11. Thread가 DB Query Wait에 걸려 있는 stack>

1.prstat 명령을 이용해서 java process의 LWP(Light Weight process) CPU 사용률을 구한다. % prstat -L -p [WeblogicPID] 1 1 <그림 3-6. Lock Contention에서 Lock을 기다리고 있는 상황의 Thread Dump> 2. pstack 명령어를 이용해서 native thread와 LWP 간의 id mapping을 알아낸다. (※ 전에 먼저 java process가 lwp로 돌아야되는데, startWebLogic.sh에 LD_LIBRARY_PATH에 /usr/lib/lwp 가 포함되어야 한다.) % pstack [WebLogicPID] <그림 3-6. Lock Contention에서 Lock을 기다리고 있는 상황의 Thread Dump> 3. 1에서 얻은 LWP ID를 pstack log를 통해서 분석해보면 어느 Thread에 mapping되는지를 확인할 수 있다. 여기서는 LWP 8이 Thread 24과 mapping이 되고 있음을 볼 수 있다. kill -3 [WebLogicPID]를 해서 ThreadDump를 얻어낸다. <그림 3-6. Lock Contention에서 Lock을 기다리고 있는 상황의 Thread Dump> Thread dump에서 nid라는 것이 있는데, 2에서 얻어낸 thread id를 16진수로 바꾸면 이값이 nid값과 같다. 즉 2에서 얻어낸 thread 24는 16진수로 0x18이기 때문에, thread dump에서 nid가 0x18인 쓰레드를 찾아서 어떤 작업을하고 있는지를 찾아내면 된다.

1. ps 명령을 이용하여, WebLogic Process의 각 시스템thread의사용률을 구한다. % ps -mp [WeblogicPID] -0 THREAD 여기서 CP가 가장 높은 부분을 찾는다. 이 시스템 쓰레드가 CPU를 가장 많이 점유하고 있는 시스템 쓰레드이다. (여기서는 66723 이다.) 2. dbx 명령을 이용해서 1.에서 찾은 시스템 쓰레드의 Java Thread ID를 얻어온다. 1) % dbx -a [WebLogicPID] 2) dbx에서 “thread” 명령을 치면 Thread ID 를 Listing할 수 있다. k-tid 항목에서 1에서 찾은 Thread ID 를 찾고, 그 k-tid에 해당하는 thread id를 찾는다. (여기서는 $t17이 된다.) 3) dbx에서 $t17 번 쓰레드의 Java Thread ID를 얻는다. dbx에서 “th info 17” 이라고 치면 $t17번 쓰레드의 정보를 얻어온다. pthread_t 항목에서 Java Thread ID를 얻는다. 여기서는 1011이된다. 3. Java Thread Dump에서 2에서 얻어온 Java Thread ID를 이용해서 해당 Java Thread를 찾아서 Java Stack을 보고 CPU를 많이 사용하는 원인을 찾아낸다. 1) kill -3 [WebLogicPID] 2) Thread dump를 보면 native ID 라는 항목이 있는데, 2.에서 찾은 Java Thread ID와 이 항목이 일치하는 Execute Thread를 찾으면 된다.

1. 먼저 JVM이 Hotspot mode로 작동하고 있어야 한다. (classic 모드가 아니어야 한다.) 옵션을 주지 않았으면 Hotspot 모드가 default이다. 2. glance를 실행해서 ‘G’를 누르고 WAS의 PID를 입력한다. 각 Thread의 CPU 사용률이 실시간으로 모니터링이 되는데. 여기서 CPU 사용률이 높은 Thread의 TID를 구한다. 3. kill -3 을 이용해서 Thread dump를 추출해서. 2에서 구한 TID와 Thread Dump상의 lwp_id가 일치하는 Thread를 찾으면 된다.

<그림 4-1. JVM의 메모리 구조>

<그림. Connection close의 올바른 예>

J2EE Application의 병목구간을 확인하기 위해서는 그 문제를 발견하고 툴과 경험을 이용해서 문제의 원인을 발견하고 제거해야한다.

대부분의 WAS또는 User Application의 slow down이나 hang up은 Thread dump를 통한 분석을 통해서 대부분 발견 및 해결을 할 수 있다.

그외에 부분 JVM이나 WebServer,Network 등에 대해서는 별도의 경험과 Log 분석등을 알아내야하고 DB에 의한 slow down이나 hang up현상은 DB 자체의 분석이 필요하다.

<그림 1. 메모리 foot print>

<그림 2. Java 메모리 구조>

<표 1. Java 메모리 영역>

<그림 3-1. 1st Minor GC>

<그림 3-2. 2nd Minor GC>

<그림 3-3. 3rd Minor GC>

<그림 4. Full GC>

<그림 7. Parallel GC 개념도>

옵션을 이용하여 Parallel GC에 사용되는 Thread의 수를 지정할 수 있다.

3) Concurrent GC

앞에서도 설명했듯이, Full GC즉 Old 영역을 GC하는 경우에는 그 시간이 길고 Application이 순간적으로 멈춰버리기 때문에, 시스템 운용에 문제가 된다.

그래서 JDK1.4부터 제공하는 Concurrent GC는 기존의 이런 Full GC의 단점을 보완하기 위해서 Full GC에 의해서 Application이 멈추어 지는 현상을 최소화 하기 위한 GC방법이다.
Full GC에 소요되는 작업을 Application을 멈추고 진행하는것이 아니라, 일부는 Application이 돌아가는 단계에서 수행하고, 최소한의 작업만을 Application이 멈췄을때 수행하는 방법으로 Application이 멈추는 시간을 최소화한다.

<그림 8. Concurrent GC 개념도>

그림 8에서와 같이 Application이 수행중일때(붉은 라인) Full GC를 위한 작업을 수행한다. (Sweep,mark) Application을 멈추고 수행하는 작업은 일부분 (initial-mark, remark 작업)만을 수행하기 때문에, 기존 Default GC의 Mark & Sweep Collector에 비해서 Application이 멈추는 시간이 현저하게 줄어든다.

Solaris JVM에서는 -XX:+UseConcMarkSweepGC Parameter를 이용해 세팅한다.

4) Incremental GC (Train GC)

Incremental GC또는 Train GC라고도 불리는 GC방법은 JDK 1.3에서부터 지원된 GC방법이다. 앞에서 설명한 Concurrent GC와 비슷하게, 의도 자체는 Full GC에 의해서 Application이 멈추는 시간을 줄이고자 하는데 있다.

Incremental GC의 작동방법은 간단하다. Minor GC가 일어날때 마다 Old영역을 조금씩 GC를 해서 Full GC가 발생하는 횟수나 시간을 줄이는 방법이다.

<그림 9. Incremental GC 개념도>

그림 9에서 보듯이. 왼쪽의 Default GC는 FullGC가 일어난후에나 Old 영역이 Clear된다. 그러나, 오른쪽의 Incremental GC를 보면 Minor GC가 일어난후에, Old 영역이 일부 Collect된것을 볼 수 있다.

Incremental GC를 사용하는 방법은 JVM 옵션에 ?Xinc 옵션을 사용하면 된다.
Incremental GC는 많은 자원을 소모하고, Minor GC를 자주일으키고, 그리고 Incremental GC를 사용한다고 Full GC가 없어지거나 그 횟수가 획기적으로 줄어드는 것은 아니다. 오히려 느려지는 경우가 많다. 필히 테스트 후에 사용하도록 하자.

※ Default GC이외의 알고리즘은 Application의 형태나 HW Spec(CPU수, Hyper threading 지원 여부), 그리고 JVM 버전(JDK 1.4.1이냐 1.4.2냐)에 따라서 차이가 매우 크다. 이론상으로는 실제로 성능이 좋아보일 수 있으나, 운영환경에서는 여러 요인으로 인해서 기대했던것만큼의 성능이 안나올 수 있기 때문에, 실환경에서 미리 충분한 테스트를 거쳐서 검증한후에 사용해야 한다.


5. GC 로그는 어떻게 수집과 분석


JVM에서는 GC 상황에 대한 로그를 남기기 위해서 옵션을 제공하고 있다.
Java 옵션에 ?verbosegc 라는 옵션을 주면되고 HP Unix의 경우 ?verbosegc ?Xverbosegc 옵션을 주면 좀더 자세한 GC정보를 얻을 수 있다. GC 정보는 stdout으로 출력이 되기 때문에 “>” redirection등을 이용해서 file에 저장해놓고 분석할 수 있다.

Example ) java ?verbosegc MyApplication

그럼 실제로 나온 GC로그를 어떻게 보는지를 알아보자.

<그림 5. 일반적인 GC 로그, Windows, Solaris>

<그림 5>는 GC로그 결과를 모아논 내용이다. (실제로는 Application의 stdout으로 출력되는 내용과 섞여서 출력된다.)
Minor GC는 ”[GC “로 표기되고, Full GC는 “[Full GC”로 표기된다.
그 다음값은 Heap size before GC인데,GC 전에 Heap 사용량 ( New/Young 영역 + Old 영역 + Perm 영역)의 크기를 나타낸다.

Heap size after GC는 GC가 발생한후에 Heap의 사용량이다. Minor GC가 발생했을때는 Eden과 Survivor 영역으 GC가 됨으로 Heap size after GC는 Old영역의 용량과 유사하다.(Minor GC에서 GC되지 않은 하나의 Survivor영역내의 Object들의 크기도 포함해야한다.)

Total Heap Size는 현재 JVM이 사용하는 Heap Memory양이다. 이 크기는 Java에서 ?ms와 ?mx 옵션으로 조정이 가능한데. 예를 들어 ?ms512m ?mx1024m로 해놓으면 Java Heap은 메모리 사용량에 따라서 512~1024m사이의 크기에서 적절하게 늘었다 줄었다한다. (이 늘어나는 기준과 줄어드는 기준은 (-XX:MaxHeapFreeRatio와 ?XX:MinHeapFreeRation를 이용해서 조정할 수 있으나 JVM vendor에 따라서 차이가 나기때문에 각 vendor별 JVM 메뉴얼을 참고하기 바란다.) Parameter에 대한 이야기는 추후에 좀더 자세히하도록 하자.

그 다음값은 GC에 소요된 시간이다.

<그림 5>의 GC로그를 보면 Minor GC가 일어날때마다 약 20,000K 정도의 Collection이 일어난다. Minor GC는 Eden과 Suvivor영역 하나를 GC하는 것이기 때문에 New/Young 영역을 20,000Kbyte 정도로 생각할 수 있다.

Full GC때를 보면 약44,000Kbyte에서 1,749Kbyte로 GC가 되었음을 볼 수 있다. Old영역에 큰 데이타가 많지 않은 경우이다. Data를 많이 사용하는 Application의 경우 전체 Heap이 512이라고 가정할때, Full GC후에도 480M정도로 유지되는 경우가 있다. 이런 경우에는 실제로 Application에서 Memory를 많이 사용하고 있다고 판단할 수 있기 때문에 전체 Heap Size를 늘려줄 필요가 있다.

이렇게 수집된 GC로그는 다소 보기가 어렵기 때문에, 좀더 쉽게 분석할 수 있게 하기 위해서 GC로그를 awk 스크립트를 이용해서 정제하면 분석이 용이하다.

<표 2. gc.awk 스크립트>

이 스크립트를 작성한후에 Unix의 awk 명령을 이용해서

% awk ?f gc.awk GC로그파일명

을 쳐주면 아래<표 3>와 같이 정리된 형태로 GC 로그만 추출하여 보여준다.

<표 3. gc.awk 스크립트에 의해서 정재된 로그>

Minor와 Major는 각각 Minor GC와 Full GC가 일어날때 소요된 시간을 나타내며, Alive는 GC후에 남아있는 메모리양, 그리고 Freed는 GC에 의해서 collect된 메모리 양이다.

이 로그파일은 excel등을 이용하여 그래프등으로 변환해서 보면 좀더 다각적인 분석이 가능해진다.

※ JDK 1.4에서부터는 ?XX:+PrintGCDetails 옵션이 추가되어서 좀더 자세한 GC정보를 수집할 수 있다.


※ HP JVM의 GC Log 수집

HP JVM은 전체 heap 뿐 아니라 ?Xverbosegc 옵션을 통해서 Perm,Eden,Old등의 모든 영역에 대한 GC정보를 좀더 정확하게 수집할 수 있다.

Example ) java ?verbosegc ?Xverbosegc MyApplication ß (HP JVM Only)

HP JVM의 GC정보는 18개의 필드를 제공하는데 그 내용을 정리해보면 <표 4.>와 같다.

<GC : %1 %2 %3 %4 %5 %6 %7 %8 %9 %10 %11 %12 %13 %14 %15 %16 %17 %18>

<표 4. HP JVM GC 로그 필드별 의미>

이 로그를 직접 보면서 분석하기는 쉽지가 않다. 그래서, HP에서는 좀더 Visual한 환경에서 분석이 가능하도록 HPJtune이라는 툴을 제공한다. 다음 URL에서 다운로드 받을 수 있다.

http://www.hp.com/products1/unix/java/java2/hpjtune/index.html

<그림 6. HP Jtune을 이용해서 GC후 Old영역의 변화 추이를 모니터링하는 화면>

6. GC 관련 Parameter


GC관련 설정값을 보기전에 앞서서 ?X와 ?XX 옵션에 대해서 먼저 언급하자. 이 옵션들은 표준 옵션이 아니라, 벤더별 JVM에서 따로 제공하는 옵션이기 때문에, 예고 없이 변경되거나 없어질 수 있기 때문에, 사용전에 미리 JVM 벤더 홈페이지를 통해서 검증한다음에 사용해야한다.

1) 전체 Heap Size 조정 옵션

전체 Heap size는 ?ms와 ?mx로 Heap 사이즈의 영역을 조정할 수 있다. 예를 들어 ?ms512m ?mx 1024m로 설정하면 JVM은 전체 Heap size를 application의 상황에 따라서 512m~1024m byte 사이에서 사용하게 된다. 그림2의 Total heap size

메모리가 모자를때는 heap을 늘리고, 남을때는 heap을 줄이는 heap growing과 shirinking 작업을 수행하는데, 메모리 변화량이 큰 애플리케이션이 아니라면 이 min heap size와 max heap size는 동일하게 설정하는 것이 좋다. 일반적으로 1GB까지의 Heap을 설정하는데에는 문제가 없으나, 1GB가 넘는 대용량 메모리를 설정하고자 할 경우에는 별도의 JVM 옵션이 필요한 경우가 있기때문에 미리 자료를 참고할 필요가 있다.

※ IBM AIX JVM의 경우
%export LDR_CNTRL=MAXDATA=0x10000000
%java -Xms1500m -Xmx1500m MyApplication

2) Perm size 조정 옵션

Perm Size는 앞에서도 설명했듯이, Java Application 자체(Java class etc..)가 로딩되는 영역이다. J2EE application의 경우에는 application 자체의 크기가 큰 편에 속하기 때문에, Default로 설정된 Perm Size로는 application class가 loading되기에 모자른 경우가 대부분이기 때문에, WAS start초기나, 가동 초기에 Out Of Memory 에러를 유발하는 경우가 많다.

PermSize는 -XX:MaxPermSize=128m 식으로 지정할 수 있다.
일반적으로 WAS에서 PermSize는 64~256m 사이가 적절하다.

3) New 영역과 Old 영역의 조정New 영역은 ?XX:NewRatio=2 에 의해서 조정이 된다.
NewRatio Old/New Size의 값이다. 전체 Heap Size가 768일때, NewRatio=2이면 New영역이 256m, Old 영역이 512m 로 설정이 된다.
JVM 1.4.X에서는 ?XX:NewSize=128m 옵션을 이용해서 직접 New 영역의 크기를 지정하는 것이 가능하다.

4) Survivor 영역 조정 옵션
-XX:SurvivorRatio=64 (eden/survivor 의 비율) :64이면 eden 이 128m일때, survivor영역은 2m가 된다.

5) -server와 ?client 옵션
JVM에는 일반적으로 server와 client 두가지 옵션을 제공한다.
결론만 말하면 server 옵션은 WAS와 같은 Server환경에 최적화된 옵션이고, client옵션은 워드프로세서와 같은 client application에 최적화된 옵션이다. 그냥 언뜻 보기에는 단순한 옵션 하나로보일 수 있지만, 내부에서 돌아가는 hotspot compiler에 대한 최적화 방법과 메모리 구조자체가 아예 틀리다.

○ -server 옵션

server용 application에 최적화된 옵션이다. Server application은 boot up 시간 보다는 user에 대한 response time이 중요하고, 많은 사용자가 동시에 사용하기 때문에 session등의 user data를 다루는게 일반적이다. 그래서 server 옵션으로 제공되는 hotspot compiler는 java application을 최적화 해서 빠른 response time을 내는데 집중되어 있다.

또한 메모리 모델 역시, 서버의 경우에는 특정 사용자가 서버 운영시간동안 계속 서버를 사용하는게 아니기 때문에 (Login하고, 사용한 후에는 Logout되기 때문에..) 사용자에 관련된 객체들이 오래 지속되는 경우가 드물다. 그래서 상대적으로 Old영역이 작고 New 영역이 크게 배정된다. <그림 7. 참조 >

○ -client 옵션

client application은 워드프로세서 처럼 혼자 사용하는 application이다. 그래서 client application은 response time보다는 빨리 기동되는데에 최적화가 되어 있다. 또한대부분의 client application을 구성하는 object는GUI Component와 같이 application이 종료될때까지 남아있는 object의 비중이 높기 때문에 상대적으로 Old 영역의 비율이 높다.

<그림 7. ?server와 ?client 옵션에 따른 JVM Old와 New영역>

이 두옵션은 가장 간단한 옵션이지만, JVM의 최적화에 아주 큰부분을 차지하고 있는 옵션이기 때문에, 반드시 Application의 성격에 맞춰서 적용하기 바란다.
(※ 참고로, SUN JVM은 default가 client, HPJVM는 default가 server로 세팅되어 있다.)

○ GC 방식에 대한 옵션

GC 방식에 대한 옵션은 앞에서도 설명했지만, 일반적인 GC방식이외에, Concurrent GC,Parallel GC,Inceremental GC와 같이 추가적인 GC Algorithm이 존재한다. 옵션과 내용은 앞장에서 설명한 “다양한 GC알고리즘” 을 참고하기 바란다.


7.JVM GC 튜닝


그러면 이제부터 지금까지 설명한 내용을 기반으로 실제로 JVM 튜닝을 어떻게 하는지 알아보도록 하자.

STEP 1. Application의 종류와 튜닝목표값을 결정한다.

JVM 튜닝을 하기위해서 가장 중요한것은 JVM 튜닝의 목표를 설정하는것이다. 메모리를 적게 쓰는것이 목표인지, GC 횟수를 줄이는것이 목표인지, GC에 소요되는시간이 목표인지, Application의 성능(Throughput or response time) 향상인지를 먼저 정의한후에. 그 목표치에 근접하도록 JVM Parameter를 조정하는것이 필요하다.

STEP 2. Heap size와 Perm size를 설정한다.

-ms와 ?mx 옵션을 이용해서 Heap Size를 정한다. 일반적으로 server application인 경우에는 ms와 mx 사이즈를 같게 하는것이 Memory의 growing과 shrinking에 의한 불필요한 로드를 막을 수 있어서 권장할만하다.

ms와mx사이즈를 다르게 하는 경우는 Application의 시간대별 memory 사용량이 급격하게 변화가 있는 Application에 효과적이다.
PermSize는 JVM vendor에 따라 다소 차이가 있으나 일반적으로 16m정도이다. Client application의 경우에는 문제가 없을 수 있지만, J2EE Server Application의 경우 64~128m 사이로 사용이 된다.

Heap Size와 Perm Size는 아래 과정을 통해서 적정 수치를 얻어가야한다.

STEP 3. 테스트 & 로그 분석.

JVM Option에 GC 로그를 수집하기 위한 ?verbosegc 옵션을 적용한다. (HP의 경우 ?Xverbosegc 옵션을 적용한다.)

LoadRunner나 MS Strest(무료로 MS社의 홈페이지에서 다운로드 받을 수 있다.)와 같은 Strest Test툴을 통해서 Application에 Strest를 줘서. 그 log를 수집한다. 튜닝에서 있어서 가장 중요한것은 목표산정이지만, 그만큼이나 중요한것은 실제 Tuning한 Parameter가 Application에 어떤 영향을 주는지를 테스트하는 방법이 매우 중요하다. 그런 의미에서 적절한 Strest Tool의 선정과, Strest Test 시나리오는 정확한 Tuning을 위해서 매우 중요한 요인이다.

○ Perm size 조정
아래 그림8.은 HP JVM에서 ?Xverbosegc 옵션으로 수집한 GC log를 HP Jtune을 통해서 graph로 나타낸 그래프이다. 그림을 보면 Application이 startup되었을때 Perm 영역이 40m에서. 시간이 지난후에도 50m 이하로 유지되는것을 볼 수 있다. 특별하게 동적 classloading등이 수십m byte가 일어나지 않는등의 큰 변화요인이 없을때, 이 application의 적정 Perm 영역은 64m로 판단할 수 있다.

<그림 8. GC 결과중 Perm 영역 그래프>

○ GC Time 수행 시간 분석

다음은 GC에 걸린 시간을 분석해보자. 앞에 강좌 내용에서도 설명햇듯이. GC Tuning에서 중요한 부분중 하나가 GC에 소요되는 시간 특히 Full GC 시간이다.

지금부터 볼 Log는 모社의 물류 시스템의 WAS 시스템 GC Log이다. HP JVM을 사용하며, -server ?ms512m ?mx512m 옵션으로 기동되는 시스템이다.

그림 9를 보면 Peak 시간 (첫번째 동그라미) 14시간동안에 Full GC(동그란점)가 7번일어난것을 볼 수 있다. 각각에 걸린 시간은2.5~6sec 사이이다.
여기서 STEP 1.에서 설정한 AP Tuning의 목표치를 참고해야하는데.

Full GC가 길게 일어나서 Full GC에 수행되는 시간을 줄이고자 한다면 Old 영역을 줄이면 Full GC가 일어나는 횟수는 늘어나고, 반대로 Full GC가 일어나는 시간을 줄어들것이다.

반대로 Full GC가 일어나는 횟수가 많다면, Old 영역을 늘려주면 Full GC가 일어나는 횟수는 상대적으로 줄어들것이고 반대로 Full GC 수행시간이 늘어날 것이다.

특히 Server Application의 경우Full GC가 일어날때는 JVM자체가 멈춰버리기 때문에, 그림 9의 instance는 14시간동안 총 7번 시스템이 멈추고, 그때마다 2.5~6sec가량 시스템이 response를 못하는 상태가 된것이다. 그래서 멈춘 시간이 고객이 납득할만한 시간인지를 판단해야 하고, 거기에 적절한 Tuning을 해야한다.

Server Application에서 Full GC를 적게일어나게하고, Full GC 시간을 양쪽다 줄이기 위해서는 Old영역을 적게한후에, 여러개의 Instance를 동시에 뛰어서 Load Balancing을 해주면, Load가 분산되기 때문에 Full GC가 일어나는 횟수가 줄어들테고, Old 영역을 줄였기 때문에, Full GC에 드는 시간도 줄어들것이다. 또한 각각의 FullGC가 일어나는동안 하나의 서버 instance가 멈춰져 있어도, Load Balancing이 되는 다른 서버가 response를 하고 있기때문에, Full GC로 인한 Application이 멈추는것에 의한 영향을 최소화할 수 있다.

<그림 9. GC 소요시간>

데이타에 따라서 GC Tuning을 진행한후에는 다시 Strest Test를 진행해서 응답시간과 TPS(Throughput Per Second)를 체크해서 어떤 변화를 주었는지를 반드시 체크해봐야한다.

<그림 10. GC후의 Old 영역>

그림 10은 GC후에 Old 영역의 메모리 변화량을 나타낸다.

금요일 업무시간에 메모리 사용량이 올라가다가. 주말에가서 완만한 곡선을 그리는것을 볼 수 있다. 월요일 근무시간에 메모리 사용량이 매우 많고, 화요일에도 어느정도 메모리 사용량이 있는것을 볼 수 있다. 월요일에 메모리 사용량이 많은것을 볼때, 이 시스템의 사용자들이 월요일에 시스템 사용량이 많을 수 있다고 생각할 수 있고, 또는 다른 주의 로그를 분석해봤을때 이 주만 월요일 사용량이 많았다면, 특별한 요인이나 Application 변경등이 있었는지를 고려해봐야할것이다.

이 그래프만을 봤을때 Full GC가 일어난후에도 월요일 근무시간을 보면 Old 영역이 180M를 유지하고 있는것을 볼 수 있다. 이 시스템의 Full GC후의 Old영역은 80M~180M를 유지하는것을 볼 수 있다. 그래서 이 시스템은 최소 180M이상의 Old 영역을 필요로하는것으로 판단할 수 있다.

STEP 4. Parameter 변경.
STEP 3에서 구한 각 영역의 허용 범위를 기준으로 Old영역과 New 영역을 적절하게 조절한다.
PermSize와 New영역의 배분 (Eden,Survivor)영역등을 조정한다.
PermSize는 대부분 Log에서 명확하게 나타나기 때문에, 크게 조정이 필요가 없고 New영역내의 Eden과 Survivor는 거의 조정하지 않는다. 가장 중요한것은 Old영역과 New 영역의 비율을 어떻게 조정하는가가 관건이다.

이 비율을 결정하면서, STEP1에서 세운 튜닝 목표에 따라서 JVM의 GC Algorithm을 적용한다. GC Algorithm을 결정하는 기본적인 판단 내용은 아래와 같다.

이렇게 Parameter를 변경하면서 테스트를 진행하고, 다시 변경하고 테스트를 진행하는 과정을 거쳐서 최적의 Parameter와 GC Algorithm을 찾아내는것이 JVM의 메모리 튜닝의 이상적인 절차이다.


지금까지 JVM의 메모리 구조와 GC 모델 그리고 GC 튜닝에 대해서 알아보았다.

정리하자면 GC 튜닝은 Application의 구조나 성격 그리고, 사용자의 이용 Pattern에 따라서 크게 좌우 되기때문에, 얼마만큼의 Parameter를 많이 아느냐 보다는 얼마만큼의 테스트와 로그를 통해서 목표 값에 접근하느냐가 가장 중요하다.

iBatis 아파치 홈페이지에가면 한국어로 된 튜토리얼이 있는데 그걸 가져왔습니다.

혹시라도 iBatis 공부하는데 필요한 사람은 다운받아가세용~

invalid-file

invalid-file

invalid-file

1. 웹 서비스 시스템과 클라이언트는 지속적인 연결을 가지지 않는다.
   클라이언트가 웹 서비스 시스템에서 제공하는 메서드를 호출하면, 웹 서비스 시스템은 메소드의 실행 결과를 클라이언트에게 보내주고 나서 즉시 연결을 해제한다
2. 웹 서비스는 상태 정보를 유지하지 않는다.
   클라이언트의 요청을 처리한 후 응답을 보내고 나서 즉시 연결이 해제되기 때문에 이전 클라이언트의 상태 정보를 웹 서비스는 유지하지 않는다. 이전에 접속한 클라이언트가 다시 접속하게 되면 새로운 클라이언트 접속으로 취급한다.
3. 사용하는 프로토콜은 XML 기반의 SOAP이다.
   웹 서비스와 클라이언트 간의 프로토콜로서 사용되는 것은 XML 기반의 SOAP이다. XML기반이 아주 중요한 의미를 가지는데 이것은 곧 플랫폼 중립적인 프로토콜을 말한다.
4. 기존의 다른 프로토콜로 구현된 분산 컴포넌트 환경을 통합시킬 수 있다.
   기존의 다른 프로토콜로 구현된 분산 컴포넌트 환경을 통합하는 것이 가능하다.인터넷상에서의 분산 컴퓨팅이 가능하다.
5. 웹 서비스와 클라이언트는 SOAP을 사용해서 요청 및 응답을 한다. SOAP는 HTTP 전송 프로토콜에 의해서 운반될 수 있다. 방화벽은 일반적으로 HTTP 프로토콜은 통과시키기 때문에 SOAP 역시 통과될 수 있다. 이것은 큰 장점인 동시에 큰 단점으로 작용할 수 있다. 익명의 SOAP이 중요한 기능의 메소드를 실행시킬 수 있기 때문이다.
   

XPath uses path expressions to select nodes or node-sets in an XML document. The node is selected by following a path or steps.

The XML Example Document

We will use the following XML document in the examples below.

<?xml version="1.0" encoding="ISO-8859-1"?>

<bookstore>

<book>
  <title lang="eng">Harry Potter</title>
  <price>29.99</price>
</book>

<book>
  <title lang="eng">Learning XML</title>
  <price>39.95</price>
</book>

</bookstore>

Selecting Nodes

XPath uses path expressions to select nodes in an XML document. The node is selected by following a path or steps. The most useful path expressions are listed below:

Examples

In the table below we have listed some path expressions and the result of the expressions:

Predicates

Predicates are used to find a specific node or a node that contains a specific value.

Predicates are always embedded in square brackets.

Examples

In the table below we have listed some path expressions with predicates and the result of the expressions:

Selecting Unknown Nodes

XPath wildcards can be used to select unknown XML elements.

Examples

In the table below we have listed some path expressions and the result of the expressions:

Selecting Several Paths

By using the | operator in an XPath expression you can select several paths.

Examples

In the table below we have listed some path expressions and the result of the expressions:

Core J2EE Pattern Catalog

Core J2EE Patterns - Business Delegate

Context

멀티 티어, 분산된 시스템은 티어들 사이에 데이터를 보내고 받기 위한 RMI(remote method invocations)가 필요하다. 클라이언트들은 분산된 컴포넌트들을 다루어야 하는 복잡성에 노출되어 있다.

Problem

프리젠테이션-티어 컴포넌트들은 비지니스 서비스들과 직접적으로 상호 작용한다. 이런 직접적인 상호 작용은 프리젠테이션 티어에 대한 비지니스 서비스 API(application program interface)의 기본적인 구현 상세사항들을 외부에 노출한다. 결과적으로, 프리젠테이션-티어 컴포넌트들은 비지니스 서비스들의 구현을 바꾸는것에 취약하다: 비지니스 서비스의 구현이 바뀌면 프리젠테이션 티어에서 외부에 노출된 구현 코드또한 바뀌어야 한다.

또한, 그것들은 네트웍 성능상 불리한 요소가 될 것이다. 비지니스 서비스 API를 사용하는 프리젠테이션-티어 컴포넌트들이 네트웍 상에 너무많은 호출을 만들기 때문이다. 이것은 프리젠테이션-티어 컴포넌트들이 클라이언트 쪽의 캐쉬 메카니즘 또는 서비스를 모으는일 없이 기본적인 API를 직접적으로 사용할때 발생한다.

마지막으로, 서비스 API들을 직접적으로 외부에 노출하는 것은 EJB(Enterprise JavaBeans) 기술의 분산된 특성들에 대한 네트웍관련 문제점을 클라이언트가 다루게 한다.

Forces
● 프리젠테이션-티어 클라이언트들이 비지니스 서비스에 접근해야 한다.

● 다양한 클라이언트들(디바이스들, 웹 클라이언트들, thick 클라이언트들)이 비지니스 서비스에 접근해야 한다.
● 비지니스 서비스 API들은 비지니스 요구사항들의 변화에 따라 바뀔수 있다.
● 프리젠테이션-티어 클라이언트들과 비지니스 서비스들 간의 결합을 최소화 시키는것이 바람직하다.

    그러므로, lookup과 access과 같은 서비스들의 기본적인 구현 상세 사항들을 숨긴다.
● 클라이언트들은 비지니스 서비스 정보를 위한 캐쉬 메카니즘을 구현해야 할 필요성이 있을 수 있다.
● 클라이언트과 비지니스 서비스들 간의 네트웍 트래픽을 줄이는 것이 바람직 하다.

※ thick 클라이언트
Thick 클라이언트는 Rich 클라이언트라고 지칭 되기도 한다. Thick 클라이언트의 대표적인 예 가 될 수 있는 환경으로는 금융권 사이트들을 들 수 있다. 키보드의 후킹(키보드로 보낸 메시지를 가로채는 작업)과 같은 작업을 보안하기 위해서는 클라이언트는 반드시 보안 모듈을 포함해야만 한다. 모듈을 배포하는 예로서는 ActiveX가 될 수가 있다. 하지만 ActiveX는 보안의 문제와 배포, 생산성 저하라는 단점들을 가지고 있다. 이와 반대로 Thin 클라이언트는 순수한 웹사이트를 그려보면 될 것이다. Thin 클라이언트는 배포가 쉽고, 유지할 수 있는 장점이 있는 반면에 사용자를 100% 만족시키지 못한다. 즉, 브라우저 기술의 한계가 나타나게 되는 것이다.

Solution(해결방안)
프리젠테이션-티어 클라이언트들과 비지니스 서비스들 간의 결합을 줄이기 위해 Business Delegate를 사용하라. Business Delegate는 EJB 기술의 lookup과 access와 같은 비지니스 서비스의 기본적인 구현 상세 사항들을 숨긴다.

Business Delegate는 클라이언트-측 비지니스 abstraction 처럼 동작한다; 이것은 비지니스 서비스들의 구현을 위한 abstraction을 제공하며 서비스들을 숨긴다. Business Delegate를 사용하면 프리젠테이션-티어 클라이언트들과 시스템의 비지니스 서비스들간의 결합을 줄인다. 구현 전략에 따라 Business Delegate는 비지니스 서비스 API의 구현안에서 발생 할 수 있는 휘발성(※서비스가 없어지는경우?)으로 부터 클라이언트들을 보호한다. 잠재적으로 이것은 비지니스 서비스 API 또는 이것의 기본적인 구현이 변할때 프리젠테이션-티어 클라이언트 코드가 수정되어야 하는 수를 감소시킨다.

그럼에도 불구하고, 기본적인 비지니스 서비스 API가 바뀌면 Business Delegate 안의 인터페이스 함수들은 여전히 수정을 필요로 할 수도 있다. 그렇지만, Business Delegate 보다 비지니스 서비스가 바뀌는 경우가 더 일반적인 경우일 것이다.

때때로, 개발자들은 비지니스 레이어를 추상화 하는것과 같은 미래에 이익이 될만한 디자인 목표가 추가적인 선행 작업을 야기시키는 것에 대해 회의적이다.

그럼에도 불구하고, 이 패턴 또는 이것의 전략들을 이용하는 것은 작은 양의 추가적인 선행 작업만으로 중요한 이점들을 제공하는 결과를 가져온다.

중요한 이점은 기본적인 서비스의 상세 사항을 숨기는 것이다. 예를 들면, 클라이언트는 naming과 lookup 서비스들에 대해 명쾌해 진다.

또한 Business Delegate는 비지니스 서비스들로 부터의 예외(java.rmi.Remote exceptions, Java Messages Service (JMS) exceptions 등등)를 처리한다.

Business Delegate는 서비스 레벨의 예외들을 중간에 가로채고 대신에 어플리케이션 레벨의 예외들을 생성한다.

어플리케이션 레벨의 예외들은 클라이언트에 의해 처리되기가 더욱 쉽고 사용자에게 친숙 할 것이다.

또한 Business Delegate는 서비스 실패시 발생하는 이벤트에서 필요한 모든 retry 또는 recovery 오퍼레이션들을 해결하지 못 할 문제라고 결정되기 전까지 클라이언트에 문제점을 노출하지 않고 명쾌하게 수행한다. 이런 점들이 패턴을 사용하는 이유이다.

또다른 이점은 delegate가 결과들을 캐쉬 할 수 있고 리모트 비지니스 서비스들을 참조 할 수 있다는 것이다.

캐쉬는 네트웍을 통한 불필요하고 값비싼 왕복들(round trips)을 제한하기 때문에 성능을 매우 많이 향상 시킨다.

Business Delegate는 Lookup 서비스에 의해 호출되는 컴포넌트를 이용한다.

Lookup 서비스는 비지니스 서비스 lookup 코드의 기본적 상세 구현을 숨길 책임이 있다.

Lookup Service는 Delegate의 일부분으로 작성될 수 있지만 우리는 Service Locator 패턴이 적용된 분리된 컴포넌트로 구현되기를 추천한다. (368 페이지의 "Service Locator" 참조.)

Business Delegate가 Session Facade와 함께 사용될때 일반적으로 둘 사이에 one-to-one 관계가 성립한다.

이런 one-to-one 관계는 여러개의 비지니스 서비스들과 상호작용 하는것(one-to-many 관계를 생성하는것)과 관련된 Business Delegate안에 캡슐화 되어져 있을 수 있는 로직이 때때로 Session Facade를 하나의 요인으로 다시 포함되기 때문에 존재한다.

마지막으로, 이 패턴이 간단히 프리젠테이션과 비지니스 티어들이 아니라, 다른 티어들간의 결합을 줄이는데 사용될수 있다는 것이 주목받을 만한 것이다.

Structure(구조)

Figure 8.1은 Business Delegate 패턴을 표현하는 클래스 다이어그램을 보여준다. 클라이언트는 기본적인 비지니스 서비스에의 접근을 제공하기 위해 BusinessDelegate를 요청한다. BusinessDelegate는 요청된 BusinessService 컴포넌트를 얻기 위해 LookupService를 이용한다.

Figure 8.1 BusinessDelegate class diagram

Participants and Responsibilities

Figure 8.2 와 Figure 8.3 은 Business Delegate 패턴의 일반적인 상호작용을 설명하는 시퀀스 다이어그램을 보여준다.

Figure 8.2 BusinessDelegate sequence diagram

BusinessDelegate는 business service를 얻기위해 LookupService를 이용한다. business service는 클라이언트 관점에서 보면 비지니스 함수들을 호출하기 위해 사용된다. Get ID 함수는 BusinessDelegate가 비지니스 서비스를 위한 handle(예, EJBHandle 객체)의 String 버젼을 얻은다음 클라이언트에 String으로 리턴 할 수 있다는 것을 보여준다. 클라이언트는 나중에 비지니스 서비스에 다시 연결하기 위해 handle을 얻었을때 사용된 handle의 String 버젼을 이용할 수 있다. 이 기술은 새로운 lookup들을 피하려고 한다, handle은 이것의 비지니스 인스턴스에 다시 접속할 수 있는 능력이 있기 때문이다.

handle 객체들이 컨테이너 제공자에 의해 구현되었으며 다른 벤더들이 만든 컨테이너들 에서는 사용할 수 없다는 것을 주의하라.

Figure 8.3 의 시퀀스 다이어그램은 handle을 이용해 BusinessService(예, session 또는 entity bean)를 얻는 것을 보여준다.

Figure 8.3 BusinessDelegate with ID sequence diagram

BusinessDelegate

BusinessDelegate의 역활은 business service의 제어와 보호이다. BusinessDelegate는 클라이언트에 2가지 타입으로 노출될 수 있다. 첫번째 요청 타입은 ID없이 BusinessDelegate를 설명한다, 반면 다른 하나는 ID를 가지고 설명한다, ID는 EJBHome 또는 EJBObject와 같은 remote object 참조의 String version 이다.

ID없이 초기화 할때 BusinessDelegate는 Lookup 서비스로 부터 서비스를 요청한다. 일반적으로 EJBHome 같은 Service Factory를 리턴하는 Service Locator 로서 구현된다. (368 페이지의 "Service Locator" 참조) BusinessDelegate는 Service Factory가 enterprise bean 같은 BusinessService를 얻고, 생성하고, 또는 제거하는 것을 요청한다.

ID string을 가지고 초기화 할때 BusinessDelegate는 BusinessService에 재접속하기 위해  ID string을 사용한다. 그러므로, BusinessDelegate는 BusinessService의 naming과 lookup의 기본적 상세 구현 으로부터 클라이언트를 보호한다. 여기에 더해, 프리젠테이션-티어 클라이언트는 결코 BusinessSession에 원격 호출을 직접적으로 하지 않는다; 대신에, 클라이언트는 BusinessDelegate를 이용한다.

LookupService

BusinessDelegate는 BusinessService를 얻기위해 LookupService를 이용한다. LookupService는 BusinessService lookup의 상세 구현을 갭슐화 한다.

BusinessService

BusinessService는 클라이언트에 요청된 서비스를 제공하는 비지니스-티어 컴포넌트(예, enterprise bean 또는 JMS component) 이다.

Strategies(전략)

Delegate Proxy Strategy

Business Delegate는 business service API의 기본 함수들을 클라이언트가 접근할 수 있게 하기위한 인터페이스를 외부에 노출한다. 이 전략에서, Business Delegate가 클라이언트 함수들을 session bean에 넘기는 proxy 기능을 제공하는 이것은 갭술화 이다. Business Delegate는 추가적으로 필요한 모든 데이터(lookup횟수를 줄여 성능향상을 얻을 수 있는 세션빈의 홈 또는 리모트 객체들의 리모트 참조)를 캐쉬 할 수 있다. Business Delegate는 또한 Service Locator의 서비스들을 이용해 이런 참조들을 String versions (IDs) 바꿀 수 있으며 그 반대도 가능하다.

이 전략을 위한 예제 구현은 이 패턴의 "Sample Code" 섹션에서 논의된다.

Delegate Adapter Strategy

Business Delegate는 Java 2 플랫폼, Enterprise Edition (J2EE) 기반의 서비스와 통신하는 B2B 환경에 매우 적합하다. 다른 종류의 시스템들은 통합 언어로 XML을 사용할 것이다. 어떤 시스템을 다른 시스템에 통합하는 것은 일반적으로 두개의 다른 시스템들을 통합하기 위한 Adapter [GoF] 를 필요로 한다. Figure 8.4 에서 예제를 볼수 있다.

Figure 8.4 Using the Business Delegate pattern with an Adapter strategy

Consequences (결론)

Reduces Coupling, Improves Manageability (결합을 줄이고, 관리성을 향상시킨다)
Business Delegate는 비지니스-티어 상세 구현을 숨김으로서 프리젠테이션 티어과 비지니스 티어간의 결합을 줄인다. 이것은 Business Delegate라는 하나의 공간에 집중화 시킴으로서 변화를 관리하기 더 쉽다.

Translates Business Service Exceptions (비지니스 서비스 예외들을 변환한다)
Business Delegate는 network 또는 infrastructure-related 예외들을 비지니스 예외들로 변환하고 기본적인 구현 명세서의 정보로 부터 클라이언트들을 보호하는데 적합하다.

Implements Failure Recovery and Thread Synchronization (실패 복구와 스레드 동기화를 구현한다)
비지니스 서비스 실패가 발생하면 Business Delegate는 클라이언트에 문제를 노출하지 않고 자동 복구 기능을 실행할 수 있다. 복구가 성공적으로 이루어 지면 크라이언트는 이 실패에 대해 알 필요가 없다. 만약 복구시도가 성공적이지 못하면 Business Delegate는 실패에 대해 클라이언트에 알릴 필요가 있다. 추가적으로, 만약 필요하면 비지니스 delegate 함수들은 동기화(synchronized) 될수 있다.

Exposes Simpler, Uniform Interface to Business Tier (비지니스 티어에 간결하고 일관된 인터페이스를 노출한다)
클라이언트에 더 나은 서비스를 하기위해 Business Delegate는 기본적인 엔터프라이즈 빈들에 의해 제공되는 다양한 인터페이스를 제공 할수도 있다.

Impacts Performance (성능 효과)
Business Delegate는 공통적인 서비스 요청들을 위해 프리젠테이션 티어에 캐쉬 서비스(그리고 더 좋은 성능)를 제공할 수 있다.

Introduces Additional Layer (추가적인 레이어 삽입)
Business Delegate는 클라이언트와 서비스 사이의 불필요한 레이어의 추가로 인해 추가적인 복잡성이 추가되고 유연성을 줄이는 것으로 보여질 수 있다. 어떤 개발자들은 Delegate Proxy 전략을 이용한 구현들을 가지고 Business Delegates를 개발하는 것은 불필요한 노력을 들이는 것으로 느낄수 있다. 그렇지만, 일반적으로 그런 약점들 보다  패턴이 주는 잇점들이 더 중요하다.

Hides Remoteness (원격특성들을 숨긴다)
location의 명쾌함이 이 패턴이 주는 잇점중 하나인 반면, 개발자가 로컬에 있는 remote service를 다루기 때문에 다양한 문제점이 발생 할 수 있다. 만약 클라이언트 개발자가 Business Delegate는 remote service의 클라이언트 측 프록시라는 것을 이해하지 못하면 이런 문제점이 발생할 수 있다. 일반적으로, Business Delegate에 있는 함수 호출은 내부에 있는 원격 함수 호출의 결과를 가져온다. 이것을 무시하고 개발자가 단일 업무를 수행하기 위해 많은 양의 함수 호출을 만들려고 시도한다면 네트웍 트래픽을 증가시킬 것이다.

Sample Code (예제 코드)

Implementing the Business Delegate Pattern (Business Delegate 패턴 구현)

Professional Services Application (PSA) 를 고려하는 웹-티어 클라이언트는 Session Facade 패턴을 구현하는 세션빈에 접근하기를 필요로한다. Business Delegate 패턴은 ResourceDelegate(Delegate class)를 디자인하기 위해 적용될 수 있다. ResourceDelegate는 ResourceSession(session bean)을 다루를 복잡성을 갭슐화 한다. ResourceDelegate는 Example 8.1 에서 보여지는 이 예제를 구현한다. 그리고 상응하는 원격 인터페이스인 ResourceSession(Session Facade bean)은 Example 8.2 에서 볼수 있다.

Example 8.1 Implementing Business Delegate Pattern - ResourceDelegate

------------------------------------------------------------------------------------------------

// imports
...

public class ResourceDelegate {

  // Remote reference for Session Facade
  private ResourceSession session;

  // Class for Session Facade's Home object
  private static final Class homeClazz =
  corepatterns.apps.psa.ejb.ResourceSessionHome.class;

  // Default Constructor. Looks up home and connects
  // to session by creating a new one
  public ResourceDelegate() throws ResourceException {
    try {
      ResourceSessionHome home = (ResourceSessionHome)
        ServiceLocator.getInstance().getHome(
          "Resource", homeClazz);
      session = home.create();
    } catch(ServiceLocatorException ex) {
      // Translate Service Locator exception into
      // application exception
      throw new ResourceException(...);
    } catch(CreateException ex) {
      // Translate the Session create exception into
      // application exception
      throw new ResourceException(...);
    } catch(RemoteException ex) {
      // Translate the Remote exception into
      // application exception
      throw new ResourceException(...);
    }
  }

  // Constructor that accepts an ID (Handle id) and
  // reconnects to the prior session bean instead
  // of creating a new one
  public BusinessDelegate(String id)
    throws ResourceException {
    super();
    reconnect(id);
  }

  // Returns a String ID the client can use at a
  // later time to reconnect to the session bean
  public String getID() {
    try {
      return ServiceLocator.getId(session);
    } catch (Exception e) {
      // Throw an application exception
    }
 }

  // method to reconnect using String ID
  public void reconnect(String id)
    throws ResourceException {
    try {
      session = (ResourceSession)
                ServiceLocator.getService(id);
    } catch (RemoteException ex) {
      // Translate the Remote exception into
      // application exception
      throw new ResourceException(...);
    }
  }

  // The following are the business methods
  // proxied to the Session Facade. If any service
  // exception is encountered, these methods convert
  // them into application exceptions such as
  // ResourceException, SkillSetException, and so
  // forth.

  public ResourceTO setCurrentResource(
    String resourceId)
    throws ResourceException {
    try {
      return session.setCurrentResource(resourceId);
    } catch (RemoteException ex) {
      // Translate the service exception into
      // application exception
      throw new ResourceException(...);
    }
  }

  public ResourceTO getResourceDetails()
    throws ResourceException {

    try {
      return session.getResourceDetails();
    } catch(RemoteException ex) {
      // Translate the service exception into
      // application exception
      throw new ResourceException(...);
    }
  }

  public void setResourceDetails(ResourceTO vo)
    throws ResourceException {
    try {
      session.setResourceDetails(vo);
    } catch(RemoteException ex) {
      throw new ResourceException(...);
    }
  }

  public void addNewResource(ResourceTO vo)
    throws ResourceException {
    try {
      session.addResource(vo);
    } catch(RemoteException ex) {
      throw new ResourceException(...);
    }
  }

  // all other proxy method to session bean
  ...
}

------------------------------------------------------------------------------------------------

Example 8.2 Remote Interface for ResourceSession

------------------------------------------------------------------------------------------------

// imports
...
public interface ResourceSession extends EJBObject {

  public ResourceTO setCurrentResource(
    String resourceId) throws
    RemoteException, ResourceException;

  public ResourceTO getResourceDetails()
     throws RemoteException, ResourceException;
  public void setResourceDetails(ResourceTO resource)
     throws RemoteException, ResourceException;

  public void addResource(ResourceTO resource)
      throws RemoteException, ResourceException;

  public void removeResource()
      throws RemoteException, ResourceException;

  // methods for managing blockout time by the
  // resource
  public void addBlockoutTime(Collection blockoutTime)
      throws RemoteException, BlockoutTimeException;

  public void updateBlockoutTime(
    Collection blockoutTime)
      throws RemoteException, BlockoutTimeException;

  public void removeBlockoutTime(
    Collection blockoutTime)
      throws RemoteException, BlockoutTimeException;

  public void removeAllBlockoutTime()
      throws RemoteException, BlockoutTimeException;

  // methods for resource skillsets time by the
  //resource
  public void addSkillSets(Collection skillSet)
      throws RemoteException, SkillSetException;

  public void updateSkillSets(Collection skillSet)
      throws RemoteException, SkillSetException;

  public void removeSkillSet(Collection skillSet)
      throws RemoteException, SkillSetException;

  ...
}

------------------------------------------------------------------------------------------------

Related Patterns (관련 패턴)

● Service Locator
Service Locator 패턴은 Business Delegate의 Service Locator를 생성하고 모든 비지니스 서비스의 lookup과 access 코드의 상세 구현을 숨기는데 사용될 수 있다.

● Proxy [GoF]
Business Delegate는 프락시 처럼 동작하고 비지니스 티어안의 객체들을 위해 대리인 역활(stand-in)을 제공 할 수 있다.

● Adapter [GoF]
Business Delegate는 서로다른 시스템들을 위한 결합을 제공하는 Adapter 패턴을 사용 할 수 있다.

● Broker [POSA1]
Business Delegate는 다른 티어들안의 클라이언트들로 부터 비지니스 티어 객체들을 분리하는 broker 역활을 수행한다.

원본 : http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html

번역 : 김운주 ounju@naver.com