Tomcat 5에서의 클러스터링과 로드 밸런싱, Part 2

Tomcat 5에서의 클러스터링과 로드 밸런싱, Part 2

by Srini Penchikala
04/14/2004
번역 허태명

이 글은 톰캣 5 서버에서 클러스터링과 로드 밸런싱에 관한 시리즈의 두번째 파트이다. 파트 1에서 필자는 확장성과 고가용성을 위한 시스템을 디자인할 때 고려해야할 다양한 요소와 Large-scale J2EE 시스템 디자인의 개괄에 대해 얘기했다. 또한 클러스터링, 로드 밸런싱, 결함 허용, 세션 복제 능력에 대한 톰캣의 지원에 대해서도 논했다. 이번 파트에서 우리는 제시된 클러스터 설정의 아키텍쳐와 클러스터를 배치할 때(다수의 톰캣 서버 인스턴스를 운영함으로써)의 설치와 설정의 세세한 부분에 대해 다룰 것이다.

제시된 클러스터 설정

아래 목록은 제시된 톰캣 클러스터에서 필자가 달성하기 원하는 주 목적들이다:

• 클러스터는 고도의 확장성이 있어야 한다.
• 클러스터는 결함 허용을 지원해야 한다.
• 클러스터는 동적으로 설정가능해야 하며, 그것은 클러스터를 프로그램적(자바 코드의 변경)으로 보다는 선언적(설정 파일의 변경)으로 관리하기 쉬워야 한다는 것을 의미한다.
• 클러스터는 자동 클러스터 멤버 감지 기능을 제공해야만 한다.
• 세션 데이터를 위한 메모리 세션 상태 복제 기능을 갖고 있는 Fail-over와 로드 밸런싱 기능
• 플러그인/설정가능한 로드 밸런싱 정책
• 클러스터 멤버가 합류하거나 그룹에서 떠날 때 그룹 멤버쉽 공지 기능
• 멀티캐스트를 통한 메세지 전송의 손실이 없어야 한다.
• 클러스터링은 웹 어플리케이션과 서버에 잘 연계되어야 한다. 클러스터는 클라이언트와 서버 양쪽에 투명성을 제공해야 한다. 클라이언트 투명성은 클라이언트가 클러스터링된 서비스나 클러스터가 어떻게 설정됐는지 모른다는 의미이다. 클러스터는 각각의 서비스들 보다는 단일한 것으로써 확인되고 접근되어야 한다. 서버 투명성은 서버의 어플리케이션 코드는 그것이 클러스터 내에 있는지 몰라야 한다는 것을 의미한다. 어플리케이션 코드는 다른 클러스터 멤버와 통신할 수 없다.

클러스터링 환경을 설정하기 위해 4개의 톰캣 서버 인스턴스가 설치되었다. 톰캣은 로드 밸런싱과 클러스터링 양쪽의 요구사항을 위해 사용되었다. 클러스터 설정은 수직 확장 방법 (단일 머신에 다수의 톰캣 서버 인스턴스 운영)을 사용하였다. 1개의 서버 그룹과 2개의 복제본이 클러스터에 설정되었다.(서버 그룹은 어플리케이션 서버의 논리적 표시이다.) 복제본은 세션 복제를 최적화하기 위해 서버 그룹과 설정(웹 어플리케이션의 디렉토리 구조와 컨텐츠를 의미)을 완전히 똑같이 한다. 다음은 제시된 클러스터 설정의 주요 컴포넌트들이다:

• 로드 밸런서: 1개의 톰캣 인스턴스가 클러스터 노드들 사이에서 트래픽을 분배하기 위해 설정되었다. 이 인스턴스는 TC-LB라는 코드명을 갖는다.
• 클러스터링: 3개의 톰캣 서버 인스턴스가 클러스터의 일부로서 운영된다. 이 인스턴스들의 코드명은 TC01, TC02, TC03 이다.
• 세션 영속성: 메모리 세션 복제가 세션 영속성 메카니즘으로 선택되었다. 세션 객체가 변경될 때마다 세션 데이터는 3개의 모든 클러스터 멤버들에게 복사된다.
• Fail-Over: 톰캣 설치본에 포함되어 있는 밸런서 어플리케이션은 fail-over를 다루도록 설계되지 않았다. 필자는 어떤 리퀘스트라도 서버에 포워딩하기전에 서버의 상태를 체크하는 ServerUtil이라는 유틸리티 클래스를 작성하였다. ServerUtil은 클러스터 노드의 상태를 검증하는 2개의 메소드를 가지고 있다. 첫번째 메소드에서는 특정 서버 인스턴스가 현재 돌아가고 있는지 아닌지 체크하기 위해 McastService를 사용한다. 두번째 메소드는 파라미터로써 전달된 웹 페이지 URL에 의거하여 URL 객체를 생성함으로써 클러스터 노드의 사용가능성을 검증한다. 이 클래스를 사용하기 위해 catalina-cluster.jar (%TOMCAT_HOME%/server/lib 디렉토리에 위치)와 commons-logging-api.jar (%TOMCAT_HOME%/bin 디렉토리에 위치) 파일이 클래스패쓰에 잡혀있는지 확인하라.

