JBoss EAP7 의 변경된 Connector와 Thread 처리

JBoss EAP 7 (이하 EAP7)이 나온지도 몇개월이 되었고 (2016년 Q3)

아직 시장에 많이 풀리지는 않았고

패치도 열심히 올라오는 중임

이번에 바뀐 부분중에서 핵심(?)적이라고 할만한 부분을 말해보자면

서블릿 컨테이너를 전면 교체 하면서

요청을 받아들이는 Connector 부분과

WAS의 실질적인 요청처리 작업을 하는 Thread의 구조 및 Pooling 방법이 변경되었다


먼저 톰켓(tomcat)과 같이 설명을 하자면

EAP6까지는 Listener(Connector), Thread Pool, servlet 처리 부분을 Tomcat으로 처리해왔다

실제 tomcat 소스를 임포트 해서 개발했다고 보면 무방하다

그러다보니 tomcat tuning 포인트와 같이 생각하면 됬다.

대표적으로  Production에 적용한 tomcat 에서 기본적으로 검토해야하는

Pure java가 아닌 tomcat Native 를 사용하듯이 (APRConnector)
(BIO-blocking , NIO-non blocking JAVA Connector ,
APR-Apache Potable Runtime Native)

EAP에서는 이미 컴파일 된 Native Module을 제공하였고

Thread처리도 기본이 아니라 Executor thread Pool을 별도로 생성하여

tomcat 내부 Thread와 사용자 처리 Thread를 분리 하여 동작하도록 튜닝했다.
(안정성 개선 등)

EAP7에서는 tomcat의 이부분(서블릿컨테이너라도 통칭)을 걷어내고

경량 서블릿컨테이너인 언더토우(Undertow)로 변경되면서

서블릿 처리를 수행하는 컨테이너를 포함하여

앞서 말한 Connector 처리와 Thread Model이 변경되었다

이렇게 변경된 이유를 추측(!) 해보면

JVM의 Native 성능에 대한 신뢰가 어느정도 올라간것이 아닌가 하는 생각이다

기존에도 NIO(New IO)라고 해서 JAVA에서도 native 통신성능을 개선한 JAVA API를 제공하였으나

API 편의성이 그다지 좋지 못하고

그냥 추론에 성능이 그리 훌륭하지 못하고 안정성에 대한 신뢰 문제.... (가 있다는것이 아니라 C로 개발된 Native에 비하여) 등의 고민때문에

별도의 native module을 개발하여 제공하였다 ( 확장자 so 파일)

하지만 아무래도 별도의 모듈 개발에 필요한 공수도 감안하고

