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

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

by Srini Penchikala
03/31/2004
번역 허태명

최신 버전의 톰캣 서블릿 컨테이너는 확장성 있고 견고한 웹 어플리케이션을 배치하는데 필수적인 클러스터링과 로드 밸런싱을 제공하고 있다. 이 글의 첫번째 파트에서는 클러스터링과 로드 밸런싱 기능에 관한 설치, 설정, 사용법, 확장에 관한 개괄적인 면을 살펴볼 것이다. 두번째 파트에서는 톰캣 서버에서 클러스터링 인스턴스를 설정하는데 관련된 절차를 보여주는 예제 웹 어플리케이션을 소개하고, 클러스터 환경에서 메모리 복제를 사용하는 세션 퍼시스턴스에 대해 살펴볼 것이다.

톰캣 5 서버는 룰 기반의 로드 밸런서 어플리케이션이 탑재되어 있다. 웹 리퀘 스트를 리다이렉트 시키기 위하여 라운드-로빈과 랜덤 알고리즘을 기반으로 두 개의 간단한 커스텀 로드 밸런싱 룰(룰 API를 상속받은)이 작성되었다. 클러스터 환경 에서 실행되는 예제 웹 어플리케이션의 퍼포먼스 벤치마크가 제공된다. 로드 밸런싱 메카니즘을 살펴보기 위해 다수의 웹 유저를 시뮬레이트해주는 로드 테스팅 툴인 JMeter가 사용되었다.

이 글은 톰캣 서블릿 컨테이너에서의 클러스터링 능력을 보여주는데 주로 촛점을 두고 있기 때문에, 여기서 EJB, JNDI, JMS 객체를 복제하는 J2EE 어플리케이션의 클러스터링에 관해서는 다루지 않을 것이다. EJB와 JMS 클러스터링을 위하여 "J2EE Clustering" 과 "J2EE Clustering with JBoss"을 참조하라

Large-Scale 시스템 디자인

엔터프라이즈 웹 포탈 어플리케이션은 웹 사이트를 방문하는 수 천명의 사용자에게 서비스하기 위해 웹 서비스의 확장성과 고가용성(High Availability : HA) 을 제공해야 한다. 확장성은 클러스터에 서버를 추가함으로써 늘어나는 사용자의 수를 지원하기 위한 시스템의 능력이다. 고가용성은 기본적으로 시스템에 잉여 자원을 제공하는 것이다. 만약 어떤 클러스터 멤버가 어떠한 이유로 실패한다면, 클러스터의 또 다른 멤버가 투명하게 웹 리퀘스트를 이어받을 수 있다. 클러스터 환경에 웹 포탈 어플 리케이션을 배치하는 것은 우리에게 웹 포탈 어플리케이션에서 요구하는 확장성, 신뢰성, 고가용성을 성취할 수 있는 능력을 준다. 기본적으로, 클러스터링의 주 목적은 시스템에서 1개의 문제점(Single Point of Failure : SPoF)때문에 발생하는 웹 사이트의 어떤 장애도 방지하도록 하는 것이다.

Large-scale 시스템 디자인은 엔터프라이즈 어플리케이션 환경에서 최소한의 다운 타임과 최대한의 확장성을 보증하는 미션-크리티컬한 서비스를 제공한다. 1개의 서버를 운영하는 것보다는 다수의 협력하는 서버를 운영해라. 확장성을 위해 당신은 클러스터 내에 추가적인 머신을 포함해야만 하고, 다운타임을 최소화하기 위해 당신은 클러스터의 모든 컴포넌트에 잉여 자원이 있는지 확인해야 한다. Large-scale 시스템의 주요한 요소는 로드 밸런싱, 결함 허용(fault tolerance), 세션 상태 영속성(session state persistence) 기능을 포함하는 클러스터링이다. 일반적으로 웹 어플리케이션에서 하드웨어 또는 소프트 웨어 기반의 로드 밸런서가 클러스터 내의 어플리케이션 서버 앞단에 위치한다. 이 로드 밸런서들은 웹 트래픽을 적당한 클러스터 멤버로 리다이렉팅 시키고 동시에 서버의 장애요소를 찾아내어 클러스터 노드 사이의 부하를 분배하기 위해 사용된다.

