기록 이유
프로젝트를 진행하며 배포의 단계에 접어들었을 때, Web Server 와 WAS 라는 단어를 많이 접했었다.
웹 서버로는 주로 Nginx 를 사용해 React 를 배포하고 WAS 는 내가 사용하고 있는 Spring Boot 를 배포하는 과정에서 둘의 차이점을
정확히 알지 못한 상태로 배포를 담당했었는데, 항상 배포를 할 때 헷갈렸던 부분이라 이번 기회에 간단하게나마 짚고 넘어가고 싶어 기록을 남기게 되었다 🙂
Web Server 란 ?
서버 역할을 수행하게 하는 소프트웨어의 개념이며 아파치, Nginx, 윈도우에서 사용하는 IIS 가 대표적인 웹 서버 제품이라고 할 수 있다.
브라우저가 읽을 수 있는 HTML, JS, CSS, 이미지, 기타 데이터 들을 서버에서 사용자의 컴퓨터로 전송하는 역할을 담당한다.
클라이언트의 요청을 받아 정적 리소스를 처리하는 역할을 주로 수행하며 간단한 동적 리소스를 처리할 수도 있다.
여기서 아파치와 Nginx 는 작동방식에 있어 근본적인 차이가 존재하는데 간단하게 기록해보자.
1. 아파치
아파치에는 MPM (멀티 프로세스 모듈) 이란 모듈이 존재한다.
MPM 은 클라이언트로에게서 받은 요청을 어떤 방식으로 처리 할 것인지 결정하는 모듈로 2.4.x 버전 이후로 3 가지의 방식이 있다.
1. mpm prefork
프로세스를 미리 준비하고 클라이언트 요청에 대해 각각의 프로세스가 요청을 담당하는 방식이다.
각 프로세스는 분리되어 있고 메모리를 공유하지 않아서 스레딩을 지원하지 않는 라이브러리와 연결된 어플을 실행하는데 안전하다.
프로세스가 정지하더라도 다른 자식 프로세스에 영향을 주지 않기 때문에 안정성이 뛰어나지만 메모리를 많이 사용한다는 단점이 존재한다.
2. mpm worker
하나의 프로세스에서 여러 개의 요청을 받고 멀티 스레드를 활용해 스레드 단위로 요청을 담당하는 방식이다.
프로세스 중 일부는 새로 들어오는 요청을 수신하고 일부는 요청 받은 내용을 내어주는 방식으로 동작한다.
각 프로세스는 멀티 스레드를 사용하고 스레드 하나가 요청 하나를 담당해서, 하나의 프로세스가 여러 개의 요청을 동시 처리할 수 있다.
따라서 시작 시 프로세스 수를 줄일 수 있고, 스레드 간 메모리를 공유해 메모리 사용량이 상대적으로 낮으며 통신량이 많은 서버에 적합하다고 할 수 있다.
3. mpm event
아파치 2.4 버전부터 사용가능하고 worker 에서 한 단계 발전한 방식이다.
기존 MPM 방식에서 Keep Alive 와 같이 요청에 대한 연결을 프로세스 혹은 스레드가 계속 유지하고 있는 경우가 있는데 이는 성능 저하와 부하가 일어날 가능성이 높다. 이 점을 해결하기 위해 나온 새로운 방식이 mpm event 방식인 것.
사용자의 요청과 Keep Alive 한 아파치 요청을 그대로 맺어주는 것이 아닌, 요청을 처리하는 스레드를 따로 둬서 분산된 처리를 하는데 목적이 있다.
2. Nginx
아파치의 10CK (1만개의 클라이언트 문제) 를 해결하기 위해 등장한 Event Driven 처리 기반 구조의 웹 서버 소프트웨어이다.
프로그램의 흐름이 이벤트에 의해 결정되는 방식이라고 할 수 있고 대용량 트래픽을 처리하기 위해 가벼움과 높은 성능을 목표로 하는
경량 웹 서버라고 할 수 있다.
Nginx 는 크게 클라이언트 요청에 맞게 정적 리소스를 응답해주는 역할을 하면서 Reverse Proxy Server 로 활용하며 WAS 의 부하를
줄여주는 로드밸런서 역할을 하기도 한다. 이 부분은 아래 좀 더 기록할 예정.
아파치와의 대표적인 차이점이라면 기반 방식이 다른 점을 차이점으로 들 수 있는데, 프로세스 / 스레드 기반의 아파치는 하나의 요청 당
하나의 프로세스 또는 스레드를 필요로하지만, Nginx 의 경우 이벤트 기반으로써 여러 개의 요청을 Event Handler 를 통해 비동기적으로
처리한다. 따라서 많은 트래픽을 효율적으로 처리할 수 있다.
Web Application Server 란 ?
줄여서 와스(WAS) 라고 하며 자바 진영 기준으로 동적 리소스를 전문적으로 처리해주는 소프트웨어의 개념이다.
조금 더 풀어보자면 Web Application 은 웹에서 실행되는 프로그램이고 이 프로그램을 실행시켜 필요한 기능 (동적 리소스 처리 등) 을
수행하고 그 결과를 Web Server 에 전달해주는 역할을 한다. 그리고 와스 또한 정적 리소스 응답이 가능하기도 하다.
즉, 와스는 동적 리소스 작업을 위한 프로그램 실행 환경과 DB 접속 기능을 제공하고 프로그래밍 언어를 지원해 비즈니스 로직을 수행한다.
웹 서버 부분에서 잠시 언급했듯 Web Server 또한 동적 사이트를 처리할 수 있긴 한데, 이는 논외적인 부분으로 이해하자.
참고로 Spring Boot 를 사용한다면 내부에 Tomcat 이라는 와스가 내장되어 있어서 따로 설치하지 않아도 사용할 수 있다.
왜 굳이 나눠서 사용하는 걸까
웹 서버도 동적 리소스 처리가 가능하고, 와스도 정적 리소스 처리가 가능하다면 왜 굳이 둘로 나눠서 사용하는 걸까 ?
역할이 곂치는 부분이 있지만 각자 특화된 부분을 십분 활용하기 위해서이다.
예를 들어, 와스가 정적, 동적 리소스 모두를 제공해줄 수 있기 때문에 와스 하나로 웹 서비스를 충분히 만들어 낼 수 있다.
하지만, 담당하는 리소스가 너무 많아지기 때문에 부하가 늘어나게 되며 부하 또는 어떠한 장애로 인해 와스가 죽어버리는 일이 생긴다면
사용자에게 에러 페이지 조차 응답할 수 없는 상황이 발생할 것이다. 와스는 가장 비싼 자원인 동적 리소스를 처리하기 바쁜데 정적 리소스
까지 신경 쓸 겨를이 없는 것이다. 즉, 웹 서버는 와스의 앞 단에 위치해 웹 서버에 특화된 일을 해내고, 와스는 웹 서버의 뒷 단에서 동적
리소스를 작업하는데 집중하도록 하는 것이 좋다고 할 수 있겠다.
웹 서버가 앞 단, 와스가 뒷 단 ?
웹 어플리케이션 아키텍처의 기본으로 클라이언트의 요청을 받아내는 웹 서버가 앞 단, 동적 리소스를 처리하는 와스가 뒷 단에 존재하는게
일반적인 아키텍처인데, 왜 굳이 이렇게 나눴을까 ? 그건 바로 웹 서버가 제공하는 다양한 기능을 활용하기 위해서이다.
Reverse Proxy
클라이언트 요청을 웹 서버에서 받아내 와스로 대신 전달해주는 기능을 리버스 프록시하고 한다. (포워드 프록시와 다름)
리버스 프록시 기능을 잘 사용하면 여러가지 장점을 얻을 수가 있는데 크게 2 가지로 알아보자.
1. 보안
웹 서버의 리버스 프록시로 인해 사용자들에게서 와스의 정보를 감출 수 있다.
클라이언트는 정적 리소스 파일은 어디에 있는지 ? 톰캣과 같은 와스가 동적 리소스를 만들어내는 곳은 어디인지 ? DB 정보는 무엇인지?
라는 민감한 정보는 전혀 알 필요가 없고 알아서도 안된다. 따라서 아파치나 Nginx 웹 서버가 와스 대신 클라이언트를 맞이하고 필요한 정적 리소스를 내주되, 동적 리소스가 필요하다면 와스를 통해 동적 리소스를 대신 전달해주는 예시를 들 수 있을 것 같다.
2. 로드 밸런싱
로드 밸런싱을 통해 와스가 부담하는 부하를 분산시킬 수 있다.
톰캣으로 하는 자바 기반 웹 서비스 뿐만 아니라 웹 서버에 사용자가 많이 몰린다면 여러 개의 와스로 사용자를 분산해주는 역할을 하며,
웹 서버 하나에 하나의 와스로 서비스를 하는 것 보다 여러 와스를 같이 실행시켜 작업을 분산하는게 성능 측면에서 좋다. 따라서 이를 통해 성능 향상 및 확장성, 신뢰성을 높일 수 있다.
정리
프로젝트를 진행하며 매번 주먹구구식 수동 또는 자동배포를 해왔는데 자주 사용하는 단어와 Nginx 의 간단한 특징에 대해 정리하게 되서 좋았고, 굉장히 딥한 내용이라고 생각이 들어서 복습, 정리를 따로 시간내서 더 해봐야겠다는 생각이 들었다 🙃
'CS' 카테고리의 다른 글
| ERD와 정규화 과정 (0) | 2022.09.15 |
|---|---|
| 데이터베이스의 기본 (0) | 2022.09.15 |