WAS 최대 쓰레드의 의미

WAS에서의 최대 쓰레드의 의미.

그동안 자세히 몰랐었던 이 녀석에 대해 드디어 적합한 정보를 찾게 되었다.

가려웠던 곳을 긁는 것 같아 기분이 좋다. ㅎㅎㅎ

 

즉, 아래에 있는 이 녀석이 의미하는 바가 무엇인지! 

좋은 예시와 함께 한번 알아보려고 한다.

 

[application.yml 일부코드 발췌]

server:
  port: 8080
  tomcat:
    threads:
      max: 60

 

이것저것 찾던 중, 이해하기 쉽게 표현한 자료를 찾게되어 내용을 참고하였다.

출처는 아래에 남겨두었다!

 

웹 애플리케이션 서버(WAS)의 최대 쓰레드 개수를 늘이는 것에 대해,

다음과 같이 쉽게 설명을 시도해 봅니다. 다음과 같은 깔때기가 있다고 하겠습니다.

단위시간당 유입되는 물의 양과 단위시간당 배출되는 물의 경감에 따라,

큐잉된 물의 양인 액티브 서비스 개수가 존재할 것입니다. WAS의 최대 쓰레드 개수를 늘여준다는 것은,

위 깔때기를 다음과 같이 만들어 주는 것과 유사합니다.

 

즉, 깔때기 통의 넓이를 늘여주거나, 혹은 통의 높이를 높이는 것이지요.

근데, 그러면 성능(Performance)이 올라갈까요? 깔대기의 성능은 무엇일까요?

깔대기의 성능은 같은 시간 내에 더 많은 물을 배출할 수 있는 능력일 것입니다.

장마철에, “시간당 몇톤의 물을 방류하고 있다”는 뉴스를 듣곤 하죠?

깔때기로 본다면, “초당 2 리터의 물을 흘려보낼 수 있다”등이 깔때기의 성능일 것입니다.

 

근데, 깔때기의 통 크기만 늘이면 위 성능이 올라갈까요?

아니죠. 아랫쪽 배수구의 크기를 늘여야 궁극적으로 성능이 올라가는 것이죠.

즉, 다음과 같이 되어야 한다는 것입니다.

 

배수구의 크기를 늘인다는 것은 WAS 운영환경에서는 무엇을 늘인다는 것일까요?

애플리케이션의 처리 시간을 절대적으로 빠르게 함으로써, 애플리케이션 자체의 처리능력을 개선해야 한다는 것입니다.

 

애플리케이션 튜닝이 근본적인 배수구 성능을 나타냅니다.

혹은, WAS와 DB 서버가 있을 때, WAS입장에서 DB쪽 성능은 곧 상대적으로 배수구 역할을 합니다.

예를 들어, SQL 쿼리가 느리다거나, DB쪽이 벅벅거려서 앞쪽 WAS의 쓰레드가 꽉찼을 때,

아무리 WAS쪽 최대 쓰레드 개수를 높여준들 깔때기의 배수구(DB)는 늘이지 않고 깔때기 통만 늘인 꼴이니,

결국 단위시간당 흘려보낼 수 있는 깔때기의 능력은 상승되지 않는 것이지요.

 

그럼 WAS의 최대 쓰레드 개수는 언제 올리는 것이 좋고, 얼마나 올리는 것이 좋을까요?

그림으로 본다면 다음과 같습니다.

 

즉, “배수구의 최대 처리 능력만큼 까지만 올리면 충분”하다는 것입니다. 기형적으로 너무 높게 잡으면, thread context switching등으로 인해 배수구의 제 성능조차 내지 못하는 역효과가 일어난다는 것이죠.

 

그럼, 배수구의 크기는 어떻게 알 수 있습니까? 네..배수구의 크기를 알아야 늘여야 할 깔때기의 크기를 알 수가 있겠죠.

배수구의 크기는 결국 단위시간당 최대 처리 건수입니다.

단위 시간당 처리건수는 성능 테스트 과정을 통해, 단위시간당 처리건수의 단위인 TPS라는 단위를 사용합니다.

단위시간당 최대 배출량이 가장 많아지는 깔때기의 크기, 즉, 최대 성능이 나오는 시점의 WAS 쓰레드개수를 지정하는 것입니다.

 

