머지 않은 날..직접 AWS를 관리해야되는 날이 올 예정이여서 부랴부랴 AWS에 배포하는 법을 배우고 있다.
EC2로 배포하는 법을 배우는 중, WEB과 WAS를 설정해야된다는 것을 알게되었는데 당췌..이해가 잘 안되서 이참에 정리하고 넘어가기로 결정했다.
WEB & WAS
Static Pages / Dynamic Pages
WEB과 WAS를 이해하기 위해서는 우선 위의 두가지를 구분할 줄 알아야한다.
Static Pages
파일 경로로 request를 받고 항상 해당 경로의 file contents를 반환한다.
즉, 항상 동일한 페이지, 동일한 html, css, js를 반환한다
Dynamic Pages
인자의 내용에 맞게 동적인 contents를 반환한다.
예를 들면 제품 리스트에서 상세페이지로 넘어갈때나, 사용자 role에 따라서 보여지는 페이지가 다른 경우가 이에 해당한다.
(즉 조건부로 페이지의 내용이 바뀌는 것..!)
WEB(웹 서버)
개념에 따라 하드웨어와 소프트웨어로 구분한다.
-
하드웨어
Web 서버가 설치되어 있는 컴퓨터(EC2를 사용해서 만들면..EC2가 되겠죠) -
소프트웨어
웹 브라우저로부터 HTTP 요청을 받고, 정적인 컨텐츠(html, css)를 제공하는 컴퓨터 프로그램
대표적으로 Apache, Nginx 등이 있다
기능
HTTP 프로토콜을 기반으로 클라이언트의 요청을 서비스하는 기능을 한다.
요청은 크게 두가지이다
- 정적 컨텐츠 제공
이 경우, WAS를 거치지 않고 바로 자원을 제공한다 - 동적 컨텐츠 제공을 위한 요청 전달
요 경우는 클라이언트 요청을 WAS에 보내고, WAS에서 처리한 결과물을 클라이언트에게 전달한다
WAS (Web Application Server)
DB조회 및 다양한 로직 처리 요구시 동적인 컨텐츠를 제공하기 위해 만들어진 application server이다.
웹 컨테이너 혹은 서블릿 컨테이너라고도 부른다.
(컨테이너란 JSP, Servlet을 실행시킬 수 있는 소프트웨어. 즉, WAS는 JSP, Servlet 구동 환경을 제공해줌)
기능
HTTP를 통해 어플리케이션을 수행해주는 미들웨어이다.
프로그램 실행 환경 및 DB 접속 기능을 제공한다.
1.프로그램 실행 환경 및 DB 접속 기능 제공
2.여러 트랜잭션 관리 기능
3.업무 처리하는 비즈니스 로직 수행
WAS 종류 : Tomcat, JBoss 등
특징
WAS는 여러대를 연결지어 사용이 가능하다.
웹 서버를 앞 단에 두고, WAS에 오류가 발생하면 사용자가 이용하지 못하게 막아둔 뒤 재시작하여 해결할 수 있다는 최고 장점이 있다.
(사용자는 오류를 느끼지 못하고 이용 가능)
이 둘을 구분 짓는 이유
웹 서버에서는 정적 컨텐츠만 처리하도록 기능 분배를 해서 서버 부담을 줄이기 위해 구분짓는다.
HTML, CSS 등을 웬만큼 WEB에서 처리하면, WAS는 필요할 때에만 사용하면 되기에 서버 부담이 낮아진다.
또한, 동적인 컨텐츠를 제공해야 할 때, 웹 서버만으로는 사용자가 원하는 요청에 대한 결과값을
미리 만들어놓고 서비스하기에는 자원이 절대적으로 부족하다.
고로, WAS를 통해 요청이 들어올 때마다 DB와 비즈니스 로직을 통해 결과물을 만들어 제공함으로써 역으로 WEB의 부담을 줄이기도 한다.
Nginx
동시접속에 특화된 WEB서버이다.
동시접속자(약 700명) 이상이라면 서버를 증설하거나 Nginx 환경을 권장한다고 한다. 지금은 아파치가 시장 점유율이 압도적(?)이지만, 아마존웹서비스(AWS) 상에서는 시장 점유율 44%에 달할정도로 가볍고, 성능이 좋은 엔진이라고 한다.
기능
정적 파일을 처리하는 HTTP 서버로서의 역할 (WEB서버니까..)
- 응용프로그램 서버에 요청을 보내는 리버스 프록시로서의 역할
- 리버스 프록시의 역할이..WAS에 필요시 요청을 전송하는,,그런 역할이다
웹 응용프로그램 서버에 리버스 프록시(Nginx)를 두는 이유는 요청(request)에 대한 버퍼링이 있기 때문이다. 클라이언트가 직접 App 서버에 직접 요청하는 경우, 프로세스 1개가 응답 대기 상태가 되어야만 한다. 따라서 프록시 서버를 둠으로써 요청을 배분하는 역할을 한다.
특징
- 비동기 처리(Event-Drive) 방식을 채택하고 있다.
Phusion-Passenger
WEB, WAS를 겸하는 서버로, nodejs와 nginx 패키지를 지원한다.
특징
- Multitenancy
하나의 서버로 여러개의 노드 앱을 실행할 수 있다. - Process management and supervision
노드 프로세스는 자동으로 실행되고, 크래시 되었을때도 자동으로 재시작한다. - Statistics
app상태를 확인할 수 있는 도구들을 제공한다.
(지금 처리하고 있는 요청이라던가, 몇 개의 요청을 처리했는지 등등) - Scaling and load balancing
현재 트래픽을 판단해 노드 프로세스의 개수를 관리한다.
장점
- 프록시 룰, 초기화 스크립트, 관리 스크립트를 짤 필요가 없다.
- 로드 밸런싱이나 response buffering 등등 nginx에서 리버스 프록싱해주는 것보다 더 많은 걸 해준다.
- nginx 프록시 모듈로는 시스템 상태를 정확히 파악할 수 없지만, 패신저는 간단하고 강력한 어드민 툴을 제공한다.
커넥션이 정상적인지, 노드 프로세스들은 잘 돌아가고 있는지 등등..
Nginx와 Passenger가 동작하는 법
패신저와 엔진엑스는 완전히 통합되어 있어서, 사용자 입장에서는 패신저와 엔진엑스를 같은 거라 생각할 수 있을 정도다.
이렇게 함으로써 시스템을 상당히 쉽게 관리할 수 있는데, 엔진엑스 설정 파일을 변경하는 걸로 패신저를 설정할 수 있고,패신저를 시작하고 중지하는 걸로 앤진엑스를 시작하고 중지할 수 있다.
패신저는 엔진엑스의 요청을 받아서 노드로 전달한다.
내부적으로는 엔진엑스의 프록시 룰을 사용하고, 이 리버스 프록시 레이어는 지저분한 HTTP 헤더를 정리하고, 노드를 느린 클라이언트로부터 방어하는 버퍼링 기능을 제공한다.
패신저는 여러 개의 노드 프로세스를 관리하고 로드밸런싱 기능을 제공한다.
한 개의 프로세스가 죽으면, 다시 시작한다.
패신저가 노드를 여러 개의 프로세스로 운영하기 때문에, 노드가 싱글 스레드임에도 불구하고 멀티 CPU 코어의 이점을 활용할 수 있다. (한 개의 프로세스는 한 개의 코어를 사용할 수 있다)
정적인 파일은 엔진엑스에서 바로 제공하기 때문에 노드까지 요청되지 않는다.
엔진엑스가 정적 파일을 서빙하는데 최적화되어 있기 때문에 노드는 동적인 작업만 처리해주면 된다.
일반적으로 노드앱을 모니터링하기가 쉽지 않다.
지금 처리하고 있는 요청이 뭔지. CPU와 메모리 사용량은 얼마인지. 중지된 건 아닌지. 과부하 상탠 아닌지.
패신저가 이런 것들은 모니터링하고 관리할 수 있는 도구를 제공한다.
패신저가 하지 않는 것
패신저는 ‘최소한의 것만 한다’는 유닉스의 철학을 따른다.
- 운영체제에 서버를 설치하지 않는다.
- Node.js를 설치하지 않는다.
- 애플리케이션 코드를 서버로 전송하지 않는다. (배포 기능을 제공하지 않는다)
- 애플리케이션의 의존성을 설치하지 않는다.
- 데이터베이스를 관리하지 않는다.
- 애플리케이션이 데몬이나 서비스를 필요로 해도 이에 대한 관리를 하진 않는다. 예) Memcahed나 Redis 같은
참고
