 |
|
난이도 : 중급 Gary Karasiuk, Rational Application Developer Performance Analyst, IBM Toronto Lab Jason Sholl, Software Engineer, IBM
2008 년 8 월 05 일 이 글은 IBM® Rational® Application Developer에서 프로젝트 일부분을 소스 형식으로, 또 다른 부분을 바이너리 형식으로 유지하는 방법과 일상적인 연산을 수행할 때 속도를 향상시키는 방법을 소개합니다.
애플리케이션이 커질수록 애플리케이션의 모든 것을 작업 공간에 소스 형식으로 저장하기란 불가능하다. 거대한 작업 공간에는 백 개 이상의 프로젝트가 포함되어 있을지도 모른다. 하지만 모든 개발자가 매일 모든 프로젝트를 수정한다는 것은 시간 낭비다. 더 좋은 방법은 수정하려는 프로젝트나 모듈만 소스 형식으로 유지하고 바이너리 형식으로 사용하려는 프로젝트나 모듈은 바이너리 상태 그대로 두는 것이다. 이렇게 하면 IBM® Rational® Application Developer의 메모리 사용을 대폭 줄일 수 있고 일반적인 개발 속도를 크게 향상시킬 수 있다. 이렇게 해도 바이너리 프로젝트 내의 소스 코드를 볼 수 있고, 자주 사용하는 Open Declaration(F3) 같은 대부분의 생산적 연산을 수행할 수 있다.
고객의 작업 공간 중 하나를 예로 들어보겠다. 전체 작업 공간이 소스 형식이면 이를 빌드하는 데 27분이 걸린다. 대부분의 모듈이 바이너리 형식으로 되어 있으면 빌드 시간은 3분으로 줄어든다. 이 글 뒷부분에 있는 실제 테스트 절에서 이와 관련된 더 자세한 내용을 참조하기 바란다.
이 글을 통해 여러분의 작업 환경에서 바이너리 모듈을 어떻게 활용할 수 있는지 단계별로 소개하겠다. 여기서는 독자들이 EAR 프로젝트를 개발하고 있으며 소스 컨트롤을 사용한다고 가정한다. 이 글은 Rational Application Developer 7.0.0.3 버전 및 그 이상의 버전을 기준으로 썼다. 7.0.0.3 이전 버전에는 새로 공유된 EAR 파일에 대한 지원이 없다.
여기서 제공하는 많은 팁은 Rational® Software Architect, Rational® Software Modeler, Rational® Web Developer 등 다른 IBM Rational 제품에도 적용된다.
단계별 접근
기본 실습은 한 개발자가 한 번에 프로젝트의 하위 세트를 변경하는 것만으로 그친다. 애플리케이션의 모든 부분을 소스 형식으로 보고자 할 수도 있지만 필요할 때마다 프로젝트 목록을 변경할 수 있으므로 언제든 변경할 수 있는 프로젝트 목록에 추가가 가능하다.
기본적인 접근은 아주 간단하다.
- 소스 코드가 포함된 완전한 애플리케이션을 포함하는 EAR 파일을 시작한다.
- 이 EAR 파일을 임포트하면 이것이 기본이 된다. 일반적으로 이 EAR 파일은 하룻밤 혹은 한 주간의 빌드 프로세스에서 온다.
- 그러고 나서 소스 컨트롤에서 변경하고자 하는 프로젝트나 모듈을 임포트한다.
예제 애플리케이션
이 글은 J2EE(Java™ 2 Platform, Enterprise Edition) 애플리케이션을 개발하며 부딪히는 프로젝트의 주요 유형을 각각 실행 예제(다운로드절 참조)를 통해 소개한다.
-
SampleEAR: EAR 자체에 SampleThirdParty.jar라는 바이너리 써드파티 JAR(Java Archive) 파일 또한 포함되어 있다.
-
SampleEJBClient: EJB 프로젝트 예제의 클라이언트 부분
-
SampleUtility: 유틸리티 프로젝트 예제
애플리케이션에는 더 많은 프로젝트가 있기 마련이지만 이 예제에는 J2EE 프로젝트의 주요 유형이 포함되어 있다(그림 1).
그림 1. 예제 애플리케이션
EAR 만들기
보통 EAR은 자동화된 빌드 프로세스 같은 것을 통해 만든다. 일반적으로 대다수의 고객은 하룻밤 혹은 한 주간의 빌드를 만들지만 이 예제에서는 수동으로 EAR을 만드는 방법을 보여줄 것이다.
- 애플리케이션에 EJB가 있다면 익스포트를 하기 전에 EAR이 배치 준비됐는지 확인해야 한다(그림 2).
- 그림 3처럼 Export Shared EAR file 마법사를 사용해 EAR 파일을 익스포트한다.
그림 2. 배치 준비
그림 3. EAR 파일 익스포트하기
- 그림 3과 같이 헬퍼 플러그인으로 새로운 shared EAR file 메뉴 아이템이 추가됐다.
주의:
이를 자동화된 빌드 프로세스의 한 부분으로 통합하려면 추가로 다음 단계를 거쳐야 한다(Export > Shared EAR file 메뉴 아이템을 사용한다면 아래 단계는 무시한다).
- Rational Application Developer 7.0.0.3에서 EAR이 익스포트된 후 다음 두 가지 특별한 파일을 EAR에 수동으로 추가하자.
-
.settings\com.ibm.etools.j2ee.teamshare: 이 파일은 marker 파일로 내용은 중요하지 않다. 이 파일에 "marker"라는 단어를 넣어 빈 파일이 되지 않도록 한다.
-
.settings\org.eclipse.wst.common.component: 이 파일은 소스 작업 공간의 EAR 프로젝트에서 가져와야 한다.
- 이 두 파일은 파일 시스템 어디에나 복사해도 된다(그림 4).
- 그러고 나서 파일 압축 유틸리티를 사용해 이 파일들을 EAR 파일에 압축하는데 다음과 같은 명령을 사용한다.
>
zip -r SampleEAR.ear .settings/*.
이제 EAR 파일에는 원래 파일과 수동으로 추가한 파일 두 개(그림 4)가 포함되어 있다.
그림 4. 작업 공간 내의 수정된 EAR 파일
EAR 임포트하기
팀 세팅시 각 개발자는 기존에 익스포트된 EAR 파일을 임포트하는 것으로 시작한다.
- J2EE 화면에서 Import를 선택한다(그림 5).
- Import 창에서 Shared EAR file을 선택한다(그림 6).
- Shared EAR import 창의 화살표를 사용해 name of the file, the name of the project, the runtime target server를 선택한다(그림 7).
그림 5. 시작을 위해 Import 선택
그림 6. 임포트할 파일 선택
그림 7. 파일 이름, 프로젝트 이름, 런타임 서버 선택
- SampleEAR 프로젝트를 닫았다가 다시 연다(이렇게 하면 Rational Application Developer의 동기화 버그에서 벗어날 수 있다).
- 프로젝트를 다시 열면 작업 공간은 그림 8처럼 보인다. 모든 모듈이 바이너리 모듈인 것을 볼 수 있다.
그림 8. 프로젝트를 임포팅한 후의 화면 뷰
- 이제 애플리케이션을 배치, 실행할 준비가 됐다.
바이너리 모듈을 소스 모듈로 바꾸기
기본을 갖췄으니 이제 변경할 프로젝트를 임포트해야 한다.
-
웹 모듈
- 소스 컨트롤에서 웹 모듈을 임포트하는 데 일반적인 기술을 사용한다. 예를 들어 그림 9와 10처럼 오픈 소스인 CVS(Concurrent Version System)를 사용한다.
- 웹 프로젝트에서 원하는 것을 변경한다. 변경 사항은 실행 중인 애플리케이션에 반영될 것이다.
- 원한다면 변경된 사항을 소스 컨트롤 시스템에서 확인할 수 있으므로 다른 사용자나 빌드 프로세스가 이를 잡아낼 수도 있다.
그림 9. CVS 폴더 하의 CVS에서 프로젝트 선택
그림 10. CVS에서 확인할 모듈 선택
-
EJB 모듈
EJB(Enterprise Java Beans) 프로젝트에 대한 접근은 웹 프로젝트의 접근과 같다. 간단히 프로젝트를 확인하자.
-
유틸리티 프로젝트
유틸리티 프로젝트에 대한 접근은 웹 프로젝트의 접근과 같다. 간단히 프로젝트를 확인하자.
소스 모듈을 바이너리 모듈로 바꾸기
소스 모듈을 다시 바이너리 모듈로 바꾸는 것은 매우 쉽다. 작업 공간의 소스 프로젝트를 지운 후 서버에 재발행을 요청하면 된다. 이제 다시 모듈의 바이너리 형식을 사용한다.
웹 프로젝트 삭제하기
IBM® WebSphere® Application Server가 웹 라이브러리 파일 일부에 락(lock)을 걸기 때문에 웹 프로젝트를 지울 수 없다. 그 해결책은 다음과 같다.
- WebSphere 서버를 멈추고 웹 프로젝트를 삭제한다.
- 서버를 다시 시작한 후 EAR도 재시작해야 WAR(Web archive) 파일의 바이너리 버전을 사용할 수 있다.
임시 변경
또한 소스 컨트롤 시스템에서 프로젝트를 임포트하지 않고도 코드를 변경할 수 있다. 밤늦게 일하고 있는데 다른 이의 코드를 잠시 수정한다고 해보자. 이 코드를 다시 확인하기보다는 그저 임시로 변경만 해서 자신의 코드 테스트를 끝내고 싶다.
다음과 같이 하면 EAR에서 직접 바이너리 모듈을 소스 모듈로 전환할 수 있다.
- 마우스 오른쪽 버튼으로 a shared EAR project를 클릭하고 Shared EAR > Extract Binary Modules to Projects를 선택한다(그림 11).
그림 11. 바이너리 모듈을 프로젝트로 뺀다.
- shared EAR 파일과 함께 있는 바이너리 모듈 옆의 박스를 체크해(이 경우에는 SampleUtility.jar 파일) 프로젝트로 뺀다(그림 12).
그림 12. Shared EAR와 함께 있는 바이너리 모듈 선택
- 임포트를 하면 그림 13과 같이 변경 사항을 테스트할 수 있는 곳에 일반적인 소스 프로젝트가 나올 것이다(하지만 기억하자. 이 프로젝트가 소스 컨트롤 시스템에서 온 것이 아니므로 이를 저장해도 변경한 사항을 확인할 수 없을 것이다).
그림 13. 일반적인 소스 프로젝트
- 수정된 소스 프로젝트 사용이 끝나면 이를 삭제해 원래 바이너리 버전으로 바꾼다.
- Shared EAR > Repackage Projects to Binary Modules 순으로 선택해 수정된 소스 프로젝트와 모듈의 바이너리 버전을 변경할 수 있다.
실제 테스트
실제 테스트에서는 6개의 EJB 모듈, 5개의 웹 모듈, 28개의 유틸리티 프로젝트를 가진 거대한 작업 공간을 사용했다. 먼저 모든 프로젝트가 소스 형식일 때 깨끗하게 빌드했다. 이 작업을 위해 펜티엄 4, 3GHz 머신의 2GB 메모리를 사용했다. 그러고 나서 바이너리 모듈을 사용하는 것으로 바꾸되 하나의 웹 프로젝트만 남기고 깨끗하게 빌드했다. 다음 표는 두 가지 다른 접근 방식을 측정한 결과다.
표 1. 소스 작업 공간과 바이너리 작업 공간 각각의 빌드 결과 비교
| 소스 작업 공간 | 바이너리 작업 공간 |
|---|
| 경과 시간 | 29.9분 | 2.7분 |
|---|
| CPU 시간 | 30.5분 | 3.9분 |
|---|
| 읽은 바이트 수 | 1.9 GB | 0.25 GB |
|---|
| 페이지 폴트 | 443 K | 22 K |
|---|
| 최대 작업 세트 | 931 MB | 318 MB |
|---|
여기서 볼 수 있듯이 저장 결과는 인상적이다.
결론
이 글을 통해 프로젝트를 소스 형식과 바이너리 형식으로 각각 저장해 Rational Application Developer에서 수행되는 일반적인 운영 속도를 향상시키는 방법을 소개했다. 이 방법 외에 이런 환경에 효과적인 다른 팁이 있다면 언제든 알려주기 바란다.
다운로드 하십시오 | 설명 | 이름 | 크기 | 다운로드 방식 |
|---|
| 이 글에 쓰인 예제 애플리케이션 | SampleEAR.zip | 10KB | HTTP |
|---|
참고자료 교육
제품 및 기술 얻기
토론
필자소개  | |  | Gary Karasiuk은 IBM 토론토 연구소의 Rational Application Developer 성능 분석가이다. (karasiuk@ca.ibm.com) |
 | 
|  | Jason Sholl은 IBM Raleigh 연구소에서 Rational Java 2 Platform, Enterprise Edition (J2EE) 툴링 작업을 하고 있다. |
기사에 대한 평가
 |
| 이 문서 북마킹 하기
|
|