[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 설정을 튜닝하여 성능을 최적화해 보세요.

[Tomcat] Linux 환경 Apache Tomcat 8.x 설치 및 구성 가이드 (Java, Firewall 설정 포함)

Apache Tomcat은 전 세계적으로 가장 많이 사용되는 경량 웹 애플리케이션 서버(WAS)입니다. Java 기반의 서블릿 컨테이너이므로 JDK 설치가 선행되어야 합니다. 본 포스팅에서는 Linux(CentOS) 환경에서 Java 설치부터 Tomcat 구동, 그리고 방화벽 설정까지의 전체 과정을 다룹니다.

[Image of Apache Tomcat architecture]

1. 사전 준비: Java (JDK) 설치 확인

Tomcat은 Java로 작성된 애플리케이션이므로 서버에 JDK(Java Development Kit)가 설치되어 있어야 구동됩니다. 단순 JRE보다는 개발 및 디버깅 도구가 포함된 JDK 설치를 권장합니다.

설치 여부 확인

# Java 버전 확인
java -version

# 설치 경로 확인
which java

명령어 실행 시 버전 정보가 출력되지 않는다면 JDK를 설치해야 합니다.

JDK 설치 (yum 사용 시)

Oracle JDK는 라이선스 이슈가 있으므로, 오픈소스인 OpenJDK 설치를 권장합니다.

# OpenJDK 1.8 설치 예시
yum install -y java-1.8.0-openjdk-devel

# 설치 후 환경변수 확인 (필수)
# Tomcat은 JAVA_HOME 변수를 참조하므로 설정되어 있는지 확인합니다.
echo $JAVA_HOME

Note: JAVA_HOME 환경 변수가 설정되어 있지 않다면 /etc/profile 등에 경로를 등록해야 Tomcat이 정상적으로 실행됩니다.

---

2. Tomcat 설치 (Download & Install)

패키지 매니저(yum)로 설치할 수도 있지만, 실무에서는 버전 관리와 디렉토리 구조 커스터마이징을 위해 Binary Core(tar.gz)를 직접 다운로드하여 설치하는 방식을 선호합니다.

다운로드 및 압축 해제

최신 버전은 Apache Tomcat 공식 사이트에서 확인 가능합니다.

# 1. 설치 파일 다운로드 (wget)
# (링크는 버전에 따라 달라질 수 있으니 공식 사이트 참조)
wget http://archive.apache.org/dist/tomcat/tomcat-8/v8.0.27/bin/apache-tomcat-8.0.27.tar.gz

# 2. 압축 해제
tar -zxvf apache-tomcat-8.0.27.tar.gz

# 3. 디렉토리 이동 및 정리 (관리 편의성)
# /WAS 디렉토리 하위로 이동하여 관리하는 것을 가정합니다.
mv apache-tomcat-8.0.27 /WAS/tomcat8

---

3. Tomcat 구동 및 로그 확인

Tomcat의 실행 스크립트는 bin 디렉토리에 위치합니다.

서비스 기동

cd /WAS/tomcat8/bin

# 실행 스크립트
./startup.sh

구동 로그 확인 (중요)

startup.sh를 실행했다고 해서 무조건 성공한 것은 아닙니다. 반드시 로그 파일(catalina.out)을 열어 에러 없이 "Server startup in [xxxx] ms" 메시지가 뜨는지 확인해야 합니다.

# 실시간 로그 확인
tail -f /WAS/tomcat8/logs/catalina.out

---

4. 방화벽 설정 및 접속 테스트

Tomcat이 정상 구동되었더라도 외부에서 접속이 안 된다면 방화벽(Firewall) 문제입니다. Tomcat의 기본 포트는 8080입니다.

포트 리슨 확인

# 8080 포트가 LISTEN 상태인지 확인
netstat -anotp | grep 8080

방화벽 오픈 (CentOS 7 이상)

# 8080 포트 영구 허용
firewall-cmd --permanent --zone=public --add-port=8080/tcp

# 방화벽 설정 재로드
firewall-cmd --reload

최종 접속 확인

브라우저 주소창에 http://[서버IP]:8080 을 입력합니다.

• 성공: Apache Tomcat 고양이 로고가 그려진 기본 페이지가 출력됩니다.
• 실패: "사이트에 연결할 수 없음"이 뜬다면 방화벽 설정이나 클라우드 보안 그룹(Security Group) 설정을 다시 확인하세요.

---

Next Step:
설치가 완료되었다면, 운영 환경에 맞춰 /WAS/tomcat8/conf/server.xml 파일에서 포트(Port)를 80으로 변경하거나, UTF-8 인코딩 설정을 추가하는 튜닝 작업을 진행해 보십시오.

[Apache] Linux 소스 컴파일 설치 가이드 (httpd, apr, pcre)

Linux 환경에서 yum이나 apt 같은 패키지 매니저 대신, Apache HTTP Server(httpd)를 소스 코드로 직접 컴파일하여 설치하는 방법을 정리합니다. 특정 버전이 필요하거나, 모듈을 커스터마이징해야 할 때 필수적인 기술입니다.

0. 시작하기 전에 (Why & Prerequsite)

왜 소스 컴파일을 하나요?

• 버전 관리: OS 저장소(Repository)에서 제공하는 구버전이 아닌, 최신 보안 패치가 적용된 버전을 사용할 수 있습니다.
• 최적화: 불필요한 모듈을 빼거나, 경로를 /usr/local이 아닌 /WAS 등 원하는 곳으로 지정하여 관리 효율성을 높일 수 있습니다.

필수 컴파일 도구 설치

소스 코드를 기계어로 번역하기 위해서는 컴파일러(gcc)와 빌드 도구(make)가 반드시 필요합니다. 설치 전 아래 명령어로 환경을 준비해주세요.

# CentOS/RHEL 기준
yum install -y gcc gcc-c++ make expat-devel

---

1. 소스 파일 다운로드

각 프로젝트의 공식 홈페이지에서 Stable(안정) 버전을 다운로드합니다. 보통 /usr/local/src 나 임시 디렉토리에서 작업합니다.

다운로드 링크

• Apache HTTPD: http://httpd.apache.org/download.cgi
• APR / APR-Util: https://apr.apache.org/download.cgi
• PCRE: http://www.pcre.org/

※ Apache 2.4 버전부터는 APR(Apache Portable Runtime)과 PCRE(정규표현식 라이브러리)가 내장되어 있지 않아 별도 설치가 필수입니다.

---

2. 의존성 라이브러리 설치

Apache 본체를 설치하기 전에 기초가 되는 라이브러리를 먼저 깔아야 합니다. 관리 편의를 위해 모든 경로는 /WAS 하위로 통일하겠습니다.

1) APR (Apache Portable Runtime) 설치

