[Network] Apachi, Nginx, Tomcat 이 하는일이 뭘까? (Feat. Proxy)

# 대충 개념 잡기

Apachi, NginX 은 프록시서버(웹서버)이며 Tomcat, Jetty, Undertow 는 WAS다.

(WAS : Web Application Server , 자바진영 용어)

 

용어차이기 때문에 복잡하게 생각하지말고 Spring+Tomcat / Node.js 등으로 만든 서비스를 Application

Apachi, NginX 등은 Application 앞단에서 일을 처리하는 웹서버(관리자, 스케줄러)라 생각하면 된다. 

 

그래서 Apachi와 NginX는 관리자의 역할에 맞게 Application 들이 각자의 서비스를 잘 수행할 수 있게 관리하는 법들을 고민한다.

 

Tomcat 은 Spring 프로그램(Application)의 관리자(컨테이너) 정도로 생각하면 된다. 

(Application 을 관리하기 때문에 Application과 다른 용어로 표현해야 되니, 그래서 Tomcat을 WAS라 칭하는 것이다.)

 

Node.js 는 톰캣과 스프링보다 뒤에 개발되었기 때문에, 이러한 Tomcat과 Spring의 구조를 보고 올인원으로 관리자가 내장되어 있는 구조라 만들었다 생각하면 된다.

(그러니까 전체적인 그림에서 수행 하는일로 보자면 Node.js = Tomcat+Spring 과 같다고 보면된다.)

 

즉, Apachi, NginX, Tomcat은 모두 관리자이며 Apachi와 NginX는 Tomcat보다 상위 관리자라고 생각하자.

 

---

# Apachi 와 NginX의 차이점은?

Apachi는 멀티 프로세스 모듈(MPM) 방식으로 처리하고, NginX는 이벤트 기반(Event-Driven) 방식으로 처리한다.

(Apachi도 이벤트기반 방식을 추가하긴 했음)

 

따라서 잦은 IO를 처리하는 서비스는 성능과 가벼움이 강점으로 여겨지는 NginX,  안정성이 중요시되는 서비스에는 Apachi를 사용한다.

[IT지식] Node.js 와 Spring Boot 의 차이점

 

---

# 관리자의 고민과 역할 (Apachi, NginX, Tomcat)

 이러한 고민은 웹서비스뿐만 아니라, 모든 서비스(클라우드 컴퓨팅, 엣지컴퓨팅, OS 등)에서도 똑같이 적용 된다.

 

 쿠버네티스, 하둡, OS 도 모두 관리자이니 근본적으로 같은 고민을 하는 셈이다.

 심지어 OSI 7 Layer 각 계층, HTTP도 어떻게 보면 하나의 서비스를 담당하는 관리자인 셈이다.

 

 해당 게시물에서 관리자의 역할에 대해서 모두 따져보기엔 양이 너무 방대해질 것 같아 모두 다루지 않는 점을 알려드린다.

 운영체제(OS)에 대해 공부를 하시면 아래에 소개드릴 고민 말고도 여럿 고민들을 확인 하실 수 있다.

 

 1. 서비스가 중지되어선 안된다.

   

   서비스를 수행중에 서비스가 업데이트 되어야하는 상황이라 가정하자. 하지만 서비스는 중지되어선 안된다.

   그래서 하나의 서비스를 여러개의 톰캣으로 수행시키는 것이며, 업데이트를 순차적으로 적용시킨다.

 

   이러한 방법으로 서비스가 죽는 상황이 오더라도 대처가능하다.

 

   그리고 서비스가 죽는 상황을 되도록 만들지 않기 위해 로드 밸런싱(부하분산)을 하는 것도 관리자의 몫이다.



 2. 보안을 신경써야 한다.

   

  외부의 사용자가 우리의 서버가 어떻게 돌아가는지 모르게 해야 한다.    

  여기서 리버스 프록시(Reverse Proxy)가 등장한다. (아래에서 설명)

 

 3. 서비스가 가능하면 빠르게 수행되도록 한다.  

 

  사용자에게 느린 서비스보다는 빠른서비스를 제공하기 위한 고민이다.

  여기서는 캐싱(Caching)과 포워드 프록시(Forward Proxy)가 등장한다. (아래에서 설명)

 

  적절한 로드 밸런싱 또한 서비스의 성능 향상에 기여한다.

 

 

---

 

# Proxy

 프록시서버(Proxy)는 클라이언트가 자신을 통해 다른네트워크 서비스(Node.js, Spring, WAS)에 간접적으로 접근할 수 있게 하는 컴퓨터 시스템이나 응용프로그램을 일컫는다.

 

 중계자(관리자)로서 로드밸런싱, Reverse Proxy, 캐싱 등의 작업을 수행한다. 

https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9D%EC%8B%9C_%EC%84%9C%EB%B2%84

 

 

# Reverse Proxy

 클라이언트에게서 서버의 정보를 감추는 작업

 (서버 내부적으로 파일들이 어느 폴더에 있는지, 어느 서비스가 어느 포트에서 작업중인지 등)

 

 클라이언트와 WAS 사이의 중계자로서 둘 사이의 통신을 담당한다.

 리버스 프록시서버를 통해 응답을 내려주기 때문에, 실제 서버의 정보를 알 수 없게 된다.

 또한 WAS는 서버확장에 있어 자유로워지는 이점이 생긴다.

 

 클라이언트가 요청하는 End Point 는 프록시서버의 도메인이다.

 

[Reverse Proxy의 캐싱] - 서버의 성능향상에 초점

클라이언트들이 자주 요청할 리소스들을 리버스 프록시에 캐싱하여 요청이 들어오면 바로 건네 줌

 

# Forward Proxy

 서버에게서 클라이언트를 감추는 작업

 요청받는 서버는 포워드 프록시 서버를 통해서 요청을 받기에 클라이언트의 정보를 알 수 없게 된다.

 

 [Forward Proxy의 캐싱] - 클라이언트의 성능향상에 초점

 빈번히 사용될 리소스들을 포워드 프록시에 캐싱하여 서버까지 요청할 필요 없이 프록시에서 받아오게 함

 

 

 

- 끝 -

 

---

# 짤막지식

[war]

스프링으로 작성한 웹앱을 war 파일로 빌드하면, 그 안에 class, jsp, img, css, js 파일들이 압축되어 있음

톰캣의 특정폴더에 war파일을 넣고 명령어를 실행하면 스프링서비스가 톰캣을 사용해서 돌게 됨 

 

[jar]

스프링과 톰캣이 같이 묶여서 압축된 파일 

 

---

# Reference

>> 얄코님의 유튜브