클러스터링

클러스터는 J2EE 어플리케이션에서 마치 하나의 엔터티인 것처럼 투명하게 운영되는 어플리케이션 서버들의 그룹으로 정의된다. 클러스터링은 두 가지 방법으로 구현될 수 있다: 수직 확장(Vertical Scaling) 과 수평 확장(Horizontal Scaling). 수직 확장은 1개의 머신에 운영되는 서버의 갯수를 증가시키는 것이고, 반면에 수평 확장은 클러스터 내에 머신의 갯수를 증가시키는 것이다. 오직 1대의 머신에 비해 클러스터 환경에 포함된 다수의 머신이 있기 때문에 수평 확장이 수직 확장보다 더 신뢰성이 있다. 수직 확장에서는 머신의 프로세싱 파워, CPU 사용과 JVM Heap 메모리의 설정이 얼마나 많은 서버 인스턴스가 한 대의 머신(또한 server-to-CPU ratio로도 알려져 있는)에서 운영될 수 있는지 결정하는 주요한 요소이다.

J2EE 클러스터 내에 있는 서버들은 보통 세가지 옵션 중에 한가지를 사용하여 설정된다. 독립적 접근방식에 있어서 각 어플리케이션 서버는 자신의 어플리케이션 파일들의 복사본을 가지고 자기 자신의 파일 시스템을 가지고 있다. 또 다른 접근법은 공유된 파일 시스템을 사용하는 것이다. 공유된 파일 시스템에서 클러스터는 모든 어플리케이션 서버가 어플리케이션 파일을 획득하기 위해 사용할 단일의 저장장치를 사용한다. 세번째 설정 접근방식은 관리 접근법이라고 불린다. 이 방식에서는 관리 서버가 어플리케이션의 컨텐츠에 관한 접근을 통제하고 적당한 어플리케이션 컨텐츠를 관리되는 서버로 "보내는데(pushing)" 책임이 있다. 관리 서버는 클러스터 내의 모든 서버가 어플리케이션을 사용가능하다는 것을 보장한다. 관리 서버는 또한 어플리케이션이 배치될 때 모든 서버를 업데이트하고 어플리케이션이 제거될 때 모든 서버의 어플리케이션을 제거한다.

클러스터링은 데이터베이스 티어를 포함하여 J2EE 어플리케이션의 다양한 티어에서 이뤄질 수 있다. 어떤 데이터베이스 벤더는 클라이언트(일반적으로 서블릿 컨테이너나 또는 어플리케이션 서버)가 데이터를 가져오기 위해 어떤 데이터베이스에 연결되어 있는지 알 필요가 없도록 클라이언트 투명성을 제공함으로써다수의 데이터베이스 사이에서 데이터 복제를 지원하는 클러스터링된 데이터베이스를 제공한다. JDBC 클러스터링의 예로는 오라클 9i의 Real Application Clusters (RAC)과 Clustered JDBC (C-JDBC)가 있다. RAC는 데이터베이스 커넥션의 fail over를 지원하고 투명하게 fail over된 데이터베이스 노드에 JDBC 커넥션과 데이터베이스 요청을 재연결한다. C-JDBC는 웹 어플리케이션이 JDBC 드라이버를 통해 투명하게 데이터베이스 클러스터에 접근하게 해주는 오픈 소스 데이터베이스 클러스터이다. C-JDBC 구현은 클러스터에서 데이터베이스 노드들 사이의 JDBC 커넥션을 로드 밸런싱할 뿐만 아니라, 보조 데이터베이스 서버로 fail over 처리를 해준다.

톰캣에서의 클러스터링

톰캣 이전 버전(버전 4.1)에서는 서드-파티의 JAR 파일을 사용하여 클러스터링을 할 수 있었다; 그것은 클러스터에서 다수의 톰켓 인스턴스를 운영하기 위하여 설치하고 설정하는 것이 쉽지 않았다. JavaGroups는 오픈 소스 서블릿 컨테이너(톰캣)과 어플리케이션 서버(JBoss)에 클러스터링 기능을 추가해주는 잘 알려진 대안이다. 그러나 톰캣 최신 버전에서 클러스터링은 주요 설치 패키지의 일부가 되었다. 이것은 서드-파티 클러스터링 구현을 톰캣 서버와 연동하기 위한 추가의 노력을 최소화해 준다.