예를 들어, WAS-DB 구조에서 부하량이 증가함에 따라, 1차적으로 DB쪽 장애가 먼저 생긴다고 했을 때, WAS 쓰레드 개수를 점진적으로 늘이다 보면, DB쪽 병목으로 인해 더이상 성능(tps)이 증가하지 않는 최소의 WAS 쓰래드 개수가 바로 적정 WAS 쓰레드 개수가 되는 것입니다. 그래서 통상적으로 그 수치가 얼마냐구요? 그 질문은 우문입니다.

 

당신 손에 들고 있는 깔때기 배수구 크기를 제가 알고 있지는 않지요. 사이트마다 HW 성능이 다르고, 구성이 다르고, 개발하신 애플리케이션의 처리속도가 천차만별인데, “일반적으로”라는 통계적 수치가 나올 수 없습니다.

 

배수구가 뻥 뚫려 있을수록 깔때기에 쌓여있는 물의 양은 오히려 작아집니다. 쏵~ 내려가버리니까요. 즉, 응답속도가 빠를 수록 액티브하게 돌고 있는 액티브 서비스 개수는 오히려 작아지게 됩니다.

따라서, 상대적으로(!) 응답속도가 무지 빠른 특성을 갖고 있을 수록 WAS의 최대쓰레드 개수는 상대적으로(!) 작은 수치로 설정하는 것이 더욱 효과적입니다. (WAS 튜닝의 여러 방법 중 한 방법이죠.)

 

제니퍼(Jennifer)라는 애플리케이션성능관리(APM) 툴이 이젠 정말 많은 사이트에 적용되어 있습니다. 정량화된 데이타를 실시간으로 확인해 볼 수 있습니다. WAS에서 최대쓰레드 적정개수는 제니퍼에서 액티브서비스개수가 peak시에 평균적으로 몇 개인가를 확인함으로써 가능할 것입니다. 수십군데 사이트에서 모니터링 해 보면, 그 개수는 천차만별입니다. 단지, 그 개수는 통상적으로 이 글을 읽고 있는 초심자가 생각하는 것 보다는 매우 적다는 경험적 사실이 있습니다.

 

PS: 또다른 예시를 들어보면, 고속도로는 통상 편도 2차선입니다.

근데 차가 쌩쌩 달리기 때문에 비록 2개 차선만으로도 단위시간당 통과된 차량의 대수는 무지 많습니다.

근데, 서울 시내에 보면 편도 10차선 이상 되는 곳이 꽤나됩니다.

근데 곳곳에 신호등이 걸리고, 곳곳에 차량정체가 일어나기 때문에, 10차선일지라도 고속도로보다 시간당 통과한 차량 대수는 많지 않을 수 있습니다.

 

즉, 도로의 차선만 늘인다고 차량혼잡이 해결되진 않고, 도로 저편에 있는 건널목을 제거하고 육교를 적절히 세우는 등 교통흐름을 막는 병복구간을 없애야하는 것이죠.

10차선에서 2차선으로 좁아지는 곳에서는, 앞의 10차선을 굳이 20차선으로 증설할 필요가 없는 것이지요.

 

적체되는 차량만 늘어날 뿐…

즉, 서비스큐잉되는 액티스 서비스 개수만 팡팡 늘어나 50보 100보 현상이 일어난다는 것입니다.

앞서 언급했던 thread context switching등으로 인한 역효과는, “고속도로에서 2차선이 1차선으로 갑자기 좁아지는 길목에서는 끼어드는 차 때문에 갑자기 속도를 줄이게 되어, 원래 1차선 하나 있을 때의 교통 흐름보다도 못하게 되는 현상”과

유사하다 하겠습니다.(비유를 하여 말하자면 그렇다는 것이죠)

 

결국, 응답 속도가 무지 빠르면, WAS의 최대 쓰레드 개수는 작아도 된다는 것입니다.

차량이 빨리 달릴 수만 있다면, 고속도로에서 2개 차선만으로 충분하듯이… 근데, 고속도로에서 저 멀리 톨게이트에서 막혀서 줄줄이 사탕으로 차량 정체가 일어났는데, 고속도로를 편도 10차선으로 늘인들, 정체가 해결 되겠습니까? 고속도로에 들어오는 족족 주차장으로 변한 애꿎은 차량만 늘어날 뿐 이 때는 경찰이 오히려 고속도로에 진입하지 말라고 교통통제를 해 주는 것이 효과적인 것입니다. 이것이 제니퍼의 PLC입니다.

 

출처: ㈜자바서비스컨설팅 대표 이원영