OS(Linux, Windows 등)에 상관없이 Apache가 실행될 수 있도록 도와주는 플랫폼 추상화 라이브러리입니다.

tar -zxvf apr-1.5.2.tar.gz
cd apr-1.5.2

# --prefix 옵션으로 설치 경로 지정
./configure --prefix=/WAS/apr
make && make install

2) APR-Util 설치

APR의 유틸리티 확장판입니다. 반드시 위에서 설치한 APR의 경로를 지정해야 합니다.

tar -zxvf apr-util-1.5.4.tar.gz
cd apr-util-1.5.4

# --with-apr 옵션 중요!
./configure --prefix=/WAS/aprutil --with-apr=/WAS/apr
make && make install

3) PCRE (Perl Compatible Regular Expressions) 설치

Apache의 URL 재작성(Rewrite) 모듈 등에서 사용하는 정규표현식 라이브러리입니다.

tar -zxvf pcre-8.37.tar.gz
cd pcre-8.37

./configure --prefix=/WAS/pcre
make && make install

---

3. Apache HTTP Server 설치

이제 주인공인 Apache를 설치합니다. configure 단계에서 앞서 설치한 라이브러리들의 경로를 연결해주는 것이 핵심입니다.

Configuration 실행

tar -zxvf httpd-2.4.16.tar.gz
cd httpd-2.4.16

