tjddus97 님의 블로그

# 테스트 환경

• OS : Oracle Linux Server release 8.6
• JDK : 1.8
• Jboss ver. : jboss-eap-7.4.0
• Jboss Mode : standalone mode
• Nginx ver. : 1.14.1

기본적인 Log 레벨은 설치 시 INFO 레벨로 설정되어 있다.

하지만 로그를 통해 자세히 보고 싶은 부분이 있거나 INFO로 설정을 했음에도 불구하고 Log가 지나치게 많이 쌓여 불가피하게 Log Level을 변경해야 할 때가 있다.

Log Level 정보

• TRACE : 가장 상세한 디버깅 정보
• DEBUG : 디버깅용 정보가 포함
• INFO : 애플리케이션 상태를 나타내는 일반적인 정보 포함
• WARN : 주의가 필요한 상황에 대한 정보 포함
• ERROR : 오류 발싱 시 사용
• FATAL : 심각한 오류에 대한 정보 포함

가장 밑에 작성한 FATAL이 가정 내용이 적게 기록되며 가장 위에 작성한 TRACE이 가장 내용이 많이 기록된다.

Log Level 변경 방법

1. Jboss Admin Console을 통해 변경

Jboss 관리 콘솔에 로그인 후 Configuration -> Subsystems -> Logging 메뉴 클릭

Edit 버튼을 클릭 후 원하는 Log Level로 설정을 변경한 후 저장 및 Jboss 재 기동하여 확인

2. 설정 파일 변경

logging.properties와 standalone.xml 파일의 내용을 변경 후 저장 및 재 기동

해당 파일들은 [JBOSS_STANDALONE_HOME_DIR]/configuration 경로에 위치해 있다.

- logging.properties

파일 상단에 logger.level 부분을 수정

- standalone.xml

변경하고자 하는 logger 태그를 검색 후 level name 태그에 설정하고자 하는 로그 레벨을 설정

해당 파일의 해당 부분 설정 후 저장 및 재 기동하여 반영

Jakarta EE는 Java를 이용하여 서버 측 개발을 위한 플랫폼이다.

해당 프로젝트가 2027년 이클립스 재단으로 이관됨에 따라 PC 표준 플랫폼이었던 Java EE를 확장하여 Jakarta EE로 변경되었다.

이름만 변경된 것이 아니라 기존의 패키지 네임스페이스가 javax.*에서 jakarta.*로 변경되었다.

따라서 표준 패키지 구조와 API 호출 방식에 영향을 미칠 수 있으며 기존 Java EE 애플리케이션과의 호환성 문제를 야기할 수 있기 때문에 버전에 대한 확인 및 고민이 필요하다.

주요 변경점

Tomcat 9.x

기존의 javax.* 네임 스페이스를 사용하며 Jakarta EE의 패키지 구조 변경을 포함하지 않기 때문에 Jakarta EE와 호환 되지 않는다.

Tomcat 10.x

Jakarta EE 9를 지원하며 패키지 네임스페이스가 jakarta.*로 변경되었다.

• 기존 Java EE 기반 App을 10.x에서 실행하기 위해선 코드나 라이브러리를 jakarta.* 네임스페이스로 변환해야 한다.
• Java SE 8 이상에서 실행된다.

Tomcat 10.1.x

Jakarta EE 10을 지원하며 Java SE 11 이상이 요구된다.

권장 사항

Tomcat 9.x를 유지할 경우 App의 패키지가 변경되지 않는 이상 현재 쓰고 있는 대로 사용하면 되지만 장기적으로는 Jakarta EE 로 전환을 준비하는 것이 권장된다.

Tomcat 10.x 이상으로 업그레이드를 진행할 예정일 경우 jakarta.*로 패키지 네임스페이스 변경이 필요하다.

Tomcat migration Tool을 사용할 경우 전환 작업을 단순화할 수 있다.

Application을 올려야 하는 WAS는 초기 설치 시 Java version, Application에서 필요로 하는 지원 목록에 대한 고려를 하여 version을 선택 후 설치를 진행해야 한다.

각 Tomcat Version 별 특징과 지원되는 항목에 대해 정리해 보았다.

특징과 지원 환경

EOS 날짜

9.X, 10.1.X, 11.X 을 제외 한 이전 버전에 대한 지원은 모두 종료된 상태이다.

현재 지원 중인 version들 세부 특징

Tomcat 9.X

