Boost Tomcat performance for static content
PippoProxy offers an alternative to standard Apache-Tomcat implementations
By Gino Tesei, JavaWorld.com, 02/28/05

원문 : http://www.javaworld.com/javaworld/jw-02-2005/jw-0228-pippo.html?page=1

더 성능이 좋은 이유는 자체 캐싱 알고리즘이 더 훌륭해서라는 군요.

LRU(least-recently used)를 GoF의 Chain of Responsibility 패턴을 사용해서

구현했다고 하는데, 어쨌든 중요한 것은 이 걸 쓰면 더 빠르다라는 내용입니다.

원문을 보시면 설치하는 방법도 좀 나와있으니, 혹 Proxy서버 성능 개선에

관심있으신 분들께선 한 번 써보시고 쓸만한지 좀 알려주세요.

Sponsored by:

This story appeared on JavaWorld at
http://www.javaworld.com/javaworld/jw-02-2005/jw-0228-pippo.html

Boost Tomcat performance for static content

PippoProxy offers an alternative to standard Apache-Tomcat implementations

By Gino Tesei, JavaWorld.com, 02/28/05

Protecting corporate internal networks from hackers, thieves, or high load traffic is a common concern. A typical security measure consists of placing an intermediary Web server, known as an HTTP(S) proxy server, between the Internet and the internal network for controlling access. Such an intermediary Web server forwards HTTP(S) requests from clients to other servers, making those requests look like they originated from the proxy server and vice versa (reverse proxy).

Malicious users or excessive traffic load are just two good reasons for controlling access to internal servers. More generally, they are two application scenarios of the well-known structural design pattern Proxy, or Surrogate, whose intent, according to the Gang of Four, (GoF) is to "provide a surrogate or placeholder for another object to control access to it." Obviously such a surrogate adds a cost in terms of complexity. Complex systems are more difficult to understand and any modification is made harder by added complexity. So, why should we pay such a complexity fee? Typical reasons are:

• Performance: You will eventually have to provide temporary cached instances of resources to multiple clients that share them (Cache Proxy design pattern). For example, this approach makes sense for static content (images, Javascripts, Cascading Style Sheets, static HTML pages).
• Security: You will eventually have to control access to resources (Protection Proxy). Typically, the proxy server is placed outside the main corporate firewall in the so-called demilitarized zone, while proxied servers are placed inside the firewall in the so-called militarized zone. Furthermore, you will eventually have to provide clients with different levels of access (Protection Access Proxy). For instance, in banking applications, clients may have different levels of access to financial reports.
• Scalability: As traffic load increases, you will eventually have to add more application servers to maintain good performance, or you might need some kind of automatic failover in case one of the nodes breaks.
• Audit: You will eventually have to count the number of accesses or trace access details to requested references (Smart Reference Proxy). For instance, this approach is common in banner advertising applications.

When such complexity is necessary in an application, PippoProxy, a Java HTTP proxy designed and implemented for Tomcat, can be used in place of standard Apache-Tomcat solutions. This article presents the rationale behind the development of PippoProxy, the need for this type of proxy, and its advantages over more traditional proxies. In addition, PippoProxy's typical deployment scenarios and comparison benchmarks to more traditional solutions are presented.

Typical Apache-Tomcat proxy configurations

The standard Apache-Tomcat proxy configuration places an Apache (proxy) HTTP server before the Tomcat application servers in a "neutral zone" between the company's private network and the Internet (or some other outside public network) for secure access to the company's private data. This proxy server also acts as a load balancer and as a server of static content. Figure 1 shows such a configuration scenario.

To connect Apache to Tomcat, you can choose one of the standard connectors. For production deployment, mod_jk is the best choice (see Tomcat FAQ and "Fronting Tomcat" for further details). In particular, the mod_jk connector is said to provide approximately double the performance than mod_proxy for several reasons, including a persistent connection pool to Tomcat and a custom optimized protocol named AJP (see the Apache Jakarta Tomcat Connector). For a step-by-step explanation on how to connect an array of Tomcats to Apache using such a connector, see "High Availability Tomcat" (JavaWorld, December 2004).