# 한 줄씩 옵션을 확인하며 입력하세요.
./configure \
--prefix=/WAS/apache \
--enable-mods-shared=all \
--enable-so \
--enable-rewrite \
--enable-auth-digest \
--with-apr=/WAS/apr \
--with-apr-util=/WAS/aprutil \
--with-pcre=/WAS/pcre

주요 옵션 설명

• --enable-mods-shared=all: 모듈을 동적(Dynamic)으로 컴파일하여, 추후 httpd.conf에서 Load/Unload가 가능하게 합니다.
• --enable-rewrite: URL 주소를 변경하는 Rewrite 기능을 활성화합니다. (실무 필수)

컴파일 및 설치

# 에러 없이 완료되면 실행
make && make install

---

4. 기동 및 검증 (Verification)

설치가 끝났다고 바로 브라우저가 열리는 것은 아닙니다. 프로세스를 띄우고 포트를 확인해야 합니다.

1) 서비스 기동

# Apache 기동 스크립트 실행
/WAS/apache/bin/apachectl start

# 프로세스 확인 (httpd 프로세스가 보여야 함)
ps -ef | grep httpd

2) 포트 리슨 확인

웹 서버의 기본 포트인 80번이 열려있는지 확인합니다.

netstat -anotp | grep :80

3) 방화벽 설정 (중요!)

프로세스가 떴는데 브라우저 접속이 안 된다면 99%는 방화벽 문제입니다. 테스트를 위해 방화벽을 잠시 끄거나 80포트를 열어야 합니다.

# CentOS 7 (firewalld) 포트 오픈 예시
firewall-cmd --permanent --zone=public --add-port=80/tcp
firewall-cmd --reload

4) 최종 접속 테스트

PC 브라우저 주소창에 http://[서버IP]를 입력합니다. 화면에 "It works!"가 보인다면 성공입니다.

---

Next Step:
이제 /WAS/apache/conf/httpd.conf 파일을 열어 ServerName 경고 메시지를 해결하고, DocumentRoot(웹 문서 위치)를 실제 운영 경로로 변경해 보세요.

[Linux] FTP CLI 명령어 완벽 가이드 및 상태 코드(Response Code) 정리

리눅스 쉘 환경에서 FTP 서버에 접속하여 파일을 업로드/다운로드하는 필수 명령어와 주요 옵션을 정리합니다. 또한 트러블슈팅 시 유용한 FTP 응답 코드(Response Code)의 의미를 설명합니다.

[Image of FTP client server data transfer diagram]

1. 서버 접속 및 로그인 (Connection)

FTP 클라이언트를 실행하여 원격 서버에 접속하는 과정입니다. open 명령어를 사용하거나 실행 시 인자로 IP를 전달합니다.

[test@zeroTest]$ ftp 210.xxx.xxx.xxx
Connected to 210.xxx.xxx.xxx.
220 web17 FTP server (Version 5.60) ready.
Name (210.xxx.xxx.xxx:test): [아이디 입력]
331 Password required for user.
Password: [패스워드 입력]
230 User test logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

---

2. 디렉토리 탐색 (Navigation)

FTP는 원격(Remote) 서버와 로컬(Local) 클라이언트의 디렉토리를 동시에 제어해야 합니다. 로컬 명령어 앞에는 주로 l(local)이 붙습니다.

원격 서버 (Remote) 제어

• pwd : 원격 서버의 현재 경로 확인
• ls (또는 dir) : 원격 서버의 파일 목록 출력
• cd [path] : 원격 서버의 디렉토리 이동
• cdup : 원격 서버에서 상위 디렉토리로 이동

로컬 클라이언트 (Local) 제어

• !pwd : 로컬 클라이언트의 현재 경로 확인
• lcd [path] : 로컬 클라이언트의 작업 디렉토리 변경 (다운로드/업로드 위치 변경 시 필수)

# 로컬 다운로드 경로를 /bin으로 변경 예시
ftp> lcd /bin
Local directory now /bin

