[JBoss/Apache] mod_cluster 연동 완벽 가이드: 동적 클러스터링 및 멀티캐스트 설정

JBoss EAP 6와 Apache HTTP Server를 mod_cluster 모듈을 사용하여 연동하는 방법을 정리합니다. 정적인 설정 없이도 WAS의 추가/삭제를 자동으로 감지하는 동적 클러스터링을 구현하며, 멀티캐스트(Advertise) 설정을 중심으로 다룹니다.

0. 사전 준비 (Prerequisites)

• OS: Windows 10 (테스트 환경)
• Web Server: Apache 2.2.x (JBoss EWS 포함 버전 권장)
• Middleware: JBoss EAP 6.4.x

버전 호환성 주의: Apache 버전에 맞는 mod_cluster 모듈(.so)을 사용해야 합니다. JBoss EWS(Enterprise Web Server) 패키지를 사용하면 이미 최적화된 모듈이 포함되어 있습니다.

---

1. Apache 설정 (Web Server)

Apache에 mod_cluster 관련 모듈을 로드하고, JBoss가 보낸 멀티캐스트 신호를 수신할 수 있도록 설정합니다.

1) 필수 모듈 복사

JBoss EAP 설치 경로에 포함된 mod_cluster 관련 모듈(.so)을 Apache의 modules 디렉토리로 복사합니다.

• 원본 위치: [EAP_HOME]/modules/system/layers/base/native/lib64/httpd/modules
• 복사할 파일:
  • mod_advertise.so
  • mod_manager.so
  • mod_proxy_cluster.so
  • mod_slotmem.so

2) mod_cluster.conf 작성

httpd.conf에서 include 할 설정 파일을 작성합니다. 핵심은 VirtualHost 내의 ServerAdvertise On 설정입니다.

# 필수 모듈 로드 (순서 중요)
LoadModule slotmem_module modules/mod_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule advertise_module modules/mod_advertise.so

# 공유 메모리 파일 위치 지정
MemManagerFile "C:/Apache/logs/mod_cluster"


  # JBoss 상태 관리 및 Advertise 수신 포트
  Listen 6666
  
    
      Order deny,allow
      Deny from all
      Allow from 127.0.0.1  # 보안상 로컬 접근만 허용 권장
    
    
    # 멀티캐스트 광고 활성화 (핵심)
    ServerAdvertise on
    EnableMCPMReceive

    # 관리 콘솔 URL
    
      SetHandler mod_cluster-manager
      Order deny,allow
      Allow from all
    
  

---

2. JBoss 설정 (Middleware)

JBoss가 기동될 때 자신의 정보를 멀티캐스트로 전파하거나, 프록시(Apache) 리스트를 받아오도록 설정합니다.

1) Instance ID 설정 (domain.xml)

Sticky Session을 위해 각 서버 인스턴스에 고유한 ID를 부여해야 합니다. ${jboss.server.name} 변수를 사용하면 편리합니다.

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" instance-id="${jboss.server.name}" native="false">
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
    <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/>
    ...
</subsystem>

2) 소켓 바인딩 (Socket Binding) - 멀티캐스트 주소

동일 네트워크 내에 여러 JBoss 클러스터가 존재할 경우 혼선을 방지하기 위해 멀티캐스트 주소나 포트를 변경해야 합니다.

domain.xml 수정 (socket-binding-group):

<socket-binding-group name="full-ha-sockets" default-interface="public">
    
    ...
</socket-binding-group>

Tip: XML을 수정하지 않고 기동 시 파라미터(System Property)로 주소를 변경할 수 있습니다.
-Djboss.modcluster.multicast.address=224.10.1.1

---

3. 검증 및 테스트

설정 완료 후 Apache -> JBoss 순서로 기동합니다.

1) Apache 관리 콘솔 접속

브라우저에서 http://[Apache_IP]:6666/mod_cluster_manager 로 접속합니다.

• 정상: 하단에 연결된 JBoss Node(Node Name, IP, Port) 리스트가 나타납니다.
• 실패: 리스트가 비어있다면 멀티캐스트 통신이 방화벽에 막혀있거나, Advertise 설정이 잘못된 것입니다.

2) 클러스터링 동작 확인

애플리케이션 호출 시 세션이 유지되는지 확인하고, 한 쪽 노드를 셧다운 시켰을 때 Failover가 일어나는지 테스트합니다.

[그림] mod_cluster 매니저 화면 (노드 인식 성공)

---

Next Step:
멀티캐스트 사용이 불가능한 클라우드 환경이라면, mod_cluster 설정을 TCP 유니캐스트(Proxy List 지정 방식)로 변경하여 구성하는 방법을 검토해 보십시오.

[JBoss EAP 6] Windows Service 등록 가이드 (service.bat install)

Windows 환경에서 JBoss EAP 6를 백그라운드 서비스로 등록하여, 시스템 부팅 시 자동으로 시작되도록 설정하는 방법을 정리합니다. JBoss Native 패키지에 포함된 service.bat 스크립트를 사용합니다.

0. 사전 준비 (Prerequisites)

서비스 등록 작업을 수행하기 위해 관리자 권한(Run as Administrator)으로 실행된 명령 프롬프트(CMD)가 필요합니다.

시스템 환경 변수 설정

JBoss가 서비스로 구동될 때 참조할 필수 변수를 시스템 환경 변수에 등록해야 합니다.

• JBOSS_HOME: JBoss EAP 6 설치 디렉토리 (예: C:\jboss-eap-6.4)
• NOPAUSE: 값을 1로 설정.
  (※ 중요: 이 설정이 없으면 서비스 종료 시 배치 스크립트가 "Press any key..." 상태로 대기하여 서비스가 정상적으로 멈추지 않는 문제가 발생합니다.)

---

1. 서비스 설치 스크립트 위치

JBoss EAP 6는 Windows 서비스 등록을 위한 Native 유틸리티를 내장하고 있습니다. 해당 경로로 이동합니다.

:: 경로 이동 (설치 환경에 따라 경로가 다를 수 있음)
cd %JBOSS_HOME%\modules\system\layers\base\native\sbin