Figure 1의 어플리케이션 아키텍쳐 다이어그램은 클러스터의 주요 컴포넌트를 보여준다.

Figure 1. Tomcat cluster architecture diagram

톰캣 인스턴스의 설치 & 설정

Table 1. 톰캣 클러스터링을 설정하는데 사용된 머신의 하드웨어/소프트웨어 스펙

Processor	HP Pavilion Pentium III 800 MHz
Memory	512 MB RAM
Hard Disk	40 GB
Operating System	Windows 2000 server with Service Pack 4
JDK 버전	1.4.0_02 (주: 톰캣 클러스터링을 사용하기 위해서는 JDK 1.4 이상의 버전이 필요하다.)
Tomcat 버전	5.0.19
사용된 툴	Ant 1.6.1, Log4J, JMeter, JBuilder

클러스터 프레임워크의 주요 요소들

자바 클래스

• BaseLoadBalancingRule

  이 클래스는 커스텀 Rule 클래스에 일반적인 룰 로직을 캡슐화하기 위해 생성된 추상 클래스이다. 예제 웹 어플리케이션에서 사용된 커스텀 로드 밸런싱 룰은 이 베이스 클래스를 확장한 것이다.

• RandomRedirectRule

  이 클래스는 랜덤한 방법으로 사용가능한 서버에 웹 리퀘스트를 포워드하는 로직을 정의한다. 난수를 생성하기 위한 시드(seed)로 현재의 시스템 시간을 사용한다.

• RoundRobinRule

  이 클래스는 라운드 로빈 룰에 의거한 로드 밸런싱 룰을 정의한다. 리퀘스트가 올 때 이 클래스는 리퀘스트를 목록의 다음 멤버에게 포워딩한다. 다음 사용가능한 클러스터 멤버를 추적하고 매 새로운 리퀘스트마다 값을 하나씩 증가시키기 위해 정적 변수를 사용한다.

• ServerUtil

  이 클래스는 특정 클러스터 노드가 리퀘스트를 받을 수 있도록 사용가능한지 아닌지를 체크하기 위해 만들어진 유틸리티 클래스이다. 이 클래스는 클러스터 멤버가 그룹을 떠났는지 검사하기 위해 McastService (org.apache.catalina.cluster.mcast 패키지) 클래스를 사용한다.

이 자바 클래스들간의 관계가 Figure 2의 클래스 다이어그램에 나타나 있다.

Figure 2. Cluster application class diagram

설정 파일

• server.xml

  이 파일은 톰캣 서버 인스턴스의 클러스터링을 설정하기 위해 사용된다. 톰캣 설치본에 포함되어 있는 버전은 파일에 자세한 설정이 되어 있지만 주석처리되어 있다.

• web.xml

  이 설정 파일은 웹 어플리케이션 세션 데이터가 복제될 필요있다는 것을 규정하기 위해 사용된다.

• rules.xml

  이 파일은 커스텀 로드 밸런싱 룰을 정의하기 위해 사용된다. 이 파일은 우리가 클러스터 멤버 사이의 부하를 분배하기 위해 어떤 로드 밸런싱 룰을 사용하기 원하는지 규정하기 위해 사용하는 파일이다.

스크립트

• test.jsp

  서버 상태를 체크하기 위해 사용하는 간단한 테스트 JSP 스크립트이다. test.jsp 파일이 실행된 시스템 시간과 톰캣 인스턴스의 이름을 보여준다.

