[개발 일기] 2025.01.27 - Nginx (Feat : Apache Web Server)

오늘 ‘HTTP 완벽 가이드’의 웹 서버 파트를 읽다가 해당 책이 출판되었을 당시의 웹 서버 1등은 Apache Web Server라는 것을 보고 이번 일기를 쓰게 되었다. 왜냐하면 현재는 Nginx가 1등이기 때문이다.

그 사이 어떤 일이 발생했는지, 뭐 때문에 Apache Web Server가 밀려났는지 정리해 보자.

2014년 웹 서버 서베이 결과

2025년 웹 서버 서베이 결과

Nginx는 웹 애플리케이션 서버(WAS)를 보조하는 비동기 이벤트 기반의 웹 서버(WS)이다.

주요 역할은 다음과 같다.

정적 리소스 제공
- 이미지, 동영상, JavaScript 등의 정적 파일을 클라이언트에 전달
- 동적 리소스(변동 데이터)는 WAS를 통해 처리
HTTP 로드 밸런서
- 여러 서버에 트래픽을 분산하여 부하를 줄임
리버스 프락시
- 클라이언트 요청을 내부 서버로 전달하며 보안을 강화하고 성능을 최적화

Apache Web Server는 Nginx가 출현하기 전까지 가장 널리 사용된 웹 서버로, HTTP 서버 기능을 제공하며 다양한 기능을 지원하고 구축이 쉬운 점이 특징이다.

Apache Web Server의 동작 방식은 다음과 같다.

Apache Web Server는 클라이언트의 요청이 들어오면 클라이언트와 서버 간의 커넥션을 위해 요청마다 프로세스를 생성해 요청을 처리한다. → 하지만 이 프로세스를 생성하는 과정의 시간이 많이 소요됨!
생성에 시간이 많이 소요되는 단점 때문에 Prefork라는 자식 프로세스를 미리 생성하여 준비해 두는 프로세스 풀을 사용한다.
이러한 방식을 통해 Apache Server는 프로세스 풀과 서버가 다양하다는 장점을 사용해 동적 데이터 또한 쉽게 다룰 수 있게 된다.

이처럼 Apache Web Server도 프로세스 풀을 사용해 클라이언트와 서버 간의 커넥션에서 발생할 수 있는 지연시간을 줄이려는 시도도 있었다.

하지만 더 큰 문제는 클라이언트와 서버 간의 커넥션에 있다.

위의 말을 그대로 따라 하면 클라이언트가 서버에게 커넥션을 요청, 즉 HTTP 요청-응답을 시도한다면 커넥션 수는 자연스럽게 늘어나게 된다.

이 커넥션 수가 10,000개를 넘어가는 순간, Apache Web Server에 장애가 발생하는 것이다.

이러한 장애의 가장 큰 원인은 Apache Web Server의 Prefork 방식으로 생성된 많은 프로세스로 인해 메모리 부족, CPU 부하 등이 아닐까 싶다.

이러한 한계를 극복하기 위해 Nginx를 사용하게 된 것이다.

Nginx는 하나의 Master Process와 여러 개의 Worker Process로 구성된다.

Master Process는 Nginx의 설정 파일(nginx.conf)을 읽고, 이에 따라 Worker Process를 생성하고 실행한다.

Worker Process는 기본적으로 CPU 코어 수에 맞춰 생성되며, 요청이 많아지더라도 추가적인 프로세스를 생성하지 않고 효율적으로 요청을 처리한다. (실질적으로 작업을 수행하는 것은 Worker Process임)

이 방식은 Apache Server의 Prefork 방식과 달리 메모리 및 CPU 자원을 절약하면서 높은 성능을 유지할 수 있는 구조이다.

참고

[개발 일기] 2025.01.29 - 불변 객체 (0)	2025.01.29
[개발 일기] 2025.01.28 - 이분탐색 (Lower Bound, Upper Bound) (0)	2025.01.28
[개발 일기] 2025.01.26 - 논리적 동치성 (Feat : equals()) (1)	2025.01.26
[개발 일기] 2025.01.25 - volatile (1)	2025.01.25
[개발 일기] 2025.01.24 - 낙관적 락 vs 비관적 락 (0)	2025.01.24

티스토리툴바