Limitations of Apache-Tomcat

In typical Apache-Tomcat configurations, static content lives with the proxy server and is typically served without processing by filters or security constraints (Figure 1). This architecture proves inadequate for those security-conscious environments that deliver documents from internal servers to external customers in a controlled manner according to specific business rules inherently bound to the application itself and its lifecycle.

The following section considers application scenarios where such inadequacies are evident and where the adoption of a Tomcat-embeddable HTTP proxy has clear advantages.

Sample application: Managing financial reports at MegaBank

Consider a banking application at MegaBank, a large financial institution, where customers may have different levels of access to financial reports (PDF files, for instance) or other documents such as research produced by financial advisors regarding the companies they are considering investing in. These documents are typically provided by a content management system (CMS) that deploys them in an internal Web server (not Tomcat, in general), for which our initial Web application acts as a service consumer. For example, a user request to access a particular report is processed according to the user profile and other business rules before the document is delivered from the internal server. Moreover, such a CMS and its Web server typically live in a more internal security layer than our Web application. Figure 2 shows such a scenario.

In the standard Apache-Tomcat configuration, the Web server is responsible for proxying the documents after applying business logic. Since the internal Web server will not necessarily be Tomcat, the proxy must use the mod_proxy module. Besides performance penalties related to mod_proxy, this solution has the main disadvantage of not complying with standard security policies since the proxy server must pass through two firewalls, see Figure 3.

To block out malicious requests for internal resources protected by security constraints, all business rules used by Tomcat to filter requests to Apache should be replicated (using another programming language) by Apache itself. Thus, the whole setup is difficult to manage. In addition to the correct forwarding of HTTP headers up and down the chain, Apache must also include additional modules (e.g., mod_rewrite and mod_auth) to implement such rules that must remain consistent with the rest of the system. For further details see "URL Rewriting Guide." In particular, this setup violates two design-level principles:

• Once and only once: This is a principle within agile development methods, such as extreme programming, that strives to eliminate code and data duplication. Generally, if you find yourself duplicating a code fragment or datastructure, you should instead create abstractions or use indirection to remove the duplication. Applying the same philosophy at the enterprise level, this principle means you should not allow different modules to perform the same logical work.
• Law of Demeter: The simple version of this guideline is "only talk to your immediate friends." Bringing this philosophy from the object-oriented design level to the enterprise level, applications should talk only to those applications on the functional levels immediately above or below them.

Other scenarios

The above limitations of typical Apache-Tomcat configurations are related to a quite complex application scenario. Simple scenarios, on the other hand, might also suffer from lack of resources when, for instance, for simple or internal Websites, no Apache Web server is available for proxy use. In addition, in the case of static content (or quasi-static content, as in the MegaBank example), caching mechanisms are important for boosting performance and reducing the offered load to internal Web servers not built for production use.

To summarize, application scenarios are common where the adoption of a Tomcat-embeddable HTTP proxy has clear advantages. Enter PippoProxy.

PippoProxy

PippoProxy is a 100 percent pure Java HTTP proxy designed/implemented for Tomcat that can be used instead of standard Apache-Tomcat solutions. Technically, it is implemented as a servlet and requires:

• J2SE 1.4.1 or newer
• Apache Ant 1.6.2 or newer
• Apache Tomcat 5.0.x or newer

Overview

PippoProxy is deployable in one of two modes: it can be plugged into any existent Web application acting as a service provider or serve as a standalone Web application.

In the first deployment scenario, classes responsible for handling business logic may use PippoProxy on demand. For instance, in our MegaBank example, a user request to access a particular report may be processed according to a user profile and other business rules, and eventually forward to PippoProxy.

