[네트워크] 웹서버 vs WAS

TaesunPark·2022년 1월 18일
4

web

목록 보기
1/1
post-thumbnail

안녕하세요~ 이번 주제는 웹 서버와 WAS (Web Application Service)에 대해 알아보겠습니다.

이런 분들이 보면 좋을 거 같아요

  1. 와쓰??? 떠블류에이에스?? 많이 들어봤는데 이게(WAS) 뭐지?
  2. 서버는 들어봤는데 웹 서버?? 웹 서버가 뭐지?
  3. Nginx, Apache를 이용해서 서비스 배포를 하고 싶은데 어떤 식으로 구성을 해야하지?
  4. Tomcat?? 들어봤는데 사용까지 해봤는데 그래서 이게 뭐지?

본론에 들어가기 전에 우리는 컴퓨터를 킨 다음 네이버 웹툰을 보기까지의 과정을 생각해보겠습니다.

우리는 네이버 웹툰을 보기 위해서 웹 브라우저(크롬, 사파리, 익스플로어 등)을 실행하고 네이버에 접속한 후 네이버 웹툰 카테고리를 눌러서 웹툰을 봅니다.

이 과정에서 우리는 당연하게 네이버를 들어간 건데 자세하게 말하자면, 인터넷에 접근하기 위해 브라우저를 실행하고,URL인 https://www.naver.com 을 입력함으로써 네이버(회사)에 네이버 페이지를 주세요 라고 요청을 했고, 네이버 회사에서 운영중인 컴퓨터(서버)에서 여기 네이버 페이지 줄게 하고 제공을 받음으로써 우리는 네이버 페이지를 받아볼 수 있습니다.

조금 더 구체적 살펴 보겠습니다.

우리가 인터넷을 하기 위해 실행한 브라우저는 다음 아래 그림과 같이 동작이 됩니다.

웹 브라우저 동작 원리

