CS/인프라

[인프라] WAS, ThreadPool 이란?

김yejin 2022. 10. 20. 23:10

 

 

목차

1. WAS(Web Application Server)란?
2. WEB vs WAS
3. Thread Pool

 

WAS (Web Application Server) 란?

Web Application 을 동작시키기 위한 모든 환경을 포함한 서버

Knowlege Center에서 설명하고 있는 Application Server의 정의를 가져오면 다음과 같다.
해석해보면 Web Application, 즉 응용단의 web 프로그램을 실행시키기 위하여 제공하는 모든 환경을 일컫는다.

A server specifically designed to run application
Includes both hardware & software that provide an environment for programs to run.

Used for :
- Running web applications
- Hosting a hypervisor that manages virtual machines
- Distributing and monitoring software updates
- Processing data sent from another server

by Knowledge Center Youtube : Web Server and Application Server | Explained 🔥🔥
https://www.youtube.com/watch?v=thJSev60yfg

 

위키에서는 다음과 같이 정의한다.

즉, 응용소프트웨어가 실행되기 위한 계층적 구조로 보았을 때,
"미들웨어" 에 속하는 일종의 소프트웨어 프레임워크 라고 말하고 있다.
일반적으로 Web Server와 구분지어 "동적 서버 콘텐츠"를 실행시키는 역할을 담당한다.

웹 애플리케이션 서버(Web Application Server, 약자 WAS)는 웹 애플리케이션과 서버 환경을 만들어 동작시키는 기능을 제공하는 소프트웨어 프레임워크이다. 인터넷 상에서 HTTP를 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해 주는 미들웨어(소프트웨어 엔진)로 볼 수 있다.
웹 애플리케이션 서버는 동적 서버 콘텐츠를 수행하는 것으로 일반적인 웹 서버와 구별이 되며, 주로 데이터베이스 서버와 같이 수행이 된다.
한국에서는 일반적으로 "WAS" 또는 "WAS S/W"로 통칭하고 있으며 공공기관에서는 "웹 응용 서버"로 사용되고, 영어권에서는 "Application Server" (약자 AS)로 불린다.
웹 애플리케이션 서버는 대부분이 자바 기반으로 주로 자바 EE 표준을 수용하고 있으나, 자바 기반이지만 자바 EE 표준을 따르지 않는 제품과 .NET이나 Citrix 기반인 비 자바 계열도 존재한다.

by Wiki


여기서 "미들웨어", "응용 소프트웨어", "Web application" 이라는 용어가 생소하다면?

(블로그 글 링크 : )

마지막으로 EDUCBA 에서 설명하고 있는 정의를 보면 다음과 같다.


An application server is a program that resides on the server-side, and it’s a server programmer providing business logic behind any application. This server can be a part of the network or the distributed network.

Working

They are basically used in a web-based application that has 3 tier architecture. The position at which the application server fits in is described below:
Tier 1 – This is a GUI interface that resides at the client end and is usually a thin client (e.g. browser)
Tier 2 – This is called the middle tier, which consists of the Application Server.
Tier 3 – This is the 3rd tier which is backend servers. E.g., a Database Server.

Main purpose of the Application Server
- A mechanism for reducing the size and complexity of the client programs.
- For the need to cache and control the data flow for better performance.
- A mechanism for implementing security for data as well as end-user traffic.

by EDUCBA

 

위 이미지를 보면 3계층 구조의 2계층, 어플리테이션 계층의 역할로써 Application Server를 정의하고 있다.

1계층 - 프레젠테이션 계층 (Presentation Tier) : Web Server, Front-end
2계층 - 어플리케이션 계층 (Application Tier) :  Application Server, 비즈니스 로직
3계층 - 데이터 계층 (Data Tier) : DBMS 

따라서 일반적인 WAS의 역할로 정의해보면 비즈니스 로직을 제공하는 2계층의 "미들웨어" 속하는 것으로써,  Web 서버, DBMS의 사이에서 동적인 Web Application을 수행하고 Web Server 에 전달, DBMS에 접근 가능하도록 환경을 제공 하는 역할을 수행하는 것이다.

 

따라서 WAS의 정의를 두가지 관점에서 정리해 보면 아래와 같다.

등장 배경으로 부터의 정의