In particular, let's assume a front end that uses some kind of Model-View-Controller (MVC) framework, whose servlet acts as controller running under http://[domain]:[port]/[context]/servlet/*.[extension]. Such a servlet (or the classes handling its actions in MVC frameworks such as Struts) receives requests from clients, decides whether they have the required authorization, sets a suitable request/session attribute to some value, and forwards the request to PippoProxy, running, for example, under http://[domain]:[port]/[context]/proxy/.

PippoProxy checks the attribute, fetches the required resource from the internal server (or its cache, if it is static), and returns the resource to the client (see Figure 4). This way, malicious users attempting to directly request resources under security constraints without the required authorization fail since their HTTP request/session has no authorization attribute set.

To maximize performance, PippoProxy manages a persistent (configurable) connection pool to the internal server, avoiding the opening and closing of connections for each request. In the case of static content, the performance is further improved with an efficient caching mechanism that uses a hierarchical structure both in memory and in the filesystem. Such a caching structure consists of a chain composed of a first node for memory cache, followed by another node for the filesystem cache. PippoProxy's caching mechanism implements the well-known GoF behavioral design pattern Chain of Responsibility, see Figure 5.

PippoProxy's main servlet asks for a resource to the first node. If the node has the requested resource, it returns it; otherwise, the node passes the request along the chain to the second node. If the second node has the requested resource, it returns it; otherwise the second node fetches the resource from the internal Web server.

The memory and filesystem cache can be configured to have a maximum size (in MB). The cache use a LRU (least-recently used) replacement strategy to decide which resource to force-pass to successive nodes or remove (last node only). Also, the cache is structured as an exclusive cache hierarchy, meaning that the contents of the memory and filesystem nodes are exclusive (eliminating redundant copies). See PippoProxy documentation for further details about implementation. Also see the discussion on Ephemeral Cache Item in Java Enterprise Design Patterns for a sample of a LRU cache in Java.

The following sections show how to install, configure, and deploy PippoProxy.

For the impatient

If you don't already have Tomcat or Ant, download the recent copies and install them. Then download PippoProxy and unpack it in a directory (e.g., /usr/local/pippoproxy). Edit the _ant.properties file, have deploy_local point to the local Tomcat Web applications (e.g., /usr/local/tomcat/webapps), and set application_name to the name of the Web context under which PippoProxy works (e.g., pp). Now the command line ant deploy deploys PippoProxy under the local Tomcat, producing the output shown in Figure 6.

To test your installation, go to http://localhost:8080/pp/lp/ and you should see a well-known Website.

Custom configuration

PippoProxy can also be deployed as a standard J2EE application. As a result, the related web.xml deployment descriptor must contain a servlet element for specifying the servlet name and setting other servlet-specific properties, for example:

  PippoProxyServlet org.pippo.proxy.WebCachedProxyServlet  ENABLE_SESSION_ATTR_KEY_FOR_LOGIN true  ... ... ... 1 

