웹 서버와 WAS

📌 정적 웹 페이지와 동적 웹 페이지

 

🔍 정적 웹 페이지

웹 서버에 이미 저장된 정적 자원(HTML, CSS, Javascript, 이미지 파일 등)을 클라이언트에게 전송

• 서버가 웹 페이지 요청을 받으면 추가 과정없이 응답을 전송
• 저장된 데이터를 변경할 때까지 페이지가 동일하게 유지

https://share.google/images/TwOCqlQIMcRwpVb6Y

 

🔍 동적 웹 페이지

서버에 저장된 HTML 파일이 그대로 브라우저에 나오는 것이 아닌 동적으로 만들어지는 웹 페이지

• 데이터를 가공해 사용자에게 맞춤형으로 화면을 보여주어 데이터베이스와 웹 애플리케이션 서버가 필요
• 클라이언트에서 요청을 보내면 웹 애플리케이션 서버에서 데이터베이스를 조회하거나 외부 서버에서 데이터를 읽어 HTML을 렌더링

https://share.google/images/TwOCqlQIMcRwpVb6Y

 

🔖 정리

구분	정적 웹 (Static Web)	동적 웹 (Dynamic Web)
내용	미리 완성된 HTML, CSS, JS, 이미지 등 그대로 제공	서버에서 요청 시마다 새로운 콘텐츠 생성
예시	HTML 파일, 정적 이미지, JS/CSS 파일	게시판, 로그인, 검색 결과 페이지 등
비유	음식점에서 콜라(캔) 바로 제공	요리사가 주문에 따라 음식 조리

 

• 정적 웹은 이미 완성된 자원을 그대로 내려주므로 속도가 빠르고 리소스 소모가 적습니다.
• 동적 웹은 클라이언트 요청에 따라 서버에서 동적으로 데이터를 처리하고 응답을 생성합니다.

 

⭐ 웹서버

웹 서버(Web Server)

HTTP 프로토콜을 기반으로 클라이언트 요청에 알맞은 정적 콘텐츠를 제공

 

요청에 따라 두 가지 기능중 선택하여 수행합니다.

1. 정적 콘텐츠 제공
   • 요청에 알맞은 정적 콘텐츠를 반환한다.
2. 동적인 콘텐츠 제공을 위해 WAS에 요청 전달
   • 동적으로 데이터나 콘텐츠를 생성하는 요청은 처리하기 어렵기에 해당 요청을 웹 애플리케이션 서버에게 전달합니다.
   • 웹 애플리케이션 서버로부터 만들어진 동적 데이터나 콘텐츠를 받아 클라이언트에게 반환한다.

대표적인 예로는 Apache, Nginx 가 있습니다.

 

🚀 WAS (Web Application Server)

📖 WAS

• 다양한 로직 처리를 요구하는 동적 콘텐츠를 생성하고 처리해 제공

 

WAS는 사용자의 요청에 대해 다양한 비즈니스 로직과 데이터를 처리하여 동적 콘텐츠를 생성하고 제공하는 서버입니다.

정적인 자원(HTML, 이미지, CSS 등)을 제공하는 웹 서버와 달리 WAS는 사용자 맞춤형 페이지 생성, 데이터베이스 연동, 복잡한 로직 수행 등을 담당합니다.

 

대표적인 예로는 Tomcat, Jetty 가 있습니다.

 

🤔 왜 WAS 앞에 웹 서버를 둘까? - 웹 서버의 핵심 기능

웹 서버는 단순한 정적 파일 제공 외에도 중요한 기능들을 수행하며 이 때문에 WAS 앞에 두는 것이 일반적입니다.

 

1️⃣ 리버스 프록시(Reverse Proxy)

웹 서버는 클라이언트의 요청을 받아 WAS로 전달하고 응답을 다시 클라이언트에게 보내주는 중간 다리 역할을 합니다.

 

이 과정에서 WAS의 실제 주소나 포트 번호 같은 내부 정보를 외부에 노출시키지 않아 보안을 강화할 수 있습니다.

또한, 여러 개의 WAS가 있더라도 클라이언트는 웹 서버 하나만 알면 되므로 시스템 구조가 단순해집니다.

 

2️⃣ 로드 밸런싱(Load Balancing)