---

3. 파일 전송 설정 (Transfer Settings)

파일 전송 전, 전송 모드와 시각적 피드백 옵션을 설정하는 것이 중요합니다.

전송 모드 (Transfer Mode)

바이너리 파일(이미지, 실행파일, 압축파일 등) 전송 시 반드시 binary 모드를 사용해야 파일 깨짐을 방지할 수 있습니다.

• ascii (또는 as) : 텍스트 파일 전송 모드
• binary (또는 bi) : 바이너리 전송 모드 (권장)

편의 옵션

• hash : 파일 전송 진행 상황을 #(Hash Mark)로 표시 (대용량 파일 전송 시 유용)
• prompt : 다중 파일 전송(mget/mput) 시 파일마다 확인하는 과정을 On/Off

ftp> binary
200 Type set to I.
ftp> hash
Hash mark printing on (1024 bytes/hash mark).

---

4. 파일 업로드 및 다운로드

단일 파일 처리와 다중 파일(Wildcard * 사용) 처리 명령어가 구분됩니다.

다운로드 (Server -> Local)

• get [filename] : 단일 파일 다운로드
• mget [pattern] : 다중 파일 다운로드 (예: mget *.pdf)

ftp> get thinkinjava.pdf
local: R389.PDF remote: R389.PDF
200 PORT command successful.
150 Opening BINARY mode data connection for R389.PDF (44028 bytes).
#######################
226 Transfer complete.

업로드 (Local -> Server)

• put [filename] : 단일 파일 업로드
• mput [pattern] : 다중 파일 업로드 (예: mput *.html)

---

5. 기타 관리 명령어

• delete [filename] / mdelete [pattern] : 원격 파일 삭제
• mkdir [dirname] / rmdir [dirname] : 원격 디렉토리 생성 및 삭제
• chmod [mode] [file] : 원격 파일 권한 변경 (예: chmod 755 run.sh)
• rename [old] [new] : 파일 이름 변경
• size [filename] : 파일 크기(Byte) 확인
• bye, quit, exit : 접속 종료

---

6. FTP 응답 코드 (Response Codes)

서버가 반환하는 3자리 숫자를 통해 트러블슈팅이 가능합니다. 주요 코드는 다음과 같습니다.

Code	Description (의미)
150	파일 상태 정상. 데이터 연결을 엽니다. (전송 시작)
200	명령어 성공 (OK)
220	서비스 준비 완료 (접속 초기 메시지)
226	데이터 연결 닫힘. 요청 작업 성공 (전송 완료)
230	사용자 로그인 성공
331	사용자 이름 확인됨. 패스워드 필요
421	서비스 사용 불가. 연결 종료
425	데이터 연결을 열 수 없음 (방화벽, Passive 모드 이슈 등)
530	로그인 실패 (ID/PW 오류)
550	요청 작업 실패 (파일 없음, 권한 부족 등)

---

Next Step:
FTP는 데이터를 암호화하지 않아 보안에 취약합니다. OpenSSH에 포함된 sftp 명령어를 사용하여 암호화된 파일 전송 환경을 구성하는 방법을 검토해보십시오.

[WebSphere] JSESSIONID 충돌 해결: 동일 도메인 세션 분리 전략 (Cookie Name 변경)

동일한 도메인(예: www.test.com) 아래에서 컨텍스트 루트(Context Root)만 다른 여러 애플리케이션을 운영할 때, 브라우저가 세션 쿠키(JSESSIONID)를 구분하지 못해 세션이 끊기거나 덮어써지는 현상을 해결하는 방법을 정리합니다.

1. 문제 상황 및 원인 (Context)

WAS는 클라이언트 식별을 위해 JSESSIONID라는 이름의 쿠키를 기본적으로 사용합니다. 하지만 아래와 같은 구성에서는 문제가 발생합니다.

• 서비스 A: http://domain.com/app1 (Server1)
• 서비스 B: http://domain.com/app2 (Server2)

