WAS와 웹서버 차이
Web Server란? 🧐
웹 서버는 클라이언트(사용자)가 브라우저 주소창에 url을 입력하여 어떤 페이지를 요청하면, http 요청을 받아들여 HTML 문서와 같은 정적인 콘텐츠를 사용자에게 전달해주는 역할을 한다.
웹 서버의 대표적인 임무로는 2가지가 있다.
- 단순히 저장된 웹 리소스들을 클라이언트로 전달하고, 클라이언트로부터 콘텐츠를 전달받아 저장하거나 처리한다.
- 사용자로부터 동적인 요청이 들어왔을 때, 해당 요청을 웹 서버 자체적으로 처리하기 어렵기 때문에 WAS에게 요청한다.
- 대표적인 웹 서버의 종류 : Apache, Ngnix
Nginx 설정 파일로 알아보는 Web Server(Nginx) 주요 기능 🤠
Reverse Proxy(리버스 프록시)
- 클라이언트 요청을 백엔드 서버로 전달하고 응답을 반환하는 기능
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
server {
// ngnix 포트설정
listen 80;
// 서버 이름 또는 도메인 설정
server_name example.com;
location / {
// 클라이언트 요청을 백엔드 서버로 전달
proxy_pass http://backend_server;
// 클라이언트가 요청한 Host 헤더 백엔드 서버로 전달
proxy_set_header Host $host;
// 클라이언트의 실제 IP 백엔드 서버 전달
proxy_set_header X-Real-IP $remote_addr;
// 리버스 프록시를 거쳐온 요청인지, 거쳐왔다면 어떤 프록시 거쳐왔는지 정보 백엔드 서버 전달
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Load Balancing(로드 밸런싱)
- 여러 서버로 트래픽을 분산하여 부하를 줄이는 기능
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 여러대의 백엔드 서버를 하나로 묶어서 하나의 그룹으로 관리
upstream backend {
server backend1.example.com;
server backend2.example.com;
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend;
}
}
Static File Hosting(정적 파일 서비스)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
server {
listen 80;
server_name example.com;
location / {
// 웹 사이트 파일이 저장된 루트 디렉토리 설정
// 클라이언트가 요청한 파일은 var/www/html 디렉토리에서 찾는다
root /var/www/html;
// 기본 파일 이름 설정
index index.html;
}
}
클라이언트가 example.com으로 접속하면
Nginx는 /var/www/html/index.html 파일을 찾아서 클라이언트에게 제공
Gzip 압축
1
2
3
4
5
6
7
server {
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
}
Gzip 압축을 사용하면 웹 서벙에서 클라이언트로 전송되는 파일의 크기를 줄여
네트워크 대역폭을 절약하고 로딩 시간 단축된다.
SSL/TLS 설정(HTTPS 지원)
- Let’s Encrypt 같은 인증서를 적용하여 HTTPS 활성화
1
2
3
4
5
6
7
8
9
10
11
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location / {
proxy_pass http://backend;
}
}
Access Control (접근제어)
- 특정 IP만 접근 허용 또는 차단
1
2
3
4
5
6
7
8
server {
location /admin {
// 허용 IP
allow 192.168.1.100;
// 다른 모든 IP 차단
deny all;
}
}
Rate Limiting(속도 제한)
- 트래픽을 제한하여 Dos 공격 방지
1
2
3
4
5
6
7
8
9
10
11
12
http {
// 초당 1 요청 허용
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
server {
location / {
// 최대 5개까지 대기 가능
limit_req zone=one burst=5;
}
}
}
WAS란?
WAS 또한 웹 서버와 동일하게 HTTP 기반으로 동작하고, 웹 서버가 할 수 있는 기능 대부분이 WAS에서도 처리가 가능하며, 비즈니스 로직(서버 사이드 코드)을 처리할 수 있어서 사용자에게 동적인 콘텐츠를 전달할 수 있다. 주로 데이터베이스 서버와 같이 수행되게 된다.
WAS = WAS + WebContatiner
위에 사진을 보면 WAS = Web Server + Web Container라고 볼 수 있는데, 그럼 정확히 Web Container가 뭘까?
웹 컨테이너
- 웹 컨테이너는 Servlet, JSP, WebSocket등의 웹 애플리케이션을 실행하고 관리하는 환경을 제공하는 컴포넌트
- 클라이언트 요청을 받아서 서블릿이나 JSP가 실행되도록 하고, 결과를 클라이언트에게 반환하는 역할을 한다.
- 톰캣, 제티 등이 있다.
웹 컨테이너 주요 기능
- HTTP 요청 및 응답 처리
클라이언트가 HTTP 요청을 보매녀 웹 컨테이너가 이를 받아 적절한 서블릿이나 JSP로 전달하고 결과를 응답으로 반환
1 2 3 4 5 6 7 8 9
@WebServlet("/hello") public class HelloServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println("<h1>Hello, Web Container!</h1>"); } }
/hello경로로 요청이 오면, 웹컨테이너가 이 서블릿을 실행해 응답을 반환자바로 작성하였는데, 웹 컨테이너에서
/hello요청을 어떻게 알고 서블릿을 실행한다는거지? 매핑 정보가 있나?
→ WAS를 시작하게 되면, WAS안에 있는 웹컨테이너가 초기화되고, 이때 웹 컨테이너는 서블릿 클래스를 스캔하여 필요한 서블릿을 서블릿 컨텍스트에 등록한다. 위의 코드를 예시로 들자면, 웹 컨테이너는 HelloServlet 서블릿 객체를 생성하고, 이를 서블릿 컨텍스트에 저장. 이 때 URL 매핑 정보도 함께 저장! (Spring에서 HandlerMapping 생각하면 될듯?)
- 서블릿 라이프사이클 관리
- 웹 컨테이너는 서블릿을 생성하고, 요청을 처리하고, 종료하는 라이프사이클을 자동으로 관리한다.
- 세션 및 쿠키 관리
- 웹 컨테이너는 사용자의 로그인 상태를 유지하기 위해 세션과 쿠키를 관리
그럼 스프링에서 사용하던 세션 및 쿠키가 웹 컨테이너에서 전달받아서 사용할 수 있었던거였나?
→ 세션과 쿠키는 웹 컨테이너가 생성하고, 이를 스프링이 전달받는거 였구나!!
- 웹 컨테이너는 사용자의 로그인 상태를 유지하기 위해 세션과 쿠키를 관리
- JSP 실행 및 변환
- 웹 컨테이너는 JSP 파일을 서블릿으로 변환하여 실행할 수 있다.
- JSP는 실행될 때 내부적으로 서블릿으로 변환된 후 웹 컨테이너에서 실행
아 그럼 스프링에서는 뷰 리졸버를 거쳤다가 경로만 웹 컨테이너에 넘기는건가?
- 스프링이 경로를 웹 컨테이너에 넘김
- 웹 컨테이너는 JSP 파일을 서블릿으로 변환하고 실행하여 동적인 HTML 생성해 응답
- 이 결과가 클라이언트에 표시
- 필터와 리스너 관리
그럼 필터는 웹 컨테이너가 직접적으로 사용을 할까? 굳이 서블릿을 만들 필요가 없이 독립적으로 실행될거같은데 어떻게 되는걸까?
또한, 웹 컨테이너가 초기화될 때 스프링에서 작성한 정보를 읽어서 생성하는 건가?- 필터는 웹 컨테이너가 직접적으로 사용을 하고, 서블릿을 만들지 않고도 요청과 응답을 처리할 수 있다.
- 스프링에서 필터를 설정하는 방법은 2가지가 있다.
- web.xml에 명시 (웹 컨테이너가 초기화 할때 해당 정보를 읽고, 필터를 생성한다.)
- FilterRegistrationBean을 사용한 등록
- 필터는 웹 컨테이너가 직접적으로 사용을 하고, 서블릿을 만들지 않고도 요청과 응답을 처리할 수 있다.
이제 웹 컨테이너에 대해서 알았으니 다시 WAS를 봐보자!
WAS는 웹서버와 웹 컨테이너로 이루어져있고, WAS 내부의 웹 서버도 일반 웹 서버가 할 수 있는 일들을 할 수 있다고 한다.
그럼 굳이 왜 웹 서버를 사용해야 할까?
효율적 사용
만약 WAS가 정적 콘텐츠 요청까지 처리하게 된다면, 부하가 커지고 동적 콘텐츠 처리가 지연되면서 수행 속도가 느려진다. 이에 따라 페이지 노출 시간이 늘어나느 문제가 발생하여 효율성이 크게 떨어진다. 
위 그림과 같이 웹 서버를 앞단에 두고, WAS는 웹 서버가 처리하기 힘든 서버 사이드 코드의 로직 등을 수행하여 웹 서버와 함께 사용자에게 양질의 콘텐츠를 제공할 수 있다.
장애 극복 기능
사람들이 많이 접속하는 대용량 WAS의 경우, 서버의 수가 여러 대일 수도 있다. 만약 사용 중 WAS에서 문제가 생겨 WAS를 재시작해야 하는 경우가 생긴다면 이 때 앞단의 웹 서버에서 WAS를 사용하지 못하도록 요청을 차단한다. 그 다음 WAS를 재시작한다면, 사용자들은 WAS에 문제가 발생한지 모르고 이용할 수 있다.
이를 장애 극복 기능이라고 한다. 즉 규모가 커질수록 웹 서버와 웹앱 서버를 분리하는 것이다.
웹 서버만으로도 동적 처리가 가능한 경우도 있다.
PHP, Phython의 경우 WAS없이 아파치나 nginx를 통해서 동적인 요청 처리가 가능하다.
그게 가능한 이유는 CGI인데 이걸 웹 서버에 별도로 설정해주어야 한다. CGI는 인터페이스로서, 웹 서버상에서 프로그램을 동작시키기 위한 방법을 정의한 프로그램(또는 스크립트)이다.
웹 서버는 클라이언트의 요청을 받아 CGI 스크립트 실행하고 웹 서버는 단지 요청을 전달하고 응답을 반환하는 역할만 하며, 실제 로직은 CGI 스크립트에서 처리한다.
CGI 스크립트는 웹 서버와 별도로 독립적인 프로세스로 실행된다.