[https://poiemaweb.com/js-browser](https://poiemaweb.com/js-browser)
그림 참조 : https://poiemaweb.com/js-browser

잠깐 위키백과에서 웹 브라우저의 사전적 의미를 집고 넘어가겠습니다.

웹 브라우저(web browser)는 웹 서버에서 이동하며(navigate) 쌍방향으로 통신하고 HTML 문서나 파일을 출력하는 그래픽 사용자 인터페이스 기반의 응용 소프트웨어이다.
참고 : https://ko.wikipedia.org/wiki/웹_브라우저

조금 더 구체적으로 살펴본다면 Client인 브라우저 내부 동작이 그림 왼쪽 빨간 영역에 나타나여져 있는데

하나씩 짚고 알아가기엔 너무 글이 길어지니 동작 구조가 간단하지 않다! 라고 알아두고 넘어가겠습니다.

그림의 오른쪽 위 빨간 박스를 보겠습니다. 중요한건 오른쪽에 서버와 쌍방향으로 HTTP 통신을 하고,

브라우저에서 URL을 보내면 서버에서 Index.html 즉 html 문서를 받는 걸 볼 수 있습니다.

아까 웹 브라우저 정의에서 살펴봤듯이 웹 브라우저는 웹 서버와 통신한다. 그러면 서버 구역에 있는 Nginx, IIS가 웹 서버의 역할을 한다고 짐작해볼 수 있습니다.


웹 서버(Web Server)란?

  1. HTTP를 통해 웹 브라우저에서 요청하는 HTML 문서나 오브젝트(이미지 파일 등)을 전송해주는 서비스 프로그램이라고 일반적으로 부르지만, 그 웹 서버 소프트웨어가 동작하는 컴퓨터를 말합니다.
  2. 웹 서버의 가장 중요한 기능은 클라이언트에서 요청을 하면 HTML 문서나 pdf, png 등 정적(static) 컨텐츠를 전달하는 것입니다.
  3. 클라이언트에서 요청이 올 때 맨 앞 단에서 처리를 해줍니다.

웹 서버 종류

웹 서버의 종류로는 Apache, IIS, Nginx 가 있습니다.

아래 그림으로 보면 Apache, Nginx, IIS순으로 2022년 기준 높은 점유율을 차지하는 걸 알 수 있습니다.

IIS는 윈도우 환경에서 사용하는 웹 서버 프로그램입니다. 만약 윈도우 환경이 아니라면 Apache, Nginx를 이용할 수 있습니다. 물론 윈도우 환경에서도 Apache, Nginx를 이용할 수 있습니다.


참조 : https://ko.hostadvice.com/marketshare/server/

잠시 웹 서버로 쓰이는 Nginx 아키텍처를 살펴 보도록 하겠습니다.

Nginx 아키텍처


참조 : http://www.aosabook.org/en/nginx.html

잠깐 웹 서버의 종류인 Nginx 구조를 살펴보겠습니다.

Nginx는 하나의 Master Process와 여러 개의 Worker Process로 구성되어 실행합니다.

Master Process 에서는 설정 파일을 읽고, Worker Process를 관리합니다.

모든 요청은 Worker Process에서 처리하는 데 Worker Process의 개수는 설정 파일에서 정의할 수 있으며 정의된 프로세스 개수와 사용가능한 CPU 코어 숫자에 맞게 자동으로 정의됩니다.

클라이언트와 HTTP 통신을 하는 걸 볼 수 있으며, 캐싱 프로시 기능 또한 사용하는 걸 볼 수 있습니다.

이외에도 nginx은 HTTP 웹 서버 기능 뿐만 아니라 다양한 역할을 수행합니다.

FastCGI는 상호 작용 프로그램을 웹 서버와 통신하기 위한 바이너리 프로토콜이다. FastCGI의 주 목적은 웹 서버와 CGI 프로그램 간 통신 시 발생되는 부하를 줄임으로써 서버가 한 번에 더 많은 웹 페이지 요청을 관리할 수 있게 하는 것이다. - 참조 : https://ko.wikipedia.org/wiki/FastCGI

공용 게이트웨이 인터페이스(영어: Common Gateway Interface; CGI)는 웹 서버 상에서 사용자 프로그램을 동작시키기 위한 조합이다. 존재하는 많은 웹 서버 프로그램은 CGI의 기능을 이용할 수 있다. 참조 : https://ko.wikipedia.org/wiki/공용게이트웨이인터페이스


동적인 컨텐츠가 필요한 상황

웹 서버는 정적인 데이터만 브라우저에 전달하는 역할을 합니다.

만약에 구구단을 출력하는 사이트라고 가정할 때, 웹 서버는 HTML은 프로그래밍 언어가 아니기 때문에

우리가 아는 반복문을 사용할 수 없어 하나 하나 입력해줘야 합니다.

오늘 날 회사를 소개 하는 사이트 처럼 글만 있는 사이트가 아니라면 대부분 동적인 사이트일텐데 웹 서버로는 정적인 데이터만 보낼 수 있으니 WAS를 사용해 동적인 컨텐츠를 제공할 수 있습니다.

WAS란?

  1. Web Aplication Server 의 축약
  2. 동적인 컨텐츠를 제공하기 위해 만들어진 애플리케이션 서버인데 일종의 미들웨어로 클라이언트의 요청 중 웹 애플리케이션이 동작하도록 지원하는 응용 소프트웨어
  3. 웹 어플리케이션을 수행할 수 있는 환경을 제공해 주는 서버


그림 참조 : https://gap85.tistory.com/45

WAS는 일반적으로 Web Server와 Web Container로 구성되어 있습니다.

WAS 자체만으로도 http 통신 처리를 할 수 있는 Web Server가 있습니다.

Web Server에서 동적인 data를 Web Container에 요청을 합니다. 그러면 Web Container에서

서블릿을 통해 요청을 동적으로 처리한 후 HTML에 대한 응답을 구성하고 다시 Web Server에 전달합니다.

Web Server에선 이렇게 동적 작업을 거친 컨텐츠들을 정적인 data로 바꾼 후 다음 client에 전달합니다.

WAS의 종류

WAS의 종류에는 아파치사의 톰켓, 티멕스의 제우스, 레드헷의 JBOSS가 있는 데

사실 같은 WAS라 해도 NGINX와 APACHE 웹서버 차이처럼 구성 요소 라든지, 용량 등

사용하기에 적합한 환경이 다 다릅니다. 하지만 다른 건 못 들어봤어도 Tomcat을 많이 들어봤을 것입니다.

그래서 WAS도 이해하고, Tomcat도 간단하게 이해하기 위해 조금만 깊게 들어가보겠습니다.

JAVA EE(Java Enterprise Edition) 구조


그림 참조 : https://docs.oracle.com/javaee/5/tutorial/doc/bnaay.html

살짝 딥하게 설명할건데 크게 이해하지 않아도 상관 없습니다.

Java Enterpise Edition 플랫폼은 보통 우리가 잘 알고 있는 Java 스텐다드 에디션 플랫폼을 기반으로 그 위에 탑재됩니다. 웹 프로그래밍에 필요한 기능을 다수 포함 JSP, Servlet, JDBC, EJB 등 대규모, 다계층, 확장성, 신뢰성, 보안 네트워킹 API, 환경 등을 제공합니다.

구조를 살펴보자면

위에부터 클라이언트 티어, 웹티어, 비즈니스 티어, EIS 티어 이렇게 나뉘어져 있습니다.

클라이언트 티어는 왼쪽부터 어플리케이션 클라이언트(Swing Application), 그리고 웹 브라우저 등 웹 통신을 할 수 있는 구성으로 나뉘어져 있습니다.

어플리케이션 클라이언트는 우리가 알고 있는 스윙 어플리케이션이고 웹이 아니니까 웹티어를 거칠 필요 없이 바로 데이터베이스 티어로 접근하거나 비즈니스 로직이 필요하면 비즈니스 티어도 거친 다음 요청한 데이터를 받습니다.

그와 다르게 웹 브라우저에서 동적인 컨텐츠를 요청을 하면 Web Tier에서 서블릿을 통해 비즈니스 티어를 거치고, 데이터베이스가 있는 EIS 티어까지 거친다음 다시 비즈니스 티어 웹 티어로 서블릿으로 요청한 동적 컨텐츠를

클라이언트 티어에 전달해줍니다.

Client Tier

클라이언트 계층은 Java EE 서버에 액세스하고 일반적으로 서버와 다른 시스템에 있는 응용 프로그램 클라이언트로 구성됩니다. 클라이언트는 웹 브라우저, 독립 실행형 애플리케이션 또는 기타 서버가 될 수 있으며 Java EE 서버와 다른 시스템에서 실행됩니다.

https://docs.oracle.com/cd/E19226-01/820-7759/gcrla/index.html

Web Tier

웹 계층은 클라이언트와 비즈니스 계층 간의 상호 작용을 처리하는 구성 요소로 구성됩니다. 주요 업무는 다음과 같습니다.

  • 클라이언트를 위해 다양한 형식의 콘텐츠를 동적으로 생성합니다.
  • 클라이언트 인터페이스 사용자로부터 입력을 수집하고 비즈니스 계층의 구성 요소에서 적절한 결과를 반환합니다.
  • 클라이언트에서 화면 또는 페이지의 흐름을 제어합니다.
  • 사용자 세션에 대한 데이터 상태를 유지합니다.
  • 몇 가지 기본 논리를 수행하고 JavaBeans 구성 요소에서 일부 데이터를 임시로 유지합니다.

https://docs.oracle.com/cd/E19226-01/820-7759/gcrnl/index.html

서블릿 : 요청을 동적으로 처리하고 일반적으로 HTML 페이지에 대한 응답을 구성하는 Java 프로그래밍 언어 클래스

Business Tier

비즈니스 계층은 응용 프로그램에 대한 비즈니스 논리를 제공하는 구성 요소로 구성됩니다. 

EIS Tier

데이터베이스 서버, 전사적 자원 관리 시스템 및 메인프레임과 같은 기타 레거시 데이터 소스로 구성됩니다.

JAVA EE 구성도

JAVA EE에서 정의하고 있는 컨테이너들은 다음과 같습니다.

JAVA 엔터프라이즈
에디션에서 정의하고 있는 컨테이너들은 다음과 같습니다.

위에서 설명했던 말했던 웹 티어가 웹 컨테이너고 비즈니스 티어가 EJB 컨테이너 입니다.

아깐 티어로 되어있던 이유는 단지 그냥 영역을 구분하기 위해서 용어를 그렇게 지칭했고 컨테이너는 좀 기술적인 용어라고 생각하시면 됩니다.

엔터프라이즈 자바빈즈(Enterprise JavaBeans; EJB)는 기업환경의 시스템을 구현하기 위한 서버측 컴포넌트 모델이다 - 위키 백과

Tomcat

아파치 톰캣은 아파치 소프트웨어 재단에서 개발한 서블릿 컨테이너만 있는 웹 애플리케이션 서버입니다.

java ee는 web container와 ejb container로 구성되어 있는데, 톰켓은 web container만 구현되어 있습니다.

하지만 다른 WAS인 JBoss는 web container, ejb container 모두 지원합니다. 그렇기에 톰켓은 다른 WAS에 비해 가볍고 Java EE 서버가 필요없는 Spring과 같은 프레임 워크를 사용하는 응용 프로그램에서 많이 사용됩니다.

아파치 공식 문서에 따라 톰켓 정의는 다음과 같습니다.

Apache Tomcat ® 소프트웨어는 Jakarta Servlet , Jakarta Server Pages , Jakarta Expression Language , Jakarta WebSocket , Jakarta Annotations 및 Jakarta 인증 사양의 오픈 소스 구현입니다. 이러한 사양은 Jakarta EE 플랫폼 의 일부입니다. 참조 : https://tomcat.apache.org/ 아파치 공식 문서

웹서버 vs WAS

우리는 웹서버와 WAS를 다 알아봤습니다.

결론적으로 웹서버는 정적인 컨턴츠만 제공할 수 있고, WAS는 정적 + 동적 컨텐츠를 제공할 수 있습니다.

웹서버는 컨테이너가 없지만, WAS는 컨테이너가 존재해서 동적 데이터를 처리할 수 있습니다.

웹서버를 앞 단에 두는 이유

→ Nginx, Apache 등 웹 서버 소프트웨어가 제공하는 기능을 쓰기 위해서 사용합니다.

  1. Web Server에 SSL 적용

    웹 서버 자체적으로 SSL 적용을 할 수 있어 보안 강화를 해줍니다.

  2. 리버스 프록시로 사용 가능

    리버스 프록시를 사용함으로 써 사용자들이 어떤 WAS에서 제공하는 지 알 수 없습니다.

  3. 로드 밸런서 이용 가능

    로드 밸런싱을 통해 여러 대의 WAS를 연결할 수 있고, 두 대의 WAS가 동작하고 있다 가정할 때 서비스에

    오류가 생겨도 하나의 WAS를 중단시켜도 하나의 WAS가 돌아가기에 무뭉단 서비스 배포를 할 수 있습니다.

  4. 캐싱 서버 이용 가능

    캐싱 서버로 이용함으로 써 사용자가 이전에 받아본 이미지 등을 DB를 거치지 않고 받아볼 수 있습니다.

즉, 초반에 Nginx 아키텍처를 설명할 때 그 관련 기능들을 모두 사용할 수 있습니다.

물론 이런 4가지 말고도 당연히 더 있습니다.

클라이언트 - 웹서버 - WAS -DB 아키텍처

그럼 어떻게 서비스를 구성할까?

클라이언트는 웹서버와 통신하고 웹 서버는 요청에 따라 각 WAS에 보내고 WAS에선 다시 로직을 수행한 후 Web Server를 통해 클라이언트에 요청한 컨텐츠를 전달합니다.

만약 사용자가 apitest1234.co.kr:80 포트로 접근하면 80포트에서 실행하고 있는 Nginx에 접근을 합니다. 그럼 여기 Nginx에서는 정적인 문서만 제공해줍니다.

Tmi로 그럼 우리는 리엑트로 작업한 결과물을 nginx에서 설정해줌으로써 받아볼 수 있습니다.

api 요청이 spring/login 이면, nginx에서 8000번 포트에 있는 스프링 애플리케이션에 포트 포워딩을 함으로 써 로직이 8000포트에 실행되고 있는 Spring 애플리케이션이 동작하는 걸 볼 수 있습니다.


만약 사용자가 apitest1234.co.kr:8000 포트로 접근하면 Nginx를 안거치고 8000번 포트에 실행중인 WAS에 접근하는 데 접근이 불가합니다. 왜냐면 앞 단 웹서버 Nginx에서 방화벽 처리가 되기에 접근이 불가합니다.


참조

웹서버 특징 : https://www.boostcourse.org/web316/lecture/16665?isDesc=false

Nginx 구조 : https://icarus8050.tistory.com/57

Java EE : https://docs.oracle.com/javaee/5/tutorial/doc/bnaay.html

Java EE, Tomcat : https://bankienkate.tistory.com/?page=2

Tomcat, Jboss 차이점 : https://soye0n.tistory.com/64

WAS 구조 : https://gap85.tistory.com/45

웹서버vsWAS: https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html

0개의 댓글

관련 채용 정보