• Servlet 4.0, JSP 2.3, EL 3.0, WebSocket 1.1, JASPIC 1.1(Java EE 8 플랫폼에서 요구하는 버전) 지원
• HTTP/2 지원
• JSSE 커넥터를 사용하여 TLS 지원을 위한 OpenSSL 사용 지원 추가
• TLS 가상 호스팅(SNI) 지원

Tomcat 10.1.X

• Servlet 6.0, JSP 3.1, EL 5.0, WebSocket 2.1, Authentication 3.0(Jakarta EE 10 플랫폼에 필요한 버전) 지원

Tomcat 11.0.X

• Servlet 6.1, JSP 4.0, EL 6.0, WebSocket 2.2, Authentication 3.1(Jakarta EE 11 플랫폼에 필요한 버전) 지원

참고 문헌

# 테스트 환경

• OS : Oracle Linux Server release 8.6
• JDK : 1.8
• Tomcat ver. : 9.0.89

Tomcat에 애플리케이션을 배포하기 위해서 고려해야 할 사항이 2가지 있다.

1. war 파일명 또는 디렉토리 명

Tomcat에서는 기본적으로 [TOMCAT_ENGINE]/webapps/ROOT 디렉토리를 기본 애플리케이션 경로로 가지고 있다.

따라서 최초에 Tomcat 기동 후 기본 페이지를 호출할 경우 아래와 같이 따로 context 경로 입력 필요 없이 /로 설정이 되어 있다.

여기서 배포를 위해 가져온 .war 파일이나 디렉터리 명을 따로 설정하지 않고 ROOT로 설정할 경우 server.xml 변경점 없이 그대로 사용이 가능하다.

기존의 ROOT dir을 ROOT_old로 변경 후 배포하고자 하는 애플리케이션의 dir 명을 ROOT로 변경하고 재기동 및 호출 시 아래와 같은 결과를 얻을 수 있다.

만약 ROOT 말고 다른 이름으로 설정할 경우 2번을 통해 server.xml을 수정하자.

2. server.xml 수정

[TOMCAT_ENGINE]/conf/server.xml 파일을 vi 편집기로 열어 보게 되면

위와 같이 해당 Host 태그 안에 name, appBase, unpackWARs, autoDeploy 등과 같은 옵션들을 통해 default 설정이 되어 있는 것을 확인할 수 있다.

appBase가 webapps로 설정되어 있어 기본 설정 경로가 /webapps/ROOT 였던 것이다.

만약 다른 context path, ROOT가 아닌 다른 어플리케이션 명을 사용하고 싶다면 아래와 같이 설정 후 재기동 및 호출 테스트를 진행해보자

<Host name="localhost"  appBase="webapps"
              unpackWARs="true" autoDeploy="true">
              <Context path="/test" docBase="test"  reloadable="false" > </Context>

- context path : /test

- 애플리케이션 dir 명 : test

테스트 결과는 다음과 같다.

만약 다른 context path, ROOT가 아닌 다른 어플리케이션 명을 사용하고 어플리케이션 배포 경로도 커스텀 하고 싶다면 아래와 같이 설정 후 재기동 및 호출 테스트를 진행해 보자.

<Host name="localhost"  appBase="/sw/tomcat/apache-tomcat-9.0.89"
              unpackWARs="true" autoDeploy="true">
              <Context path="/test" docBase="test"  reloadable="false" > </Context>

- 애플리케이션 위치 : /sw/tomcat/apache-tomcat-9.0.89

- context path : /test

- 어플리케이션 dir 명 : test

테스트 결과는 다음과 같다.

appBase에 설정한 대로 /sw/tomcat/apache-tomcat-9.0.89 경로에 있는 test 폴더를 어플리케이션 경로로 잘 잡고 있는 것을 확인할 수 있다.

정리를 하자면 다음과 같다.

1. Application war 파일이나 DIR 명을 ROOT로 사용할 경우 

- /webapps 밑에 있는 ROOT 파일을 어플리케이션 war 파일이나 DIR로 변경

- server.xml 변경 X

2. Application war 파일이나 DIR 명을 수정 및 context path 수정할 경우

- /webapps 밑에 Application war 파일이나 DIR 위치시키기

- 해당 파일, DIR명을 server.xml에 태그를 추가하여 정보 입력

<Context path="/test" docBase="test"  reloadable="false" > </Context>

3. Application 배치 경로 수정할 경우

- 원하는 경로에 Application 위치시킨 후 server.xml에서 appBase 정보 변경 입력