웹 브라우저의 등장 이후로, 시스템의 변경에 따라서 사용자의 화면을 수정하는 동적 웹 프로그래밍의 기능 제공을 위해 서버가 등장하였다.이러한 서버의 고성능화를 위하여 어플리케이션의 위치가 클라이언트 단이 아닌, 서버단으로 이동되었고 이러한 서버 사이드에서 어플리케이션 동작을 위한 소프트웨어 프레임워크가 바로 WAS 이다.

 

기능,역할으로부터의 정의

Web Application Server = Web Server + Web Container

WAS 는 정적 데이터를 처리하는 Web Server와 동적 데이터를 처리할 수 있도록 환경을 제공하는 Web Container를 합친 Web Application Server 이다.


Web Server : 클라이언트에게 웹(정적) 서비스를 제공하는 서버
Container : jsp, servlet 등의 동적 서비스를 실행시킬 수 있는 소프트웨어
Web Application Container : Web Application 이 배포되는 공간

클라이언트로부터 요청이 들어왔을 때, WAS에서 어떻게 처리하는지 보면 아래와 같다.
동적인 데이터의 경우, Web Container에서 Servlet 구동환경을 제공함으로써 동적인 data를 처리한다.
처리한 데이터를 client로 전달하는 Web Server의 역할도 같이 수행한다.

 

WAS의 역할

정적인 페이지에서 처리할 수 없는 비즈니스 로직이나 DB 조회 같은 동적인 컨텐츠를 제공한다.

  • 프로그램 실행 환경과 DB 접속 기능 제공
  • 여러 개의 트랜잭션 관리기능
  • 업무 처리하는 비즈니스 로직수행

대표적인 WAS 제품

  • Tomcat
  • 넷스케이프의 Netscape Application Server
  • BEA의 Weblogic Enterprise
  • 볼랜드의 AppServer
  • IBM의 Webshpere Application Server

WAS 장점

  • 세션 관리, 동기 및 비동기 클라이언트 알림과 같은 모든 구성 요소와 실행 중인 서비스를 처리하기 위한 메커니즘을 제공합니다.
  • 응용 프로그램을 한 곳에 설치하는 것이 매우 쉬워집니다.
  • 데이터베이스 서버 이동과 같은 구성 변경은 한 위치에서 중앙 집중식으로 수행할 수 있습니다.
  • 패치 및 보안 업데이트는 이를 통해 쉽게 배포할 수 있습니다.
  • 이를 통해 가용성에 따라 다른 서버에 요청을 배포할 수 있습니다. 이것은 로드 밸런싱을 통해 수행됩니다.
  • 애플리케이션에 보안을 제공합니다.
  • 복구/장애 조치 복구 기능으로 내결함성을 제공합니다.
  • 각 시스템에 개별적으로 구성 사본을 설치해야 하는 경우 큰 시간을 절약할 수 있습니다.
  • 트랜잭션 지원을 지원합니다.
  • 성능 면에서 응용 프로그램 서버는 클라이언트-서버 모델을 기반으로 하므로 응용 프로그램 성능을 크게 향상시킵니다.

출처 : https://www.educba.com/what-is-application-server/

 

WEB vs WAS

 

WAS 는 Web Server의 역할도 수행하고 있다. 
그렇다면 왜  Web Server와  Web Application Server를 분리하여 사용하는가?

1. 책임 분할을 통한 서버 부하 방지

- 대규모 트래픽이 유발되는 서비스의 경우, WEB과 WAS를 물리적으로 분리하여 작동하는 것은 서버 부하 방지에 큰 도움이 된다.
-> 최근 WAS의 기능 향상으로(Tomcat 5.5 이후) 정적 컨텐츠를 WAS 에서 처리하는 것이 성능의 큰 차이가 없다는 자료가 있다. 하지만 물리적으로 서버가 분리되는 것에는 성능의 이점이 존재한다.

2. 분산된 WAS의 로드 밸런싱 기능

- 물리적으로 여러대의 WAS가 분리된 분산 환경에서 WAS에 들어가는 요청을 분리해주는 기능을 제공한다.
-> 실제 Nginx, Apache 와 같은 Web 서버에서 많이 사용하는 기능 중에는 StickySession 을 이용한 LB 처리 방식이 있다. 이는 동일한 클라이언트가 같은 WAS 컨테이너로 접근함으로써 캐싱 기능을 활성화하고, 서비스의 이상동작을 방지하는 역할을 진행한다.

