#성능최적화

JBoss EAP 7.x 성능 튜닝 완벽 가이드: 스레드·JVM·OS 통합 설정

    
      ⚙️ WAS
    
    📅 2026. 04. 07
    |
    ⏱ 약 2분 읽기

JBoss EAP 운영 중 응답 지연·Out of Memory·503 오류가 발생한다면 스레드 풀, JVM 힙, OS 커널 파라미터 세 가지를 함께 점검해야 합니다. 이 글에서는 JBoss EAP 6.4 / 7.x 기준으로 각 계층을 체계적으로 튜닝하는 방법을 실무 중심으로 정리합니다.

적용 버전: JBoss EAP 6.4 / 7.x | OS: RHEL 6/7, CentOS 7

1. Apache HTTPD 튜닝 (MPM 설정)

Apache가 JBoss 앞에서 프록시 역할을 할 경우 MPM(Multi-Processing Module) 선택이 전체 처리량에 직접 영향을 줍니다.

MPM	특징	권장 환경
`prefork`	프로세스 기반, 안정성 최우선	mod_php 사용 시
`worker`	프로세스+스레드 혼합, 메모리 효율↑	고트래픽 프록시
`event`	KeepAlive 연결 비동기 처리, 최고 효율	Apache 2.4+ 권장

# /etc/httpd/conf.modules.d/00-mpm.conf
# worker MPM 예시 (JBoss 프록시 환경 권장)
LoadModule mpm_worker_module modules/mod_mpm_worker.so


    StartServers          4
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadsPerChild      25
    MaxRequestWorkers   400
    MaxConnectionsPerChild 10000