The deployment descriptor also must have a servlet-mapping element for mapping it to one or more URL patterns according to the Servlet specification:

  PippoProxyServlet /lp/* 

You can complete this customization by either editing your web.xml deployment descriptor or using PippoProxy's Ant scripts. PippoProxy's Ant scripts have all you need if you want to deploy PippoProxy as a standalone Web application. Thus, you should need to edit your web.xml only when you integrate PippoProxy into an existing Web application.

To edit your deployment descriptor, place PippoProxy's Java classes into your J2EE application's WEB-INF/lib directory as a JAR according to the Servlet specification and then edit the web.xml deployment descriptor. For packaging PippoProxy's classes into a JAR, you can use the jarPkg Ant target after editing the _ant.properties file:

 # # Application name. # application_name=pp

# # Local temp directory to do stuff. # outdir=build

For example, if your PippoProxy home is /usr/local/pippoproxy, launching ant jarPkg in the previous instance of _ant.properties will package PippoProxy's Java classes into the JAR /usr/local/pippoproxy/build/dist/pp.jar and the HTTP client library used by PippoProxy into the JAR /usr/local/pippoproxy/build/dist/HTTPClient.jar. These JARs should be copied into your J2EE application's WEB-INF/lib directory. Next, edit the web.xml deployment descriptor, setting all parameters, whose semantics are described in the next section.

If you want to deploy PippoProxy as a standalone Web application—running under http://[domain]:[port]/pippo/, for example—edit the _ant.properties file (as above), setting the property deploy_local as below:

 # # Local Tomcat webapps. # deploy_local=C:/java/tomcat/5.0/Tomcat 5.0/webapps

So configure the _proxy.properties file (see next section) and launch ant deploy to generate PippoProxy's war file and copy it into Tomcat Web applications automatically.

As a further deployment mode, you can allocate a complete Tomcat server as a proxy server using PippoProxy. In this mode, PippoProxy will proxy all URLs matching the pattern http://[domain]:[port]/* (for further details, see PippoProxy documentation).

Advanced settings

This section describes parameters used by PippoProxy, whether you configure them manually in your J2EE application's deployment descriptor or edit them in the _proxy.properties file.

• ENABLE_SESSION_ATTR_KEY_FOR_LOGIN: True for checking the value of a session attribute before proxying (e.g., true).
• SESSION_ATTR_KEY_FOR_LOGIN: The eventual attribute to check before proxying (e.g., my_attr_for_proxy).
• CACHE_ENABLED: True (static content only) for enabling PippoProxy's cache (e.g., true).
• CACHE_TIMEOUT: Lifetime (in milliseconds) of a resource before being removed from the cache (e.g., 3600000).
• CACHE_MAX_MEMORY_SIZE: The maximum size (in MB) of memory cache (e.g., 10).
• CACHE_MAX_DISK_SIZE: The maximum size (in MB) of filesystem cache (e.g., 50).
• CACHE_PATH_DIR: The absolute path where resources are stored (e.g., /usr/local/pippoproxy/cache).
• REMOTE_HOST: The remote host to proxy (e.g., cocoon.apache.org).
• REMOTE_PORT: The remote port to proxy (e.g., 80).
• IS_ROOT: True for making the application server act as a proxy server (e.g., true); in this mode, PippoProxy handles all http://[domain]:[port]/* URLs. See PippoProxy documentation for further details.
• LOCAL_PREFIX: The local prefix under which PippoProxy runs (e.g., by setting /lp, PippoProxy handles all client requests matching the URL pattern http://[domain]:[port]/[context]/lp/*).
• REMOTE_PREFIX: The remote prefix to proxy (e.g., by setting /2.1, a client request for http://[domain]:[port]/[context]/lp/index.html will map to http://[REMOTE_HOST]:[REMOTE_PORT]/2.1/index.html).
• NOT_ALLOWED_HEADERS: The pipe-separated list of HTTP headers to block (e.g., Content-Encoding|Content-Type).
• PROXY_ENABLED: True if a further proxy server is available for reaching the internal server to proxy (e.g., true).
• PROXY_HOST: The eventual proxy host for reaching the internal server to proxy (e.g., my_company.proxy).
• PROXY_PORT: The eventual proxy port for reaching the internal server to proxy (e.g., 80).
• PROTOCOL: Only http currently supported.
• INIT_CONNECTION: The initial number of HTTP connections (e.g., 10).
• MAX_CONNECTION: The maximum HTTP connections in the pool (e.g, 15).

Performance comparisons

This section compares the performance of PippoProxy deployed to Tomcat (5.5.4) and a standard Apache(2.0.49)-Tomcat(5.5.4) pair connected with mod_jk2 in the same machine.

Note: mod_jk2 has been configured so that the required resources are not forwarded by Apache to Tomcat, but handled locally by Apache itself (workers2.properties file).

Testing platform:

• Intel 730 GHz Pentium III
• Single processor
• 256 MB RAM
• Linux 2.6.8

The tests attempt to simulate user scenarios where the same set of static resources is requested at a high repetition rate, hence, where the efficiency of the cache directly affects overall performance. Two file sizes have been used, 13 KB and 128 KB, and the same resource is requested 1,000 and 500 times, respectively.

As shown in Figure 7, the performance gap relative to the standard proxy increases as the file size increases. This is due to the fact that the PippoProxy cache works on the well-known principle of temporal locality, where programs tend to reuse data and instructions they have recently used (see Resources for more information).

For small files, mod_jk and PippoProxy performances are quite similar, since the file initial-access time is a substantial portion of the total time for handling requests. But for larger files, differences among diverse caching behaviors are more evident. Though elapsed time for first calls is quite comparable, after 500 calls, on average, PippoProxy is five times faster than mod_jk. See Figure 8, where PippoProxy's throughput increases as the file size increases, while mod_jk throughput decreases.

This comparison shows how PippoProxy's built-in cache speeds up the delivery of static content for medium to large file sizes, without any penalty on the delivery of dynamic content, since the latter is managed in both cases by the supporting servlet engine.

Conclusion

This article introduced PippoProxy, a one-to-one replacement for standard Apache-Tomcat proxy solutions, and illustrated application scenarios in which this Tomcat-embeddable HTTP proxy offers clear advantages over standard Apache-Tomcat proxy solutions. Regardless of the deployment scenario, in case of static (or quasi-static) content, PippoProxy caching proves to be efficient; its performance is five times that of the traditional mod_jk-based proxy. Finally, PippoProxy does not require any optional modules or even a Web server for connecting to Tomcat, and configuration and deployment are easy when using Apache Ant.

I'd like to thank my manager Marco Fillo at Virgilio for his support while preparing this article and Vanessa di Lima for her invaluable assistance.

Author Bio

Gino Tesei is a senior software architect at Virgilio, one of the largest Italian Web portals. He specializes in search engines, e-shopping, and financial Websites. He has previously worked on a variety of projects in the finance and fashion industries. He is the creator of PippoProxy, has authored several technical articles, and is a member of the Java User Group Milano.

All contents copyright 1995-2007 Java World, Inc. http://www.javaworld.com

실 전산에서 적용한 방법으로 Fail-Over도 지원이 된다.

가중치 라운드 로빈방식으로 할당비중치를 줄수 있으나 다만 문제는 톰켓이 완전히 죽지 않은 상태... 즉 웹 어플리케이션이 GC나 스타팅이 되지 않은 상태에도 할당이 된다....

PS)당연하겠지만.. 톰켓자체가 죽지 않는 상태이니 그럴꺼란 생각이 든다

Apache2.0 + Tomcat 5.5.27 + jk-connect

1.workers.properties
# workers.properties
worker.list=tomcatlb,tomcat6,tomcat7

worker.tomcatlb.type=lb
worker.tomcatlb.balanced_workers=tomcat6,tomcat7
worker.tomcatlb.sticky_session=1
worker.tomcatlb.local_worker_only=1
 
worker.tomcat6.port=1901
worker.tomcat6.host=localhost
worker.tomcat6.type=ajp13
worker.tomcat6.lbfactor=1
worker.tomcat6.local_worker=1
worker.tomcat6.socket_timeout=60
worker.tomcat6.socket_keepalive=true
 
#worker.tomcat6.cachesize=10
# END workers.properties
 
#tomcat7.tomcat-test.com
worker.tomcat7.port=1902
worker.tomcat7.host=localhost
worker.tomcat7.type=ajp13
worker.tomcat7.lbfactor=1
worker.tomcat7.local_worker=1
worker.tomcat7.socket_timeout=60
worker.tomcat7.socket_keepalive=true

2.http.conf

    ServerAdmin root@tomcat-test.com
    DocumentRoot $APACHE2/htdocs
    #ErrorDocument 404 /jsp/base/404.jsp
    ServerName tomcat6.tomcat-test.com
    ErrorLog "|/usr/local/sbin/cronolog $APACHE2/logs/%Y%m/tomcat6.tomcat-test.com-error_log-%Y%m%d"
    CustomLog "|/usr/local/sbin/cronolog $APACHE2/logs/%Y%m/tomcat6.tomcat-test.com-access_log-%Y%m%d" common
 
    JkMount /jsp/* tomcatlb
    JkMount /servlet/* tomcatlb
    JkMount /admin/* tomcatlb
    JkMount /manager/* tomcatlb
    JkMount /probe/* tomcat6
    JkMount /probe2/* tomcat7
    #JkMount /otherworker/*.jsp remoteworker

클러스터링 스케줄링

1)라운드-로빈(round-robin)
라운드-로빈 방식은 로드밸런서에 들어오는 요청 패킷들을 차례대로 실제 서버에 할당하는 방식이 다. 이 방식에서 실제 서버의 현재 부하 상황 등은 고려되지 않는다. 단지 차례대로 할당할 뿐이다. 하지만, 이렇게 하더라도 로드밸런싱을 위해 이전에 사용되던 라운드-로빈 DNS 방식에 의해 서버를 할당하는 방식에 비해서는 우수한데, DNS의 경우는 한번 서버가 지정되면 해당 서버에 수많은 요청 패킷이 몰릴 수 있기 때문이다.

2)가중 라운드-로빈(weighted round-robin)
가중 라운드-로빈 방식은 기본적으로 라운드-로빈 방식인데, 각 서버에 서로 다른 가중치를 주어서 할당하는 방식이다. 이 방식을 사용해야 하는 경우는 실제 서버들이 CPU의 수와 성능, 메모리 용량 등 서로 다른 성능을 가지고 있어서, 각 서버를 동등하게 취급할 수 없는 경우이다.

3)최소 연결(least connection)
최소 연결 방식은 실제 서버들 중에서 현재 가장 적은 수의 요청을 처리하고 있는 서버를 선택하여 요청 패킷을 할당하는 방식이다. 이 방식은 실제 서버의 현재 부하 상황을 동적으로 판단하여 요청을 처리하기 때문에, 앞의 두 방식에 비해서 동적으로 우수한 부하 분산 효과를 얻을 수 있다.

4)가중 최소 연결(weighted least connection)
가중 최소 연결 방식은 기본적으로 최소 연결 방식인데, 가중 라운드-로빈 방식과 마찬가지로 각 서버에 서로 다른 가중치를 주어서 할당하는 방식이다.

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

제시된 클러스터 설정

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

• 로드 밸런서: 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. Tomcat cluster architecture diagram

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

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

자바 클래스

• BaseLoadBalancingRule

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

• RandomRedirectRule

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

• RoundRobinRule

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

• ServerUtil

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

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 타겟을 호출하라.

예제 코드

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. Cluster application sequence diagram (큰 화면으로 보기 위해 그림을 클릭하시오)

클러스터 설정

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 책의 톰캣 클러스터링 챕터는 이 주제에 대해 매우 훌륭하게 설명하고 있다.

로드 밸런서 설정

테스팅 설정

세선 영속성 테스팅

부하 테스팅

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

결론

참고 자료

• 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

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

Large-Scale 시스템 디자인

클러스터링

톰캣에서의 클러스터링

로드 밸런싱

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

톰캣에서의 로드 밸런싱

결함 허용(Fault Tolerance)

톰캣에서의 결함 허용

• 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)

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

톰캣에서의 세션 복제

• 톰캣 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 클러스터를 구현하는데 있어서 고려해야 할 요소

클러스터링

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

로드 밸런싱

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

결함 허용(Fault Tolerance)

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

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

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

제안된 클러스터 설정

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

결론