개인적으로
Web Server와 Web Application Server 개념 정리가 필요해서 남기는 글이다.
1. 웹 서버(Web Server)란?
웹 서버는 HTTP/HTTPS 프로토콜을 통해 클라이언트(주로 브라우저)로부터의 요청을 처리하고 HTML 파일, CSS, JavaScript, 이미지 등의 정적 리소스를 클라이언트에 전달하는 역할을 한다.
+ 유저가 구글을 이용하기까지의 과정 :
1. DNS 조회: 사용자가 브라우저에 "www.google.com"을 입력하면, 먼저 DNS(Domain Name System) 조회가 일어납니다. 이 과정에서 "www.google.com"이라는 도메인 이름이 실제 IP 주소(예: 172.217.161.36)로 변환된다.
2. HTTP 요청 생성 : 브라우저는 이 IP 주소를 사용하여 Google의 웹 서버에 HTTP GET 요청을 생성한다.
3. 웹 서버 수신 : Google의 웹 서버(예: 구글은 자체 개발한 웹 서버를 사용)가 이 요청을 수신한다.
4. 요청 처리 : 웹 서버는 요청된 리소스가 무엇인지 확인한다. www.google.com의 경우, 일반적으로 홈페이지에 해당하는 HTML 파일을 요청한다.
5. 정적 파일 전송 : 웹 서버는 요청된 Google 홈페이지의 기본 구조를 포함한 HTML 파일을 찾아 클라이언트(브라우저)에게 전송한다.
6. 추가 리소스 요청 : 브라우저가 HTML 파일을 받아 파싱하면, 그 안에 포함된 CSS, JavaScript, 이미지 등의 추가 리소스에 대한 요청을 다시 웹 서버에 보낸다.
7. 정적 리소스 전송 : 웹 서버는 이러한 추가 요청들을 받아 해당하는 CSS, JavaScript, 이미지 파일들을 클라이언트에게 전송한다.
8. 페이지 렌더링 : 브라우저는 받은 모든 리소스를 사용하여 Google 홈페이지를 렌더링한다.
주요 역할:
(예시 Google)
- 정적 리소스 처리: 클라이언트 요청을 수신하고 서버의 파일 시스템에서 직접 정적 콘텐츠(HTML, CSS, JS, 이미지)를 제공한다.
(대규모 다국어 서비스의 경우 CDN(Content Delivery Network)를 활용해 사용자와 가까운 서버에서 정적 리소스를 제공) - 프록시 기능: 다른 백엔드 서비스로 요청을 전달하는 프록시 서버 역할을 할 수 있다.
- 검색 요청 처리: 사용자가 검색어 입력 시, 이 요청을 검색 엔진 백엔드로 전달한다.
- API 요청 관리: Google Maps, YouTube 등의 API 요청을 적절한 백엔드 서비스로 라우팅한다.
- 보안 처리: 사용자 인증, HTTPS 암호화 등의 보안 관련 처리를 수행하거나 전문 보안 서비스로 요청을 전달한다.
- 트래픽 분산(로드 밸런싱): 여러 서버에 요청을 분산하여 높은 가용성과 장애 허용성을 보장한다.
(로드 밸런싱(Load Balancing): 서버에 가해지는 부하(load)를 분산(balancing)해주는 컴퓨터 네트워크 기술의 일종)
- 지역별 분산: 사용자의 지리적 위치에 따라 가장 가까운 데이터 센터로 요청을 라우팅한다.
- 서비스별 분산: Gmail, Google Drive, YouTube 등 각 서비스에 특화된 서버로 요청을 분배한다.
- 부하 기반 분산: 각 서버의 현재 부하 상태를 모니터링하고, 가장 여유 있는 서버로 새로운 요청을 할당한다.
- 장애 대응: 특정 서버나 데이터 센터에 문제가 발생했을 때, 자동으로 다른 정상 서버로 트래픽을 리다이렉트한다.
범용적인 웹 서버 종류 및 특징:
- Apache HTTP Server: 공유 호스팅 환경 / LAMP(Linux, Apache, MySQL, PHP/Perl/Python) 스택에 주로 쓰임
- 모듈식 구조(다양한 기능을 모듈로 추가/제거 가능),
- .htaccess 파일을 통한 디렉토리 별 설정 가능
- 가상 호스팅 지원
- 다양한 프로그래밍 언어 지원 (PHP, Perl, Python 등)
- Nginx: 고성능 웹 서버가 필요한 대규모 웹사이트 / 마이크로소프트 아키텍처 API GateWay에 주로 쓰임
- 이벤트 기반 비동기 아키텍처
- 리버스 프록시 및 로드 밸런서 기능
리버스 프록시: 클라이언트 요청을 서버 대신 받아 클라이언트와 웹 서버 간의 중개자 역할을 하는 서버 - 고성능 정적 파일 서빙
- 웹 가속화 기능 (캐싱, 압축 등)
- Microsoft IIS
- Windows 인증과 통합
- ASP.NET 및 .NET Core 애플리케이션 지원
- 웹 배포 도구 (Web Deploy) 제공
- Windows PowerShell을 통한 관리 자동화
2. WAS(웹 애플리케이션 서버)란?
웹 애플리케이션 서버(WAS)는 단순히 정적 파일을 제공하는 것을 넘어선 고급 서버이다. 웹 애플리케이션이 실행될 수 있는 환경을 제공하며, 동적 콘텐츠 생성을 가능하게 한다. WAS는 비즈니스 로직을 처리하고 데이터베이스와 상호 작용하며, 복잡한 연산을 수행하고 동적 콘텐츠(예: 사용자 데이터나 대시보드)를 생성할 수 있도록 설계되었다.
주요 역할:
- 동적 페이지 실행 :
- 서버 사이드 스크립트 실행 : PHP, JSP, ASP.NET 등의 서버 사이드 스크립트 언어를 실행하여 동적 콘텐츠를 생성한다.
- 템플릿 엔진 지원 : Thymeleaf, Freemarker 등의 템플릿 엔진을 통해 동적 HTML 생성을 지원한다.
- 실시간 데이터 처리 : 사용자 요청에 따라 실시간으로 데이터를 처리하고 결과를 반환한다.
- 데이터베이스 접근 및 애플리케이션 로직 :
- 데이터베이스 연결 관리 : 커넥션 풀을 통해 효율적인 데이터베이스 연결 관리를 수행한다.
- 트랜잭션 처리 : 데이터의 일관성을 유지하기 위한 트랜잭션 관리를 제공한다.
- ORM 지원 : JPA, Hibernate 등의 ORM(Object-Relational Mapping: 객체(Object)와 DB의 테이블을 자동으로 연결(Mapping)) 기술을 지원하여 객체와 관계형 데이터베이스 간의 매핑을 용이하게 한다.
- 비즈니스 로직 실행 : 복잡한 비즈니스 규칙과 알고리즘을 실행하여 데이터를 처리한다.
- 컨테이너 및 프레임워크 :
- 서블릿 컨테이너 : Java 서블릿의 라이프사이클을 관리하고 실행 환경을 제공한다.
- 의존성 주입(DI) 지원 : Spring과 같은 프레임워크의 DI 컨테이너를 통해 객체 간의 의존성을 관리한다.
- AOP(Aspect-Oriented Programming) 지원 : 로깅, 보안, 트랜잭션 관리 등의 크로스커팅 관심사를 효과적으로 처리한다.
- 세션 관리 :
- 사용자 세션 유지: 상태를 유지해야 하는 웹 애플리케이션에서 사용자 세션을 관리한다.
- 분산 세션 관리: 클러스터 환경에서 여러 서버 간 세션 정보를 동기화한다.
- 보안 기능 :
- 인증 및 권한 부여: 사용자 인증 및 권한 관리 기능을 제공한다.
- SSL/TLS 지원: 암호화된 통신을 위한 프로토콜을 지원한다.
- 보안 필터 제공: XSS, CSRF 등의 웹 보안 위협에 대응하는 필터를 제공한다.
- 리소스 관리 :
- 메모리 관리: 애플리케이션의 메모리 사용을 최적화하고 관리한다.
- 스레드 풀 관리: 동시 요청 처리를 위한 스레드 풀을 효율적으로 관리한다.
- 모니터링 및 관리 도구 :
- 성능 모니터링: 애플리케이션의 성능을 실시간으로 모니터링한다.
- 로깅 기능: 애플리케이션의 동작과 오류를 기록하고 분석할 수 있는 로깅 기능을 제공한다.
- 관리 콘솔: 애플리케이션 서버의 설정과 상태를 관리할 수 있는 GUI 또는 CLI 도구를 제공한다.
인기 있는 WAS 솔루션 및 특징:
- Apache Tomcat: 오픈 소스 서블릿 컨테이너 // 중소규모 Java 웹 애플리케이션, 마이크로서비스 아키텍처에 주로 쓰임
- Java 서블릿과 JSP를 실행할 수 있는 환경 제공
- 경량화되어 있어 리소스 사용이 적음
- 설정이 비교적 간단하고 사용하기 쉬움
- IBM WebSphere Application Server: 상용 엔터프라이즈급 애플리케이션 서버 // 대규모 엔터프라이즈 애플리케이션, 금융 및 통신 분야의 미션 크리티컬 시스템에 주로 쓰임
- Java EE 전체 스펙 지원
- 고가용성과 확장성을 위한 고급 기능 제공
- 강력한 관리 및 모니터링 도구 제공
- JEUS (Java EE 애플리케이션 서버): 상용 애플리케이션 서버 // 국내 금융권 및 공공 기관의 대규모 시스템에 주로 쓰임
- Java EE 표준 준수
- 국내 환경에 최적화된 기능 제공
- 고성능 트랜잭션 처리 능력
- JBoss EAP(Enterprise Application Platform): 오픈 소스 기반 엔터프라이즈 애플리케이션 서버 // 엔터프라이즈 Java 애플리케이션, 하이브리드 클라우드 환경에 주로 쓰임
- Java EE 전체 스펙 지원
- 마이크로서비스 아키텍처 지원
- 클라우드 네이티브 애플리케이션 개발 지원
- Oracle WebLogic Server: 상용 엔터프라이즈급 애플리케이션 서버 // 국대규모 엔터프라이즈 시스템, Oracle 제품 기반의 솔루션에 주로 쓰임
- Java EE 전체 스펙 지원
- Oracle 데이터베이스 및 미들웨어 제품군과의 긴밀한 통합
- 대규모 분산 환경에서의 고성능 지원
프론트엔드 개발자가 WAS를 알아야하냐 누군가 묻는다면, 향후 풀스택 애플리케이션을 다루거나 백엔드 시스템과 통합할 때 필수적일 것이기에, 알아야 한다고 대답할 것 같다.
3. 프로세스 흐름: 웹 서버와 WAS 상호 작용
클라이언트가 요청을 보낼 때의 웹 서버와 웹 애플리케이션 서버 간 상호 작용은 다음과 같다:
- 클라이언트(브라우저)가 웹페이지에 대한 HTTP 요청
- 웹 서버가 요청(클라이언트로부터의) 수신:
- 정적 콘텐츠(HTML, CSS, JS 등)의 경우, 웹 서버가 직접 제공
- 동적 콘텐츠(사용자 로그인, 데이터베이스 쿼리 등)의 경우, 웹 서버가 요청을 WAS로 전달
- WAS는 요청을 처리하고(백엔드 로직 실행, 데이터베이스 상호 작용 등), 동적 콘텐츠(예: 개인화된 대시보드)를 생성하여 웹 서버로 응답을 보낸다.
- 웹 서버는 이 동적 콘텐츠를 클라이언트에게 전달한다.
웹 서버는 정적 콘텐츠를 빠르게 제공하고 네트워크 트래픽을 관리하는 데 집중할 수 있으며, WAS는 복잡한 애플리케이션 로직 실행과 동적 요청 처리에 집중할 수 있다.
4. In Frontend
프론트엔드 개발자에게 웹 서버와 WAS의 차이를 이해하는 것은 현대적인 웹 아키텍처, 특히 풀스택 애플리케이션에서 작업할 때 중요하다.
- 웹 서버 사용 사례: React나 Vue 애플리케이션을 배포할 때, Nginx나 Apache와 같은 웹 서버가 일반적으로 정적 에셋을 제공한다.
- WAS 사용 사례: 애플리케이션에 동적 콘텐츠(예: 사용자별 데이터 가져오기나 복잡한 비즈니스 로직 수행)가 필요한 경우, 웹 서버는 해당 요청을 Apache Tomcat이나 WAS와 유사한 역할을 하는 Node.js로 전달한다.
(Node.js는 전통적인 의미의 WAS는 아니지만, 동적 콘텐츠 생성, DB 연결, 비즈니스 로직 처리, 세션 관리 등 WAS 역할을 수행)
웹 서버와 WAS가 언제 요청을 처리하는지 아는 것은 성능 최적화, 확장성 향상, 프론트엔드-백엔드 상호 작용의 효과적인 디버깅에 도움이 될 것이다.
5. 현대 웹 개발 트렌드에서의 웹 서버와 WAS
웹 서버와 WAS의 경계는 모호해지고 있다.
1. Next.js
React 기반의 프레임워크로, 주로 프론트엔드 개발에 사용되지만 서버 사이드 렌더링(SSR)과 정적 사이트 생성(SSG) 기능을 제공
서버 사이드 렌더링(SSR): 서버에서 브라우저에 보일 HTML 파일을 미리 준비해서 동적으로 HTML을 생성해주는 방식
정적 사이트 생성(SSG):페이지를 정적인 HTML 파일로 미리 빌드함으로써 컴퓨팅하는 대신 미리 렌더링된 페이지를 제공
- 웹 서버: 정적 파일 서빙, 파일 시스템 기반의 라우팅 제공(웹 서버의 URL 처리 역할)
- WAS: SSR , API Route 역할
2. Nest.js
Nest.js는 Node.js 기반의 서버 사이드 프레임워크
- 웹 서버: HTTP Server(Express or Fastify 기반 HTTP 요청 처리), 데코레이터 기반 라우팅
- WAS: 비즈니스 로직 처리(컨트롤러, 서비스 , 모듈 등), DB 연동(ORM 통합), 의존성 주입 지원
3. 서버리스 아키텍처(Serverless Architecture)
AWS Lambda, Azure Functions, Google Cloud Functions 등의 서비스를 통해 개발자가 서버 관리 없이 코드에만 집중할 수 있게 됨.
- 웹 서버: 전통적인 웹 서버의 역할이 클라우드 제공업체의 인프라로 대체됨.
- WAS: 애플리케이션 로직이 독립적인 함수 단위로 실행되며, 전통적인 WAS의 필요성이 감소함.
4. 마이크로서비스 아키텍처(MicroService Architecture)
애플리케이션을 작고 독립적인 서비스로 분할하여 각각이 자체 프로세스를 실행하고 경량 메커니즘(주로 HTTP/REST API)으로 통신.
- 웹 서버: API 게이트웨이 역할이 중요해짐. 요청 라우팅, 로드 밸런싱, 인증 등을 처리.
- WAS: 각 마이크로서비스가 자체 WAS 역할을 수행하며, 경량화된 애플리케이션 서버 사용이 증가.
5. 컨테이너화(Containerization)
Docker와 Kubernetes의 인기로 애플리케이션의 컨테이너화가 표준화됨.
- 웹 서버 & WAS: 웹 서버와 WAS가 동일한 컨테이너 내에 패키징되어 배포되는 경우가 많아짐. 이로 인해 두 시스템의 경계가 더욱 모호해짐.
6. Edge Computing
Cloudflare Workers, Vercel Edge Functions 등을 통해 사용자와 가까운 곳에서 코드 실행.
- 웹 서버: CDN의 역할을 넘어 edge 서버가 동적 콘텐츠 생성 및 처리를 담당.
- WAS: 일부 애플리케이션 로직이 edge로 이동하여 전통적인 중앙 집중식 WAS의 부하 감소.
7. JAMstack
JavaScript, APIs, Markup을 사용한 정적 사이트 생성과 서버리스 기능의 결합.
- 웹 서버: 정적 파일 서빙에 최적화된 CDN의 역할이 더욱 중요해짐.
- WAS: API 서버의 역할이 강조되며, 서버리스 함수로 대체되는 경우가 많아짐.
8. GraphQL
RESTful API의 대안으로 GraphQL 사용 증가.
- 웹 서버: GraphQL 엔드포인트를 처리하기 위한 새로운 라우팅 및 처리 로직 필요.
- WAS: 데이터 쿼리 및 응답 생성 방식의 변화. 유연한 데이터 제공을 위한 새로운 로직 구현 필요.
6. 웹 서버 vs WAS 정리
| 목적 | 정적 콘텐츠 제공 (HTML, CSS, JS, 이미지) | 애플리케이션 로직 실행을 통한 동적 콘텐츠 처리 |
| 콘텐츠 유형 | 정적 파일만 | 동적 콘텐츠 생성 (예: 데이터베이스 쿼리) |
| 통신 프로토콜 | HTTP/HTTPS 요청 처리 | 애플리케이션 로직 관리 및 데이터베이스 상호 작용 |
| 리소스 처리 | 정적 리소스 (HTML, CSS, JS) | 서버 사이드 스크립트 실행 (PHP, JSP, 서블릿 등) |
| 스택에서의 역할 | 일반적으로 클라이언트 요청의 첫 접점 | 백엔드로 작동하며 동적 프로세스와 데이터 처리 |
| 로드 밸런싱 & 캐싱 | 정적 리소스의 로드 밸런싱과 캐싱에 효율적 | 캐싱에 중점을 두지 않지만 로직과 비즈니스 처리에 중요 |
| 예시 기술 | Apache HTTP Server, Nginx, Microsoft IIS | Apache Tomcat, WebSphere, JEUS |
이번 글을 통해 서버의 큰 틀은 감을 잡았지만, 각각의 웹서버인 nginx, apache를 각각 깊게 파볼 필요성을 느낀다.