전형적인 클러스터 환경에서 클러스터 내의 서버들은 협력하고 상태를 복제하기 위해 서로 통신을 해야 할 필요가 있다. 이러한 그룹 커뮤니케이션은 point-to-point RMI (TCP-IP) 또는 IP 멀티캐스트를 통하여 이루어 진다. 대부분의 J2EE 어플리케이션 서버들(JBoss, 오라클, 웹로직, 볼랜드와 같은)은 클러스터 내에서 다른 서버로 상태/업데이트/심장박동(heartbeats : 서버의 이상유무)을 전송하기 위하여 모두 IP 멀티캐스트 통신을 사용한다. 이제 톰캣에서 클러스터 멤버들 사이에 통신이 어떻게 이루어 지는지 살펴보자: 모든 클러스터 멤버는 멀티케스트 ping 메세지를 사용하여 서로 통신한다. 각 톰캣 인스턴스는 세션 복제를 위한 IP 주소와 TCP 리스너 포트를 전파하는 메세지를 전송할 것이다. 만약 한 인스턴스가 주어진 시간 단위안에 메세지를 받지 못하면, 그 인스턴스는 다운된 것으로 간주될 것이다.

클러스터링에서 또 다른 잘 알려진 개념은 farming이라고 불리는데, 웹 어플리케이션에서 cluster-wide hot deployment를 제공한다. 서버 farm에서 웹 어플리케이션은 클러스터 내의 오직 한 노드의 어플리케이션 WAR 파일을 복사함으로써 배치된다; farming은 전체 클러스터에서 웹 어플리케이션의 배치를 다룰 것이다. 유사하게 한 개의 클러스터 노드에서 WAR 파일을 제거하는 것은 클러스터의 모든 노드에서 웹 어플리케이션을 제거하게 할 것이다. 톰캣 클러스터링 문서에서는 톰캣의 다음 버전에서 farming 기능을 지원할 것을 언급하고 있다.

로드 밸런싱

로드 밸런싱(또한 high availability switch over으로 알려져 있는)은 서버 부하가 서버 클러스터 내에서 다른 노드들로 로드 밸런싱 정책에 의거하여 분배되도록 하는 메카니즘이다. 한 개의 서버에서 어플리케이션을 실행하기 보다는, 시스템은 어플리케이션 코드를 동적으로 선택한 서버 상에서 실행한다. 클라이언트가 서비스를 요청할 때, 협력하는 서버들 중의 하나(또는 그 이상)이 요청을 수행하도록 선택된다. 로드 밸런서는 클러스터 내에서 요청을 받아들이는 유일한 진입점으로서, 또 개별적인 웹 또는 어플리케이션 서버의 트래픽 관리자로서 역할을 수행한다.

두 가지 잘 알려진 클러스터에서 로드 밸런싱 방법은 DNS round robin과 하드웨어 로드 밸런싱이다. DNS round robin은 하나의 논리적인 이름을 제공하고 클러스터 내에서 노드들의 어떤 IP 주소를 돌려 받는다. 이 옵션은 비용이 많이 들지 않고, 단순하며 설정하기 쉽다. 하지만 DNS round robin은 서버에 어떤 유연성이나 고가용성도 제공하지 않는다. 반면에 하드웨어 로드 밸런싱은 가상 IP 어드레싱을 통해 DNS round robin의 한계점을 해결한다. 로드 밸런서는 클러스터를 위하여 하나의 IP 주소를 제공하고 그것은 클러스터 내의 각 머신에 매핑된다. 로드 밸런서는 각 요청을 받고 클러스터 내에서 다른 머신들에게 헤더를 다시 써준다. 만약 우리가 클러스터에서 어떤 머신을 제거한다면, 변화는 즉각적으로 나타난다. 하드웨어 로드 밸런싱의 장점은 서버의 유연성 고가용성이다; 단점은 매우 비용이 많이 들고 설정하기 복잡하다는 것이다.

