내용 목차
WebtoB는 상업용 웹 서버로 대규모의 전문적인 웹 서비스의 운영을 위해 개발되었다. 전문가를 위한 서버인 만큼 사용자에 대한 자유도가 높고 각자의 환경에 맞는 최적의 미세조정을 제공한다. 웹 서버 운영자가 각자의 환경에 맞게 서버를 튜닝하여 사용하게 되면 엄청난 효율과 성능을 얻을 수 있다.
WebtoB의 이러한 특징을 적절히 활용하여 사용할 수 있도록 본 장에서는 튜닝에 있어 가장 중요한 항목들과 그 적용사례에 대해서 설명한다.
WebtoB는 특정 프로세스에서 일반 브라우저에 관련된 연결을 모두 관리한다. 이러한 구조는 하나의 프로세스에서 모든 처리를 관리하므로 빠른 작업을 할 수 있는 장점이 있으나 프로세스의 안정성에 의해 시스템의 성능이 크게 좌우되므로 주의해야 할 필요가 있다. HTH라는 프로세스가 바로 이런 역할을 한다. 이 HTH라는 프로세스는 멀티 스레드로 구성되어 있기 때문에 이 프로세스 및 스레드 관리가 성능에 가장 큰 영향을 줄 수 있으므로 이를 적당히 조절할 필요가 있다.
WebtoB에서는 HTH 프로세스를 통해서 사용자의 연결을 관리하고 HTH 프로세스에 모든 사용자의 연결이 맺어진다. HTH 프로세스 하나에 몇 개의 연결을 맺는 것이 좋은가는 사용하는 운영체제마다 다르다. 이는 각 운영체제마다 프로세스 하나가 열 수 있는 연결의 수를 제한하고 있기 때문이다.
또한, 하나의 프로세스에서 너무 많은 처리를 하면 많은 CPU 점유를 차지하게 되고 프로세스의 동작에 무리를 줄 수 있다. 따라서 동시 사용자가 많은 경우 가급적 적당한 정도로 분리하여 실제 사이트에서 운영한다. HTH process 하나당 최대로 처리할 수 있는 연결의 개수는 FD 설정과 관련이 있다. 따라서 더 많은 동시 사용자를 처리하고자 하는 경우 프로세스 하나가 열 수 있는 연결 제한(최대 16384)을 더 크게 하거나, NODE 절의 HTH 항목의 설정(최대 100)을 늘려서 사용할 수 있다.
이러한 정보는 WebtoB 환경 파일을 컴파일하면, 화면에 WebtoB가 자체적으로 운영체제에 문의하여 자신이 받아 들일 수 있는 최대의 동시 사용자수를 출력해 준다. 따라서 운영자는 동시 사용자 수의 예측과 이 정보를 바탕으로 HTH 프로세스의 적당한 수를 예측해야 한다.
WebtoB는 HTH 프로세스가 요청 처리의 많은 부분을 관리하기 때문에 운영장비에 WebtoB만 단독으로 사용할 경우 운영장비의 CPU Core 수 만큼 HTH를 설정하는 것이 장비를 효율적으로 사용할 수 있는 방법이며 이하 Thread 설정을 추가적으로 고려할 수 있다. HTH를 CPU Core 수보다 크게 설정했을 경우에는 context-switch로 인한 부하가 발생할 수 있다.
HTH가 많아지면 여러 HTH를 관리하기 위한 부하가 발생하고, HTH 캐싱이 분산된다는 문제가 있을 수 있기 때문에 동시 사용자가 많지 않은 경우 NODE 절의 HTH 항목은 기본값인 1을 사용할 것을 권장한다.
HTH 프로세스는 다른 프로세스들과 달리 멀티 스레드로 이루어져 있다. 이 스레드 관리가 성능에 영향을 줄 수 있으므로 이를 적당히 조절할 필요가 있다.
HTH 프로세스는 스레드간 통신을 담당하는 하나의 Selector 스레드와 그외 작업 스레드로 구성되어 있다.
다음은 작업 스레드에 대한 설명이다.
이 스레드는 주로 요청을 처리하기 위한 대부분의 작업을 처리하는 스레드이다. 주로 HTML 요청을 처리하기 위해 요청 파일을 읽어드리는 역할을 한다. 또한 SSL이 사용되어지는 경우 SSL Handshake, 암호화, 복호화, 작업을 한다. 또한 Compression을 사용하는 경우 압축하는 작업을 한다. 그외 HTTP Authentication 작업등 대부분의 작업을 처리한다. Worker Thread 설정은 무조건 많이 설정하는 것보다 CPU 수에 맞춰 설정하는 것이 좋다. Worker Thread는 하나의 요청에 매이지 않고 맡겨진 작업(파일 읽기 등)만 처리하고 Selector에게 반환하므로 하나의 요청에 블록되지 않는다.
특정 OS에서 지원하는 sendfile 기능을 사용할 수 있을 때 적용할 수 있는 스레드이다. 주로 요청 파일의 크기가 큰 경우 사용될 수 있으며, 크기가 큰 파일을 블록킹으로 처리하게 된다. 서비스하기 위한 파일 중 파일 크기가 큰 경우를 고려해서 설정해야 한다.
HTH에서 모든 HTTP 요청이 끝나고 나면 AccessLog를 남겨야 하는데 이를 위한 스레드이다. 이 스레드를 사용하지 않으면 Selector 스레드가 WSM에 AccessLog를 남겨달라도 보내야 한다. 기본값을 사용하는 것이 좋다.
스레드가 많아지면 여러 스레드를 관리하기 위한 부하가 발생하고, 스레드간 context-switch로 인한 부하가 발생할 수 있으므로 동시 사용자가 많지 않은 경우 기본값을 사용할 것을 권장한다. 참고로 각 작업 스레드는 HTH 프로세스 하나당 생성되므로 전체 작업 스레드가 많아지지 않도록 주의해야 한다.
SSL 사용 빈도가 높아지면서, 대부분의 요청을 SSL로 처리하는 경우가 있을 수 있다. SSL 처리는 CPU 사용률이 높기 때문에 CPU를 효율적으로 사용하는 것이 중요하다. WebtoB는 이에 대해 프로세스 및 스레드를 CPU 환경에 맞춰 설정할 수 있다. 다음은 간단한 예이다.
아래와 같은 서버 환경에서 SSL 사용 빈도가 높은 경우를 예로 들 수 있다.
서버 OS : IBM AIX
물리 CPU 수 : 8
하나의 물리 CPU당 SMT-THREADING THREAD 수 : 4
가상 CPU 수 : 32
위와 같은 서버에서 운영자가 HTH 프로세스를 물리 CPU 수에 맞춰 설정하고, 작업 스레드 수를 물리 CPU당 SMT-THREADING THREAD 수에 맞춰 설정한다면 가장 최적인 환경을 구성할 수 있을 것이다.
WebtoB 설정 파일에서 HTH 프로세스의 수 및 HTH의 스레드를 설정하는 방법은 다음과 같다.
*DOMAIN
webtob1
*NODE
webmain
WebtoBDir = "$WEBTOBDIR",
SHMKEY = 69000,
Docroot = "docs/",
AppDir = "ap/",
Port = "5469",
HTH = 8,
IndexName = "index.html",
Logging = "accesslog",
ErrorLog = "errorlog"
*HTH_THREAD
hworker
WorkerThreads = 4
위와 같이 설정하면 WebtoB가 8개의 HTH 프로세스를 기동하게 된다. 각각의 HTH 프로세스는 4개의 작업 스레드를 사용하게 되고, 총 작업 스레드는32개가 된다. 즉, 서버의 물리 CPU, 가상 CPU에 맞춰 프로세스 및 스레드를 설정함으로써 효과적인 성능을 낼 수 있게 된다.
참고로 각각의 HTH 프로세스는 각 프로세스에 걸리는 로드에 따라서 적당히 사용자의 요구를 분배하기 때문에 하나의 HTH 프로세스가 특별히 일을 많이 하는 등의 문제는 발생하지 않는다.
다른 웹 서버의 경우 하나의 프로세스에 HTML, CGI, SSI 등의 모든 서비스 처리 루틴이 포함되어 있다. 따라서 사용자가 접속하는 경우 하나의 프로세스에서 모든 처리가 끝난다. 사용자당 담당 프로세스가 연결되는 구조에서는 각 사용자의 요구 순간마다 프로세스가 접속을 연결받아 처리한다. 이런 구조에서는 하나의 프로세스에서 모든 사용자의 Request를 처리할 수 있다는 장점은 있으나, 사용자가 사용하지도 않는 기능들이 의미없이 설정되어 있을 수도 있다. WebtoB는 이에 대해 필요한 서비스들을 분리시켜 제공한다. 다음은 간단한 예이다.
어느 쇼핑몰 사이트에서 100%의 사용자를 기준으로 다음과 같은 가정을 세운다.
60%가 HTML 이용자
20%가 Servlet 이용자
10%가 CGI 이용자
10%가 SSI 이용자
대부분의 경우 하나 혹은 2개 정도의 서비스에 사람이 몰리는 경우가 일반적이다.
다른 웹 서버의 경우 운영자는 100개의 프로세스를 설정하여 서비스할 것이다. 이는 사용자가 동시에 100명 정도가 들어오는 경우 반드시 필요한 수치이다. 위와 같은 사용자 분포도를 보인다면, 100개의 프로세스에서 60개는 거의 HTML만을 서비스하고 20개는 Servlet을 서비스하고, 10개가 CGI를 서비스하고 10개가 SSI를 서비스하게 된다. 각각의 프로세스에 포함된 다른 기능들은 의미없이 메모리만 차지한다. 게다가 사용자가 HTML만을 반복적으로 이용하는 경우 이런 현상은 더 더욱 두드러지게 되어 메모리를 효율적으로 운영할 수 없다.
이런 경우에 WebtoB는 위와 같은 문제를 다음과 같은 방법으로 해결한다.
WebtoB의 경우 특정 서비스가 분리되어 있기 때문에 각각의 서비스 프로세스 수를 조정할 수 있다. 가장 많은 HTML은 HTH의 Worker 스레드에서 처리하고, 그외 각각의 CGI, SSI 등의 서비스들을 별도의 독립적인 프로세스로 설정한다. 하나의 프로세스에서 모든 처리를 하는 것이 아니라, 각각의 서비스를 처리하는 것을 분리하여 별도로 각각의 수치를 조정한다.
위와 같은 경우 운영자가 CGI를 사용자가 많이 사용한다는 것을 알게 된다면, CGI를 처리하는 프로세스들을 많이 설정한다. 그리고 다른 프로세스들은 적게 설정하여 불필요한 메모리의 낭비를 막을 수 있다. HTH의 Worker 스레드를 6개, Servlet에 관련된 프로세스를 2개, CGI와 SSI와 관련된 프로세스를 1개씩 띄운다면 가장 최적인 환경에서 서비스를 할 수 있을 것이다.
이러한 설정은 WebtoB 설정 파일의 SERVER 절에 'MinProc'와 'MaxProc' 항목에서 한다. 자세한 사항은 “3.7. SERVER 절”을 참고한다.
다음은 SERVER 절의 설정에 대한 예이다.
*SERVER jsv1 SvgName = jsvg, MinProc = 2, MaxProc = 10 cgi SvgName = cgig, MinProc = 1, MaxProc = 10 ssi SvgName = ssig, MinProc = 1, MaxProc = 2
| 항목 | 설명 |
|---|---|
| MinProc | MinProc는 처음 WebtoB가 기동될 때 시작되는 프로세스의 수이다. 따라서 위의 경우 각 경우의 초기값은 다음과 같이 설정한다.
|
| MaxProc | MaxProc는 최대로 이용할 수 있는 프로세스의 수이다. 이는 동적으로 WebtoB를 조정하는 것이 가능하기 때문에 필요한 값이다. |
사용자가 초기값으로 설정한 후에 약간의 변화가 생겨 프로세스의 조정이 필요한 경우 MinProc와 MaxProc의 범위 안에서 조정하는 것이 가능하다. MinProc의 값은 MaxProc의 값보다 작거나 같아야 한다. wsadmin이라는 관리자용 툴에서 설정한다.
다음과 같이 wsadmin 환경에서 st -p 명령의 수행을 통해 서버 프로세스의 정보를 확인할 수 있다.
$ wsadmin> st -p 정보 HTH 0(12689): RDY --------------------------------------------------------------------------- svr_name svgname spr_no(pid) status count avg(rt) clid svc v --------------------------------------------------------------------------- cgis cgig 0( 12690) BRUN 0 0.0000( 6) 0 cgi 0
위와 같이 조회된 정보 중 상태(status)가 'BRUN'인 경우가 있다. BRUN(Blocked Run) 상태는 서버 프로세스가 HTH에게 응답을 보내지 않고 잠시 멈춰있는 상태를 의미한다. 일반적으로 클라이언트가 응답을 받는 속도가 느린 경우에 발생한다. 크기가 큰 응답을 처리하는 경우 또는 모바일 환경과 같이 네트워크 속도가 느린 경우에 발생할 수 있다.
BRUN이 발생하면 서버 프로세스가 Block 상태이기 때문에 사용자는 서비스에 장애가 있다고 판단할 수 있지만, BRUN이 발생한 상황은 서비스의 장애가 아니다. 또한, BRUN이 자주 발생하면 다른 요청에 대한 큐잉(Queuing) 현상이 발생할 가능성이 높아진다.
일종의 서비스 지연 현상이라고 할 수 있는 BRUN 발생에 대한 튜닝 포인트는 HttpOutBufSize 및 FlowControl 설정이다. 이 2가지 설정을 통해 BRUN의 발생 빈도를 줄일 수 있다.
HTML을 처리하는 경우에는 BRUN이 발생하지 않는다. Worker Thread에서 HTML 요청을 처리하기 위해 파일을 읽게 되는데 ReadBufSize 단위로 읽어서 Selector Thread에게 전달후 Selector Thread에서 FlowControl하면 보내기 때문에 Worker Thread에 블록이 걸리는 일도 발생하지 않는다.
다음은 BRUN의 발생 빈도를 줄이기 위해 HttpOutBufSize와 FlowControl을 설정한 예이다.
*SERVER
cgis SvgName = cgig, MinProc = 5, MaxProc = 10,
HttpOutbufSize = 4096, FlowControl = 50
HttpOutbufSize(기본값: 8192bytes)는 서버 프로세스가 응답을 만들어 HTH에게 전달할 때 버퍼의 단위이다.
예를 들어 위와 같은 설정에서는 사이즈가 1024KB인 응답을 CGIS가 처리해야 하는 경우에 CGIS는 HttpOutbufSize(4KB)만큼 256(1024KB / 4KB)번 나눠서 이(조각)를 HTH에게 전달한다. 이는 한 번에 모두 처리하는 것이 아니라 4KB 버퍼에 담아서 HTH에게 전달하고, 다음 데이터를 동일한 4KB 버퍼에 담아서 HTH에게 전달하는 방식이다. 따라서 HttpOutbufSize 설정은 서버 프로세스가 HTH에게 전달하는 사이즈를 설정함과 동시에 응답 사이즈가 큰 경우에는 몇 번(몇 조각)씩 나눠서 전달할 것인지를 설정하는 것도 포함된다.
참고로, JSV타입의 서버인 경우에는 응답을 전달하는 기준이 JSV 서버이기 때문에 JSV 서버에서 설정해야 하며, HTH는 FlowControl 버퍼를 만드는데만 해당 값을 사용하게 된다.
HTH는 서버 프로세스로부터 전달되는 응답을 FlowControl 버퍼에 받아서 클라이언트에게 전달하게 되는데 FlowControl 버퍼의 크기는 (HttpOutBufSize * FlowControl)이다. 즉, FlowControl 설정은 HttpOutBufSize와 함께 FlowControl 버퍼의 크기를 조절하는 설정이다. (기본값: 50)
클라이언트가 응답을 받는 속도가 느리다면 FlowControl 버퍼가 꽉 차게 되는 경우가 발생하고, 이때 더 이상 서버 프로세스로부터 전달되는 응답을 받을 수 없게 되므로 HTH는 HTMLS로부터 읽는 것을 중지한다. 이때 HTMLS는 BRUN이 발생하여 일시정지 상태가 된다. 클라이언트가 응답을 받아가면서 HTH의 FlowControl 버퍼가 절반 이상 비워지게 되면 HTMLS의 상태가 BRUN에서 RUN으로 전환되고, HTH는 HTMLS로부터 응답을 다시 읽기 시작한다.
HTH의 FlowControl 버퍼 크기를 크게 설정하는 것은 HTH가 사용하는 메모리 양 또한 증가한다는 것을 의미한다. 예를 들어 HTH는 한 요청에 대해 FlowControl 버퍼 크기(default 200KB = 4k * 50)만큼 사용하게 되고, 요청이 많아지는 경우 메모리 사용량은 요청 수만큼 증가하게 된다.
BRUN 상태를 줄이기 위해서는 FlowControl 및 HttpOutBufSize 설정을 통해 FlowControl 버퍼의 크기를 조절하는 것이 필요하다.
다음은 1MB의 파일이 많은 경우의 HttpOutbufSize 및 FlowControl의 설정 변경 예제이다.
*SERVER
cgis SvgName = cgig, MinProc = 5, MaxProc = 10,
HttpOutbufSize = 8192, FlowControl = 100
HttpOutBufSize 및 FlowControl 설정을 크게 하면 HTH가 사용하게 되는 최대 메모리 양이 증가할 수 있다는 것에 주의한다. 특히, 4.1.5 이전 버전에서는 HttpOutBufSize 설정은 HTH에서 캐시하게 되는 파일 사이즈를 설정하므로, HttpOutBufSize 설정을 크게하면 HTH에서 캐시로 사용할 메모리 양도 증가하게 된다.