3. 서로다른 Web Application을 하나의 웹 서버로 서비스가 가능

- 예를 들어, aaa.com 이라는 도메인에서 제공하는 A,B,C 라는 서비스가 있을 때,
A 서비스는 A WAS 에 있는  Web Application 이고, B,C 는 B WAS에 있는 Web Application 이다.
Web Server는 서로 다른 A, B WAS를 모두 하나의 aaa.com 이라는 도메인으로 서비스 할 수 있도록 가상 host 기능을 제공한다.

4. WAS의 Health Check를 통한 장애처리 기능

- Failover, Failback 등의 상황에서 올바른 장애처리가 진행될 수 있도록 한다.
-> Failover 상황은 WAS 이중화 상황에서 WAS 1번기에 장애가 발생했을 때, WAS 1번기에 붙어있는 세션이 종료되지 않고, WAS 2번기에서 처리될 수 있도록 Fail이 난 서비스를 over 시킨다는 의미의 장애 처리 기능이다. 해당 상황에서 Web Server는 1번기의 장애 상태를 주기적인 health check를 통해 1번기의 status가 정상이 아님을 확인하고 모든 요청을 2번기로 보내는 로드 밸런싱 기능을 제공한다.
-> Failback 상황은 1번기 장애 이후, 1번기가 정상으로 돌아왔을 때, 기존에 1번기에 있던 session을 모두 복구하여 가져오는 장애처리 기능이다. 해당 상황에서 Web Server는 1번기의 status가 정상임을 주기적인 health check를 통해 확인하고 1번기로 다시 로드밸런싱을 제공한다.

5. 보안에 유리

- Web Server와 물리적으로 분리하여, 네트워크 구성 망자체를 분리함으로써 보안의 이득을 취할 수 있다.
- 공격에 대한 SSL 암호화 처리를 구현하고 있고,  중요 로직이 담긴 WAS, DB의 앞단에 위치하여 공격으로부터 보호하는 역할을 수행한다.

 

즉, "분산 환경"에서의 이점을 가지고, "보안"에서 유리하기 때문에 사용한다고 볼수 있다.

 

 

Thread Pool

Thread Pool 이란?

작업 처리에 사용되는 스레드를 제한된 개수만큼 정해 놓고 작업 큐(Queue)에 들어오는 작업들을 하나씩 스레드가 맡아 처리하는 것을 말한다.

 

Thread Pool 의 필요성

JAVA에서 Thread Pool을 왜 사용할까?

- 성능 저하 방지
다수의 작업을 동시에 병렬적으로 처리하기 위하여 Thread를 사용한다. Thread의 개수가 증가할 수록 작업량이 증가할 것인가? 그렇지 않다. 다수의 Thread를 생성,수거하는 작업은 오히려 전체 프로그램의 성능을 저하시킬 수 있습니다. 또한 물리적인 서버의 자원 또한 한정적이기 때문에 Thread의 개수를 항상 증가시키는 것은 성능을 저하시킬 수 있다.
따라서 적절한 개수의 Thread를 재사용할 수 있도록 하는 Thread Pool을 사용하는 것이 좋다.

- 다수의 사용자 요청을 동시적으로 처리
서비스적인 측면에서 Thread Pool은 동시적으로 들어오는 다수의 사용자의 요청을 빠르게 처리할 수 있도록 한다.

 

WAS 에서 Thread Pool을 어떻게 처리할 것인가?

1.  Spring Boot의 내장 톰캣에서 Thread Pool 개수를 조정하는 방법

server:
  tomcat:
    threads:
      max: 200
      min-spare: 10
    accept-count: 100
  port: 8080

2. JEUS 에서 Thread Pool 개수를 조정하는 방법

WAS 중 하나인 JEUS에 Thread Pool 개수를 아래와 같이 설정하고 확인할 수 있다.
다음은 JEUS8 의 Web UI 인 Webadmin을 기준으로 작성한 내용이다.