로드 밸런싱을 수행하기 위해 부하를 분배하는 정책을 정의하는 알고리즘은 간단한 라운드 로빈 알고리즘에서 매우 복잡한 알고리즘까지 다양하다. 일반적으로 많이 쓰이는 알고리즘은 다음과 같은 것이 있다:

• Round-robin
• Random
• Weight-based
• Minimum load
• Last access time
• Programmatic parameter-based (로드 밸런서는 입력 인자에 따라 서버를 선택할 수 있다)

로드 밸런싱 알고리즘은 통계적 변수, 속도, 단순성에 영향을 미친다. 예를 들어, weight-based 알고리즘은 "Load Balancing Web Applications."을 참조하면 다른 알고리즘보다 더 긴 계산시간을 가지고 있다.

톰캣에서의 로드 밸런싱

이전 버전의 톰캣에서는 로드 밸런싱 기능이 제공되지 않았다. 아파치 웹서버와 톰캣 서블릿 컨테이너를 함께 연동하는 것은 웹 리퀘스트를 조절하고 로드 밸런싱을 하는 잘 알려진 방법이다. 아파치-톰캣 설정에서 Tomcat Worker로 불리는 톰캣 인스턴스가 로드 밸런싱을 구현하기 위해 설정된다.

톰캣 5는 세 가지 방법으로 로드 밸런싱을 제공한다: JK native connector의 사용, mod_proxy와 mod_rewrite를 아파치 2와 사용, 그리고 balancer 웹 어플리케이션의 사용이다. 이 글에서 우리는 클러스터 내에서 웹 리퀘스트를 다른 노드들로 리다이렉트 시키는 balancer 웹 어플리케이션을 사용하는 세번째 옵션을 설명하는데 중점을 둘 것이다. 로드 밸런서 어플리케이션은 클러스터 내의 다음 이용가능한 멤버로 웹 리퀘스트를 리다이렉트 시키는 서블릿 필터 메카니즘을 사용하는 룰 기반의 어플리케이션이다. 서블릿 필터는 서블릿 2.3 스펙에서 소개되었다. 이 필터는 웹 어플리케이션의 JAAS 인증, 암호화, 로깅, 감사(auditing), 데이터 압축, XML 컨텐츠를 변환하는 XSLT 필터 등과 같은 다양한 작업에 사용된다. 톰캣 밸런서 웹 사이트에 언급된 것과 같이, 밸런서 어플리케이션은 다른 견고한 로드 밸런싱 메카니즘을 대체하기 위해 디자인된 것은 아니다. 그보다 톰캣 밸런서 어플리케이션은 다수의 서버 사이에서 트래픽을 조절하는 단순하고 확장가능한 방법이다. 여러가지 룰을 사용하여 로드 밸런싱이 다양한 방법으로 어떻게 구현되는지 이해하기 위하여 밸런서 어플리케이션에 제공되는 샘플 자바 클래스를 살펴보라.

로드 밸런싱은 다양한 룰과 리다이렉션 URL을 포함하고 있는 룰 설정 파일(rules.xml이라고 불리는)을 생성함으로써 사용 가능해 진다. 밸런서 필터는 rules.xml 파일에 정의되어 있는 것과 같은 순서로 룰을 체크함으로써 리퀘스트를 어디로 리다이렉트할지 결정하기 위해 RuleChain을 체크한다. Rule이 기준에 맞으면, 필터는 검사를 중단하고 리퀘스트를 해당하는 룰에 정의된 URL로 리다이렉트시킨다.

결함 허용(Fault Tolerance)

결함 허용은 클러스터 내의 어떤 서버가 다운되면 가능한한 엔드 유저에게 투명하게 이용가능한 다른 서버로 fail over하기 위하여 계산을 허용하는 시스템의 능력이다. 이상적인 fail over 시나리오는 클러스터 서비스가 리퀘스트를 처리하기위해 서버 인스턴스가 더 이상 사용 불가능할 때를 감지하고 그 인스턴스에 대해 리퀘스트 보내는 것을 멈추는 것이다. 또한 정기적으로 클러스터 멤버가 다시 사용가능한지 알아보도록 점검하고, 그렇다면 자동적으로 그 멤버를 액티브 클러스터 노드 풀에 추가해야만 한다.

톰캣에서의 결함 허용