<Host name="localhost"  appBase="/sw/tomcat/apache-tomcat-9.0.89"
              unpackWARs="true" autoDeploy="true">

# 테스트 환경

• OS : Oracle Linux Server release 8.6
• JDK : 1.8
• WebLogic ver. : 12cR2

SSL 인증서의 경우 보통은 Application이 적재되어 있는 WAS가 아닌 WEB에 설정을 하지만 가끔가다 WLS에 직접 적용해 달라고 요청 오는 사례가 가끔 있다.

아래의 예시는 JKS 확장자의 SSL keystore를 통해 테스트를 진행했다.

1. 대상 서버의 SSL 수신 포트 사용 체크

WLS console에 접근하여 환경 - 서버 - 대상 서버 - 구성 - 일반 탭에서 SSL 수신 포트 사용 체크

(여기서 주의할 점은 다른 수신 포트들과 SSL 수신 포트가 겹치지 않게 설정을 해야 한다.)

2. 키 저장소 정보 입력

환경 - 서버 - 대상 서버 - 구성 - 키 저장소 탭에서 정보 입력

키 저장소 : 사용자정의 ID 및 Java 표준 보안

사용자정의 ID 키 저장소 : 인증서의 위치를 절대 경로로 입력

사용자정의 ID 키 저장소 유형 : JKS

사용자정의 ID 키 저장소 문장암호 : 해당 인증서 패스워드 입력

사용자정의 ID 키 저장소 문장암호 확인 : 해당 인증서 패스워드 입력

3. 개인 키 별칭 등록

환경 - 서버 - 대상 서버 - 구성 - 키 저장소 탭에서 정보 입력

개인 키 별칭 : 인증서 생성 시 입력하였던 Alias Name 작성

개인 키 비밀번호 구문: 인증서 패스워드 입력

개인 키 비밀번호 구문 확인 : 인증서 패스워드 입력

만약 개인 키 별칭 즉, Alias name을 모른다면 아래의 명령어를 통해 찾아보자

keytool -v -list -keystore [Keystore 파일]

4. TEST

SSL 설정을 완료하였다면 해당 서버를 재기동하고 TEST 해보자.

testM1 instance server의 일반 수신 포트인 8002로 호출한 결과와 SSL 수신 포트인 7002로 호출한 결과 모두 정상적으로 애플리케이션의 테스트 페이지를 보여주고 있다.

WebLogic에서 Application 배포 시 정상적으로 배포가 완료되지 않고 에러가 떨어지며 이슈가 발생하는 이유는 아주 다양하다.

대부분은 instance log에서 배포 시 발생한 error log를 통해 문제점 파악 및 유추가 가능하다.

그러나 당장 방문이 힘들거나 유선 혹은 원격 지원을 통해 해결을 해야 하는 상황이라면 다음 목록을 먼저 확인해 보자.

1. 배치는 완료되었으나 application 시작을 하지 않은 경우

WebLogic console을 통하여 배치는 정상적으로 완료를 하였는데 사용자가 서비스는 안된다고 말할 경우 대부분이 application 배치 후 시작을 하지 않은 경우이다.

위와 같이 application이 활성 상태이지만 서비스 페이지 접속이 안된다고 할 경우에는 컨트롤 탭에서 application을 시작해 보자.

2. Application 수정 사항이 반영되지 않은 경우

WebLogic Console의 배치 탭에서 application의 상태가 실패로 떠 있을 경우

담당자에게 소스 수정 사항이 있는지 물어본 후 수정 사항 없다고 해도 application 업데이트 반영 해보자.

업데이트 반영 후 application 시작은 필수이다.

소스 수정 후(xml 파일이나 class 파일 수정의 경우) console과 application 동기화가 반드시 필요하다.

3. Application 배포 대상 서버가 shutdown 상태일 경우

정말 말도 안 되는 상황이긴 하지만 OOM이나 다른 이슈로 instance 서버가 shutdown 상태여서 application이 활성화되지 않을 수 있다.

WebLogic Console의 서버 탭이나 터미널 접속하여 process를 확인해 보자.

4. Application 배포 대상 서버를 선택하지 않은 경우

본인이 아닌 다른 사람이 배포를 진행하였을 경우 충분히 발생할 수 있는 경우이다.

배치 탭에서 대상에 대상 서버가 지정되어 있지 않은 경우 당연히 서비스는 불가하다.

해당 상태일 때 application 테스트 탭을 확인해 보면 다음과 같이 적혀 있다.