위와 같이 Web Server와 연동될 Thread Pool의 개수를 30개로 지정 시, 아래와 같이 실제 요청을 기다리고 있는 thread 자원이 30개 존재하는 것을 확인 할 수 있다. 여기서 state 가 의미하는 것은 thread의 상태로 wating 상태는 thread가 동작하고 있지 않은 상태, 즉 요청을 받을 수 있는 대기 상태로 유효한 스레드임을 의미한다.
여기서 30개의 사용자 요청이 동시에 들어온다면, 해당 WAS는 30개의 요청을 모두 처리할 수 있다. 하지만 이중 DB 조회 등의 시간이 오래 소요되는 서비스가 있어 10개의 thread가 동작중, (active) 상태라면, 20개의 사용자 요청은 정상적으로 처리할 수 있지만, 10개의 사용자 요청은 처리되지 못하고 Queue에 pending 상태로 대기하고 있게 된다.
해당 Queue에서 빠져나와 thread로 처리되지 못하고, 계속해서 남아있는 상태가 지속되면 서비스 지연이 발생되었다고 판단이 되며 이러한 상황에서는 thread dump 자료를 남겨 어느 서비스에서 지연이 발생되고 있는지 확인하는 것이 좋다.

Thread Dump 뜯어보기

블로그 주소 : 

 

* 참고 : 적절한 Thread Pool 개수의 산정 방법

- TPS 를 기준으로 한 통산적인 계산 방법이 있으나, 보편적으로는 부하테스트 등을 통한 경험에 의한 적정 Thread Pool 개수를 산정하는 것이 더 효과적인 값을 얻을 수 있다.

 

 

 

참고자료

https://www.youtube.com/watch?v=thJSev60yfg 
https://www.youtube.com/watch?v=NyhbNtOq0Bc&t=30s
https://www.educba.com/what-is-application-server/
https://dadadamarine.github.io/computer/science/2019/05/20/About-WAS.html
https://velog.io/@gillog/Web-Server%EC%99%80-Web-Application-Server%EC%9D%98-%EC%B0%A8%EC%9D%B4

 

 

기술면접 질문 정리

1. WAS 가 무엇인가요?

WAS 란, 넓은 범위에서 보았을 때 일종의 미들웨어로서 Web Application 을 실행시키기 위한 소프트웨어 플랫폼이라고 할 수 있습니다. 기능적 측면에서 보았을 때는 Web Server + Web Container 로 웹서버 단독으로는 처리할 수 없는 DB 조회나 동적 서비스를 처리하는 기능을 수행하는 서버라고 할 수 있습니다. 주로 사용하는 제품으로는 Tomcat, Websphere, Weblogic 등이 있습니다. 저는 spring 서버에 내장되어있는 톰캣과 web 서버인 nginx를 사용한 스프링 프로젝트를 진행한 경험이 있습니다. (또는 저는 WAS 는 JEUS, WEB은 WebtoB를 사용하여 servlet 프로젝트를 구현한 경험이 있습니다.)

2. WEB 서버와 WAS 의 차이점은 무엇인가요? 왜 WEB, WAS를 모두 사용하는지 설명해 주세요.

단순히 말해 WEB 서버는 정적 서비스를, WAS 서버는 동적 서비스를 처리한다는 점에 차이가 있습니다. WAS의 등장 배경은 단순 정적 서비스에서 CGI, Servlet 으로 복잡해진 Web Application을 처리하기 위함입니다.
WAS는 WEB서버의 기능을 포함하지만, WEB과 WAS를 모두 사용하는 이유는 분산 환경에서의 부하 방지 등의 이점, 보안에서의 이점이 있기 때문입니다. 예를 들어 WEB,WAS 를 다중화하여 구성한 경우, WEB서버를 분리하여 앞단에 배치하는 것이 부하 분산, 세션 관리, 보안 측면에서 유리합니다.

3. ThreadPool 이 무엇인가요? 왜 사용하는지 설명해주세요.

Thread Pool이란 다수의 요청을 동시적으로 처리하기 위해 사용하는 Thread를 제한된 개수만큼 정해 놓고 작업 큐(Queue)에 들어오는 작업들을 하나씩 Thread가 맡아 처리하도록 하는 것입니다. Thread Pool은 Thread를 재사용 함으로써 서버의 부하를 줄일 수 있고, 서비스적인 측면에서 다수의 요청을 더 빠르게 처리할 수 있도록 합니다.

 

 

저작자표시 (새창열림)