WAS에 독립된 Web Server를 두는 이유 / 리버스 프록시

 

 

 

WAS에 독립된 Web Server를 두는 이유

WAS에서도 정적 자원을 처리할 수 있음에도, 아래와 같이 web server를 was 전면에 두는 꼴의 서버 구조가 보편적인 이유가 궁금했다.

 

왜 WAS와 독립된 Web server를 따로 두는 걸까. 그 이유를 정리해보았다.

 

 

 

 

 

 

1. 캐싱과 역할 분담 :: 정적 요청은 WAS까지 안가도 되잖아?

WAS는 바쁘다. 요청을 처리해야하고, DB 서버가 분리되어 있다면 DB 서버와 통신도 해야할 것이다. 

 

정적 자원 요청을 전면 web server에서 빠르게 처리해주면 WAS에 부담이 줄 것이다. 

 

 

 

 

이때 서버에 따라  캐싱을 사용할 수 있을 것이다. (예를 들면 NginX는 정적 컨텐츠의 캐싱을 지원한다.)

 

 

요즘의 웹 페이지는 모두 동적이지, 정적인 컨텐츠가 있다면 얼마나 있을까를 고민하는가? 

 

조금만 더 고민해보면 동적인 페이지 속에 얼마나 많은 정적인 컨텐츠가 숨어있는지 알 수 있다. 동적으로 만들어진 페이지 안에서도 이미지, PDF 파일, CSS, JS 파일, 심지어 애초에 정적인 html 문서를 사용하는 경우도 상당하다.

 

이것들을 WAS에서 처리하는 것이 아니라, WAS에 도달 전, web server를 이용하는 것만으로도 상당히 많은 부하를 줄일 수 있다.

 

 

2-1. 로드 밸런싱 :: 여러 대의 WAS로 부하 나누기

만약 web server 없이 한 대의 WAS로만 요청을 처리한다면 많은 요청이 동시에 몰렸을 경우 어떻게 될까. 하드웨어의 한계를 넘어버려 서버가 다운될 것이다.

 

 

 

 

web server를 이용하고 여러 WAS를 사용하는 것으로 이런 부하를 분산할 수 있다. 아래 그림처럼 두 개의 WAS를 두는 것만으로도 사용자 요청을 한 개의 WAS에서 모두 처리하지 않아도 돼 부담을 줄일 수 있다.

 

 

 

이렇게 서버에 가해지는 부하를 분산하는 기술을 로드 밸런싱이라고 한다. 그렇다면 어떤 방식으로 부하를 분산하는 게 좋을지에 대한 고민으로 이어져야한다.

 

대표적으로는 OSI7 계층의 4레벨(Transport), 7레벨(Application)을 이용하는 방식이 있다. 이름으로도 충분히 분산 기준을 유추할 수 있으므로, 자세한 방식은 생략한다. 

 

 

 

2-2. 로드밸런싱 :: Health check

이렇게 WAS를 여러 대로 나누면 서버의 상태에 따른 대응도 가능하다. 

 

예를 들어 web server에서 각 WAS의 상태를 확인하여, 서버의 처리 불가 상황이라면 해당 WAS에게 요청을 넘기지 않고 다른 서버로 처리할 수 있도록 하여 사용자에게는 서버의 문제에 상관없이 정상적인 응답을 받을 수 있도록 한다.

 

그리고 역시 WAS의 상태를 체크하여 해당 서버가 복구되면 다시 요청을 처리할 수 있도록 넘기는 것이다.

 

 

3. 리버스 프록시 :: 요청을 대신 처리한다.  (설정을 전면에서 처리한다)

전면 web server를 둬 리버스 프록시를 사용할 수 있다. 요청을 WAS가 직접 처리하는 것이 아닌 전면의 프록시 서버에서 대신 처리한다. 

 

TLS나 HTTPS와 같은 설정을 프록시 서버에서 맡도록하고, WAS가 요청을 처리하는 비즈니스 로직에 집중할 수 있도록 한다. 동시에 클라이언트로 하여금 요청이 어떤 내부 서버에서 처리되는지 감출 수 있다.

 

WAS를 숨기기보다는, 'WAS가 비즈니스 로직에 집중할 수 있도록 한다.'에 더 초점을 뒀으면 좋겠다.

 

 

4. 확장성 :: 스케일 아웃과 다양한 WAS

마지막으로 확장에 유연한 설계를 만들 수 있다. 아래 그림처럼 WAS의 종류를 다양하게 할 수 있고 또는 스케일 아웃이 가능해진다. 스케일 아웃은 트래픽이 증가하는 경우 비슷한 사양의 WAS를 추가하는 것으로 전체 처리 성능을 향상시키는 것을 의미한다.

 

 

 

 

더 나아가면..

1. 리버스 프록시와 포워드 프록시

 

리버스 프록시는 이름대로, 평소 알고 있는 프록시와 반대의 역할을 한다. 흔히 알고 있는 (포워드)프록시는 서버로부터 클라이언트의 정보를 숨기는 역할을 했다면, 리버스 프록시는 반대로 클라이언트로부터 내부 서버의 정보를 숨기는 것이다.

 

2. SSL과 TLS

 

Secure Socket Layer (SSL)은 데이터를 안전하게 전송하기 위한 인터넷 통신 규약 프로토콜이다. 

 

Transport Layer Security (TLS)는 SSL의 결함을 보완하며 등장한 프로토콜로, 어플리케이션들이 네트워크 상에서 안전하게 통신하기 위해 사용된다. 이메일, 웹 브라우징, 메세징, 그리고 다른 프로토코들의 감청을 통한 정보의 변형을 방지한다.

 

3. HTTP와 HTTPS

 

 HTTP 통신이 SSL(TLS) Layer 위에서 이루어 지는 것을 HTTPS라고 한다.