JVM의 NIO의 개선을 목적으로 XNIO (http://xnio.jboss.org/) 프로젝트가 진행되었고

이 Xnio를 기반으로 Undertow(http://undertow.io)가 개발되었으며

EAP7 에서는 이 부분을 신규로 적용한 것이다.


그럼 XNIO 기반의 Undetow를 적용함으로써 실제 좋아지는게 뭐냐?

니들끼리 바꿨다고 자축해봐야 나하고 뭔 상관이냐고....

라기 보다는

노가다 뛰는 엔지니어 입장에서 보면 다음과 같은 개선사항이 있다

1. Native 추가적인 설치가 필요없다
기본 Pure JAVA 기반의 WAS를 Native로 동작하게 하기 위해서는 별도의 Lib 모듈이 필요하며 tomcat의 경우 별도의 모듈 생성을 위하여 gcc를 사용하여 컴파일 하는 작업.....(아...구차나...안되면 골때리고...생성되도 운영시 문제발생시 해결방법이 없다)
JVM의 NIO를 기반으로 하는 XNIO를 사용하여 Connector 와 Buffer를 처리함으로써 JVM만 있으면 별도의 라이브러리가 필요없다.
설치가 단순해 진다.

2. Connector(Listener)의 단순화
EAP5를 구동하면  WAS 하나에 엄청나게 많은 Listen Port가 열렸다.
별별 다른 APP들과 충돌이 나고
포트 번호 하나 바꾸는데 진이 빠질 정도였던 환경에서
EAP6로 가면서 일부 최적화가 되었으나
tomcat Connector는 Multiplexer(MUX) 기능(1개 포트로 여러  프로토콜통신수행)을 구현할 수 없었기 때문에 어쩔 수 없이 다수의 Listen port가 사용되었다.
(예를 들어 관리용 Native Port 9999, EJB용, 기타 등등)
EAP7에서는 XNIO의 MUX기능을 사용할 수 있게 되었고 이를 통하여 Port를 통합함으로써 점유하는 Port 수를 획기적으로 줄였다
(관리용 Port 9999 하나로 EJB, JMX 등 여러 서비스를 동시 제공, HTTP 8080 포트하나로 HTTP2.0 프로토콜 동시제공)

3. Direct Buffer 사용
성능과 큰 관계가 있는 부분으로 기존에는 사용자 요청을 받으면  JVM 내부 Heap 영역의 일부를 Buffer로 지정하여 해당 영역에 저장하여 처리 하였으며 이 버퍼는 Blocking 모드로 동작했다(JVM의 내부는 무조건 Blocking Thread 모델이다...태생이 그렇다.
(Native 모듈설치한 WAS나 NIO 빼고)

EAP7 부터는 XNIO를 사용하여 JVM 외부 메모리 영역(Native Memory) 즉 Process의 메모리 영역에 접근할 수 있게 되어 non blocking으로 메모리에 저장함으로써 Buffer 처리 능력을 획기적으로 상승시킨다.
(솔까말 Native Module 설치한 WAS와는 비교하면 그놈이 그놈)

4. IO thread  별도로 추가됨 
위에서 말한 MUX에 들어오는 요청은 기존에는 WAS Thread와 1:1 매칭 되는 구조였으나
이제 부터는 별도의 IO Thread가 Listener로 들어온 요청을 non blocking으로 읽어서 direct buffer에 저장하게 되므로 Rush 성 요청에 대한 대응능력이 개선됬을 것으로 보인다.

무슨말이냐...

요청이 엄청나게 밀려드는 웹사이트에서 JVM이 그러한 요청처리를 하기 위해서는 Kernel과 통신하여 요청을 처리해야 하고 이때 Blocking이 걸린다.
만약 JVM이 처리하는 속도 보다 요청이 더 빠르게 유입된다면
요청은 큐에 쌓이다가 결국 튕겨져 나가는 현상이 발생할 수 있다.

느린 (blocking thread) JVM Thread는 기존과 같이 working thread로 사용하지만
그 앞단에 Non blocking Thread를 별도로 두어서
들어오는 요청을 빠르게 수용할 수 있도록 변경함으로써
일단 들어오는 요청은 최대한 빨리 내부로 진입 시킬 수 있도록 개선되었다는 이야기.....
(아...씨바...머이리 복잡해.....)

이러한 구조는
대형 사이트에서 사용되던 상용 Product 에 이미 적용되곤 했던 검증된 구조로써
대표적으로 Iplanet Web Server(Sun One Web Server, Oracle iplanet webserver)에 적용되어
뛰어난 성능과 안정성을 자랑했다.

5. Worker(Working Thread Pool) 가 추가 되었다.
IO Thread가 단순히 요청을 빠르게 읽어들어 뒷단으로 저장하는 기능을 담당(Non Blocking)한다면

Working Thread는 실제 처리를 수행하는 (파싱하고..적달한 엔진으로 넘기고...대답하고)하는 역할(Blocking)을 수행한다.

기존의 Executor Thread Pool 이라고 불리던 Thread Pool이
Worker 라는 이름으로 변경되었다고 보면 된다.

사실 Thread Pool이야 원래 있던 내용이지만
이전까지 직접 config 파일을 열어서 추가하고
connector와 연결하는 작업을 해야 했던 터라
구조를 이해 하지 못하고 작업 해서는 잘 되지 않고
잘못넣으며 문제를 일으키기 십상...

이러한 부분을 CLI 및 GUI로 통합하여 구성 할 수 있도록 해서
Pool 관리가 월등히 편리해 졌다.



그럼 사용자 입장에서는 뭐가 좋아졌을까?

일단 성능이 좋아졌을 것으로 기대(?) 하고 있다.

본인이 직접 BMT를 해보지 못해서 딱 그렇다고 는 못하겠지만

EAP7이 안정화 되면 기존 버젼보다는 안정성 및 성능면에서 상당한 개선이 기대 된다.


뭐...WAS가 다 그놈이 그놈이지...

내가 운영하는 사이트가 최소한 동시접속이 수천~만 까지 되는것이 아니라면

솔직히 직업 운영할 능력 되면 tomcat도 좋고  Resin도 좋다   그 단순함의 미학....

하지만 아무래도 대용량 접속이 고려 되는 사이트이거나

자체적인 운영 능력이 낮은 조직라면

이제와서 WAS BMT 하자는건 너무 오바고
(올해 2017년이다.
WAS BMT가 웬 말이냐 이미 시장에서 검증된것 좀 믿어라...
김태희 예쁜걸 꼭 같이 살아봐야 알겠냐... 믿어라)

되도록 상용 WAS를 권하고 싶다.

.이상