JBoss EAP 7 TCP Kernel : 최적화 방안 해결책
JBoss EAP 7의 성능을 극대화하는 방법: TCP 커널 파라미터 조정 및 최적화에 대한 필수 팁과 연관성을 알아보세요.
들어가며
안녕하세요 오픈마루 기술지원팀입니다.
최근 많은 고객께서 당사에 JBoss EAP 6에서 JBoss EAP 7로 업그레이드를 진행하면서, 기존 TCP 관련 Kernel Parameter (커널 파라미터)를 계속 사용할 수 있는지 질문을 받았고, 질문에 답변으로 오늘은 JBoss EAP 6에서 사용하던 TCP 관련 커널 파라미터를 JBoss EAP 7에서도 계속 사용할 수 있는지에 대한 답을 이번 포스팅을 통해 공유해 드리겠습니다.
JBoss EAP 6과 JBoss EAP 7은 모두 Java(자바) 기반의 Enterprise Application (엔터프라이즈 애플리케이션) 서버로, 각각의 버전에는 특정 요구사항과 최적화 설정을 가지고 있습니다.
특히, TCP 관련 Kernel Parameter(커널 파라미터)는 애플리케이션을 운영하는데 있어, 성능과 안정성에 중요한 영향을 미칠 수 있는 영향을 알아보겠습니다.
TCP 관련 커널 파라미터란 무엇인가요?
쉽게 한마디로 정의하면, TCP 관련 Kernel Parameter는 운영체제의 네트워크 성능을 조정하는 중요한 설정입니다.
이러한 파라미터 설정들은 네트워크의 동작을 제어하고, 데이터를 빠르고 안전하게 전송하는데 중요한 역할을 합니다.
JBoss EAP 와 같은 애플리케이션 서버는 대규모의 트랜잭션(Transaction)을 처리하기 떄문에, 제품에서 제공하는 기본 설정값 보다는 적절한 TCP 파라미터 설정이 필수적입니다.
꼭 변경해야만 하는 주요 TCP 커널 파라미터
| 구분 | 구분 | 설명 | 권장값 | 설정방법 |
| 네트워크 관련 파라미터 | net.core.somaxconn | 소켓의 최대 대기 연결 큐의 크기를 지정합니다. 기본적으로 설정된 값이 낮을 경우, 동시에 많은 연결 요청이 들어올 때 일부 연결이 거부될 수 있습니다. | 4096 이상 | sysctl -w net.core.somaxconn=4096 |
| net.core.netdev_max_backlog | 네트워크 인터페이스의 수신 큐의 최대 길이를 지정합니다. 이 값이 너무 낮으면, 높은 네트워크 부하 시 패킷 손실이 증가할 수 있습니다. | 2500 이상 | sysctl -w net.core.netdev_max_backlog=2500 |
|
| net.ipv4.tcp_max_syn_backlog | SYN 요청의 최대 대기 수를 설정합니다. SYN 대기열이 가득 차면 새로운 연결 요청이 무시될 수 있습니다. | 2048 이상. | sysctl -w net.ipv4.tcp_max_syn_backlog=2048 |
|
| net.ipv4.tcp_fin_timeout | 소켓이 FIN-WAIT-2 상태에서 머무는 시간을 지정합니다. 너무 길게 설정하면 리소스가 낭비될 수 있고, 너무 짧게 설정하면 연결이 비정상적으로 종료될 수 있습니다. | 15 초 | sysctl -w net.ipv4.tcp_fin_timeout=15 |
|
| net.ipv4.tcp_tw_reuse 및 net.ipv4.tcp_tw_recycle | TIME-WAIT 상태의 소켓을 재사용하는 설정입니다. 이를 통해 빠른 연결 재사용이 가능하지만, NAT 환경에서는 사용에 주의가 필요합니다. | tcp_tw_reuse=1 (활성화), tcp_tw_recycle은 최근 리눅스 커널에서는 비활성화 권장. | sysctl -w net.ipv4.tcp_tw_reuse=1 |
|
| net.ipv4.tcp_rmem 및 net.ipv4.tcp_wmem | TCP 연결의 송수신 버퍼 크기를 설정합니다. 적절한 버퍼 크기는 네트워크 대역폭과 응용 프로그램 요구에 따라 성능을 최적화할 수 있습니다. | 4096 87380 16777216 (수신 버퍼), 4096 16384 16777216 (송신 버퍼). | sysctl -w net.ipv4.tcp_rmem=”4096 87380 16777216″ sysctl -w net.ipv4.tcp_wmem=”4096 16384 16777216″ |
|
| 시스템 리소스 관리 관련 파라미터 | fs.file-max | 시스템에서 열 수 있는 최대 파일 개수를 지정합니다. 이 값이 너무 낮으면 많은 파일을 동시에 열어야 하는 상황에서 오류가 발생할 수 있습니다. | 100000 이상. | sysctl -w fs.file-max=100000 |
| vm.swappiness | 시스템이 메모리를 스왑으로 얼마나 자주 사용할지를 결정합니다. 값이 낮을수록 스왑 사용을 줄이고, 물리적 메모리를 우선 사용하게 됩니다. | 10 (기본값은 60) | sysctl -w vm.swappiness=10 |
|
| 파일 처리 관련 파라미터 | fs.aio-max-nr | 시스템에서 사용할 수 있는 비동기 I/O 요청의 최대 수를 설정합니다. 이 값이 너무 낮으면 고성능 I/O 작업에 제한이 생길 수 있습니다. | 1048576 이상. | sysctl -w fs.aio-max-nr=1048576 |
| fs.inotify.max_user_watches | inotify(파일 시스템 이벤트 모니터링)의 사용자별 최대 감시 수를 설정합니다. 이 값이 너무 낮으면 많은 파일 시스템 이벤트를 모니터링할 때 제한이 발생할 수 있습니다. | 524288 이상. | sysctl -w fs.inotify.max_user_watches=524288 |
|
| 시스템 전반에 대한 최적화 | vm.dirty_ratio 및 vm.dirty_background_ratio | 메모리가 더티 데이터(수정된 데이터)를 유지할 수 있는 비율을 설정합니다. 더티 데이터는 디스크로 플러시되기 전에 메모리에 남아있는 데이터를 의미합니다. | dirty_ratio=15, dirty_background_ratio=5. | sysctl -w vm.dirty_ratio=15 sysctl -w vm.dirty_background_ratio=5 |
JBoss EAP 업그레이드시 TCP 파라미터를 변경해야 하는 이유
JBoss EAP 6과 JBoss EAP 7은 아키텍처와 구성 방식에 차이가 있습니다.
물론 단순하게 ‘제품 버전만 upgrade되었기 때문에, parameter의 변경없이 사용할 수 있지 않나요?’ 라고 질문하시는 분들도 많이 있습니다.
물론 JBoss EAP 7에서도 기존에 사용하던 파라미터 값을 그대로 사용할 수 있습니다만, 몇가지 중요한 점을 고려하셔야 합니다.
| 이유 | 설명 |
| 아키텍처 차이 | JBoss AS 6는 기본적으로 AS(애플리케이션 서버) 구조를 기반으로 하며, JBoss EAP 6 및 7은 도메인 구조를 지원합니다. 이로 인해, 네트워크 트래픽과 연결 관리 방식에 차이가 있을 수 있습니다. |
| 성능 최적화 | JBoss EAP 7은 개선된 네트워크 성능과 확장성을 제공하기 위해 여러 최적화가 적용되었습니다. 이로 인해, JBoss 6에서 사용한 일부 파라미터가 JBoss EAP 7에서 최적의 성능을 제공하지 않을 수 있습니다. |
| 버전별 파라미터 요구사항 | 특정 버전의 JBoss는 그 버전에 맞는 권장 TCP 파라미터 설정을 가지고 있습니다. JBoss EAP 7에서는 더 높은 성능과 확장성을 위해 파라미터 설정이 다를 수 있습니다. |
JBoss TCP 파라미터를 최적화 하지 않으면 발생할 수 있는 문제점
JBoss와 같은 미들웨어 서버에서 커널 파라미터를 최적화하지 않으면 시스템 성능과 안정성에 매우 치명적으로 요소가 될 수 있습니다.
이러한 치명적 요소는 추후 장애를 발생시킬 수 있고, 원인을 알지 못해, 원인을 찾기 위해 많은 시간과 노력을 들이게 됩니다.
다음은 JBoss TCP 파라미터를 최적화 하지 않았을 때 발생할 수 있는 문제점을 유발할 수 있는지 미리 예측하여 살펴보겠습니다.
| 구분 | 분류 | 설명 |
| 네트워크 성능 저하 | 느린 데이터 전송 | 네트워크 버퍼 크기나 TCP 창 크기 설정이 적절하지 않으면, 데이터 전송 속도가 느려질 수 있습니다. 이는 클라이언트와 서버 간의 응답 시간이 길어지거나, 대용량 파일 전송 시 전송 속도가 떨어지는 문제를 야기할 수 있습니다. |
| 패킷 손실 증가 | 네트워크 큐의 크기가 부족하거나 TCP 연결 관리가 비효율적일 경우, 패킷 손실이 발생할 수 있습니다. 이는 재전송 요구가 증가하고, 결국 네트워크 부하가 커지는 결과를 초래합니다. | |
| TCP 연결 제한 | 연결 대기열 크기가 충분히 설정되지 않으면, 동시 접속이 많은 경우 연결 요청이 거부될 수 있습니다. 이는 서비스 거부(DoS) 공격을 받거나, 정상적인 사용자 요청이 처리되지 않는 상황을 유발할 수 있습니다. | |
| 시스템 리소스 과부하 | 메모리 사용량 증가 | 잘못 설정된 버퍼 크기나 큐 길이는 필요 이상의 메모리를 사용하게 만들 수 있습니다. 이는 다른 프로세스가 사용할 수 있는 메모리가 부족해지는 결과를 초래하며, 결국 시스템 성능 저하로 이어집니다. |
| CPU 부하 증가 | 비효율적인 TCP 연결 관리나 과도한 인터럽트 처리로 인해 CPU 사용량이 증가할 수 있습니다. 이는 서버가 요청을 처리하는 데 더 많은 시간을 필요로 하게 만들어, 응답 시간 증가와 서비스 지연을 초래합니다. | |
| 서버 안정성 문제 | 서버 다운타임 증가 | 자원 과부하나 비효율적인 네트워크 처리로 인해 서버가 불안정해질 수 있습니다. 이는 서버가 다운되거나 재부팅이 필요한 상황을 유발할 수 있습니다. |
| 시스템 충돌 및 오류 | 잘못된 커널 파라미터 설정은 네트워크 충돌이나 소켓 에러 등을 유발할 수 있습니다. 이러한 오류는 애플리케이션이 제대로 동작하지 않게 만들고, 서버 운영에 큰 지장을 초래할 수 있습니다. | |
| 서비스 가용성 저하 | 클라이언트의 연결 요청이 효율적으로 처리되지 않으면, 서비스의 가용성이 저하될 수 있습니다. 이는 사용자의 경험에 부정적인 영향을 미치고, 비즈니스에 손실을 초래할 수 있습니다. | |
| 보안 취약성 | DoS 공격에 대한 취약성 | 네트워크 연결 큐의 크기나 SYN 요청 처리 능력이 낮을 경우, 서비스 거부(DoS) 공격에 쉽게 노출될 수 있습니다. 이는 서버의 자원을 고갈시켜 정상적인 서비스 제공을 방해합니다. |
| 세션 하이재킹 | TCP 관련 설정이 부적절하면, 세션 하이재킹 공격에 취약할 수 있습니다. 이는 공격자가 사용자의 세션을 가로채어 악용할 수 있는 가능성을 높입니다. | |
| 사용자 불만 | 응답 시간 지연 | 서버의 응답 시간이 길어지면, 사용자는 느리고 비효율적인 서비스에 불만을 느낄 수 있습니다. |
| 연결 실패 | 클라이언트의 연결 시도가 자주 실패하면, 서비스 신뢰도가 떨어지고, 이는 고객 만족도 저하로 이어질 수 있습니다. |
전격공개!! 오픈마루 기술지원팀이 사용하는 파라미터 값
.리눅스 시스템에서 JBoss를 최적의 성능으로 운영하기 위해서는 위에서 언급한 커널 파라미터들을 적절히 조정하는 것이 중요합니다.
이에 오픈마루 기술지원팀에서는 다양한 산업군의 고객사를 지원하면서, 다년간의 노하우가 녹아 있는 커널 파라미터를 값을 전격적으로 공개합니다.
이 파라미터들은 시스템의 네트워크 처리와 파일 처리, 전반적인 성능에 큰 영향을 미칩니다.
[중요] 오픈마루 기술지원팀이 사용하는 파라미터 값 사용에 관련해서는 오로지 사용하시는 분에게 책임과 결정에 의한 것이며, 오픈마루는 그에 대한 책임과 기술지원을 하지 않습니다.
| 파라미터 | 설정값 | 설명 |
| net.ipv4.tcp_keepalive_time | 1800 | keep-alive 시간을 줄인다. |
| net.ipv4.tcp_fin_timeout | 10 | FIN 타임아웃 시간을 줄여 FD를 빨리 확보할 수 있도록 한다. |
| net.core.netdev_max_backlog | 2500 | 백로그에 들어오는 소켓 개수를 늘린다. |
| net.ipv4.tcp_retries1 | 2 | TCP 연결에 문제가 있을 때 연결을 재시도하는 횟수(기본값은 3이다) |
| net.ipv4.tcp_retries2 | 3 | TCP 연결을 끊기 전에 재시도하는 횟수를 줄인다. |
| net.ipv4.ip_local_port_range | 20000 65000 | 사용할 수 있는 로컬 포트 범위를 늘린다. |
| net.core.rmem_max | 56777216 | TCP 수신 버퍼크기 최댓값을 늘린다. |
| net.core.rmem_default | 16777216 | TCP 수신 버퍼크기 기본값을 늘린다. |
| net.core.wmem_max | 56777216 | TCP 전송 버퍼크기 최댓값을 늘린다. |
| net.core.wmem_default | 16777216 | TCP 전송 버퍼크기 최댓값을 늘린다. |
| net.ipv4.tcp_window_scaling | 1 | 65kb 이상의 큰 TCP 윈도우 스케일링을 사용한다. |
| net.ipv4.tcp_orphan_retries | 0 | 서버 측에서 닫은 TCP 연결을 끊기 전에 확인하는 횟수를 줄인다. 기본값은 7로 50초~16분 정도 걸린다. |
| net.ipv4.tcp_sack | 0 | SYNC 패킷을 전송한 후 일부 ACK를 받지 못했을 경우 선택적으로 받지 못한 ACK 패킷을 받도록 설정할 수 있다. 0은 받지 않는 설정이다. 패킷 유실이 많은 네트워크에서는 1로 설정한다. |
| net.ipv4.tcp_timestamps | 0 | TCP 패킷 송수신시 Timestamp 값을 이용한다. 패킷 크기가 커지므로 부하가 발생할 수 있습니다. 다만, sequence number 의 overflow 로 인한 패킷 드랍이 발생하면, 해당 옵션을 1로 설정한다. |
마무리
JBoss EAP 6에서 사용하던 TCP 파라미터를 JBoss EAP 7에서도 사용해도 큰 문제는 없을 수 있지만, 최적의 성능을 얻기 위해서는 JBoss EAP 7에 맞는 권장 설정을 적용하는 것이 좋습니다.
특히, 시스템의 네트워크 트래픽 패턴과 부하를 고려하여 파라미터를 조정하면 더 나은 성능을 기대할 수 있습니다. JBoss EAP 7으로의 전환을 준비하고 계시다면, JBoss EAP 7에 맞는 TCP 커널 파라미터를 검토하고 적절하게 조정하는 것이 중요합니다.
감사합니다.
2023 Red Hat Summit Boston에 오픈마루가 간다
/in News, OPENMARU, Seminar, 오픈나루 공지사항/by 오픈마루 마케팅0최신 컨테이너 기술 총정리! Red Hat Container Day에서 확인하세요!
/in JBoss, OpenShift, Red Hat, Seminar, 오픈소스/by 주하 원2023년 캘린더 출시 – 오픈마루의 친환경 캘린더 Goods
/in gift/by 실장 님