배치를 진행 후 마지막 부분이나 배치 완료 후 application 탭에 들어가 대상 탭에서 반드시 배치 대상 서버를 지정해주어야 한다.

5. Tomcat에서는 잘 되는데 WebLogic에서는 안 돼요 상황일 때

보통 개발자 분들께서는 test 환경으로 weblogic이 아닌 구성하고 설치하기 용이한 tomcat을 선호하신다.

따라서 application을 WebLogic에 배치를 하더라도 test는 tomcat을 통해 진행할 때가 많다.

두 제품 모두 WAS인 것은 동일하나 세부적으로 들어갈 경우 JDK 버전, servlet, kernel과 같은 부분에서 문제가 발생할 수 있다.

애초에 WebLogic Console에서 배치 부분에서 에러가 발생하고 적용되지 않을 경우

해당 WebLogic version에 맞는 JDK 버전을 확인해 보고 해당 WebLogic version에서 사용가능한 세부적인 서비스 버전도 비교해 보아야 한다.

아래는 WebLogic 12.2.1.4 version이다.

# 테스트 환경

• OS : Oracle Linux Server release 8.6
• JDK : 1.8
• Jboss ver. : jboss-eap-7.4.0
• Jboss Mode : standalone mode
• Nginx ver. : 1.14.1

# Jboss EAP Clustering

WLS Cluster과 동일한 개념으로 특정 서버 상태에 서비스를 의존하지 않고 Cluster로 묶인 서버 그룹이 마치 하나의 서버에서 서비스를 제공하는 것으로 인식

사용 목적은 다음과 같음

  - 부하 분산 : 처리량을 늘리고 부하를 균등하게 분산

  - 고가용성 : Cluster 멤버에게 장애가 발생할 경우 다른 멤버가 그 역할을 대체 (failover 가능)

# 핵심 기술

1. JGroups

멀티캐스트 프로토콜을 사용하여 신뢰성 높은 통신을 제공할 수 있도록 구현된 네트워크 통신 라이브러리

ha, full-ha 프로파일에 jgroups 서브 시스템이 설정되어 있음

멀티캐스트를 사용하는 udp protocol 스택과 tcp를 사용하는 tcp protocol 스택이 정의되어 있고 default 값은 udp

(그 아래 하위 내용들은 대부분 기본값으로 사용하길 권장)

default 값인 udp에서 tcp로 사용 프로토콜을 변경하고 싶을 경우 channel의 stack="udp" 부분을 tcp로 변경

2. 멀티캐스트

특정 주소에 참여하는 모든 host에 동시에 같은 메시지를 전송하는 방식으로 패킷이 그룹 단위로 하나만 전송되기 때문에 네트워크 트래픽인 혼잡해지지 않음

반대로 유니캐스트의 경우 멤버 수만큼 여러 번 패킷을 전송해야 하기 때문에 트래픽 발생확률이 높아짐

3. UDP / TCP

UDP의 경우 멀티캐스트를 통한 통신을 하며 처리 속도가 빠르지만 메시지 송신 확인과 같은 중간 과정을 생력 하기 때문에 신뢰성이 낮음

TCP의 경우 UDP보다 처리 속도는 느리지만 신뢰성이 높고 네트워크 방화벽의 제한을 UDP보단 덜 받기 때문에 더 범용적으로 쓰임

# tcp 통신을 통한 Cluster 환경 구성

기본이 udp 구성이기 때문에 tcp 환경으로 변경이 필요

1. Jboss Admin Console에서 변경

Jboss Admin Console - Configuration = Subsystems - JGroups - View - Channel - ee - Stack 부분을 udp에서 tcp로 변경

2. ha 파일에서 직접 변경

ha 파일에서 jgroups 태그 부분에서 channel의 stack을 udp에서 tcp로 변경

위와 같이 stack을 tcp로만 변경한다고 바로 해당 설정으로 동작하지 않음

tcp 스택으로 변경이 되었다 하더라도 tcp 스택에 클러스터 멤버를 찾기 위한 PING 프로토콜로 멀티캐스트를 사용하는 MPING을 사용하도록 설정이 되어 있기 때문

따라서 socket-protocol type를 MPING에서 TCPPING으로 변경한 후 initial_host에 직접 host의 ip와 port를 지정

3. application 설정

application 설정이 없으면 ha 파일에 Cluster 설정이 구성되어 있어도 세션이 복제되지 않기 때문에 실제 세션이 복제되기 위해서는 application에 세션을 복제하겠다는 설정이 필요

