이 둘의 개념과 차이를 알아보기 이전에 Static pages, Dynamic pages에 대해 알아볼 필요가 있다.
Static pages
- image, html, css, javascript 파일과 같이 컴퓨터에 저장되어 있는 파일들을 의미한다.
- 웹 서버에서 요청에 알맞은 파일을 반환하며, 항상 동일한 페이지를 반환한다. (말 그대로 정적인 컨텐츠)
- 웹 서버에서 제공한다.
Dynamic pages
- 들어온 요청에 맞게 동적으로 만들어진 컨텐츠를 의미한다.
- 데이터베이스, 서버 내 로직 등을 활용해 만들어진 컨텐츠를 반환한다.
- 웹 어플리케이션 서버에서 제공한다.
Web Server 웹 서버
HTTP 요청을 받아 Static contents를 제공하는 서버, 프로그램
- HTTP 프로토콜을 기반으로 하여 클라이언트의 요청을 서비스하는 기능을 담당
(Ex. Apache Server, Nignx, ...)
기능 1: 정적인 컨텐츠 제공
- 주로 웹 브라우저에서의 하이퍼텍스트 전송 프로토콜(HTTP) 요청에 응답하여 WAS를 거치지 않고, 바로 요청한 컨텐츠를 제공할 수 있다.
기능 2: 동적인 컨텐츠 제공을 위한 요청 전달
- 요청을 WAS에 보내고, WAS가 처리한 결과를 클라이언트에게 전달한다.
- WAS (Web Application Server) 웹 어플리케이션 서버
- 다양한 서버 내 알고리즘, 비즈니스 로직, DB 조회 등 클라이언트 요청에 따라 동적인 컨텐츠를 제공하는 서버, 프로그램
- HTTP 프로토콜을 기반으로 하여 클라이언트의 요청에 따라 구현된 비즈니스 로직을 통해 동적으로 만들어진 컨텐츠를 반환
(Ex. Tomcat, JBoss, Jeus, ...)
- 데이터베이스 접속 기능, 여러 개의 트랜잭션 관리 등 수행
사실 의미가 조금 다양하다. WAS = Web server + Web container라는 곳도 있고, WAS = Web server와 APP 간의 미들웨어라고 하는 곳도 있고, WAS = WAS + APP 라고 해서 한번에 모든 기능을 한다고 말하는 곳도 있다. 대부분의 경우, Web server + Web container 설명하고 있으니 그렇게 이해하자.
컨테이너(Container) 는 무엇인가?
- 웹 서버가 보낸 JSP, PHP, ASP.net 등의 파일들을 실행하고 수행결과를 다시 웹 서버로 보내주는 역할을 한다.
결국, 웹 어플리케이션 서버는 웹 서버에서 요청을 받고, 이를 웹 컨테이너로 보내 로직(알고리즘, DB 연결 등)을 수행하고 그 결과를 다시 웹 서버로 보내 최종적으로 클라이언트에게 보내주는 것이다.
WAS가 Web Server의 모든 기능을 수행하면 되는 것 아닌가? Web Server는 왜 사용하는가?
기능을 분리하여 서버 부하를 방지한다.
- WAS는 DB 조회, 다양한 로직을 수행하기라 바쁘기 때문에 단순한 정적 컨텐츠는 Web Server에서 빠르게 클라이언트한테 제공하는 것이 좋다.
- 정적 컨텐츠 요청까지 WAS에서 수행하게 되면 부하가 커지게 되고, 동적 컨텐츠 처리가 지연됨에 따라 수행속도가 느려진다.
물리적으로 분리하여 보안을 강화시킨다.
- SSL 대한 암복호화 처리에 Web Server를 사용
여러 대의 WAS를 연결해 로드 밸런싱 용도로 사용할 수 있다.
- Fail over, Fail back 처리에 유리하다.
- 대용량 웹 어플리케이션의 경우, Web Server와 WAS를 분리하여 오류가 발생한 WAS를 사용하지 않고, 다른 WAS를 사용하게 만듦으로써 무중단 운영을 가능하게 한다.
여러 언어의 웹 어플리케이션 서비스가 가능하다.
- 하나의 서버에서 PHP Application, Java Application를 함께 사용하는 등과 같이 여러 웹 어플리케이션의 활용이 가능해진다.
- 톰캣은 Java언어만 해석이 가능하다. JSP 같은 경우, 처리가 가능하지만 PHP는 실행이 불가능하다. 고로, Web server로 아파치를 사용해 PHP를 사용할 수 있게 만들 수 있다.
https://www.ibm.com/kr-ko/cloud/learn/web-server-vs-application-server
에서확인한 내용으로는 웹 브라우저가 애플리케이션 클라이언트로 선택되게 되고 웹 애플리케이션과 웹 애플리케이션 성능에 대한 사용자의 기대치가 점점 커지면서, 사실상 웹 서버와 애플리케이션 서버 간의 구분선은 더욱 모호해졌습니다.
성능과 안정성을 높이고 개발자가 인프라보다는 코딩에 보다 집중할 수 있도록 해주는 서비스인 리버스 프록시, 클러스터링, 이중화 및 로드 밸런싱 등의 서비스를 활용할 수 있습니다.
다수의 웹 서버와 일부 애플리케이션 서버가 웹 애플리케이션 서버라고 불리거나 자신을 이런 이름으로 부른다는 사실은 상황을 더 혼란스럽게 만들고 있습니다.
결과적으로, 오늘날의 가장 인기 있는 웹 서버와 애플리케이션 서버는 둘의 하이브리드라는 것입니다. 오늘날 사용되는 점점 더 풍부해지는 대부분의 애플리케이션은 웹 서버와 애플리케이션 서버 기술을 결합하여 제공되는 정적 웹 콘텐츠와 동적 애플리케이션 콘텐츠의 결합을 주요 특성으로 제시합니다.
로드밸런싱이란?
https://www.ibm.com/cloud/learn/load-balancing
1. 트래픽을 고르게 분산 하여 특정 리소스의 과부하로 인한 오류를 방지할 수 있습니다
2. 잠재적으로 혼란스러운 상황에 질서를 가져오는 "교통 경찰" 역할을 합니다. 애플리케이션 및 가상 인프라와 같은 특정 환경에서 로드 밸런싱은 가용성을 보장하고 가동 중지 시간을 유발할 수 있는 문제를 방지하기 위해 상태 검사도 수행합니다. 로드 밸런싱은 관리하기 쉬운 서버 그룹 전체에 중앙 집중식 보안을 제공할 수도 있습니다.
결론 및 요약
정적인 데이터는 웹서버가 잘하고 동적인 데이터는 앱서버가 잘처리하니 두개를 혼용해서 쓰자.
사용자가 많이 몰려서 서버가 터져 개발자들이 힘들 수 있으니 리버스 프록시, 클러스터링, 이중화 및 로드 밸런싱같은 서비스를 잘 사용하자
출처.
https://www.ibm.com/kr-ko/cloud/learn/web-server-vs-application-server
'서버관련' 카테고리의 다른 글
| HTTP와 IP 그리고 [TCP,UDP]의 원리 및 차이점, QUID 짤막 (0) | 2022.04.26 |
|---|---|
| 서버 구축순서(token, oauth) (0) | 2022.04.23 |
| 지정된 Origin의 중요성과 사전요청/Content-type에 대해(CORS도있음) (0) | 2022.04.06 |
| REST API (0) | 2022.03.31 |
| HTTP 메세지 (0) | 2022.03.30 |