웹 애플리케이션 서버

웹 서버 vs 웹 애플리케이션 서버

웹 서버

  • HTTP 기반으로 동작

  • 정적 리소스 제공, 기타 부가기능

    • 로드밸런싱: 여러 인스턴스를 띄울 때 부하를 적절히 분배할 수 있다.

    • 보안: 서버의 포트 등과 같은 정보를 클라이언트로부터 숨길 수 있다.

    • 고가용성: 여러 인스턴스 중 하나에서 장애가 발생한 경우 다른 인스턴스로 요청을 보내 처리할 수 있다.

    • 중앙화된 인증: 인증 관리를 웹 서버 한 곳에서 수행할 수 있다.

  • 정적(파일) HTML, CSS, JS, 이미지, 영상

  • 리버스 프록시: 클라이언트의 요청을 대신 받아 웹 애플리케이션 서버에 넘겨주는 방식

  • ex) NGINX, APACHE HTTP Server

웹 애플리케이션 서버(WAS)

  • HTTP 기반으로 동작

  • 웹 서버 기능 포함 → 정적 리소스 제공 가능

  • 프로그램 코드를 실행해서 애플리케이션 로직 수행하는 데에 특화되어 있음

  • 동적 HTML, HTTP API(JSON)

  • 서블릿, JSP, 스프링 MVC

  • ex) 톰캣(Tomcat) Jetty, Undertow

웹 시스템 구성

  • 웹 시스템은 WAS, DB만을 사용해 구성할 수 있다.

  • 하지만 WAS가 너무 많은 역할을 담당할 경우 서버 과부하로 다운될 수 있다.

    • 가장 비용이 비싼 로직이 정적 리소스를 제공하는 리소스 사용때문에 수행되지 못할 수 있다.

  • WAS 단독 구성 시 오류 화면도 노출이 불가능하다

  • 따라서 웹 서버를 두어 정적 리소스(바뀌지 않는 메인 페이지, 오류 화면 등)만 처리하도록 하고, 동적인 처리가 필요하면 WAS에 요청을 위임한다.

  • 정적 리소스가 많이 사용되면 웹서버를 증설하고, 애플리케이션 리소스가 많이 사용되면 WAS를 증설할 수 있다.

서블릿

  • 서블릿은 위 그림에서 비즈니스 로직 실행을 제외한 모든 것을 담당해준다!

  • 이로 인해 서블릿을 지원하는 WAS를 사용하면 비즈니스 로직에만 집중할 수 있다.

  1. WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체 호출

  2. 개발자는 Request 객체에서 HTTP 요청 정보를 편리하게 꺼내서 사용

  3. 개발자는 Response 객체에 HTTP 응답 정보를 편리하게 입력

  4. WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성

서블릿 컨테이너

  • 서블릿을 지원하는 WAS

  • WAS는 서블릿 생성, 초기화, 호출, 종료하는 서블릿의 생명주기 관리하는 역할을 한다.

  • 서블릿 객체는 싱글톤으로 관리되므로 공유 변수 사용에 주의해야 한다.

  • JSP도 서블릿으로 변환되어 사용한다.

  • 동시 요청을 위한 멀티 쓰레드 처리 지원

동시 요청 처리

스레드

  • 애플리케이션 코드를 하나하나 순차적으로 실행하는 것

  • 자바 메인 메서드를 처음 실행하면 main이라는 이름의 쓰레드가 실행

  • 쓰레드가 없다면 자바 애플리케이션 실행이 불가능

  • 쓰레드는 한번에 하나의 코드 라인만 수행

  • 동시 처리가 필요하면 쓰레드를 추가로 생성

스레드 풀

  • 동시에 여러 요청이 들어올 때마다 스레드를 생성해 사용하는 것은 비용도 크고, 느리고, 한계를 넘어가면 서버가 다운될 수 있다.

  • 따라서 필요한 스레드만 스레드 풀에 보관하고 관리한다.

  • 스레드 풀에 생성 가능한 쓰레드의 최대치를 관리한다. (톰캣 기본: 200개)

  • 스레드가 필요하면, 이미 생성되어 있는 쓰레드를 쓰레드 풀에서 꺼내서 사용한다.

  • 만약 모든 스레드가 사용중이라면 기다리거나, 지정해둔 대기 요청량 개수가 넘어가면 실패한다.

  • 스레드가 미리 생성되어있어 생성/종료 비용이 절약되고 응답시간이 빠르다.

  • 너무 많은 요청이 들어와도 서버가 다운되지 않는다.

스레드 수 튜닝

  • WAS의 주요 튜닝 포인트는 최대 쓰레드(max thread) 수이다.

  • 너무 낮게 설정할 경우, 동시 요청이 많으면 서버 리소스는 여유롭지만 클라이언트는 금방 응답 지연 (대기하거나 거절되는 요청이 많아짐)

  • 너무 높게 설정할 경우, 동시 요청이 많으면 CPU, 메모리 리소스 임계점 초과로 서버가 다운될 수 있다.

  • 장애가 발생했다면 클라우드면 일단 서버부터 늘리고, 이후에 튜닝한다. 만약 클라우드가 아니라면 튜닝을 해서 손봐야 한다.

  • 적정 쓰레드풀 수 찾기

    • 애플리케이션 로직의 복잡도, CPU, 메모리, IO 리소스 상황에 따라 모두 다르므로 성능 테스트를 해봐야 한다.

    • 최대한 실제 서비스와 유사하게 성능 테스트 툴(Apache ab, JMeter, nGrinder) 을 사용해야 한다. 싱글톤 객체 (서블릿, 스프링 빈)은 주의해서 사용해야 한다.

Last updated