튜닝 포인트: MaxRequestWorkers × ThreadsPerChild가 실제 최대 동시 연결 수를 결정합니다. 메모리 여유분 확인 후 설정하세요. (ab -n 1000 -c 100 http://... 부하 테스트 병행 권장)

2. JBoss Thread Pool 튜닝

JBoss EAP 7.x의 스레드 풀은 Undertow 커넥터와 IO 워커 두 계층으로 구분됩니다.

2-1. Thread Pool (standalone.xml)

<!-- EAP 6.x: threads 서브시스템 -->
<subsystem xmlns="urn:jboss:domain:threads:1.1">
  <blocking-queueless-thread-pool name="http-executor">
    <max-threads count="200"/>
    <keepalive-time time="60" unit="seconds"/>
  </blocking-queueless-thread-pool>
</subsystem>

2-2. IO Worker (EAP 7.x Undertow)

<!-- EAP 7.x: io 서브시스템 -->
<subsystem xmlns="urn:jboss:domain:io:1.1">
  <worker name="default"
          io-threads="16"
          task-max-threads="256"
          task-keepalive="60"/>
</subsystem>

파라미터	기본값	권장값	설명
`io-threads`	CPU×2	CPU×2 ~ CPU×4	I/O 이벤트 처리 스레드. CPU 코어 수에 비례하여 조정
`task-max-threads`	CPU×16	128~256	비동기 작업 스레드 최대치. 과도하게 높이면 컨텍스트 스위칭 증가
`task-keepalive`	60	60	유휴 스레드 유지 시간(ms). 기본값 유지

검증 명령어:

$JBOSS_HOME/bin/jboss-cli.sh --connect \
  command="/subsystem=io/worker=default:read-resource(include-runtime=true)"

3. JVM 튜닝 (Heap & GC)

JBoss 성능 문제의 상당수는 잘못된 JVM 힙 설정과 GC 정책에서 비롯됩니다. G1GC는 EAP 7.x(JDK 8+) 환경에서 가장 권장되는 GC 알고리즘입니다.

3-1. 힙 크기 설정

# standalone.conf (또는 domain.conf)
JAVA_OPTS="-Xms2048m -Xmx4096m"
JAVA_OPTS="$JAVA_OPTS -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m"

옵션	기본값	권장값	설명
`-Xms`	256m	서버 RAM × 25%	초기 힙. -Xmx와 동일하게 설정 시 힙 조정 오버헤드 제거
`-Xmx`	512m	서버 RAM × 50%	최대 힙. 물리 RAM의 50% 이상은 OS/캐시용으로 남겨야 함
`MetaspaceSize`	21m	256m	초기 Metaspace 크기. OutOfMemoryError 예방
`MaxMetaspaceSize`	무제한	512m	반드시 상한 설정. 무제한 시 메모리 누수로 서버 OOM 가능

3-2. G1GC 설정

JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC"
JAVA_OPTS="$JAVA_OPTS -XX:MaxGCPauseMillis=200"
JAVA_OPTS="$JAVA_OPTS -XX:G1HeapRegionSize=16m"
JAVA_OPTS="$JAVA_OPTS -XX:InitiatingHeapOccupancyPercent=45"
# GC 로그 (운영 환경 필수)
JAVA_OPTS="$JAVA_OPTS -Xlog:gc*:file=/app/was/logs/gc.log:time,uptime:filecount=5,filesize=20m"

주의: MaxGCPauseMillis=200은 목표값이지 보장값이 아닙니다. 실제 GC 로그를 확인하며 점진적으로 조정하세요.

4. OS 튜닝 (Linux 커널 파라미터)

고트래픽 환경에서는 OS 레벨의 네트워크 백로그와 파일 디스크립터 제한이 병목이 될 수 있습니다.

4-1. sysctl 파라미터

# /etc/sysctl.conf
net.core.somaxconn=65535
net.ipv4.tcp_max_syn_backlog=65535
net.ipv4.tcp_fin_timeout=30
net.ipv4.tcp_keepalive_time=300
net.ipv4.tcp_tw_reuse=1

# 적용
sysctl -p

4-2. 파일 디스크립터 제한 (ulimit)

# /etc/security/limits.conf
jboss soft nofile 65536
jboss hard nofile 65536

# 적용 확인 (JBoss 프로세스 PID로 확인)
cat /proc/$(pgrep -f jboss.modules)/limits | grep "open files"

파라미터	기본값	권장값	설명
`somaxconn`	128	65535	소켓 연결 큐 최대 크기. 부족 시 SYN Dropped 발생
`tcp_fin_timeout`	60	30	TIME_WAIT 소켓 유지 시간. 줄이면 포트 재사용 빨라짐
`nofile`	1024	65536	열 수 있는 파일/소켓 수. 부족 시 "Too many open files" 오류

5. 검증 체크리스트

# ① JBoss IO Worker 런타임 상태 확인
$JBOSS_HOME/bin/jboss-cli.sh --connect \
  command="/subsystem=io/worker=default:read-resource(include-runtime=true)"

# ② JVM 메모리 현재 상태
$JBOSS_HOME/bin/jboss-cli.sh --connect \
  command=":read-attribute(name=max-memory)"

# ③ OS 파라미터 적용 확인
sysctl net.core.somaxconn
sysctl net.ipv4.tcp_max_syn_backlog

# ④ GC 로그 실시간 모니터링
tail -f /app/was/logs/gc.log

튜닝 적용 순서 (권장)

① OS 파라미터 적용 (sysctl, limits) — 재부팅 불필요, 즉시 적용 가능
② JVM 힙 및 GC 옵션 조정 후 JBoss 재기동
③ 스레드 풀 설정 변경 후 reload (재기동 없이 적용 가능한 항목도 있음)
④ Apache MPM 변경은 httpd 재기동 필요 — 점검 시간 확보 후 진행

#WAS#JBoss#EAP#JVM#Tuning#ThreadPool#G1GC#Linux

📝 원문 노트: Notion에서 보기 →

Open Stream →

#IBM HTTPServer

[IHS/Liberty] WAS에서 실제 Client IP가 보이지 않을 때 해결 방법 (X-Forwarded-For 설정)

WebSphere Liberty와 IBM HTTP Server(IHS)를 연동하여 운영하다 보면, WAS 접근 로그나 애플리케이션 내부에서 실제 클라이언트 IP(Client IP) 대신 웹 서버(IHS)의 IP가 찍히는 현상을 자주 마주하게 됩니다.

보통 mod_remoteip를 먼저 떠올리지만, 네트워크 구성(DSR, L4 설정 등)에 따라 해당 모듈만으로는 해결되지 않는 경우가 있습니다.

오늘은 IHS에서 물리적인 연결 IP(REMOTE_ADDR)를 강제로 헤더에 할당하고, Liberty에서 이를 신뢰하도록 설정하여 실제 사용자 IP를 완벽하게 가져오는 방법을 공유합니다.

1. 원인 분석

기본적으로 WAS는 자신과 TCP 연결을 맺은 대상의 IP를 Client IP로 인식합니다.

Flow: Client → IHS → WAS
Problem: WAS 입장에서 직접 연결된 대상은 IHS이므로, 별도 설정이 없으면 IHS IP를 클라이언트로 판단합니다.

이를 해결하려면 HTTP 헤더(X-Forwarded-For)를 통해 IP를 전달해야 하며, 아래 두 가지 조건이 충족되어야 합니다.

IHS (Sender): 접속한 클라이언트의 실제 IP를 헤더에 확실히 심어서 보낼 것.
Liberty (Receiver): "IHS가 보낸 헤더는 믿을 수 있다"고 신뢰 설정을 할 것.

2. IHS (Web Server) 설정

mod_remoteip가 복잡하게 얽혀 작동하지 않거나 L4에서 헤더를 넘겨주지 않는 상황이라면, mod_rewrite와 mod_headers를 조합해 "지금 붙은 IP"를 강제로 헤더에 주입하는 것이 가장 확실합니다.

httpd.conf (VirtualHost 설정)

<VirtualHost *:80>
    ServerName your.service.com

    # 1. Rewrite 엔진 활성화
    RewriteEngine on

    # 2. 현재 접속한 실제 IP(REMOTE_ADDR)를 환경변수 'CLIENT_IP'에 저장
    RewriteRule ^(.*) - [E=CLIENT_IP:%{REMOTE_ADDR},L]

    # 3. 환경변수에 담긴 IP를 X-Forwarded-For 헤더에 덮어쓰기 (Set)
    # 기존 값을 무시하고, IHS가 식별한 IP로 강제 설정하여 신뢰성 확보
    RequestHeader set X-Forwarded-For %{CLIENT_IP}e
    
    # (선택) HTTPS 통신임을 WAS에 알리기 위한 헤더
    # RequestHeader set X-Forwarded-Proto "https"
</VirtualHost>

Point: RequestHeader set을 사용하여 헤더를 재작성(Overwrite)함으로써, 중간 단계에서 변조되거나 누락된 IP 정보를 IHS가 인식한 정확한 물리적 IP로 보정해서 WAS로 보냅니다.

3. WebSphere Liberty (WAS) 설정

Liberty는 보안상의 이유로 신뢰하지 않는 프록시가 보낸 헤더는 무시하는 것이 기본 정책입니다. IHS가 헤더를 잘 보내줘도, Liberty 설정(server.xml)에서 IHS를 "신뢰하는 통로"로 등록하지 않으면 적용되지 않습니다.

server.xml 설정

<httpDispatcher> 태그를 사용하여 IHS 서버의 IP를 신뢰 목록에 추가합니다.

<server description="My Liberty Server">

    <!-- ... 기존 설정들 ... -->

    <!-- 
      trustedHeaderOrigin: X-Forwarded-For 등 일반 헤더를 신뢰할 IP 목록
      trustedSensitiveHeaderOrigin: SSL 관련 등 민감한 헤더를 신뢰할 IP 목록
      값: IHS(Web Server)의 IP 주소를 쉼표(,)로 구분하여 입력
    -->
    <httpDispatcher trustedHeaderOrigin="192.168.0.10, 192.168.0.11" 
                    trustedSensitiveHeaderOrigin="192.168.0.10, 192.168.0.11" />

</server>

주의: 테스트 시 * (전체 허용)를 사용할 수도 있으나, 운영 환경(Production)에서는 보안을 위해 반드시 연동된 웹 서버의 IP만 명시하는 것을 권장합니다.

4. 결과 확인 및 요약

설정 적용(IHS 재기동, Liberty 동적 반영) 후, WAS의 접근 로그나 애플리케이션 로직을 확인하면 결과가 달라집니다.

IHS: 접속자의 REMOTE_ADDR을 X-Forwarded-For 헤더에 Set 해서 전송.
Liberty: 지정된 IP(IHS)에서 온 요청임을 확인하고 헤더를 신뢰.
Result: request.getRemoteAddr() 대신 헤더 값을 참조하여 실제 Client IP 획득 성공.

네트워크 구성이 복잡하거나 L4 설정 권한이 없을 때, IHS단에서의 명시적 헤더 Rewrite와 Liberty의 신뢰 IP 등록 조합은 가장 강력하고 확실한 해결책이 됩니다.

Open Stream →

#Life

[Engineering Note] 문자열 인코딩의 이해: ASCII부터 UTF-8까지

Summary: 개발자가 반드시 알아야 할 문자열 인코딩의 기본 원리 정리. Charset과 Encoding의 차이를 명확히 하고, 한글 깨짐 현상(Mojibake)의 기술적 원인과 UTF-8이 표준이 된 이유를 비트(Bit) 단위로 분석한다.

1. 서론: 문자는 숫자의 약속이다

컴퓨터는 0과 1밖에 모른다. 우리가 화면에서 보는 'A'나 '한글'이라는 글자는 결국 특정 숫자에 매핑된 약속일뿐이다. 이 약속은 크게 두 가지 개념으로 나뉜다.

Character Set (문자 집합): 표현할 수 있는 글자들의 목록과 각 글자에 부여된 번호(Code Point). (예: Unicode, ASCII)
Encoding (인코딩): 그 번호를 컴퓨터가 이해할 수 있는 이진수(Binary)로 저장하는 방식. (예: UTF-8, ASCII)

2. 인코딩의 진화 과정

2.1. ASCII (American Standard Code for Information Interchange)

1960년대, 영문 알파벳과 숫자, 제어 문자를 표현하기 위해 제정되었다. 7비트(bit)를 사용하여 총 128개의 문자를 표현한다.

범위: 0x00 ~ 0x7F
특징: 1바이트(8비트) 중 맨 앞 1비트(MSB)는 Parity Bit로 남겨두고 사용하지 않았다. 영미권 외의 문자는 표현이 불가능하다는 한계가 있다.

2.2. EUC-KR vs CP949 (한글의 혼란기)

한국어 윈도우 환경에서 개발할 때 가장 많이 겪는 혼란이다. 둘 다 2바이트로 한글을 표현하지만 범위가 다르다.

구분	설명	특징
EUC-KR	완성형 한글 표준	자주 쓰는 한글 2,350자만 표현 가능. '믜', '햏' 같은 글자는 깨짐.
CP949	MS 확장 완성형	EUC-KR을 확장하여 11,172자를 모두 표현 가능. 윈도우 메모장의 기본 저장 방식(ANSI).

3. 사실상의 표준: Unicode와 UTF-8

국가별로 제각각인 인코딩 방식(EUC-KR, Shift_JIS 등)을 통합하기 위해 유니코드(Unicode)가 등장했다. 유니코드는 '전 세계 모든 문자에 고유 번호(Code Point)를 부여'한 것이다.

중요한 점은 유니코드 그 자체는 인코딩 방식이 아니라는 것이다. 이 유니코드 번호를 어떻게 저장하느냐에 따라 UTF-8, UTF-16 등으로 나뉜다.

왜 UTF-8인가?

UTF-8은 가변 길이 인코딩(Variable-width encoding) 방식을 채택했다.

영어(ASCII): 1바이트 사용 (기존 ASCII와 100% 호환).
한글/한자: 주로 3바이트 사용.
이모지: 4바이트 사용.

이러한 특성 덕분에 영문이 많은 문서에서는 용량을 획기적으로 줄일 수 있으며, 엔디안(Endian) 문제에서 자유롭기 때문에 웹 표준으로 자리 잡았다.

4. 트러블슈팅: 한글은 왜 깨지는가?

한글이 깨지는 현상(Mojibake)은 인코딩 방식(저장할 때)과 디코딩 방식(읽을 때)이 일치하지 않을 때 발생한다.

Case 1: 'Ã«ÂÃ...' (UTF-8을 ISO-8859-1로 읽음)

UTF-8로 저장된 한글(3바이트)을 1바이트씩 끊어서 읽는 라틴 계열 인코딩(ISO-8859-1 등)으로 해석할 때 발생한다. 톰캣(Tomcat) 등의 기본 설정이 ISO-8859-1인 경우가 많아 자주 목격된다.

Case 2: '????' (표현 불가)

유니코드 문자를 EUC-KR이나 ASCII 처럼 해당 문자가 없는 인코딩으로 변환하려 할 때 발생한다. 정보가 유실되었으므로 복구가 불가능하다.

5. Python을 이용한 검증

다음은 파이썬을 이용해 문자열이 바이트로 변환되는 과정과, 잘못된 디코딩이 어떤 결과를 초래하는지 보여주는 예제다.

# 1. 문자열 준비
text = "한글"

# 2. 인코딩 (String -> Bytes)
utf8_bytes = text.encode('utf-8')
euc_bytes = text.encode('euc-kr')

print(f"UTF-8 Bytes: {utf8_bytes}")
# 출력: b'\xed\x95\x9c\xea\xb8\x80' (한 글자당 3바이트: ed 95 9c / ea b8 80)

print(f"EUC-KR Bytes: {euc_bytes}")
# 출력: b'\xc7\xd1\xb1\xdb' (한 글자당 2바이트: c7 d1 / b1 db)

# 3. 잘못된 디코딩 (Bytes -> String)
try:
    # UTF-8로 인코딩된 데이터를 EUC-KR로 해석 시도
    broken_text = utf8_bytes.decode('euc-kr')
    print(f"Broken: {broken_text}")
except UnicodeDecodeError as e:
    print(f"Decoding Error: {e}")
    # 데이터 비트 조합이 EUC-KR 테이블에 없으면 에러 발생, 
    # 억지로 매핑되면 이상한 한자나 외계어 출력

6. Conclusion

문자열 인코딩 문제는 기초적이지만, 데이터베이스 마이그레이션이나 레거시 시스템 연동 시 치명적인 버그를 유발한다.

가능하면 모든 시스템(DB, Server, Client)의 인코딩을 UTF-8로 통일하라.
Content-Type 헤더나 meta 태그에 반드시 charset=utf-8을 명시하라.
한글이 깨진다면, 원본 데이터의 헥사(Hex) 값을 확인하여 몇 바이트로 구성되었는지 파악하는 것이 해결의 첫걸음이다.

Open Stream →

#IBM HTTPServer

[Troubleshooting] Edge 보안 업데이트 대응: IHS & IIS CORS 설정 완벽 가이드

최근 Edge 및 Chrome 브라우저의 보안 정책 업데이트(Private Network Access, SameSite 등)로 인해, 내부망 시스템 간 호출 시 발생하는 CORS(Cross-Origin Resource Sharing) 오류 해결 과정을 정리합니다.

특히 IBM HTTP Server(IHS) 환경에서 Invalid CORS request 오류와 로그가 남지 않는 현상을 해결한 최종 설정 가이드입니다.

1. IHS (IBM HTTP Server) 설정 가이드

이 설정은 단순 CORS 허용뿐만 아니라, WAS(애플리케이션)단의 거부 에러 해결과 최신 브라우저의 사설망 접근 허용을 모두 포함한 통합본입니다.

📂 설정 파일 경로: IHS_HOME/conf/httpd.conf
📂 적용 위치: <VirtualHost ...> 태그 내부

✅ httpd.conf 최종 적용 코드

<VirtualHost *:8080>
    # ... 기존 설정 ...

    # =========================================================================
    # [1. 브라우저용 설정] CORS 및 PNA(사설망 접근) 보안 정책 대응
    # =========================================================================
    
    # 1. 도메인 화이트리스트 검사 (https 및 모든 서브도메인 허용 정규식)
    # 문법: ^(시작) + http(s):// + .*(와일드카드) + \.도메인\.com + $(끝)
    SetEnvIf Origin "^http(s)?://.*\.test\.com$" ACCESS_CONTROL_ORIGIN=$0

    # 2. 브라우저에게 보내는 허가증 (Response Header)
    Header set Access-Control-Allow-Origin %{ACCESS_CONTROL_ORIGIN}e env=ACCESS_CONTROL_ORIGIN
    
    # 3. SSO 필수: Credentials(쿠키/세션) 전송 허용
    Header set Access-Control-Allow-Credentials "true" env=ACCESS_CONTROL_ORIGIN
    
    # 4. ★핵심: 최신 Edge PNA(Private Network Access) 허용 헤더
    # (공인망에서 사설망 호출 시 차단 방지)
    Header set Access-Control-Allow-Private-Network "true" env=ACCESS_CONTROL_ORIGIN
    
    # 5. 허용 메소드 및 헤더 정의
    Header set Access-Control-Allow-Methods "POST, GET, OPTIONS" env=ACCESS_CONTROL_ORIGIN
    Header set Access-Control-Allow-Headers "Content-Type, Authorization, X-Requested-With, Access-Control-Allow-Private-Network" env=ACCESS_CONTROL_ORIGIN

    # 6. 캐싱 문제 방지
    Header add Vary Origin


    # =========================================================================
    # [2. WAS(애플리케이션)용 설정] "Invalid CORS request" 해결
    # =========================================================================
    
    # 설명: WAS가 요청 Origin을 엄격하게 검사하여 에러를 뱉는 경우,
    # IHS가 WAS로 넘기기 직전에 Origin 헤더를 '내부 도메인'으로 변조하여 통과시킴.
    
    # ★ 수정 포인트: 아래 주소는 실제 IHS 서버의 호스트 주소(https 포함)로 변경
    RequestHeader set Origin "https://www.test.com"

    # ... 기존 설정 ...
</VirtualHost>

⚠️ 주의사항: 설정 적용 후 반드시 IHS를 재기동해야 합니다.
./apachectl restart

2. 테스트 및 검증 방법

🛠️ 테스트 준비 (필수)

브라우저 캐시 삭제 (Ctrl + Shift + Delete)
F12 개발자 도구 실행 → [Network] 탭 확인
팝업이 닫히는 경우: F12 설정(F1) → '팝업용 DevTools 자동 열기' 체크

🔍 성공 기준 (Checklist)

확인 항목	정상 결과
HTTP 상태 코드	`200 OK` (OPTIONS 및 POST 요청 모두)
Response Header	`Access-Control-Allow-Origin` 값이 요청한 도메인으로 변환되어 있어야 함
Response Header	`Access-Control-Allow-Private-Network: true` 확인

3. 문제 해결 (Troubleshooting)

❌ 증상 1: 서버에 액세스 로그조차 남지 않음

원인: Mixed Content (HTTPS 페이지에서 HTTP 호출) 또는 브라우저 PNA 정책 차단
해결: 호출 URL을 https://로 변경하고, 위 설정의 PNA 헤더 적용 확인

❌ 증상 2: "Invalid CORS request" 텍스트가 화면에 뜸

원인: WAS(애플리케이션)가 요청 도메인을 거부함
해결: 위 코드의 RequestHeader set Origin "내부주소" 설정이 올바른지 확인

❌ 증상 3: ERR_CONNECTION_RESET 발생

원인: HTTPS(443) 호출을 했으나 IHS 포트가 8080(HTTP)이거나 SSL 설정이 없음
해결: IHS httpd.conf에 SSL 설정(Listen 443, 인증서) 확인

Open Stream →

#Liberty

[Liberty] 특정 로그(CWWKS4001I) 숨김 설정이 적용되지 않을 때 해결 방법

WebSphere Liberty (Open Liberty) 운영 중 불필요하게 반복되거나, 보안 정책상 숨겨야 하는 로그 메시지가 발생할 때가 있습니다. 예를 들어, CWWKS4001I 같은 보안 감사 로그가 대표적입니다.

일반적으로 bootstrap.properties에 설정을 추가하지만, 상황에 따라 적용되지 않는 경우가 있어 이를 확실하게 적용하는 두 가지 방법(server.xml 활용 등)을 정리합니다.

1. 문제 상황

bootstrap.properties 파일에 아래와 같이 설정했음에도 불구하고, messages.log나 console.log에 여전히 해당 메시지가 출력되는 현상이 발생했습니다.

        # bootstrap.properties 설정 예시

        com.ibm.ws.logging.hideMessage=CWWKS4001I

원인: 서버 초기화 시점과 로깅 시스템 로드 시점의 차이, 혹은 server.xml 설정의 우선순위 문제일 수 있습니다.

2. 해결 방법 A: server.xml에서 제어 (권장)

가장 확실한 방법은 server.xml의 <logging> 태그를 사용하는 것입니다. 이 방식은 명시적이며 설정 반영 확률이 가장 높습니다.

파일 경로: ${server.config.dir}/server.xml

<server description="My Server">

    <!-- 기존 logging 태그가 있다면 속성을 추가, 없다면 신규 작성 -->

    <!-- hideMessage: 숨길 메시지 ID를 콤마(,)로 구분하여 작성 -->

    <logging hideMessage="CWWKS4001I"/>

    <!-- 기타 설정들... -->

</server>

3. 해결 방법 B: bootstrap.properties 재점검

부트스트랩 파일을 계속 사용해야 한다면, 다음 사항을 체크해야 합니다. 부트스트랩 변경은 반드시 서버 재기동(Stop & Start)이 필요합니다.

설정 값 뒤에 공백(Space)이 포함되어 있지 않은지 확인
오타 확인 (com.ibm.ws.logging.hideMessage)

# 공백 없이 정확하게 입력

com.ibm.ws.logging.hideMessage=CWWKS4001I

4. 검증 및 결과

설정 적용 후 기존 로그를 정리하고 서버를 재기동하여 적용 여부를 확인합니다.

# 1. 로그 파일 삭제

rm messages.log console.log

# 2. 서버 재기동

server stop [서버명]

server start [서버명]

# 3. 로그 확인 (결과가 없어야 성공)

grep "CWWKS4001I" messages.log

💡 Tip: server.xml 방식이 관리 포인트 일원화 측면에서 더 유리하므로, 특별한 이유가 없다면 Method A를 추천합니다.

Open Stream →

#Life

[Windows 11] 삼성 패스(Samsung Pass) 데이터 내보내기 및 .spass 파일 복호화 가이드

본 가이드는 Windows 11 환경에서 삼성 패스(Samsung Pass)의 내보내기 파일(.spass)을 복호화하여, Bitwarden이나 1Password 등 타 암호 관리자로 이관하기 위한 CSV 변환 절차를 다룹니다. Android 에뮬레이터(Termux) 없이 Windows PowerShell을 활용한 효율적인 변환 방법을 제시합니다.

1. 개요 및 사전 준비

삼성 패스의 데이터는 암호화된 .spass 포맷으로 저장됩니다. 이를 다른 플랫폼에서 사용 가능한 .csv 포맷으로 변환하기 위해 Python 기반의 복호화 도구를 사용합니다.

OS: Windows 11
Shell: PowerShell (관리자 권한 권장)
필수 도구: Python 3.11+, Git

2. 작업 환경 구성 (Environment Setup)

Windows 패키지 매니저(winget)를 사용하여 필요한 런타임과 도구를 설치합니다.

# Python 및 Git 설치 (이미 설치된 경우 생략 가능)
winget install Python.Python.3.11
winget install Git.Git

3. 변환 도구 설치 (Installation)

GitHub에 공개된 삼성 패스 복호화 도구를 로컬 환경으로 가져옵니다.

# 작업 디렉토리 생성 및 이동
mkdir $HOME\Downloads\spass_converter
cd $HOME\Downloads\spass_converter

# 리포지토리 클론
git clone https://github.com/NHClaessens/samsung_pass_converter.git .

# 필수 Python 라이브러리(Cryptography) 설치
pip install cryptography

4. .spass 파일 변환 실행 (Execution)

내보내기 한 .spass 파일을 작업 폴더로 이동시킨 후, 아래 스크립트를 실행합니다. 개인정보 보호를 위해 비밀번호는 변수 처리되었습니다.

사용법: python convert.py "파일명.spass" "비밀번호" --all

# 변수 설정 (실제 비밀번호로 변경하여 사용)
$SPASS_FILE = "2025_12_26_16_23_10_spass_export_data.spass"
$EXPORT_PASSWORD = "YOUR_PASSWORD_HERE"  # <-- 여기에 실제 비밀번호 입력

# 변환 스크립트 실행
python convert.py $SPASS_FILE $EXPORT_PASSWORD --all

5. 결과 확인 및 보안 조치

명령어 실행이 완료되면 동일한 폴더 내에 변환된 파일이 생성됩니다.

생성 파일:
- ...bitwarden.csv: Bitwarden/1Password 등에서 가져오기(Import) 가능한 파일
- ...decrypted.txt: 육안 확인용 평문 텍스트 파일

⚠️ 보안 주의 (Critical Security Warning)

생성된 .csv 및 .txt 파일에는 모든 계정 정보와 비밀번호가 평문(Plain Text)으로 저장되어 있습니다.
타 암호 관리자로 데이터를 이관(Import)한 즉시, 해당 파일들을 반드시 영구 삭제(Shift + Delete) 하시기 바랍니다.

💡 트러블슈팅 (Troubleshooting)

경로 오류: 파일명에 공백이 있거나 경로가 복잡한 경우 인식이 안 될 수 있습니다. 파일명을 data.spass와 같이 단순화하여 시도하십시오.
라이브러리 오류: pip install cryptography 실행 시 권한 오류가 발생하면 python -m pip install cryptography 명령어를 사용하십시오.

Open Stream →

#WebLogic

[WebLogic 14c] JDBC 데이터소스 튜닝 가이드: 안정적인 DB 연결 최적화

[WebLogic 14c] JDBC 데이터소스 튜닝: 설정 경로 및 파라미터 최적화

Connection Pool 고갈 방지와 DB 성능 향상을 위한 실무 가이드

WebLogic 운영 중 발생하는 DB 접속 지연이나 BEA-001129(커넥션 부족) 에러는 대부분 데이터소스 설정 미흡에서 발생합니다. 오늘은 관리 콘솔의 정확한 설정 경로와 반드시 튜닝해야 할 5가지 핵심 파라미터를 알아보겠습니다.

1. 어디서 설정하나요? (설정 경로)

데이터소스 튜닝은 WebLogic 관리 콘솔에서 아래 경로를 통해 접근할 수 있습니다. 수정 후에는 반드시 [저장] 및 [변경 활성화]를 눌러야 적용됩니다.

📌 설정 메뉴 경로:
도메인 구조 > 서비스(Services) > 데이터 소스(Data Sources) > [해당 데이터 소스 이름 클릭] > 구성(Configuration) 탭 > 커넥션 풀(Connection Pool) 하위 탭

2. 반드시 튜닝해야 할 핵심 파라미터

커넥션 풀 탭 하단의 [고급(Advanced)] 버튼을 클릭하면 더 세부적인 설정이 가능합니다.

항목	설명 및 권장 가이드
Initial Capacity	기본값: 1. 서버 시작 시 생성할 커넥션 수입니다. 예상 최소 부하량에 맞춰 설정하면 초기 응답 속도가 개선됩니다.
Maximum Capacity	가장 중요한 설정입니다. WebLogic 스레드 풀 크기와 DB 서버의 수용 능력을 고려하여 설정합니다. (보통 50~100 사이)
Test Connections On Reserve	[고급] 메뉴에 위치. 커넥션을 빌려주기 전 DB 연결 상태를 체크합니다. 방화벽 등에 의한 세션 끊김 방지를 위해 반드시 활성화합니다.
Statement Cache Size	SQL 실행 계획 캐시입니다. 반복 쿼리가 많은 시스템은 20~50 정도로 높여 성능을 향상시킵니다.
Inactive Connection Timeout	커넥션 누수(Leak) 시 강제 회수 시간입니다. 0(무한대)보다 특정 시간(예: 300초)을 설정하는 것이 안전합니다.

3. 설정 후 상태 모니터링

설정한 값이 적절한지는 [모니터링(Monitoring) > 통계(Statistics)] 탭에서 실시간으로 확인할 수 있습니다.

Active Connections High Count: 서버 기동 후 최대 몇 개의 커넥션이 동시에 사용되었는지 보여줍니다. 이 수치가 Max Capacity에 근접하면 한도를 늘려야 합니다.
Wait for Connection: 커넥션이 없어 대기한 횟수입니다. 이 수치가 0보다 크면 병목이 발생하고 있다는 증거입니다.

🚀 데이터소스 최적화 핵심 요약

✅ 경로는 [서비스 > 데이터 소스 > 커넥션 풀]
✅ 'Test Connections On Reserve' 체크는 필수 안전장치
✅ 모니터링 탭의 'Wait Count'가 발생하지 않도록 유지

이 가이드는 WebLogic 14c 버전 관리 콘솔을 기준으로 작성되었습니다.

Open Stream →

#WebLogic

[WebLogic 14c] 성능 최적화 가이드: 스레드 풀 튜닝과 메모리 계산법

안정적인 Java 엔터프라이즈 서버 운영을 위한 핵심 모니터링 포인트

안녕하세요! 오늘은 WebLogic 14.1.x (14c) 환경을 운영하면서 가장 빈번하게 마주하는 성능 최적화 이슈를 정리해 보려고 합니다. 특히 순간적인 부하가 발생하는 시스템에서 필수적인 스레드 풀(Thread Pool) 튜닝과 Java 8 이후 변경된 메모리 계산 방식에 대해 심도 있게 다뤄보겠습니다.

1. WebLogic 스레드 풀(Thread Pool) 튜닝

WebLogic은 기본적으로 부하에 따라 스레드 수를 조절하는 Self-Tuning 모델을 사용합니다. 하지만 엔터프라이즈 환경에서는 스레드 생성 오버헤드를 방지하기 위해 최소/최대 값을 고정하는 것이 권장됩니다.

✅ 기동 옵션 적용 예시


            -Dweblogic.SelfTuningThreadPoolSizeMin=100

            -Dweblogic.SelfTuningThreadPoolSizeMax=100

* 시스템 환경에 따라 50~200 사이로 설정하며, Min/Max를 동일하게 설정하여 'Warm-up' 상태를 유지합니다.

2. 관리 콘솔을 통한 실시간 모니터링

설정한 스레드 풀이 정상적으로 동작하는지 확인하기 위해 WebLogic Admin Console의 모니터링 기능을 활용합니다.

📌 모니터링 경로:
환경(Environment) > 서버(Servers) > [대상 서버 선택] > 모니터링(Monitoring) > 스레드(Threads)

핵심 지표	의미	위험 신호
Queue Length	대기 중인 요청 수	지속적인 상승
Stuck Threads	고착된 스레드	1건 이상 발생
Throughput	초당 처리량	급격한 하락

3. 정확한 메모리 계산법 (Heap vs Metaspace)

Java 8 이후로는 Metaspace가 Native Memory 영역으로 이동했습니다. 따라서 전체 메모리 사용량 = Heap + Metaspace + Native 영역으로 계산해야 합니다.

💡 Metaspace 사용률의 오해

jstat -gc 명령어로 확인 시 전체 크기(MC)가 작게 보일 수 있습니다. 이는 JVM이 클래스 로딩 양에 맞춰 메모리를 동적으로 할당하기 때문입니다.

MC (Metaspace Capacity): 현재 OS로부터 할당받은 크기
MU (Metaspace Used): 실제 클래스 메타데이터가 점유한 크기

※ 운영 팁: 사용률 계산 시 MC가 아닌, 기동 옵션에서 설정한 MaxMetaspaceSize를 분모로 계산해야 정확한 자원 고갈 여부를 판단할 수 있습니다.

🚀 안정적인 운영을 위한 체크리스트

✅ 스레드 풀 Min/Max를 동일하게 설정했는가?
✅ Metaspace 사용률이 설정값 대비 90% 이하인가?
✅ JDBC 데이터소스의 'Maximum Capacity'가 적절한가?

본 가이드는 WebLogic 14.1.1 및 JDK 1.8 기반으로 작성되었습니다.

Open Stream →

#WebSphere

[WebSphere] 실제 IP(Real IP) 인식 불가 해결: trustedHeaderOrigin 설정 가이드 (CVE-2012-5783 대응)

WebSphere Application Server(WAS)의 trustedHeaderOrigin 설정이 개선되었습니다. 기존에는 정확한 IP만 입력해야 했으나, 최신 픽스팩(9.0.5.7, 8.5.5.20)부터는 192.168.*.*와 같은 IP 세그먼트 와일드카드를 지원합니다. 유동 IP 환경에서의 설정법과 적용 버전을 정리합니다.

1. 업데이트 배경: IP 관리가 너무 힘들다?

기존에는 보안(CVE-2012-5783) 이슈로 인해 trustedHeaderOrigin에 앞단 웹 서버의 정확한 IP(Full IP)를 일일이 등록해야 했습니다.

하지만 클라우드(AWS, Azure)나 컨테이너(Docker/K8s) 환경에서는 L4/Web 서버의 IP가 수시로 변경되거나 대역으로 할당되므로, 모든 IP를 나열하는 것이 불가능했습니다. 이를 해결하기 위해 부분 와일드카드(IP Wildcard Segments) 지원이 추가되었습니다.

2. 와일드카드 지원 버전 (Target Fixpacks)

아래 버전 이상의 픽스팩(Fix Pack)이 적용된 환경에서는 IP 대역 설정이 가능합니다.

제품군	지원 시작 버전 (Minimum Version)
WAS 9.0	9.0.5.7 이상
WAS 8.5	8.5.5.20 이상
Liberty	21.0.0.2 이상

참고: 위 버전보다 낮은 경우 192.168.*.* 같은 입력을 인식하지 못하고 에러가 발생하거나 IP 인식이 실패할 수 있습니다.

3. 설정 가이드 (Configuration)

WAS 관리 콘솔에서 전송 채널의 사용자 정의 속성을 추가합니다.

설정 경로

Servers > [서버명] > Web Container Settings > Web container transport chains
대상 체인 선택 (예: WCInboundDefault)
HTTP Inbound Channel (HTTP_2) > Custom properties > New

속성 값 입력 예시 (New Feature)

이제 아래와 같이 유연한 설정이 가능합니다.

속성 이름 (Name)	값 (Value) 예시	설명
trustedHeaderOrigin trustedSensitiveHeaderOrigin	`10.10..`	10.10.0.0/16 대역의 모든 IP 신뢰 (추천)
	`192.168.1., 10.1..*`	콤마(,)를 사용하여 여러 대역 동시 지정
	`*.ibm.com`	호스트네임 기반의 와일드카드 지원

Best Practice:
과거에는 편의상 * (전체 허용)를 사용하는 경우가 많았으나, 이는 보안상 취약합니다.
이제는 10.10.*.* 처럼 내부망 IP 대역만 특정하여 허용함으로써 보안과 편의성을 모두 챙길 수 있습니다.

4. 웹 컨테이너 포트 인식 설정 (함께 적용)

IP 대역 설정과 함께, 호스트 헤더의 포트 정보를 올바르게 가져오기 위한 웹 컨테이너 설정도 잊지 마세요.

위치: Web Container > Custom properties
속성: com.ibm.ws.webcontainer.extractHostHeaderPort = true

5. 검증 (Verification)

설정 저장 후 WAS 재기동
SystemOut.log에 별다른 에러 메시지가 없는지 확인
애플리케이션에서 request.getRemoteAddr() 호출 시 실제 클라이언트 IP가 출력되는지 확인

Open Stream →

#IBM HTTPServer

[IHS/WAS] 실제 클라이언트 IP(Real IP) 식별 가이드: mod_remoteip 설정 및 버전별 패치 현황 (9.0.5.13)

로드밸런서(L4/L7) 환경에서 실제 클라이언트 IP를 식별하기 위해 IBM HTTP Server(IHS) 9.0의 mod_remoteip를 설정하는 방법을 다룹니다. 특히 보안 감사 로그의 무결성을 위해 IHS 9.0.5.13 (APAR PH47286) 패치가 왜 중요한지, 그리고 버전별 로그 포맷 설정 차이점을 중점적으로 정리합니다.

0. 배경: 왜 IP가 바뀔까?

클라이언트가 로드밸런서(Proxy)를 거쳐 웹 서버에 접속하면, 웹 서버 입장에서는 연결을 요청한 주체가 로드밸런서이므로 Source IP가 로드밸런서 IP(예: 10.0.0.1)로 기록됩니다.

이는 다음과 같은 보안 문제를 야기합니다.

접근 제어 실패: IP 기반의 ACL(Access Control List) 적용 불가
감사 추적 불가: 사고 발생 시 실제 공격자의 IP를 로그에서 찾을 수 없음

1. 버전별 패치 및 로그 포맷 주의사항 (Version History)

IHS 설정에 앞서, 사용 중인 IHS 버전에 따라 로그 포맷 변수를 다르게 써야 하므로 버전 확인이 필수적입니다.

📢 핵심 패치 정보: APAR PH47286

적용 버전: IBM HTTP Server 9.0.5.13 이상

내용: 이전 버전에서는 mod_remoteip가 정상 작동해도, 기본 로그 변수인 %h가 여전히 프록시 IP를 출력하는 문제가 있었습니다. 9.0.5.13부터는 %h가 mod_remoteip에 의해 변경된 실제 IP를 반영하도록 수정되었습니다.

버전별 권장 로그 포맷

IHS 버전	Access Log 권장 변수	설명
9.0.5.12 이하	`%a` (Client IP)	`%h`는 프록시 IP를 찍으므로 사용 금지. 반드시 `%a` 사용.
9.0.5.13 이상	`%h` 또는 `%a`	패치 적용됨. `%h`를 써도 실제 IP가 기록됨 (기존 설정 유지 가능).

2. IHS 설정 가이드 (httpd.conf)

Step 1: 모듈 활성화

# mod_remoteip 모듈 주석 해제
LoadModule remoteip_module modules/mod_remoteip.so

Step 2: 신뢰할 프록시 등록

보안을 위해 "누가 보내준 헤더를 믿을 것인가"를 명시해야 합니다. 아무 헤더나 믿으면 IP 스푸핑 공격에 당할 수 있습니다.

<IfModule mod_remoteip.c>
    # 1. 실제 IP가 담긴 헤더명 지정 (표준: X-Forwarded-For)
    RemoteIPHeader X-Forwarded-For

    # 2. 신뢰할 로드밸런서(L4/L7) IP 등록
    # 사설 IP 대역의 프록시인 경우 (10.x, 192.168.x 등)
    RemoteIPInternalProxy 10.0.0.1 10.0.0.2

    # 공인 IP 대역의 프록시인 경우
    # RemoteIPTrustedProxy 203.0.113.5
</IfModule>

Step 3: 로그 포맷 변경 (Access Log)

버전에 관계없이 가장 안전한 방법은 %a 변수를 사용하는 것입니다.

# [기존] common 포맷 (9.0.5.12 이하에서 문제 발생 가능)
# LogFormat "%h %l %u %t \"%r\" %>s %b" common

# [변경] %h -> %a 로 변경 (권장)
LogFormat "%a %l %u %t \"%r\" %>s %b" common

3. 검증 및 디버깅 (Validation)

설정 적용 후 실제로 헤더가 잘 변환되는지 확인하기 위해 임시로 로그를 상세하게 찍어봅니다.

# 디버깅용 로그 포맷 정의 (작업 후 주석 처리 권장)
# %{c}a : Connection IP (L4 IP)
# %a    : Client IP (변환된 실제 IP)
GlobalLog logs/remoteip_debug.log "L4-IP=%{c}a Real-IP=%a XFF-Header=%{X-Forwarded-For}i"

정상 결과 예시:

L4-IP=10.0.0.1 Real-IP=203.0.113.2 XFF-Header=203.0.113.2

L4-IP에는 로드밸런서 IP가 나와야 함
Real-IP에는 실제 사용자 PC의 IP가 나와야 함 (성공)

4. WAS(WebSphere) 추가 설정 필요 여부

IHS에서 mod_remoteip가 정상 작동하면, WAS 플러그인(Plugin)으로 넘어갈 때 이미 Source IP가 복원된 상태로 넘어갑니다. 따라서 WAS 쪽에서는 별도의 추가 설정 없이 request.getRemoteAddr() 호출 시 실제 IP를 획득할 수 있습니다.

(단, Plugin 설정의 TrustedProxyEnable 속성은 상황에 따라 검토가 필요할 수 있습니다.)

Open Stream →