사용자의 요청이 많아질 때 웹 서버는 여러 대의 WAS에 요청을 균등하게 분산시켜 특정 서버에 부하가 몰리는 것을 막아줍니다.

 

👍 이는 서버의 과부하를 방지하고 서비스의 안정성을 높여줍니다.

 

만약 한 WAS가 유지보수나 업데이트로 인해 일시적으로 작동을 멈춰도 웹 서버가 다른 WAS로 요청을 돌려주므로 사용자 입장에서는 서비스가 끊기는 것을 느끼지 못합니다.

 

3️⃣ 캐싱(Caching) - 리버스 프록시 캐싱

웹 서버는 자주 요청되는 정적 파일(이미지, CSS, 자바스크립트 등)을 자체적으로 저장해둡니다.

이렇게 저장된 파일에 대한 요청이 다시 들어오면, WAS까지 가지 않고 웹 서버가 직접 빠르게 응답해줍니다.

 

⚡️ 이는 WAS의 부하를 줄이고 전체적인 웹 서비스의 응답 속도를 크게 향상시키는 효과가 있습니다.

 

🆚 Apache vs Nginx

⭐ 작동방식에 있어 차이가 존재합니다.

• 아파치는 멀티 프로세스, Nginx는 이벤트로 일을 처리한다는 것.

 

1️⃣ 아파치

아파치는 MPM, 멀티 프로세스 모듈 방식으로 일합니다.

 

MPM 종류	처리 모델	특징	장점	단점
prefork	요청마다 새로운 프로세스 생성	요청이 올 때마다 독립된 프로세스로 처리	안정적, 각 요청이 격리되어 안전	메모리 사용량 많음, 속도 느림
worker	요청마다 스레드 생성 (한 프로세스 안에서 여러 스레드로 처리)	하나의 프로세스가 여러 요청을 동시에 처리	메모리 효율적, 성능 좋음	스레드 간 충돌 가능성, 스레드 안정성 필요
event	worker 기반 + keep-alive 최적화	keep-alive 연결을 전담 스레드가 관리	높은 성능, 동시 연결 최적화	복잡한 구조, 최신 버전에서만 완전 지원

 

 

🧩 prefork

 

요청 1개 = 프로세스 1개

클라이언트가 요청을 보내면 아파치는 새로운 프로세스를 만들어 그 요청을 처리

요청이 끝나면 프로세스는 반환되거나 종료됩니다.

 

특징

• 요청 간 완전한 격리가 보장 → 안정성 높음.
• CGI 스크립트처럼 멀티스레드 안전성이 없는 코드와 호환성 좋음.
• 하지만 요청 수가 많아지면 프로세스가 폭증 → 메모리 사용량 급증, 컨텍스트 스위칭 비용 큼.

 

🧩 worker

 

요청 1개 = 스레드 1개 (단, 프로세스는 유지)

기본적으로 아파치가 여러 프로세스를 띄워 놓고 각 프로세스가 여러 스레드를 생성하여 요청을 병렬 처리

 

특징

• 하나의 프로세스 안에서 스레드가 동작하므로 메모리 사용 효율적.
• 많은 요청을 동시에 처리 가능 → 성능 우수.
• 단, 스레드 간 데이터 충돌 가능성이 있어 코드가 스레드 안전해야 함.

 

🧩 event

 

worker 방식의 개선판으로 keep-alive 연결을 효율적으로 처리합니다.

 

일반 HTTP는 요청이 끝나도 TCP 연결을 유지(keep-alive)하지만 유지되는 동안 스레드가 점유되어 낭비가 발생할 수 있습니다.

• event 방식에서는 keep-alive 연결을 별도 스레드가 관리하여 메인 스레드가 낭비되지 않도록 최적화.

 

특징

• 대규모 트래픽에 가장 적합.
• 최신 아파치(version 2.4)에서 기본 MPM으로 채택

 

🏃 동작 과정

1. 아파치가 시작되면 지정한 서버 프로세스 값만큼 초기 프로세스를 실행.
2. 클라이언트 요청 발생 시
   • prefork: 새로운 프로세스를 생성하여 요청 처리.
   • worker: 기존 프로세스 내에서 새로운 스레드로 요청 처리.
   • event: 요청 처리는 worker와 동일하지만 keep-alive 연결은 별도 관리 스레드에서 처리.