:: 파일 확인
dir service.bat

---

2. 서비스 등록 (Install Command)

service.bat install 명령어를 사용합니다. 운영 모드(Standalone / Domain)에 따라 옵션이 다릅니다.

Case A: Standalone Mode (단독 인스턴스)

가장 일반적인 구성입니다. 로그 레벨을 지정하여 설치합니다.

service.bat install /loglevel INFO

Case B: Domain Mode (도메인 구성)

도메인 컨트롤러(Domain Controller)와 연결해야 하므로 컨트롤러 정보가 필요합니다.

:: 기본 구문
service.bat install /controller [Host:Port] /host [HostName] /loglevel INFO

:: 사용 예시 (로컬이 마스터인 경우)
service.bat install /controller localhost:9990 /host master /loglevel INFO

주요 옵션 설명

옵션	설명
/name	서비스 이름 지정 (기본값: JBossEAP6)
/desc	서비스 설명 지정
/serviceuser	서비스를 실행할 Windows 계정 (DOMAIN\User)
/servicepass	실행 계정의 암호

---

3. 등록 확인 및 제어 (Verification)

설치가 완료되면 Windows 서비스 관리자에서 확인할 수 있습니다.

1. 실행 창(Win+R) > services.msc 입력.
2. "JBoss Enterprise Application Platform 6" 서비스를 찾습니다.
3. 서비스를 시작(Start) 하고, 상태가 '실행 중'으로 바뀌는지 확인합니다.
4. 브라우저로 JBoss 관리 콘솔이나 메인 페이지에 접속하여 실제 구동 여부를 체크합니다.

---

4. 서비스 삭제 (Uninstall)

설정을 변경하거나 경로를 바꿀 경우, 기존 서비스를 삭제하고 다시 등록해야 합니다.

:: 서비스 중지 (먼저 수행 필수)
service.bat stop

:: 서비스 삭제
service.bat uninstall

주의: 서비스 삭제 후 services.msc 목록에 잔상이 남아있다면, 윈도우를 재부팅하거나 관리자 권한 CMD에서 sc delete [서비스명]을 강제로 수행해야 할 수 있습니다.

[IHS/Apache] 보안 강화를 위한 불필요 HTTP Method(PUT, DELETE, TRACE) 차단 설정

웹 서버 운영 시 보안 취약점(파일 변조, 정보 노출 등)을 방지하기 위해 GET, POST를 제외한 불필요한 HTTP Method(PUT, DELETE, TRACE, OPTIONS)를 차단하는 방법을 정리합니다. IBM HTTP Server(Apache) 설정과 WAS(web.xml) 설정 두 가지 방식을 다룹니다.

0. 배경 지식 (Context)

기본적으로 웹 서버는 다양한 HTTP Method를 지원하지만, 실제 서비스에서는 대부분 GET과 POST만 사용합니다. 불필요한 메소드를 열어둘 경우 다음과 같은 보안 위험이 있습니다.

• PUT, DELETE: 악의적인 사용자가 서버의 파일을 생성, 수정, 삭제할 수 있음.
• TRACE: XST(Cross-Site Tracing) 공격에 악용되어 쿠키/세션 정보가 탈취될 수 있음.
• OPTIONS: 서버가 지원하는 메소드 정보를 노출함.

Test Environment

• OS: CentOS 7.2
• Web Server: IBM HTTP Server v8.5 (Apache 2.2 Base)

---

1. Web Server 레벨 차단 (httpd.conf)

가장 앞단의 웹 서버에서 원천 차단하는 것이 리소스 낭비를 막고 안전합니다. 두 가지 방법 중 하나를 선택하여 적용하십시오.

Method A: LimitExcept 지시어 사용 (권장)

특정 디렉토리나 URL 패턴에 대해 허용할 메소드를 정의하고 나머지는 거부하는 방식입니다.

# 1. 특정 디렉토리 기준 차단
<Directory "/WAS/htdocs">
    Options FollowSymLinks
    AllowOverride None
    
    # GET, POST를 제외한 모든 메소드 거부
    <LimitExcept GET POST>
        Order allow,deny
        Deny from all
    </LimitExcept>
</Directory>

# 2. 전역(URL) 기준 차단 (Directory 설정이 모호할 때)
<Location "/*">
    <LimitExcept GET POST>
        Order allow,deny
        Deny from all
    </LimitExcept>
</Location>

버전별 문법 주의 (Note):
IHS v8.5(Apache 2.2)는 Order/Deny를 사용하지만, IHS v9.0(Apache 2.4) 이상에서는 Require all denied 문법을 사용해야 합니다.

Method B: Mod_Rewrite 사용

mod_rewrite 모듈을 사용하여 메소드 조건을 검사하고 강제로 에러 코드를 반환하는 방식입니다.

LoadModule rewrite_module modules/mod_rewrite.so

<IfModule mod_rewrite.c>
    RewriteEngine On
    
    # 조건: 요청 메소드가 GET 또는 POST가 아니라면
    RewriteCond %{REQUEST_METHOD} !^(GET|POST)
    
    # 규칙: 405 (Method Not Allowed) 에러 반환
    RewriteRule .* - [R=405,L]
</IfModule>

---

2. WAS 레벨 차단 (web.xml)

웹 서버 설정이 불가능하거나, 애플리케이션(WAR) 단위로 제어가 필요한 경우 표준 배포 서술자(web.xml)를 사용합니다.

설정 방법