브라우저는 기본적으로 도메인 단위로 쿠키를 관리합니다. 사용자가 '서비스 A'를 이용하다가 '서비스 B'로 이동하면, 브라우저는 기존 '서비스 A'의 JSESSIONID를 '서비스 B'의 새로운 JSESSIONID로 덮어씌웁니다(Overwrite). 다시 '서비스 A'로 돌아가면 세션 ID가 달라졌으므로 로그인이 풀리게 됩니다.

---

2. 해결 방법 1: 서버 레벨 설정 (Server Level)

가장 간단한 방법은 각 서버(인스턴스)마다 쿠키 이름을 다르게 설정하는 것입니다.

설정 경로

서버(Servers) > 서버 유형(Server Types) > WebSphere Application Servers > [서버명] > 세션 관리(Session management) > 쿠키 사용 가능(Enable cookies) 링크 클릭

설정 변경

• 쿠키 이름 (Cookie name): 기본값 JSESSIONID를 식별 가능한 이름으로 변경합니다.
  • Server1: JSESSIONID_SVR1
  • Server2: JSESSIONID_SVR2

Pros/Cons: 설정이 간편하지만, 하나의 서버 안에 여러 애플리케이션이 존재할 경우 그 안에서는 여전히 충돌이 발생할 수 있습니다.

---

3. 해결 방법 2: 애플리케이션 레벨 설정 (App Level)

보다 세밀하게 애플리케이션(WAR/EAR) 단위로 세션을 격리하고 싶을 때 사용합니다. 권장되는 방식입니다.

설정 경로

애플리케이션(Applications) > 엔터프라이즈 애플리케이션(Enterprise Applications) > [애플리케이션명] > 세션 관리(Session management) > 쿠키 사용 가능(Enable cookies) 링크 클릭

설정 변경

1. 세션 관리 대체 (Override session management): 반드시 체크합니다. (상위 서버 설정을 무시하고 이 설정을 따르겠다는 의미)
2. 쿠키 이름 (Cookie name): 해당 앱 전용 쿠키 이름 설정 (예: JSESSIONID_APP1)
3. 쿠키 경로 (Cookie path): 필요시 /app1 처럼 컨텍스트 루트로 한정 지을 수도 있습니다.

---

4. 필수 후속 조치: 플러그인 갱신 (Plugin Propagate)

WAS 설정만 바꾸고 끝내면 안 됩니다. 앞단의 웹 서버(IHS/Apache)가 변경된 쿠키 이름을 인식하여 세션 어피니티(Session Affinity, 스티키 세션)를 유지할 수 있도록 plugin-cfg.xml을 갱신해야 합니다.

작업 절차

1. WAS 관리 콘솔에서 변경 사항 저장.
2. Environment > Update global Web server plug-in configuration (또는 웹 서버 메뉴에서 플러그인 생성/전파).
3. 웹 서버(IHS) 재기동 (Graceful Restart).

확인 (plugin-cfg.xml)

생성된 플러그인 파일을 열어 AffinityCookie 속성이 변경되었는지 확인합니다.

<UriGroup Name="default_host_Cluster_URIs">
    <!-- AffinityCookie 값이 변경된 이름과 일치해야 함 -->
    <Uri AffinityCookie="JSESSIONID_APP1" AffinityURLIdentifier="jsessionid" Name="/*"/>
</UriGroup>

---

5. 검증 (Verification)

설정이 올바르게 적용되었는지 확인하는 방법입니다.

1. 브라우저의 개발자 도구 (F12)를 엽니다.
2. Application 탭 > Cookies 메뉴를 선택합니다.
3. 각 애플리케이션에 접속했을 때, JSESSIONID가 아닌 JSESSIONID_APP1, JSESSIONID_APP2 등으로 서로 다른 이름의 쿠키가 생성되는지 확인합니다.

주의 (Warning):
세션 쿠키 이름을 변경하면 기존에 로그인되어 있던 사용자들의 세션은 모두 무효화됩니다. 따라서 이 작업은 서비스 점검 시간이나 사용자가 적은 시간대에 수행해야 합니다.