3. 요청이 끝나면 프로세스/스레드를 반환하거나 종료.

 

2️⃣ Nginx

Nginx의 event driven 방식

 

특징	설명
비동기, 논블로킹 I/O	요청 처리가 완료될 때까지 기다리지 않고 다른 요청을 계속 처리
소수의 프로세스만 사용	기본적으로 master process + 여러 개의 worker process로 구성
이벤트 루프(Event Loop)	각 worker가 이벤트 루프를 돌면서 수많은 요청을 동시에 처리
높은 확장성	적은 리소스로도 수만 개의 동시 연결 처리 가능

 

 

🏃 동작 과정

1. Master Process 시작
   • Nginx가 실행되면 master process가 시작되어 설정 파일을 읽고 초기화.
   • 이후 여러 개의 worker process를 생성합니다.
2. Worker Process에서 이벤트 루프 실행
   • 각 worker는 이벤트 루프를 통해 수많은 요청을 비동기적으로 동시에 처리합니다.
   • 요청이 들어오면 OS 커널의 epoll이나 kqueue같은 이벤트 통지 메커니즘을 사용해 효율적으로 관리
3. 요청 처리
   • 요청이 들어오면 그 작업(예: 파일 읽기, DB 호출)을 비동기적으로 요청하고 그동안 다른 요청을 처리.
   • 작업이 완료되면 이벤트가 발생하고, 그 시점에 다시 처리 재개.

즉, 하나의 worker가 요청 - 대기 - 응답 을 병렬적으로 동시에 여러 개 관리할 수 있습니다.

 

👷‍♂️ Nginx 기본 프로세스 구조

+---------------------+
|     Master Process  |  ← 설정 관리, Worker 관리
+----------+----------+
           |
+----------+----------+
| Worker Process #1   | ← 이벤트 루프, 실제 요청 처리
| Worker Process #2   |
| Worker Process #3   |
| ...                 |
+---------------------+

• 일반적으로 CPU 코어 수만큼 worker를 띄웁니다.
• 각 worker는 단일 스레드로 동작하여 이벤트 루프 기반으로 요청을 처리합니다.

 

🆚 이벤트 기반 비유 (아파치와 비교)

아파치는 손님(요청)이 올 때마다 새로운 테이블이나 자리를 마련하는 구조라면 Nginx는 작은 데스크 하나를 두고 줄을 세워 효율적으로 처리하는 방식입니다.

💡 예시

• 손님이 한 줄로 쭉 서서 기다림.
• 직원(A)이 질문 → “어떤 일로 오셨나요?”
• 손님이 서류 작성하는 동안 직원은 바로 다음 손님을 응대.
• 서류가 준비되면 해당 손님을 다시 처리.

 

🤔 왜 Nginx가 성능이 좋은가?

1️⃣ 적은 리소스 사용

• 스레드/프로세스 급증 없이 하나의 worker가 수많은 요청 관리.

Apache는 요청 수에 따라 스레드 수가 늘어가고 스레드 하나당 메모리 스택 공간이 필요하고 스케줄링 시 컨텍스트 스위칭 비용 발생!

 

2️⃣ 논블로킹 구조

• I/O 작업(파일, DB, 네트워크)이 끝날 때까지 기다리지 않고 다른 요청을 처리.

 

3️⃣ Keep-Alive 효율적 관리

• 연결을 유지하는 동안 프로세스를 점유하지 않음.

 

4️⃣ 리버스 프록시, 로드 밸런싱에 강함

• 대규모 서버 트래픽을 효율적으로 분산 가능.

 

📚 Ref.

https://www.geeksforgeeks.org/computer-networks/difference-between-static-and-dynamic-web-pages/

https://engineering.linecorp.com/ko/blog/how-to-quickly-develop-static-pages-in-line

https://www.yalco.kr/09_static_dynamic_web/

https://developer.mozilla.org/ko/docs/Learn_web_development/Howto/Web_mechanics/What_is_a_web_server

https://httpd.apache.org/docs/current/mpm.html

https://httpd.apache.org/docs/current/en/mod/event.html

https://nginx.org/en/docs/dev/development_guide.html#event_loop