톰캣 5는 클러스터 멤버가 다운됐을 때를 감지하는 내장된 fail over 메카니즘은 제공하지 않는다. 그러나 희망적으로 톰캣의 다음 버전은 웹 리퀘스트에 대해 서비스할 준비가 되어 있는지 확인하기 위해 특정 클러스터 멤버가 이용가능한지 감지하는데 사용될 수 있는 fail over 기능을 제공할 것이다.

전형적으로 클러스터링 솔루션에서 제공되는 fail over 기능은 두 단계가 있다:

• Request-level fail over: 만약 클러스터 내의 서버 중의 하나가 다운된다면, 그 이후의 모든 리퀘스트들은 클러스터 내의 나머지 다른 서버로 리다이렉트되야만 한다. 이것은 서버 상태를 추적하고 응답하지 않는 서버에 리퀘스트를 보내는 것을 피하기 위해 heartbeat 메카니즘을 사용하는 것을 포함한다. 우리의 클러스터 설정에서 로드 밸런서로서 사용되는 톰캣 인스턴스는 웹 리퀘스트를 클러스터 내의 다른 노드로 포워딩함으로써 Request-level fail over를 수행할 수 있다.
• Session-level fail over: 웹 클라이언트는 HTTP 서버에 의해 유지되는 세션을 가질 수 있다. Session-level fail over에서 클러스터 내의 서버 중의 하나가 다운된다면, 클러스터 내의 다른 서버가 최소한의 연속성 손실만으로 최초의 서버에 의해 다뤄진 세션을 가지고 계속 작업을 수행할 수 있어야 한다. 이것은 클러스터 내에 서버간의 세션 데이터의 복제를 포함한다. 세션 복제 능력을 가지고 있는 톰캣 클러스터는 session-level fail over를 수행할 수 있다.

세선 상태 영속성(Session State Persistence)

Fail over와 로드 밸런싱은 클러스터 내에 다른 서버로 세션 상태가 복제될 수 있는 것을 필요로 한다. 세션 상태 복제는 클라이언트 세션이 최초 생성된 원래 서버가 다운됐을 때 클러스터 내의 다른 서버로부터 클라이언트의 세션 정보를 동일하게 얻을 수 있도록 한다. 상태는 시스템 상태이거나 어플리케이션 상태(어플리케이션 상태는 HTTP 세션에 저장된 객체나 데이터를 포함한다)일 수 있다. 세션 복제의 주 목적은 클러스터 멤버가 다운되거나 어플리케이션의 업데이트 또는 시스템 유지보수를 위해 멈췄을 때 세션의 세세한 사항까지 잃지 않도록 하는 것이다.

세션 영속성에 관한한, 클러스터링은 간단한 시나리오가 될 수 있다. 이 시나리오에서 클러스터 멤버는 다른 클러스터 멤버의 세션 상태에 관한 알고 있는 바가 전혀 없다. 그리고 유저 세션은 전적으로 로드 밸런서에 의해 선택된 한 서버에 존재한다. 이것은 세션 데이터가 웹 리퀘스트를 받은 클러스터 멤버에 존재하기 때문에 고착된(sticky) 세션(또한 session affinity이라고 알려져 있는)이라고 불린다.

반면에 클러스터는 세션 상태를 정기적으로 모든(하나 또는 두 개 권장) 백업 클러스터 멤버로 전달해서 각 클러스터 멤버가 다른 클러스터 멤버의 세션 상태를 완벽하게 알고 있도록 구현될 수 있다. 이러한 종류의 세션은 복제된(replicated) 세션으로 알려져 있다.

세션 영속성을 구현하는 세가지 방법이 있다:

• Memory-to-memory replication
• File System session persistence, 중앙집중화된 파일 시스템에 세션 정보가 read/write 된다.
• Database session persistence, 세션 데이터가 JDBC 데이터 저장소에 저장된다.

메모리 세션 복제에서 HttpSession 내의 객체는 상태가 변할 때마다 개별적으로 백업 서버에 직렬화 된다. 반면에 데이터베이스 세션 영속성(Database session persistence)에서 세션에 저장된 객체는 객체들중 어느 하나의 상태가 변할 때 함께 직렬화 된다.