1. web.xml에 <distributable/> 추가

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd
" version="2.4">

<distributable/>

</web-app>

2. jboss-web.xml 생성

<jboss-web>
        <context-root>/</context-root>
</jboss-web>

# 테스트 및 확인

이중화 서버에 tcping 설정의 cluster 설정 후 log를 확인해 보게 되면 아래와 같은 로그 확인 가능

2024-08-13 10:33:33,863 INFO  [org.infinispan.CLUSTER] (thread-42,ejb,server1_2) ISPN000094: Received new cluster view for channel ejb: [server1_2|3] (2) [server1_2, server1_1]
2024-08-13 10:33:33,864 INFO  [org.infinispan.CLUSTER] (thread-42,ejb,server1_2) ISPN100000: Node server1_1 joined the cluster

WEB은 nginx를 통해 failover 테스트 진행

nginx.conf 에 jboss host의 ip와 http port를 작성하여 upstream 구성

sessionTest.jsp 페이지 호출

아래와 같이 2번 장비의 jboss에서 호출 넘버가 찍히는 걸 확인 가능

2번 장비의 jboss Shutdown 후 log 확인

2번 장비 Shutdown 후 세션이 1번 장비의 jboss로 이어지는지 확인

총 session이 끊기지 않고 이어지는 거 확인

# 참조 문헌

https://docs.openmaru.io/docs/jboss-eap/JBossEAP6_Clustering/

# 테스트 환경

• OS : Oracle Linux Server release 8.6
• JDK : 1.8
• Jboss ver. : jboss-eap-7.4.0
• Jboss Mode : standalone mode

# Jboss Deployment

Jboss EAP는 관리자와 개발 자 모두를 위한 다양한 애플리케이션 배포 및 구성 옵션을 제공

Option - 관리 console, 관리 CLI, deployment scanner, HTTP API 등

위와 같은 다양한 배포 옵션이 존재하지만

이번 글에서는 standalone에서 자주 사용하는 Management console에서 deployment scanner를 통한 deploy 테스트를 진행

# Deployment scanner

배포 스캐너는 배포 디렉터리를 모니터링하여 애플리케이션을 배포하는 방식

변경 사항을 반영하기 위해 5초마다 {STANDADLONE MODE_HOME}/deployments 디렉터리 검사를 진행함

해당 방법은 JBoss EAP server를 독립 실행형 즉, standalone 서버로 실행하는 경우에만 사용 가능

# Deployment scanner를 통한 Deploy 과정

1. Management Console 실행

각자 세팅한 환경에 따라 스크립트의 위치가 다르기 때문에 {JBOSS_STANDALONE MONE_HOME}으로 이동하여 실행 스크립트 실행

cd /sw/jboss/jboss-eap-7.4/servers/server1_1

./start.sh

[oracle@was server1_1]$ ./start.sh
=================================================

##### Server Startup #####

JBOSS_HOME=/sw/jboss/jboss-eap-7.4
DOMAIN_HOME=/sw/jboss/jboss-eap-7.4/servers/server1_1
SERVER_NAME=server1_1
CONFIG_FILE=standalone-ha.xml
BIND_ADDR=192.168.56.230
PORT_OFFSET=0
MANAGEMENT_CONSOLE=http://192.168.56.230:9100

=================================================

netstat 명령어를 사용하여 LISTEN 상태인 port 확인

netstat -ntl | grep LISTEN

Management Console에서 사용하는 port인 9100와 HTTP_PORT 인 7010이 LISTEN 상태인 것 확인

2. Deploy를 위한 사전 세팅

먼저 {STANDALONE MODE_HOME}/deployments 디렉터리 내부에 배포하고자 하는 애플리케이션을 배치

애플리케이션 디렉터리 네이밍은 .war 확장자로 설정

→ deployment scanner가 .war / ear / ejb-jar와 같은 확장자로 끝나는 파일 또는 디렉터리를 찾아 배포를 진행하기 때문

deploy scanner가 webapp.war 디렉터리를 인식하고 배포를 진행할 수 있도록

해당 디렉터리 네이밍 뒤에 .dodeploy를 붙인 비어있는 디렉터리 생성

touch webapp.war.dodeploy

mkdir webapp.war.dodeploy

디렉터리를 생성하게 되면 자동으로 deploy scanner가 배포를 진행하고 .dodeploy 가 .deployed로 변경된 것 확인 가능

3.  Console에서 배포 확인