[Spring] WS/WAS

 

WS (Web Server)

정적인 처리를 제공하는 서버로 HTML, CSS ,JS, JPG와 같은 작업을 처리합니다.
정적인 작업은 WAS로 넘기지 않고, 바로 처리해버립니다.
동적 요청이 많을경우 WS 자체의 Load Balancing을 통하여 다수의 WAS에 정해진 규칙에따라 요청을 배분합니다.
서버의 Proxy 역할을 수행하여 WAS자체의 ip를 외부에 노출시키지않습니다.
또한 helath check를 통하여 WAS의 통신상태도 점검할 수 있습니다.
ex) apache, nginx..

 

 

WAS (Web Application Server)

동적인 처리를 제공하는 서버로 동적 처리를 통해 WS에 정적인 정보를 제공합니다.
일반적으로 WS의 기능도 포함하고있어 웹 서버 없이도 서비스가 가능합니다.
DB와 연결되어있어 DB에 관련된 일을 처리합니다.
ex) tomcat, jetty..

 

 

 

WS 와 WAS를 분리하는 이유

 

서버로 오는 모든 요청을 WAS가 처리한다면 WAS의 부담이 클것입니다. 그렇기에 동적인 요청은 WS가 처리하여 부담을 줄여줍니다.
앞에서 설명한것과 같이 WS는 Proxy역할을 수행합니다. 따라서 외부에 환경설정 파일이나 ip등을 노출하지 않아 보안에 좋습니다.
Load Balancing, Health check와 같은 작업을 수행할 수 있습니다. 때에 따라서 특정 WAS가 제 기능을 못하는 상황일때 다른 WAS로 요청을 보내는 작업도 할 수 있습니다.

 

 

 

Load Balancing

정의는 서버에 가해지는 부하를 분산해주는 장치 또는 기술입니다.
일반적으로 클라이언트와 서버 풀 사이에 위치하며, 한대의 서버로 부하가 집중되지 않도록 트래픽을 관리합니다.
Load Balancing에는 L4 와 L7이 많이 사용됩니다. L4는 Transport Layer를 의미하고, L7은 Application Layer를 의미합니다.
L4는 ip, port를 기준으로 스케줄링 알고리즘을 적용합니다. 
L7은 ip, port, URI, Payload, Http Header, Cookie등의 내용을 기준으로 부하분산을합니다.
각각의 Layer의 어떤 기준으로 부하분산하는것도 중요하지만 어떤 스케줄링 알고리즘을 적용하는 것 또한 중요한 문제입니다.

 

 

 

Load Balancing Scheduling Algorithm

 

Round Robin : 클라이언트로부터 받은 요청을 순서대로 할당하는 방식입니다. Load Balancing 대상 서버의 성능이 동일하고 처리시간이 짧은 어플리케이션의 경우, 균등하게 분산이 이루어지는 특징을가지고 있습니다.

 

Weight Round Robin : 실제 서버에 서로 다른 처리 용량을 지정할 수 있습니다. 각 서버에 가중치를 부여하여 분산을 적용합니다.

 

Minmum Connecting : 연결 수가 가장 적은 서버에 네트워크 연결방향을 정합니다. 동적인 분산알고리즘으로 각 서버에 대한 현재 연결수를 동적으로 알 수 있고, 동적으로 변하는 요청에 대한 부하를 분산시킬 수 있습니다.

 

 

 

Apache

Apache는 Thread, process 기반 구조입니다.
클라이언트 요청하나당 하나의 스레드가 처리하는 구조입니다. 따라서 처리해야 할 요청이 많다면 메모리 및 cpu 낭비가 심합니다.
PreFork MPM : 하나의 요청에 대해 Process를 하나 생성하여 처리합니다. 따라서 Single cpu, Dual cpu에서 성능이 좋습니다. 하지만 요청이 많다면 부담을 많이 느끼는 방식입니다.
Worker MPM : 하나의 요청에 대해 Thread를 하나 생성하여 처리합니다. Multi cpu일때 성능이 좋고, PreFork MPM보다 메모리 사용량이 적으며 일반적으로 동시 접속자가 많은 사이트에 적합합니다.

 

 

Nginx

Event-Driven 구조의 웹 서버입니다.
고정된 몇개의 프로세스만 생성하고, 여러 개의 Connection을 모두 Event-Handler를 통해 비동기 방식으로 처리합니다.
적은 양의 스레드만 사용되기 때문에 Context Swiching 비용이 적고, CPU 소모가 적습니다.
CPU와 관계없이 모든 I/O들을 전부 Event Listener로 미루기 때문에 흐름이 끊기지 않고 응답이 빠르게 진행되어 1개의 프로세스로 더 빠른 작업이 가능합니다.
리버스 프록시로 배치 가능합니다.

 

 

Apache vs Nginx

 

우선 결과론 적인 이야기를 하자면 이전까진 Apache가 정말 많이 쓰였지만, 이젠 Nginx가 Apache의 사용량을 넘었습니다.
C10K 문제로 이야기가 갈릴것 같습니다. C10K 문제란 한 시스템에 동시 접속자 수가 1만명이 넘어갈 때 효율적 방안에대한 문제입니다.
스마트폰이 생기며 인터넷 사용량이 급격하게 늘어났고, Process-Thread 방식으로 버티던 Apache는 C10K문제를 넘어서지 못했습니다.
그렇다고해서 무조건 Nginx가 좋다는 이야기는 아닙니다.
Apache는 서버의 Process가 blocking이 되면 요청을 처리하지 못하고 처리가 완료될 때까지 기다립니다. Keep-alive를 이용해 해결이 가능하지만 Keep-alive 때문에 대량 접속 시 효율이 떨어집니다.
Nginx는 동적 컨텐츠를 기본적으로 처리할 수 없습니다. 외부 프로세서로 전달하고 렌더링 된 컨텐츠를 다시 전송할 때 까지 기다려야 합니다.
또한 Apache에 비해 다양한 모듈이 없습니다.
따라서 유연하게 위의 특성을 잘 파악해 WS를 골라서 사용하면 될것 같습니다.