• testLB.jsp

  이 파일은 우리의 예제 웹 어플리케이션의 시작 페이지이다. HTML 리다이렉트를 사용하여 로드 밸런서 필터로 웹 리퀘스트를 포워딩한다.

• sessiondata.jsp

  이 스크립트는 어떤 1개의 클러스터 노드가 다운됐을 때 세션 데이터의 손실이 없다는 것을 검증하기 위해 사용된다. 세션의 자세한 정보와 또한 HTTP 세션 객체를 조작하는 HTML 필드를 보여준다.

• build.xml

  Ant 빌드 스크립트가 톰캣 인스턴스의 시작과 중지 작업을 자동화하기 위해 사용된다.(이 스크립트를 실행하기 위해 Ant 1.6.1 최신 버전이 사용됐다.) 톰캣 인스턴스가 성공적으로 구동되면, IP 주소와 포트 번호를 정함으로써 어떤 톰캣 인스턴스가 실행되는지 검증하기 위해 test.jsp를 호출할 수 있다. JSP 페이지는 현재 시스템 시간과 톰캣 인스턴스의 이름을 보여준다.(여러분은 자신의 환경에서 스크립트를 실행하기 위해 build.properties 파일에 정의된 톰캣 서버의 홈 디렉토리를 변경할 필요가 있다.)

톰캣 인스턴스를 시작하거나 중지시키는 빌드 스크립트의 몇 가지 타겟들:

• 특정 톰캣 인스턴스를 구동하기 위해 start.tomcat5x 타겟을 호출하라. (예: tomcat50)
• 특정 톰캣 인스턴스를 중지하기 위해 stop.tomcat5x 타겟을 호출하라.
• 실행되고 있는 모든 톰캣 인스턴스를 중지하기 위해 stop.alltomcats 타겟을 호출하라.

예제 코드

이 글에서 사용된 예제 코드는 tomcatclustering.zip에서 구할 수 있다. 톰캣 서버 인스턴스들을 설치한 후에(4개가 필요하다.), 톰캣 디렉토리에 zip 파일의 압축을 풀어라. 제공된 예제 코드는 로드 밸런싱 정책으로 RoundRobinRule 방식을 사용한다. 만약 랜덤 리다이렉트 정책을 사용하고 싶다면, "tomcat50/webapps/balancer/WEB-INF/config" 디렉토리에 위치한 rules.xml 파일을 변경하라. RoundRobinRule 룰 엘리먼트를 주석처리하고, RandomRedirectRule 룰 엘리먼트의 주석을 제거하라. 또한 클러스터의 톰캣 인스턴스를 3개가 아닌 2개로 사용하고 싶다면, 세번째 룰을 주석처리하고 maxServerInstances의 값을 3에서 2로 변경해라.

주 : 필자는 밸런서와 예제 웹 어플리케이션만 남기고 톰캣 설치본에 포함된 다른 모든 웹 어플리케이션(jsp-examples, 등등)은 제거했다.

HTTP Request 흐름

예제 클러스터 환경에서의 웹 리퀘스트의 흐름은 다음과 같다:

1. 시작 페이지 호출 (http://localhost:8080/balancer/testLB.jsp).
2. JSP는 밸런서 필터로 리퀘스트를 리다이렉트 시킨다. (URL: http://localhost:8080/balancer/LoadBalancer).
3. 로드 밸런서(TC-LB)로서 실행되는 톰캣 서버는 웹 리퀘스트를 인터셉트하고 설정 파일에 정의된 로드 밸런싱 알고리즘에 의거하여 다음 사용 가능한 클러스터 멤버(TC01, TC02, TC03)로 리다이렉트 시킨다.
4. 선택된 클러스터 멤버의 JSP 스크립트 sessiondata.jsp("clusterapp" 웹 어플리케이션에 위치한)가 호출된다.
5. 만약 세션이 변경되었다면 ClusterAppSessionListener에 있는 세션 리스너 메소드가 세션 변경 이벤트를 기록하기 위해 호출된다.
6. sessiondata.jsp는 웹 브라우저에 세션의 자세한 데이터를 보여준다.(세션 ID, 마지막 접근 시간, 등등)
7. 랜덤하게 하나 또는 2개의 클러스터 노드를 중지시킨다.(Ant 스크립트의 "stop.tomcat5x" 타겟을 호출함으로써)
8. 사용가능한 클러스터 멤버중의 하나로 리퀘스트 fail over가 발생하는지 살펴보기 위해 위의 단계 1부터 7까지 반복한다. 또한 데이터의 손실없이 클러스터 멤버로 세션 정보가 복사되었는지 체크해 본다.

Figure 3은 웹 리퀘스트 흐름을 시퀀스 다이어그램으로 보여준다.

Figure 3. Cluster application sequence diagram (큰 화면으로 보기 위해 그림을 클릭하시오)

클러스터 설정

"clusterapp"라고 불리는 예제 웹 어플리케이션은 클러스터 내에서 실행하기 위해 만들어졌다. 세션 복제를 최적화하기 위해 모든 인스턴스는 같은 디렉토리 구조와 컨텐츠를 가진다.

클러스터 내의 톰캣 서버 인스턴스는 세션을 전송하기 위해 IP 멀티캐스트를 사용하기 때문에, 우리는 IP 멀티캐스트가 클러스터가 설정된 머신에 사용가능한지 확인할 필요가 있다. 이것을 검증하기 위해, Tomcat: The Definitive Guide 책에서 제공하는 MulticastNode라는 예제 자바 프로그램을 실행하거나 또는 멀티캐스트 서버와 클라이언트 프로그램을 작성하는 법에 관해 자바 소프트 웹 사이트에서 구할 수 있는 예제 튜토리얼을 참조하라.

클러스터 노드가 시작될 때, 클러스터 내의 다른 멤버들은 새로운 멤버가 클러스터에 추가됐다는 로그 메세지를 서버 콘솔에 보여준다. 비슷하게, 클러스터 노드가 다운될 때, 나머지 멤버들은 클러스터에서 멤버가 제거됐다는 로그 메세지를 콘솔에 보여준다. Figure 4는 클러스터 노드가 클러스터에서 제거되거나 또는 새로운 멤버가 클러스터에 추가됐을 때, 톰캣 콘솔의 로그 메세지를 보여준다.

Figure 4. 클러스터에서 멤버가 추가되거나 제거됐을 때의 로그 메세지

톰캣 서버에서 클러스터링과 세션 복제를 사용하기 위해 아래의 절차를 따라라:

1. 세션에 저장할 모든 객체는 java.io.Serializable 인터페이스를 구현해야 한다.
2. server.xml 파일의 Cluster 요소의 주석을 제거하라. Cluster 요소의 useDirtyFlag와 replicationMode는 빈도수와 세션 복제 메카니즘의 최적화를 위해 사용된다.
3. server.xml 파일의 Valve 요소의 주석을 제거함으로써 ReplicationValve를 활성화시켜라. 만약 세션이 웹 클라이언트에 의해 변경된다면 ReplicationValve는 HTTP 리퀘스트를 인터셉트하고 클러스터 멤버들 사이의 세션 데이터를 복제하기 위해 사용된다. Valve 요소는 세션을 변경할 수 없는 리퀘스트(HTML 페이지나 이미지 파일과 같은)를 걸러내기 위해 사용할 수 있는 "filter" 속성을 가지고 있다.
4. 단일 머신에서 3개의 톰캣 인스턴스가 실행되고 있기 때문에, tcpListenPort 속성은 각 톰캣 인스턴스에 대해 유니크하게 설정된다. mcastXXX로 시작하는 속성들 (mcastAddr, mcastPort, mcastFrequency, mcastDropTime)은 클러스터 멤버쉽 IP 멀티캐스트 핑을 위한 것이고, tcpXXX로 시작하는 속성들(tcpThreadCount, tcpListenAddress, tcpListenPort, tcpSelectorTimeout)은 TCP 세션 복제를 위한 것이라는 것을 아는 것은 중요하다. (아래의 "클러스터링 설정 파라미터" 테이블은 클러스터링을 사용하기 위해 톰캣 서버 인스턴스들의 설정이 어떻게 다른지 보여준다.)
5. web.xml 메타 파일(clusterappWEB-INF 디렉토리에 위치)은 <distributable/> 요소를 가져야 한다. 특정 웹 어플리케이션에 대해 세션 상태 복제를 하기 위해, distributable 요소는 어플리케이션을 위해 정의될 필요가 있다. 이것은 세션 복제를 필요로 하는 웹 어플리케이션이 하나 이상이라면, 모든 웹 어플리케이션의 web.xml 파일에 distributable 를 추가할 필요가 있다는 것을 의미한다. Tomcat: The Definitive Guide 책의 톰캣 클러스터링 챕터는 이 주제에 대해 매우 훌륭하게 설명하고 있다.

Table 2. 클러스터링 설정 파라미터

Configuration Parameter	Instance 1	Instance 2	Instance 3	Instance 4
Instance Type	Load Balancer	Cluster Node 1	Cluster Node 2	Cluster Node 3
Code name	TC-LB	TC01	TC02	TC03
Home Directory	c:/web/tomcat50	c:/web/tomcat51	c:/web/tomcat52	c:/web/tomcat53
Server Port	8005	9005	10005	11005
Connector	8080	9080	10080	11080
Coyote/JK2 AJP Connector	8009	9009	10009	11009
Cluster mcastAddr	228.0.0.4	228.0.0.4	228.0.0.4	228.0.0.4
Cluster mcastPort	45564	45564	45564	45564
tcpListenAddress	127.0.0.1	127.0.0.1	127.0.0.1	127.0.0.1
Cluster tcpListenPort	4000	4001	4002	4003

주: 모든 클러스터 멤버는 동일한 물리적 머신에서 실행되고 있기 때문에, 같은 IP 주소를 사용한다 (127.0.0.1).

톰캣 인스턴스를 시작하고 중지하기 위해 Ant 스크립트를 사용하지 않는다면, 테스트 머신에 CATALINA_HOME 환경 변수를 설정하지 말아라. 이 변수가 설정되면, 모든 인스턴스는 톰캣 인스턴스를 구동하기 위해 같은 디렉토리(CATALINA_HOME 변수에 정의된)를 사용하려고 할 것이다. 그러한 결과로, 오직 최초의 인스턴스만 성공적으로 구동되고 나머지 인스턴스들은 포트가 이미 사용되고 있다는 바인드 익셉션 메세지와 함께 구동에 실패할 것이다: "java.net.BindException: Address already in use: JVM_Bind:8080".

로드 밸런서 설정

필자는 웹 리퀘스트를 리다이렉트 시키기 위해 룰 API를 상속받은 두개의 간단한 커스텀 로드 밸런싱 룰을 작성했다.(RoundRobinRule과 RandomRedirect) 이 룰들은 라운드 로빈과 랜덤 리다이렉트와 같은 로드 밸런싱 알고리즘에 의거한다. 여러분들도 가중치 기반, 마지막 접속 시간 등과 같은 다른 요소들을 기반으로 하는 비슷한 커스텀 로드 밸런싱 룰을 작성할 수 있다. 톰캣 로드 밸런서는 파라미터 기반의 로드 밸런싱 룰을 예제로 제공한다. 이것은 HTTP 리퀘스트의 파라미터에 따라 웹 리퀘스트를 다른 URL로 리다이렉트 시킨다.

TC-LB 인스턴스는 클러스터 멤버로 사용하기 않기 때문에, TC-LB의 server.xml의 cluster와 valve 요소는 주석을 제거하지 말아라.

테스팅 설정

세선 영속성 테스팅

세션 영속성 테스팅에서 주 목적은 클러스터 멤버가 웹 리퀘스트 처리 도중 다운됐을 때 세션 데이터가 손실되지 않았다는 것을 검증하는 것이다. sessiondata.jsp 페이지는 세션의 자세한 정보를 보여주기 위해 사용됐다. 이 스크립트는 또한 세션 속성을 추가/변경/제거 하기 위한 HTML 텍스트 필드를 제공한다. HTTP 세션에 몇 가지 속성을 추가한 후에, 필자는 랜덤하게 클러스터 노드를 중지시키고 나머지 사용가능한 클러스터 멤버에서 세션 데이터를 체크했다.

부하 테스팅

부하 테스팅의 목적은 커스텀 로드 밸런싱 알고리즘을 연구하고, 특히 하나 또는 그 이상의 노드가 다운됐을 때 웹 리퀘스트가 얼마나 효율적으로 클러스터의 노드에 분배되는지 알아보는 것이다. JMeter 부하 테스팅 툴이 다수의 동시 접속 웹 유저를 시뮬레이트 하기 위해 사용됐다.

클러스터 설정에서 로드 밸런싱을 테스트하기 위한 절차:

1. 로드 밸런서와 톰캣 서버의 클러스터 인스턴스들을 구동한다.
2. 시작 JSP 스크립트를 구동한다. (testLB.jsp).
3. 랜덤한 간격으로 하나 또는 그 이상의 서버를 중지시켜서 서버 다운을 시뮬레이트한다.
4. 부하 분배 패턴을 체크한다.
5. 절차 1부터 4를 100번 반복한다

모든 로그 메세지는 tomcat_cluster.log (tomcat50/webapps/balancer 디렉토리에 위치) 라고 불리는 텍스트 파일에 기록된다. 시퀀스 다이어그램(Figure 2)에서 보여준 모든 웹 객체에 대한 응답 시간이 Log4J 메세지를 사용하여 기록되었다. 경과시간(밀리세컨드) 자료들이 수집되고 테이블 3에 자료로 나타나 있다. 필자는 테스트동안 응답 시간을 수집하는데 Designing Performance Testing Metrics into Distributed J2EE Apps에 기술된 것과 비슷한 방법론을 따랐다.

다음 테이블은 각각 부하 테스팅 (RoundRobinRule을 사용)의 경과시간과 부하 분배율 (RandomRedirectRule을 사용) 보여준다.

Table 3. 부하 테스팅 경과시간

#	Scenario	testLB.jsp (ms)	RoundRobinRule (ms)	sessiondata.jsp (ms)	Total (ms)
1	3개의 모든 서버 인스턴스가 실행중	54	76	12	142
2	2개의 서버 인스턴스가 실행중 (TC02은 중지상태)	55	531	14	600
3	1개의 서버 인스턴스만 실행중 (TC01, TC02 중지상태)	56	1900	11	1967

주: 모든 경과시간은 100명의 동시접속 유저의 부하를 바탕으로한 평균값이다.

Table 4. 랜덤 LB 정책을 사용했을 때 부하 분배

#	Scenario	TC01 (%)	TC02 (%)	TC03 (%)
1	3개의 모든 서버 인스턴스가 실행중	30	46	24
2	2개의 서버 인스턴스가 실행중 (TC02은 중지상태)	56	0	44

주: 부하 분배율은 100명의 동시접속 유저의 부하를 바탕으로한 값이다.

결론

세션 영속성 테스팅에서, 세션 속성을 추가한 후에 클러스터 노드 중의 하나가 다운되고 세션 속성은 서버 다운때문에 손실되지 않았음을 검증했다. 텍스트 파일에 기록된 세션의 자세한 정보는 세션 속성의 상세값을 연구하기 위해 사용됐다.

부하 테스팅에서 하나 또는 2개의 서버 인스턴스가 중지되고 오직 하나의 톰캣 인스턴스만 실행중일 때, 응답 시간은 3개의 인스턴스가 모두 사용가능 했을 때에 비해 길어졌다. 중지된 인스턴스가 재시작됐을 때, 로드 밸런서는 자동적으로 서버가 다시 리퀘스트를 처리할 수 있도록 사용가능하다는 것을 알아냈고 다음 웹 리퀘스트를 리다이렉트 시켰다. 이것은 응답 시간을 현저하게 향상시켰다.

클러스터 멤버가 사용가능한지 알아보기 위해(ServerUtil 클래스를 사용하여) 필자가 사용한 메카니즘은 가장 빠른 방법은 아니다. 더욱 복잡하고 견고한 fail-over 테크닉들이 실세계의 시나리오에서 사용되어야 할 것이다.

제시된 클러스터 설정의 한계점 중의 하나는 단지 하나의 로드 밸런서만 제공한다는 것이다. 로드 밸런서 역할을 하는 톰캣 인스턴스가 다운된다면 어떤 일이 벌어지나? 어떤 클러스터 멤버에게도 리퀘스트를 포워딩할 방법이 없고, 그러한 결과로 이것을 소위 Single Point of Failure(SPoF)라고 한다. 이 문제에 대한 한가지 해결책은 만약 주 로드 밸런서가 다운된다면 그 역할을 이어받을 대기 로드 밸런서로서 두번째 톰캣 인스턴스를 가지고 있는 것이다. 전형적인 HA(High Availability) 옵션은 SPoF 상황을 방지하기 위해 2개의 로드 밸런서를 가지고 있는 것을 포함한다.

예제 클러스터 설정에서, 모든 톰캣 인스턴스(로드 밸런서를 포함해서)는 단일 컴퓨터에서 실행되도록 설정되었다. 더 좋은 디자인은 로드 밸런서를 클러스터 멤버로부터 분리된 머신에서 실행하는 것이다. 또한 수평 확장 방법론의 이점과 클러스터 성능을 향상시키기 위해 클러스터 노드를 1 머신당 2개로 제한하는 것이다.

HTTP 세션 복제는 J2EE 웹 어플리케이션 서버에서 값비싼 작업이다. 클러스터링된 J2EE 환경에서 세션 관리의 포함은 웹 어플리케이션이 제품 환경에 구현될 때까지 기다리는 것보다 프로젝트의 분석과 디자인 단계에서 고려되어야 한다. 어플리케이션 코드는 클러스터 환경을 염두에 두고 디자인되어야만 한다. 만약 클러스터링 환경을 포함하는 것이 디자인 단계에서 고려되지 않는다면, 클러스터 설정에서 작동하기 위해 코드는 아마도 완전히 재작성될 필요가 있을 수도 있고, 이것은 매우 값비싼 노력이 될 것이다.

만약 웹 어플리케이션이 객체 캐슁 메카니즘에 대한 어떤 종류의 지원이라도 한다면, 클러스터 환경에서의 객체의 캐슁은 어플리케이션 개발의 초기단계부터 고려되어야만 한다. 캐쉬된 데이터를 모든 클러스터 노드에서 동기화된 상태로 가지는 것은 웹 유저에게 정확하고 최신으로 갱신된 비지니스 데이터를 제공하기 위해 핵심적이기 때문에 이것은 매우 중요하다. 또 다른 중요한 고려사항은 클러스터 내의 만료된 세션 데이터를 제거하는 것이다.

J2EE 클러스터가 성공적으로 설정되고 실행되면, 확장성과 고가용성의 이점을 제공하기 위해 그 관리와 유지보수가 매우 중요해질 것이다. 클러스터에 많은 노드를 가지고 있으면, 유지보수는 클러스터가 실행되도록 유지하고 어플리케이션의 변경을 모든 클러스터 노드에 적용하도록 순환해야 한다. 이러한 서비스를 제공하는 한가지 방법은 정기적으로 서버의 사용가능성을 체크하고 클러스터의 노드 중 어떤 것이 다운되면 공지하는 모니터링 서비스를 구현하는 것이다. 이 서비스는 다운된 노드를 감지하고 그것을 액티브 노드 목록에서 제거해서 리퀘스트가 다운된 노드로 가지 않도록 정기적인 간격으로 노드를 체크해야 한다. 이 서비스는 변경이 일어날 때마다 클러스터 내의 모든 서버를 업데이트하고 동기화하는 능력을 포함해야 한다. 웹 어플리케이션에 대한 모든 리퀘스트는 로드 밸런싱 시스템을 통해야 하기 때문에, 시스템은 액티브 세션의 수, 어떤 인스턴스에 연결된 액티브 세션의 수, 응답 시간, 피크 부하 시간, 피크 부하 동안의 세션의 수, 최저 부하 동안의 세션의 수 등을 알 수 있다. 모든 기록 정보는 최적화 성능을 위해 전체 시스템의 세밀한 조정에 사용될 수 있다. 로드 밸런싱 정책과 클러스터 노드의 효율성을 평가하기 위한 기초로서 이러한 결과를 보여주는 리포트가 생성되야만 한다.

현재 클러스터와 로드 밸런서 설정에 필요로 하는 모든 설정은 설정 파일(server.xml과 rules.xml)을 조작함으로써 수동으로 이루어 졌다. 자카르타 그룹이 클러스터링과 로드 밸런싱 설정을 관리하기 위해 필요로 하는 설정의 변경을 수행할 수 있는 웹 기반의 클러스터 관리 GUI 툴을 제공한다면 매우 도움이 될 것이다.

참고 자료

• Tomcat 5 Home Page
• Clustering Home Page on Tomcat site
• Load Balancer Home Page on Tomcat site
• Tomcat: The Definitive Guide by Jason Brittain and Ian F. Darwin
• Java Performance Tuning, 2nd Edition by Jack Shiraji
• Creating Highly Available and Scalable Applications Using J2EE, The Middleware Company, EJB Essentials Training Class Material