데이터베이스/파일 시스템 세션 영속성의 주요 단점은 대형 객체나 수많은 객체를 HttpSession에 저장할 때 확장성이 제한된다는 것이다. 유저가 HttpSession에 객체를 추가할 때마다, 세션 내의 모든 객체들은 직렬화되고 데이터베이스타 공유된 파일 시스템에 저장된다.

톰캣에서의 세션 복제

현재 버전의 톰캣 서버에서 세션 복제는 세션 상태를 all-to-all 복제하는 것이다. 이것은 모든 클러스터 멤버에게 항상 세션 속성들을 전달하는 것을 의미한다. 이 알고리즘은 클러스터가 작을 때 효율적이다. 대형 클러스터를 위해서 다음 톰캣 릴리즈에서는 하나 또는 아마도 두 개의 백업 서버에만 세션을 저장하는 주-보조 세션 복제 기능을 지원할 것이다.

톰캣에서 세션 복제 메카니즘은 세가지 종류가 있다:

• 톰캣 5(server/lib/catalina-cluster.jar)에 내장되어 있는 SimpleTcpCluster (org.apache.catalina.cluster.tcp 패키지)과 함께 메모리 복제에서의 사용.
• 공유된 데이터베이스(org.apache.catalina.session.JDBCStore)에 세션을 저장하는 세션 영속성의 사용.
• 공유된 파일 시스템(catalina-optional.jar의 일부인 org.apache.catalina.session.FileStore)에 세션 상태 저장하기

J2EE 클러스터를 구현하는데 있어서 고려해야 할 요소

J2EE 클러스터를 디자인할 때 고려해야할 요소는 많이 있다. 다음은 large-scale J2EE 시스템 디자인에서 고려해야할 요소들의 목록이다.(이 목록은 EJB 필수 트레이닝 문서 중 "Creating Highly Available and Scalable Applications Using J2EE"에서 가져왔다.)

클러스터링

• 어떤 종류의 클러스터가 구현되야만 하는가: 수직 확장 또는 수평 확장인가?
• 어떤 티어에서 클러스터링이 구현되야만 하는가: 웹서버, 서블릿을 위한 서블릿 컨테이너, JSP, HTTP 세션 객체; 또는 EJB, JMS, JNDI 객체를 위한 어플리케이션 서버 또는 데이터베이스 클러스터링?

로드 밸런싱

• 서버가 선택될 때(예, 활용성? : affinity): 매 리퀘스트마다, 매 트랜잭션마다, 또는 매 세션마다?
• 어떻게 서버가 선택되는가(예, 로드 밸런싱 정책): 무작위, 라운드-로빈(round-robin), 가중치 기반(weight-based), 가장 덜 부하가 걸린 서버(least loaded server), 또는 어플리케이션에 의해?
• 로드 밸런싱이 어디서 이루어 지는가: 한 곳 또는 여러 곳, 클라이언트 단 또는 서버 단?

결함 허용(Fault Tolerance)

• 어떻게 서버가 문제를 감지하는가?
• fail over하고 다른 서버로 리퀘스트를 시도할 적당한 시간은 언제인가?
• 문제가 생긴 노드의 시스템과 어플리케이션의 상태는 어떻게 할 것인가?

세션 상태 영속성(Session State Persistence)

• 상태는 어떻게 통신되는가?
• 얼마나 자주 통신하는가?
• 객체의 상태는 어떻게 구체화(materialize)되는가?
• 상태 영속성 메카니즘은 효율적인가?
• 복제된 상태의 일관성이 있는가?
• 세션 상태를 복제하는데 있어서 어떤 네트웍 제한요소가 있는가?

제안된 클러스터 설정

아래 목록은 제안된 클러스터 환경에서 필자가 달성하기 원했던 주요한 목적이다:

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

결론

이 글의 파트 2에서 우리는 이러한 목적을 달성하기 위해 클러스터를 배치하는 법(다수의 톰캣 서버 인스턴스를 운영함으로써)을 살펴볼 것이다. 또한 톰캣 5에서 클러스터 아키텍쳐와 세션 복제를 가능하게 하는 설정의 자세한 부분에 관하여 논할 것이다.

Srini Penchikala는 Flagstar Bank의 정보 시스템 주제 관련 전문가이다.