web.xml에 security-constraint를 추가하여 특정 메소드에 대한 접근을 제한합니다.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Restricted Methods</web-resource-name>
        <url-pattern>/*</url-pattern>
        
        <!-- 차단할 메소드 명시 -->
        <http-method>PUT</http-method>
        <http-method>DELETE</http-method>
        <http-method>TRACE</http-method>
        <http-method>OPTIONS</http-method>
        <http-method>HEAD</http-method>
    </web-resource-collection>
    
    <!-- 중요: auth-constraint를 비워두면 누구에게도 권한을 주지 않음(차단) -->
    <auth-constraint />
</security-constraint>

---

3. 검증 (Verification)

설정 적용 후 반드시 테스트를 통해 차단 여부를 확인해야 합니다. telnet 또는 curl을 사용합니다.

Telnet을 이용한 테스트

$ telnet localhost 80
Trying ::1...
Connected to localhost.
Escape character is '^]'.

# OPTIONS 메소드 요청 입력
OPTIONS / HTTP/1.0
Host: localhost
(엔터 두 번)

# 결과 확인 (403 Forbidden 또는 405 Method Not Allowed 확인)
HTTP/1.1 403 Forbidden
Date: Wed, 04 Jul 2018 01:44:40 GMT
...

Curl을 이용한 테스트 (간편)

# -X 옵션으로 메소드 지정, -I 옵션으로 헤더만 확인
curl -v -X OPTIONS http://localhost/

# 결과: < HTTP/1.1 403 Forbidden 확인

---

Next Step:
메소드 차단 외에도 ServerTokens Prod 설정을 통해 헤더에 노출되는 웹 서버 버전 정보를 숨기는 보안 조치를 추가로 검토해 보시기 바랍니다.

[IBM HTTP Server ] IBM HTTP Server v8.5 vs v9.0: Apache Base Version 확인 및 차이점 (Apache 2.2 vs 2.4)

IBM HTTP Server(IHS)는 Apache HTTP Server를 기반으로 만들어졌습니다. IHS v8.5(Apache 2.2 기반)와 IHS v9.0(Apache 2.4 기반)의 버전 정보를 확인하고, 엔진 업그레이드에 따른 설정 파일(httpd.conf) 호환성 주의사항을 정리합니다.

1. 버전 확인 방법 (Check Version)

IHS의 실행 파일(apache.exe 또는 httpd)에 -V 옵션을 주어 컴파일 옵션과 기반 버전을 확인할 수 있습니다.

명령어

# Windows
cd [IHS_HOME]\bin
.\apache.exe -V

# Linux/Unix
cd [IHS_HOME]/bin
./apachectl -V

---

2. 버전별 상세 정보 (Output Analysis)

IHS v8.5 (Apache 2.2 Base)

IHS 8.5.5는 Apache 2.2.8 버전을 베이스로 하여 IBM의 추가적인 패치와 보안 수정이 적용된 버전입니다.

PS E:\app\was\HTTPServer\bin> .\apache.exe -V
Server version: IBM_HTTP_Server/8.5.5.0 (Win32)
Apache version: 2.2.8 (with additional fixes)  <-- Check Point
Server built:   Feb 20 2013 13:50:05
Architecture:   32-bit
Server MPM:     WinNT
  threaded:     yes (fixed thread count)
  forked:       no
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/winnt"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D HTTPD_ROOT="/apache"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

IHS v9.0 (Apache 2.4 Base)

IHS 9.0은 Apache 2.4.12 버전을 베이스로 합니다. Apache 2.4로 넘어오면서 성능 개선(Event MPM 등)과 설정 문법의 변화가 생겼습니다.

PS E:\software\IBM\HTTPServer9\bin> .\apache.exe -V
Server version: IBM_HTTP_Server/9.0.0.0-PI56034 (Win32)
Apache version: 2.4.12 (with additional fixes) <-- Check Point
Server built:   Apr 18 2016 20:28:53
Architecture:   32-bit
Server MPM:     WinNT
  threaded:     yes (fixed thread count)
  forked:       no
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/apache"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

---

3. 마이그레이션 주의사항 (Apache 2.2 vs 2.4)

IHS v8.5에서 v9.0으로 업그레이드할 때 가장 주의해야 할 점은 접근 제어(Access Control) 구문의 변화입니다. 기존 httpd.conf를 그대로 사용하면 에러가 발생할 수 있습니다.

주요 변경 점 비교

구분	IHS v8.5 (Apache 2.2)	IHS v9.0 (Apache 2.4)
모든 요청 허용	Order allow,deny Allow from all	Require all granted
모든 요청 거부	Order deny,allow Deny from all	Require all denied
특정 IP 허용	Order deny,allow Deny from all Allow from 127.0.0.1	Require ip 127.0.0.1

Warning: IHS 9.0에서 기존 2.2 문법(Order/Allow)을 사용하려면 mod_access_compat 모듈을 로드해야 합니다. 하지만 장기적으로는 신규 문법(Require)으로 전환하는 것을 권장합니다.

---

Next Step:
IHS 버전을 업그레이드할 계획이라면, 운영 중인 httpd.conf 파일 내의 접근 제어 구문을 미리 전수 조사하여 Apache 2.4 문법으로 변환하는 작업을 진행해 보십시오.

[WebSphere] Liberty Core 설치 및 필수 설정 가이드 (CLI Install, server.xml, Plugin)

IBM WebSphere Liberty Core를 GUI 없이 Command Line(CLI) 환경에서 설치하고, 서버 생성 및 기동, 핵심 설정(server.xml, JVM), 그리고 웹 서버 연동을 위한 플러그인 생성(pluginUtility) 과정을 단계별로 정리합니다.

1. 제품 설치 (CLI Mode)

Liberty는 Installation Manager(IM)의 imcl 명령어를 통해 설치합니다. GUI를 사용할 수 없는 리눅스/유닉스 서버 환경에서 필수적인 방법입니다.

설치 명령어 (imcl)

-repositories 옵션에는 설치 파일(Repository)의 경로를 지정합니다. 콤마(,)로 구분하여 WAS와 JDK 리포지토리를 동시에 지정할 수 있습니다.

# 설치 예시 (Windows 기준, Linux는 경로만 변경)
imcl install com.ibm.websphere.liberty.v85_8.5.16002.20160526_2338 \
com.ibm.websphere.liberty.IBMJAVA.v80_8.0.3020.20161124_1304 \
-repositories "D:\Liberty\16.0.0.2-WS-LIBERTY-CORE,D:\work_file\was_install\v8.5.5\SDK\8.0.3.20" \
-installationDirectory "F:\app\IBM\wlpcore\AppServer" \
-acceptLicense \
-showProgress -sP

Tip: 패키지 ID(com.ibm...)를 모를 경우 imcl listAvailablePackages -repositories [경로] 명령어로 미리 확인해야 합니다.

---

2. 서버 생명주기 관리 (Server Lifecycle)

설치가 완료되면 bin 디렉토리의 server 스크립트를 사용하여 서버 인스턴스를 생성하고 제어합니다.

1) 서버 생성 (Create)

cd [WLP_HOME]/bin
# 구문: server create [서버명]
server.bat create test01

생성이 완료되면 [WLP_HOME]/usr/servers/test01 경로에 설정 파일들이 만들어집니다.

2) 서버 기동 및 상태 확인 (Start/Status)

# 서버 기동
server.bat start test01

# 상태 확인 (필수 검증 단계)
server.bat status test01

---

3. 핵심 설정 (server.xml)

Liberty의 모든 구성은 server.xml 파일 하나에 통합되어 있습니다. 필요한 기능(Feature)만 선언해서 사용하는 구조입니다.

설정 파일 위치

• [WLP_HOME]/usr/servers/[서버명]/server.xml

주요 설정 예시

<?xml version="1.0" encoding="UTF-8"?>
<server description="Test Server">

    <!-- 1. Feature Manager: 필요한 기능 모듈 로드 -->
    <featureManager>
        <feature>jsp-2.2</feature>
        <feature>jdbc-4.0</feature>
        <feature>localConnector-1.0</feature> <!-- 로컬 관리용 -->
        <feature>adminCenter-1.0</feature>    <!-- 웹 관리 콘솔 -->
    </featureManager>

    <!-- 2. HTTP Endpoint: 포트 설정 -->
    <!-- host="*"는 모든 IP 대역에서의 접속을 허용함 -->
    <httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="9080" httpsPort="9443">
        <tcpOptions soReuseAddr="true" />
    </httpEndpoint>

    <!-- 3. Web Server Plugin 설정 -->
    <pluginConfiguration webserverPort="80" webserverSecurePort="443"/>

    <!-- 4. Application 배포 설정 (자동 인식이 편함) -->
    <applicationManager autoExpand="true"/>
    
    <!-- 5. DB Connection (Oracle 예시) -->
    <dataSource id="WorklightDS" jndiName="jdbc/WorklightDS">
        <jdbcDriver libraryRef="OracleLib"/>
        <properties.oracle 
            driverType="thin" 
            databaseName="ORCL" 
            serverName="localhost" 
            portNumber="1521" 
            user="SCOTT" 
            password="{xor}KDAtNDM2ODcr"/> <!-- securityUtility로 암호화 권장 -->
    </dataSource>

    <!-- 6. Logging 설정 -->
    <logging maxFiles="5" consoleLogLevel="INFO"/>

</server>

초보자를 위한 Tip:
설정 파일의 password="{xor}..." 부분은 평문을 그대로 넣지 않고, Liberty가 제공하는 bin/securityUtility encode [암호] 명령어를 사용하여 인코딩된 값을 넣어야 보안상 안전합니다.

---

4. 환경 변수 및 JVM 옵션 설정

메모리(Heap) 설정이나 로그 경로 변경 등은 별도의 설정 파일에서 관리합니다.

1) JVM 옵션 (jvm.options)

Heap Size나 GC 로그 설정은 jvm.options 파일에 라인 단위로 작성합니다.

• 위치: [WLP_HOME]/usr/servers/[서버명]/jvm.options

# Heap Memory 설정
-Xms512m
-Xmx1024m

# GC 로그 설정
-verbose:gc
-Xverbosegclog:verbosegc.log
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC

2) 환경 변수 (server.env)

JAVA_HOME 지정이나 커스텀 로그 경로는 server.env에 정의합니다.

# Java 버전 지정
JAVA_HOME=C:\Java\jdk1.8.0

# 로그 경로 변경 (Optional)
WLP_OUTPUT_DIR=F:\app\IBM\wlpcore\AppServer\usr\logs\test02

---

5. 웹 서버 플러그인 (Plugin) 생성

Liberty 서버 앞단에 IHS(Apache)를 둔다면, plugin-cfg.xml을 생성하여 웹 서버에 알려주어야 합니다.

플러그인 생성 도구 (pluginUtility)

Liberty 16.0.0.4 버전부터 pluginUtility 명령어를 사용합니다.

cd [WLP_HOME]/bin

# 1. 로컬 서버용 플러그인 생성
pluginUtility generate --server=test01 --targetpath=./plugin-cfg.xml

# 2. 원격 서버용 플러그인 생성 (Admin Center 기능 필요)
pluginUtility generate --server=admin:password@remoteHost:9443 --targetpath=./plugin-cfg.xml

# 3. 여러 플러그인 병합 (Merge)
pluginUtility merge --sourcepath=../usr/plugin --targetpath=../usr/merged_plugin.xml

웹 서버(httpd.conf) 적용

생성된 xml 파일을 웹 서버로 복사한 후 httpd.conf에 등록합니다.

# Windows 예시
LoadModule was_ap22_module "C:\IBM\HTTPServer\plugins\bin\mod_was_ap22_http.dll"
WebSpherePluginConfig "C:\IBM\HTTPServer\plugins\config\webserver1\plugin-cfg.xml"

# Linux/Unix 예시
LoadModule was_ap22_module "/opt/IBM/HTTPServer/plugins/bin/mod_was_ap22_http.so"
WebSpherePluginConfig "/opt/IBM/HTTPServer/plugins/config/webserver1/plugin-cfg.xml"

---

Next Step:
기본 설치와 설정이 끝났다면, adminCenter 기능을 활성화하고 브라우저(https://localhost:9443/adminCenter)로 접속하여 GUI 환경에서 서버 상태를 모니터링해 보십시오.

[JBoss EAP 6] Context Root를 루트(/)로 변경하기: Welcome Page 비활성화 설정

웹 애플리케이션을 배포할 때, URL 뒤에 붙는 프로젝트명(예: /MyApp) 없이 도메인 자체(예: http://localhost:8080/)로 접속하도록 설정하는 방법을 정리합니다. 애플리케이션 설정 변경과 JBoss 서버의 기본 Welcome Page 비활성화 작업이 필요합니다.

0. 배경 지식 (Context)

기본적으로 JBoss EAP는 루트 경로(/)에 "Welcome to JBoss"라는 기본 환영 페이지가 매핑되어 있습니다. 사용자의 애플리케이션을 루트 경로에 배포하려면, 이 기본 환영 페이지 기능을 끄고 애플리케이션이 그 자리를 차지하도록 설정해야 합니다.

Test Environment

• OS: CentOS 7.2
• WAS: JBoss EAP 6.4

---

1. 애플리케이션 설정 (jboss-web.xml)

애플리케이션(WAR) 내부의 설정 파일을 통해 "이 앱은 루트 컨텍스트(/)를 사용하겠다"고 선언합니다.

파일 생성 및 수정

• 위치: [WAR_FILE]/WEB-INF/jboss-web.xml
• 파일이 없다면 새로 생성하십시오.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
    <!-- Context Root를 / 로 지정 -->
    <context-root>/</context-root>
</jboss-web>

---

2. 서버 설정 (domain.xml / standalone.xml)

애플리케이션 설정만으로는 부족합니다. JBoss 웹 서브시스템(Web Subsystem) 설정에서 enable-welcome-root 옵션을 false로 변경하여 기본 페이지를 비활성화해야 합니다.

설정 파일 선택

• Domain Mode: [EAP_HOME]/domain/configuration/domain.xml
• Standalone Mode: [EAP_HOME]/standalone/configuration/standalone.xml

수정 내용

도메인 모드의 경우, 현재 서버 그룹이 사용 중인 프로파일(Profile)(예: ha, full, full-ha)을 정확히 찾아 수정해야 합니다.

<!-- 해당 프로파일 내의 web 서브시스템 검색 -->
<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" native="false">
    
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
    
    <!-- 핵심 수정 부분: enable-welcome-root를 false로 변경 -->
    <virtual-server name="default-host" enable-welcome-root="false">
        <alias name="localhost"/>
        <alias name="example.com"/>
    </virtual-server>

</subsystem>

주의 (Warning):
enable-welcome-root="true"인 상태에서 애플리케이션의 Context Root를 /로 설정하고 배포하면, JBoss 기동 시 "Context / is already in use" 에러가 발생하며 배포에 실패합니다.

---

3. 적용 및 검증 (Verification)

설정 변경 후에는 서버 재기동이 필요합니다.

재기동 및 접속 테스트

1. JBoss 서버를 재기동합니다.
2. 브라우저 주소창에 http://[서버IP]:8080/ 을 입력합니다.
3. JBoss 기본 환영 페이지가 아닌, 내가 배포한 애플리케이션의 메인 페이지가 뜨는지 확인합니다.

---

Next Step:
루트 컨텍스트 설정이 완료되었다면, Apache 웹 서버와의 연동 시 mod_jk의 JkMount 설정도 /*로 변경하여 모든 요청을 WAS로 넘기도록 조정해야 합니다.

[JBoss EAP 6] Session Clustering 완벽 가이드: 애플리케이션 설정부터 TCP 유니캐스트 전환까지

JBoss EAP 6의 HA(High Availability) 프로파일 환경에서 웹 애플리케이션의 세션 클러스터링을 구현하는 방법을 정리합니다. <distributable/> 선언부터 복제 트리거 설정, 그리고 웹 서버(Apache)와의 연동을 위한 jvmRoute 및 JGroups 네트워크 설정까지 다룹니다.

Test Environment

• Middleware: JBoss EAP 6.4 (Domain Mode)
• Profile: ha 또는 full-ha (클러스터링 모듈이 포함된 프로파일 필수)

---

1. 애플리케이션 설정 (Application Config)

세션 클러스터링이 작동하려면 먼저 애플리케이션이 "나는 분산 가능한 애플리케이션입니다"라고 선언해야 합니다.

1) web.xml 설정 (필수)

<distributable/> 태그가 없으면 JBoss는 해당 애플리케이션의 세션을 메모리에만 저장하고 복제하지 않습니다.

<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" ...>
    
    <distributable/>

    <session-config>
        <session-timeout>30</session-timeout> </session-config>

</web-app>

2) jboss-web.xml 설정 (옵션/상세 튜닝)

세션 복제의 빈도와 범위를 세밀하게 제어하려면 WEB-INF/jboss-web.xml 파일을 설정합니다.

<jboss-web>
    <replication-config>
        <cache-name>web</cache-name>
        <!-- 복제 시점 결정 -->
        <replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-trigger>
        <!-- 복제 단위 결정 (SESSION: 전체 / ATTRIBUTE: 변경된 속성만) -->
        <replication-granularity>SESSION</replication-granularity>
    </replication-config>
</jboss-web>

Replication Trigger 설명:

• SET: 세션 속성이 변경(setAttribute)될 때만 복제 (성능 우수).
• SET_AND_GET: 세션을 읽기만 해도 복제 (데이터 일관성 최우선).
• SET_AND_NON_PRIMITIVE_GET: (Default) 기본형이 아닌 객체를 읽거나 변경할 때 복제.

---

2. Sticky Session 설정 (jvmRoute)

웹 서버(Apache mod_jk/mod_cluster)가 로드밸런싱을 할 때, 사용자가 처음 접속한 JBoss 서버로 계속 요청을 보내게 하려면(Sticky Session), 세션 ID 뒤에 서버 식별자(jvmRoute)를 붙여야 합니다.

1) host.xml 설정 (서버별 식별자 부여)

각 서버 인스턴스에 고유한 jvmRoute 값을 시스템 프로퍼티로 정의합니다.

<servers>
    <server name="Server01" group="main-server-group" auto-start="true">
        <system-properties>
            <!-- 이 값은 workers.properties의 워커 이름과 일치해야 함 -->
            <property name="jvmRoute" value="Server01" boot-time="true"/>
        </system-properties>
    </server>
    
    <server name="Server02" ...>
        <system-properties>
            <property name="jvmRoute" value="Server02" boot-time="true"/>
        </system-properties>
    </server>
</servers>

2) domain.xml 설정 (Web Subsystem 적용)

정의한 시스템 프로퍼티(${jvmRoute})를 웹 서브시스템의 instance-id로 매핑합니다.

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" instance-id="${jvmRoute}" native="false">
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
    <!-- AJP 커넥터 필수 (mod_jk 연동 시) -->
    <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/>
    ...
</subsystem>

---

3. JGroups 네트워크 설정 (UDP vs TCP)

JBoss 클러스터링 멤버 간의 통신은 기본적으로 UDP(Multicast)를 사용합니다. 하지만 클라우드 환경이나 네트워크 장비에서 멀티캐스트를 차단하는 경우 클러스터링이 되지 않습니다. 이럴 땐 TCP(Unicast)로 변경해야 합니다.

domain.xml 수정

jgroups 서브시스템의 default-stack 속성을 변경합니다.

<!-- 기존 UDP 설정 -->
<subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="udp">

<!-- TCP로 변경 -->
<subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
    <stack name="tcp">
        <transport type="TCP" socket-binding="jgroups-tcp"/>
        ...
    </stack>
</subsystem>

주의: TCP로 변경 시, MPING(멀티캐스트 기반 멤버 검색) 대신 TCPPING을 사용하여 정적으로 IP 리스트를 지정해야 서로를 찾을 수 있는 환경이 많습니다. 네트워크 구성에 따라 추가 설정이 필요합니다.

---

4. 검증 (Verification)

1. 서버 기동 확인: 서버 시작 로그에 Received new cluster view 메시지가 나타나며 멤버들이 서로를 인식하는지 확인합니다.
2. 세션 ID 확인: 브라우저 개발자 도구(F12)에서 JSESSIONID 쿠키 값 뒤에 .Server01 처럼 jvmRoute 값이 붙는지 확인합니다.
3. Failover 테스트: 한 쪽 서버를 강제로 내린 후(Shutdown), 다른 서버에서 로그인 풀림 없이 세션이 유지되는지 테스트합니다.

[JBoss EAP 6] 도메인 모드(Domain Mode) 서버 로그 경로 변경 및 분리 설정

JBoss EAP 6를 도메인 모드(Domain Mode)로 운영할 때, 기본 로그 경로가 아닌 별도의 디스크 경로로 로그를 저장하는 방법을 정리합니다. domain.xml의 paths 설정과 logging 서브시스템을 수정하여 각 서버 인스턴스별로 로그 폴더를 동적으로 분리하는 구성을 다룹니다.

0. 배경 지식 (Context)

도메인 모드에서는 하나의 도메인 컨트롤러(Domain Controller)가 여러 서버 그룹과 인스턴스를 관리합니다. 로그 설정 시 가장 중요한 점은 "여러 서버가 동시에 실행될 때 로그 파일이 섞이지 않게 하는 것"입니다.

이를 위해 JBoss는 ${jboss.server.name}이라는 시스템 변수를 제공하여, 설정은 한 번만 하더라도 실제 로그는 각 서버의 이름으로 된 폴더에 쌓이도록 구성할 수 있습니다.

---

1. 사전 준비 및 백업

설정 변경 중 오타가 발생하면 JBoss 도메인 전체가 기동되지 않을 수 있습니다. 작업 전 반드시 설정 파일을 백업하십시오.

백업 대상

• 파일 경로: [EAP_HOME]/domain/configuration/domain.xml

# 백업 예시
cp domain.xml domain.xml.bak_YYYYMMDD

---

2. 로그 경로(Path) 정의

먼저 로그를 저장할 물리적인 디렉토리 경로를 domain.xml 내에 논리적인 이름으로 정의해야 합니다. 이 설정은 파일의 상단 <paths> 섹션에 위치합니다.

domain.xml 수정

기존 <paths> 태그 내부에 새로운 경로를 추가합니다.

<paths>
    <!-- 기존 경로들 ... -->
    
    <!-- 신규 로그 경로 정의 -->
    <!-- name: 설정에서 사용할 논리적 이름 / path: 실제 파일 시스템 경로 -->
    <path name="server.log.dir" path="D:\app\log"/>
</paths>

주의: Windows 환경에서는 백슬래시(\)를 사용하고, Linux 환경에서는 슬래시(/)를 사용하여 경로를 지정하십시오. 또한 해당 경로에 JBoss 실행 계정이 쓰기 권한을 가지고 있어야 합니다.

---

3. 프로파일(Profile) 로깅 설정 적용

위에서 정의한 경로를 실제로 사용하도록 로깅 서브시스템(Subsystem)을 수정합니다. 도메인 모드에는 여러 프로파일(default, ha, full, full-ha 등)이 존재하므로, 현재 운영 중인 서버 그룹이 사용하는 프로파일을 정확히 찾아 수정해야 합니다.

domain.xml 수정 (logging subsystem)

<profile name="ha"> (예시) 내부의 로깅 설정을 찾아 file-handler 부분을 수정합니다.

<profile name="ha">
    <subsystem xmlns="urn:jboss:domain:logging:1.2">
        <!-- Console Handler 생략 -->

        <!-- File Handler 수정 -->
        <periodic-rotating-file-handler name="FILE" autoflush="true">
            <formatter>
                <named-formatter name="PATTERN"/>
            <formatter>
            
            <!-- 핵심 설정 부분 -->
            <!-- relative-to: 위에서 정의한 경로 변수 참조 -->
            <!-- path: 서버 이름별로 폴더 자동 생성 -->
            <file relative-to="server.log.dir" path="${jboss.server.name}/server.log"/>
            
            <suffix value=".yyyy-MM-dd"/>
            <append value="true"/>
        </periodic-rotating-file-handler>
        
        <!-- 이하 생략 -->
    </subsystem>
</profile>

설정 설명

• relative-to="server.log.dir": 2번 단계에서 정의한 D:\app\log를 기준 경로로 잡습니다.
• path="${jboss.server.name}/server.log": 기준 경로 하위에 서버 인스턴스 이름(예: Server1, Server2)으로 폴더를 만들고 그 안에 server.log를 생성합니다.

---

4. 적용 및 검증 (Verification)

domain.xml은 정적 설정 파일이므로 변경 사항을 적용하려면 도메인 전체 재기동이 필요합니다.

재기동

# Linux
[EAP_HOME]/bin/domain.sh

# Windows
[EAP_HOME]\bin\domain.bat

결과 확인

서버가 기동된 후, 탐색기나 쉘을 통해 지정한 경로(D:\app\log)에 서버별 폴더가 생성되었는지 확인합니다.

D:\app\log\
    ├── Server1\
    │     └── server.log
    └── Server2\
          └── server.log

---

Next Step:
로그 경로 변경에 성공했다면, 운영 편의를 위해 로그 파일의 보관 주기(Retention Policy)를 설정하거나, 로그 포맷(Formatter)을 변경하여 가독성을 높이는 작업을 고려해 보십시오.

[Apache/Tomcat] 다중 도메인 구성을 위한 VirtualHost 및 AJP 포트 매핑 가이드

하나의 물리 서버에서 여러 도메인(예: aaa.com, bbb.com)을 서비스하기 위해 Apache의 VirtualHost와 Tomcat의 멀티 Service 구성을 연동하는 방법을 정리합니다. 도메인별로 다른 AJP 포트를 할당하여 요청을 분리하는 것이 핵심입니다.

1. 아키텍처 및 원리 (Context)

설정의 목표는 요청 흐름을 다음과 같이 분리하는 것입니다.

• AAA.test.com (Apache:80) → Worker(aaa) → Tomcat AJP(8009) → Service A
• BBB.test.com (Apache:80) → Worker(bbb) → Tomcat AJP(8010) → Service B
• CCC.test.com (Apache:80) → Worker(ccc) → Tomcat AJP(8011) → Service C

---

2. Apache 설정 (httpd-vhosts.conf)

가장 먼저 Apache가 들어오는 도메인(ServerName)을 구분하여 적절한 mod_jk 워커에게 토스하도록 설정합니다.

설정 활성화 (httpd.conf)

# 주석 해제하여 vhosts 설정 파일 로드
Include conf/extra/httpd-vhosts.conf

가상 호스트 정의 (httpd-vhosts.conf)

각 도메인별로 VirtualHost 블록을 생성하고 JkMount를 통해 서로 다른 워커 이름을 지정합니다.

# 1. AAA 도메인 설정
<VirtualHost *:80>
    ServerName AAA.test.com
    DocumentRoot "/WAS/apps/test1"
    
    ErrorLog "logs/aaa-error_log"
    CustomLog "logs/aaa-access_log" common
    
    # 워커 'aaa'에게 모든 요청 전달
    JkMount /* aaa
</VirtualHost>

# 2. BBB 도메인 설정
<VirtualHost *:80>
    ServerName BBB.test.com
    DocumentRoot "/WAS/apps/test2"
    
    ErrorLog "logs/bbb-error_log"
    CustomLog "logs/bbb-access_log" common
    
    # 워커 'bbb'에게 모든 요청 전달
    JkMount /* bbb
</VirtualHost>

# 3. CCC 도메인 설정
<VirtualHost *:80>
    ServerName CCC.test.com
    DocumentRoot "/WAS/apps/test3"
    
    ErrorLog "logs/ccc-error_log"
    CustomLog "logs/ccc-access_log" common
    
    # 워커 'ccc'에게 모든 요청 전달
    JkMount /* ccc
</VirtualHost>

---

3. mod_jk 워커 설정 (workers.properties)

Apache에서 지정한 워커 이름(aaa, bbb, ccc)이 실제로 통신할 Tomcat의 AJP 포트를 정의합니다.

# 워커 리스트 정의
worker.list=aaa,bbb,ccc

# [aaa] 워커 정의 (기본 포트 8009)
worker.aaa.port=8009
worker.aaa.host=localhost
worker.aaa.type=ajp13

# [bbb] 워커 정의 (포트 8010)
worker.bbb.port=8010
worker.bbb.host=localhost
worker.bbb.type=ajp13

# [ccc] 워커 정의 (포트 8011)
worker.ccc.port=8011
worker.ccc.host=localhost
worker.ccc.type=ajp13

---

4. Tomcat 설정 (server.xml)

Tomcat 하나에서 여러 포트를 리슨하기 위해 <Service> 태그를 복제하여 구성합니다. 각 서비스마다 포트(HTTP, HTTPS, AJP)가 겹치지 않도록 주의해야 합니다.

서비스 A (AAA) 설정

<Service name="CatalinaA">
    <!-- HTTP Port: 8080 -->
    <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
    
    <!-- AJP Port: 8009 (workers.properties의 aaa와 매핑) -->
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

    <Engine name="CatalinaA" defaultHost="localhost">
        <Host name="localhost" appBase="/WAS/apps/aaa" unpackWARs="true" autoDeploy="true">
            <Context path="" docBase="." reloadable="true"/>
        </Host>
    </Engine>
</Service>

서비스 B (BBB) 설정

<Service name="CatalinaB">
    <!-- HTTP Port: 8081 (충돌 방지) -->
    <Connector port="8081" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8444" />
    
    <!-- AJP Port: 8010 (workers.properties의 bbb와 매핑) -->
    <Connector port="8010" protocol="AJP/1.3" redirectPort="8443" />

    <Engine name="CatalinaB" defaultHost="localhost">
        <Host name="localhost" appBase="/WAS/apps/bbb" unpackWARs="true" autoDeploy="true">
            <Context path="" docBase="." reloadable="true"/>
        </Host>
    </Engine>
</Service>

서비스 C (CCC) 설정

<Service name="CatalinaC">
    <!-- HTTP Port: 8082 (충돌 방지) -->
    <Connector port="8082" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8445" />
    
    <!-- AJP Port: 8011 (workers.properties의 ccc와 매핑) -->
    <Connector port="8011" protocol="AJP/1.3" redirectPort="8443" />

    <Engine name="CatalinaC" defaultHost="localhost">
        <Host name="localhost" appBase="/WAS/apps/ccc" unpackWARs="true" autoDeploy="true">
            <Context path="" docBase="." reloadable="true"/>
        </Host>
    </Engine>
</Service>

Tip (docBase 설정):
appBase와 Context docBase 설정이 꼬일 경우 404 에러가 발생할 수 있습니다. 가장 확실한 방법은 docBase에 절대 경로를 명시하는 것입니다.
예: docBase="/WAS/apps/ccc"

---

5. 검증 및 테스트

1. Tomcat 재기동: server.xml 수정 후 재기동.

   netstat -anotp | grep java 
   # 8009, 8010, 8011 포트가 모두 LISTEN 상태인지 확인

2. Apache 재기동: 설정 적용.

   ./apachectl restart

3. 브라우저 접속: 각 도메인으로 접속하여 서로 다른 페이지가 뜨는지 확인합니다.

[그림] 도메인별 연동 테스트 결과 화면

[Apache/Tomcat] 웹 서버 연동 가이드: mod_jk (AJP) 설정 완벽 정리

Apache HTTP Server와 Tomcat을 연동(Interlink)하여 정적 컨텐츠 처리 성능을 높이고 부하 분산(Load Balancing) 환경을 구성합니다. 가장 널리 사용되는 mod_jk 모듈의 설치(컴파일)부터 workers.properties 설정까지의 전체 과정을 다룹니다.

0. 기본 개념 (Concepts)

• mod_jk: Apache가 Tomcat과 통신하기 위해 사용하는 플러그인 모듈입니다.
• AJP (Apache JServ Protocol): 웹 서버와 WAS 간의 효율적인 통신을 위해 최적화된 바이너리 프로토콜입니다. (Tomcat 기본 AJP 포트: 8009)

---

1. mod_jk 설치 (Compile)

mod_jk는 Apache 배포판에 기본 포함되어 있지 않으므로, 소스를 다운로드하여 컴파일해야 합니다. 이 과정에서 Apache의 확장 도구인 apxs가 필요합니다.

다운로드 및 압축 해제

최신 버전은 Tomcat Connectors 다운로드 페이지에서 확인 가능합니다.

# 1. 소스 다운로드 (버전은 시점에 따라 다를 수 있음)
wget http://apache.mirror.cdnetworks.com/tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.41-src.tar.gz

# 2. 압축 해제
tar -zxvf tomcat-connectors-1.2.41-src.tar.gz

Configure 및 컴파일

native 디렉토리로 이동하여 컴파일을 수행합니다. 주의: --with-apxs 옵션에는 현재 설치된 Apache의 apxs 바이너리 절대 경로를 정확히 입력해야 합니다.

cd tomcat-connectors-1.2.41-src/native

# Apache 설치 경로에 맞춰 apxs 경로 지정 (/WAS/apache/bin/apxs)
./configure --with-apxs=/WAS/apache/bin/apxs

# 컴파일 및 설치
make && make install

설치 확인 (Verification)

설치가 완료되면 Apache의 modules 디렉토리에 mod_jk.so 파일이 생성되었는지 확인합니다.

ls -l /WAS/apache/modules/mod_jk.so

---

2. 워커 설정 (workers.properties)

Apache에게 "어떤 Tomcat 인스턴스와 통신할지" 알려주는 설정 파일입니다. 일반적으로 conf 디렉토리에 생성합니다.

파일 생성

vi /WAS/apache/conf/workers.properties

설정 내용 작성

# Tomcat 및 Java 경로 (환경에 맞게 수정)
workers.tomcat_home="/WAS/tomcat8"
workers.java_home="/usr/bin/java"
ps=/

# 워커 목록 정의 (콤마로 구분하여 다수 정의 가능)
worker.list=test1

# [test1] 워커 상세 설정
worker.test1.port=8009
worker.test1.host=localhost
worker.test1.type=ajp13
# worker.test1.lbfactor=1 (로드밸런싱 시 사용)

Note: worker.test1.port는 Tomcat의 server.xml 내 <Connector protocol="AJP/1.3" ... /> 에 설정된 포트와 일치해야 합니다. (기본값: 8009)

---

3. Apache 설정 (httpd.conf)

마지막으로 Apache가 mod_jk 모듈을 로드하고, 특정 요청을 Tomcat(워커)으로 보내도록 설정합니다.

파일 수정

vi /WAS/apache/conf/httpd.conf

추가 내용

# 1. mod_jk 모듈 로드
LoadModule jk_module modules/mod_jk.so

<IfModule jk_module>
    # 2. 워커 설정 파일 위치 지정
    JkWorkersFile "conf/workers.properties"

    # 3. 로그 설정 (트러블슈팅을 위해 필수)
    JkLogFile "logs/mod_jk.log"
    JkLogLevel info
    JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
    JkRequestLogFormat "%w %V %T"
    
    # 4. URL 매핑 (JkMount)
    # /* : 모든 요청을 test1 워커(Tomcat)로 전달
    # 특정 확장자만 보내려면: JkMount *.jsp test1
    JkMount /* test1
</IfModule>

---

4. 기동 및 연동 테스트

설정이 완료되면 Apache와 Tomcat을 재기동합니다. 순서는 Tomcat 구동 -> Apache 구동 순서를 권장합니다.

설정 검증 (Syntax Check)

# Apache 설정 문법 검사
/WAS/apache/bin/apachectl -t
# "Syntax OK" 출력 확인

서비스 재기동

# Tomcat 재기동
/WAS/tomcat8/bin/shutdown.sh
/WAS/tomcat8/bin/startup.sh

# Apache 재기동
/WAS/apache/bin/apachectl restart

최종 확인

브라우저에서 Apache 포트(보통 80)로 접속했을 때, Tomcat의 페이지가 보인다면 연동에 성공한 것입니다.

---

Next Step:
연동에 성공했다면 정적 파일(이미지, CSS, JS)은 Apache가 처리하고, 동적 파일(JSP)만 Tomcat이 처리하도록 JkMount와 JkUnMount 설정을 튜닝하여 성능을 최적화해 보세요.