Web Server vs WAS
웹서버 vs WAS
웹서버
- 웹 브라우저로부터 HTTP 요청을 받아 정적 콘텐츠를 제공하는 프로그램
- 정적 콘텐츠: 요청에 따라 달라지지 않는 콘텐츠(html, css, image 등등), 어떤 사용자의 요청이던 동일한 콘텐츠
WAS
- 동적인 콘텐츠를 처리하기 위해 만들어진 프로그램
- 동적 콘텐츠: 요청에 따라 달라질 수 있는 콘텐츠
- 대부분의 WAS가 웹서버를 내장하고 있어 요청에 맞는 정적 콘텐츠를 제공할 수 있다.
WAS와 웹서버를 같이 사용했을 때의 장점
- 책임 분할을 통한 서버 부하 방지
- 정적 콘텐츠는 웹서버, 동적 콘텐츠는 WAS가 담당
- 웹서버의 로드 밸런싱을 사용하여 요청을 WAS에 나누어서 처리할 수 있다.
- 로드 밸런싱의 헬스체크를 통해 WAS의 상태를 점검할 수 있다.
- 리버스프록시를 통해 실제 서버를 외부에 노출하지 않을 수 있다.
웹서버와 ELB 비교
| 특징 | 웹서버(Nginx, Apache) | Elastic Load Balancing (ELB) |
|---|---|---|
| 관리 | 수동 설정 및 관리 필요 | AWS가 자동으로 관리 |
| 로드 밸런싱 | 제한된 성능 및 확장성 | 높은 확장성과 고가용성 |
| 정적 콘텐츠 제공 | 가능 (캐싱 포함) | 불가능 |
| 확장성 | 별도의 서버 클러스터 필요 | 자동 확장 지원 |
| 커스터마이징 | 라우팅 규칙 및 설정 자유 | 커스터마이징 제한적 |
| 비용 | 오픈소스(무료), 인프라 비용만 부담 | 사용량에 따른 비용 발생 |
언제 어떤 것을 선택해야 할까?
- *Elastic Load Balancer (ELB)**가 적합한 경우:
- AWS 클라우드 환경에서 고가용성과 확장성을 보장하고 싶을 때.
- 관리형 서비스를 이용해 인프라 운영 부담을 줄이고 싶을 때.
- 여러 AZ(가용 영역)에 걸친 로드 밸런싱이 필요할 때.
- 웹서버를 로드 밸런서로 사용하는 경우:
- 정적 콘텐츠를 캐싱하고 함께 제공하고 싶을 때.
- 세부적인 라우팅 규칙이나 고급 커스터마이징이 필요할 때.
- 인프라 비용을 최소화하고 싶을 때.
💡클라이언트 → ELB → 여러 웹서버(Nginx) → 여러 WAS 인스턴스를 주로 사용한다.
이런 구조를 사용하면 ELB로 클라이언트 트래픽을 분산하고, 웹서버에서 정적 콘텐츠 처리와 세부 라우팅을 수행하며, 최종적으로 WAS가 비즈니스 로직을 처리하는 방식으로 효율적인 트래픽 관리를 할 수 있습니다.
.