[8주차] 로드 밸런싱, 웹 서버 & WAS 차이

• 로드 밸런서란? + L4 vs L7

• 로드밸서 알고리즘 종류

• 헬스 체크 + 장애 조치

• DNS로 하는 로드밸런싱

• 정적 vs 동적 페이지 차이

• 웹 서버와 WAS의 역할 비교

• 웹 서버 ↔ WAS 협업 구조 (리버스 프록시 포함)

• 웹/WAS를 왜 분리해서 쓰는가?

---

🔵 로드 밸런서란?

인터넷의 발달로 인해 트래픽이 증가하였다. 이에 기업들은 서버를 추가로 구비해 여러대의 서버에 동일한 데이터를 저장해 수많은 트래픽을 효과적으로 분산시킨다.

하지만 단순히 다수의 서버를 구축해 운영한다고 해서 모든 클라이언트의 요청을 일관성 있게 응답할 수 있는 것은 아니다. 쏟아지는 트래픽을 여러 대의 서버로 분산해 주는 기술이 없다면 한 곳의 서버에 모든 트래픽이 몰리는 상황이 발생할 것이다.

이때 필요한 기술이 바로 로드밸런싱이다.

로드밸런서는 서버에 가해지는 부하를 분산해주는 장치 또는 기술을 통칭한다.

클라이언트와 서버풀 사이에 위치하며, 한 대의 서버로 부하가 집중되지 않도록 트래픽을 관리해 각각의 서버가 최적의 퍼포먼스를 보일 수 있도록 한다.

Scale-up

Scale-up은 서버 자체의 성능을 확장하는 것을 의미한다. CPU가 i3인 컴퓨터를 i7로 업그레이드 하는 것과 같다.

Scale-out

Scale-out은 기존 서버와 동일하거나 낮은 성능의 서버를 두 대 이상 증설하여 운영하는 것을 의미한다. CPU가 i3인 컴퓨터를 여러 대 추가 구입해 운영하는 것에 비유할 수 있습니다.

Scale-out의 방식으로 서버를 증설하였다면 여러 대의 서버로 트래픽을 균일하게 분산해주는 로드밸런싱이 반드시 필요하다.

🔵 L4 vs L7 로드밸런서

L4 로드밸런서

L4 로드밸런서는 전송 계층에서 작동하는 로드밸런서로, 주로 TCP 및 UDP 프로토콜을 기반으로 클라이언트와 서버 간의 트래픽을 분산시킨다.

클라이언트의 IP 주소와 포트, 서버의 IP 주소와 포트를 기반으로 로드밸런싱을 수행한다.

L7 로드밸런서

L7 로드밸런서는 애플리케이션 계층에서 작동하는 로드밸런서로, 주로 HTTP, HTTPS 프로토콜을 기반으로 클라이언트와 서버 간의 트래픽을 분산시킨다.

요청 내용(URL, 헤더, 쿠키 등)을 기반으로 로드 밸런싱을 수행한다.

L4, L7 로드밸런서 비교

항목	L4	L7
작동 계층	전송 계층	애플리케이션 계층
주요 프로토콜	TCP, UDP	HTTP, HTTPS
로드밸런싱 기준	IP 주소, 포트	요청 내용(URL, 헤더, 쿠키 등)
처리 속도	상대적으로 빠름	상대적으로 느림
기능 및 유연성	상대적으로 제한적	다양한 기능 및 유연성

L4 사용 사례

• 실시간 트래픽 처리가 중요한 서비스
• 온라인 게임, 스트리밍 서비스 등 실시간 트래픽 처리가 중요한 서비스에 적합하다.

L7 사용 사례

• 애플리케이션 레벨의 로드밸런싱이 필요한 서비스
• 웹 서비스, API 게이트웨이, 콘텐츠 전송 네트워크 등 애플리케이션 레벨의 로드 밸런싱이 필요한 서비스에 적합하다.

---

🔵 로드밸런서 알고리즘 종류

라운드로빈

서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식이다. 클라이언트의 요청을 순서대로 분배하기 때문에 여러 대의 서버가 동일한 스펙을 갖고 있고, 서버와의 연결이 오래 지속되지 않는 경우에 활용하기 적합하다.

가중 라운드로빈

각각의 서버마다 가중치를 매기고 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분한다. 주로 서버의 트래픽 처리 능력이 상이한 경우 사용되는 부하 분산 방식이다.

예를 들어 A라는 서버가 5라는 가중치를 갖고, B라는 서버가 2라는 가중치를 갖는다면 로드밸런서는 라운드로빈 방식으로 A서버에 5개 B서버에 2개의 요청을 전달한다.

IP 해시

클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방식이다. 사용자의 IP를 해싱해 로드를 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장한다.

최소 연결

요청이 들어온 시점에 가장 적은 연결상태를 보이는 서버에 우선적으로 트래픽을 배분한다. 자주 세션이 길어지거나 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합한 방식이다.

최소 리스폰스 타임

서버의 현재 연결 상태와 응답시간을 모두 고려하여 트래픽을 배분한다. 가장 적은 연결 상태와 가장 짧은 응답시간을 보이는 서버에 우선적으로 로드를 배분한는 방식이다.

---

🔵 헬스 체크

로드밸런서는 부하분산을 하는 각 서버의 서비스를 주기적으로 헬스 체크 하여 정상적인 서비스 쪽으로만 부하를 분산하고 비정상적인 서비스는 서비스 그룹에서 제외해 트래픽을 보내지 않는다.

서비스 그룹에서 제외된 후에도 헬스 체크를 계속 수행해 다시 정상으로 확인되면 서비스 그룹에 해당 장비를 다시 넣어 트래픽이 해당 서버 쪽으로 보내지도록 한다.

ICMP

방식: 서버에 ICMP 패킷(ping)을 보내 응답을 확인한다.

장점: 구현이 매우 간단하다.

단점: 네트워크 연결만 확인할 뿐, 애플리케이션 레벨의 상태는 확인 불가하다.

사용 여부: 실서비스 환경에서는 거의 사용하지 않는다.

TCP 서비스 포트

방식: 서버의 특정 TCP 포트에 연결을 시도하여 열려있는지 확인한다.

장점: 서비스 포트가 열려 있는지 확인할 수 있다.

단점: 포트는 열려 있어도 애플리케이션이 정상 동작하는지는 보장하지 않는다.

TCP 서비스 포트: Half Open

방식: TCP 3-way 핸드셰이크를 완료하지 않고, SYN → SYN-ACK까지만 보고 확인 후 종료하는 방식이다.

장점: 서버에 부담 없이 빠르게 상태 확인 가능하다.

용도: 빠르고 간단한 상태 체크에 적합하다.

HTTP 상태 코드

방식: 정해진 경로(e.g. /health)에 HTTP 요청(GET)을 보내고 응답 상태 코드 (e.g. 200 OK)로 정상 여부 판단하는 방식이다.

장점: 웹 애플리케이션에서 가장 일반적이며, 서버가 정상적으로 HTTP 요청을 처리할 수 있는지 확인 가능하다.

단점: 상태 코드만으로는 세부적인 오류를 알기 어렵다.

콘텐츠 확인

방식: 특정 HTTP 요청의 응답 내용(body) 을 포함하여 비교한다.

예: /health 요청의 응답이 "OK"인지 확인.

장점: 애플리케이션이 정상적으로 작동하는지 더 정밀하게 판단 가능하다.

단점: 비교 연산이 추가되어 약간의 오버헤드가 발생한다.

🔵 장애 조치

Active: 현재 서비스를 제공하는 서버

Passive: 대기 중인 예비 서버

Active-Passive

장애 발생 시 Passive가 자동으로 Active 역할로 승격한다.

간단하고 안정적이지만 리소스 낭비가 있다.

Active-Active

여러 서버가 동시에 서비스를 제공하며 로드밸런싱 된다.

하나의 서버가 장애가 나도 나머지에서 즉시 커리가 가능하다.

고가용성, 리소스가 효율적으로 사용되지만, 상태 동기화가 복잡하고 충돌 방지가 필요하다.

N+1 구조

N개의 Active 서버에 대해 한개의 Passive 서버를 두는 방식이다.

하나가 장애가 나면 예비 서버가 대신한다.

자원 효율과 안정성 간 절충안이다.

N+M 구조

N개의 Active 서버에 대해 M개의 Passive 서버를 두는 방식이다.

여러 서버에 동시에 장애가 나도 대응이 가능하다.

대규모 서비스에 적합한 방식이다.

---

🔵 DNS로 하는 로드밸런싱

DNS 서버가 하나의 도메인 이름(예: www.example.com)에 대해 **여러 개의 A 레코드(IP 주소)**를 등록해 두고, 클라이언트가 도메인 이름을 요청할 때마다 이들 중 하나 또는 여러 개를 반환함으로써 트래픽 분산을 유도하는 방식이다.

실시간 상태 반영이나 부하 기반 분산에는 한계가 있으므로, 일반적으로는 L7 로드밸서(ALB, Nginx 등) 와 함께 병행하거나, 클라우드 DNS 서비스의 고급 기능을 통해 보완한다.

작동 방식

www.example.com에 대해 다음과 같은 A레코드가 존재한다.

A www.example.com → 192.168.0.1
A www.example.com → 192.168.0.2
A www.example.com → 192.168.0.3

DNS 질의가 오면 DNS 서버는 위 세 개 중 하나 또는 모두를 응답하고, 클라이언트는 해당 IP로 접속해 트래픽을 분산한다.

한계점

DNS 캐싱

클라이언트 또는 DNS 리졸버가 응답 IP를 캐싱해 오래 유지하면 분산 효과가 저하된다.

실시간 장애 감지 불가

일반 DNS는 헬스체크를 하지 않으므로 장애 서버에 응답이 갈 수 있다.

로드량 고려 불가

서버 부하 상태나 연결 수 등을 고려하지 못한다.

세션 유지 어려움

클라이언트가 매 요청마다 다른 서버에 연결될 수 있다.

---

🔵 정적 vs 동적 페이지 차이

인터넷을 이용하면서 접속하게 되는 웹페이지는 크게 두 가지로 나뉜다.

저장된 파일을 그대로 보는 정적 웹 페이지와 다른 변수들에 의해 변경되어 보이는 동적 웹 페이지이다.

정적 웹 페이지

웹서버에 이미 저장된 파일(HTML 파일, 이미지, JavaScript 파일 등)을 클라이언트에게 전송하는 웹 페이지이다.

사용자는 서버에 저장된 데이터가 변경되지 않는 한 고정된 웹 페이지를 계속 보게 된다.

따라서 모든 사용자는 같은 결과의 웹 페이지를 서버에 요청하고 응답 받게 된다.

동적 웹 페이지

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

요청에 관하여 사용자는 조건에 따라 다른 결과를 받게 된다.

사용자는 상황, 시간, 요청 등에 따라 달라지는 웹 페이지를 보게 된다.

1. CSR (Client Side Rendering)

CSR은 데이터가 없는 HTML 문서나 Static 파일만을 처음에 받아와 로드하고, 이후에 데이터를 요청하여 받아오는 방식이다.

Javascript를 사용하여 브라우저에서 페이지를 직접 렌더링 진행한다.

모든 로직, 데이터 가져오기, 템플릿 및 라우팅 등은 서버가 아닌 클라이언트 측에서 진행한다.

2. SSR (Server Side Rendering)

CSR과 상반되게 서버에서 동적으로 데이터까지 전부 삽입하여 완성된 HTML을 넘겨준다.

서버 렌더링은 브라우저에서 응답을 받기 전에 처리되므로 클라이언트에서 데이터를 가져오거나 템플릿 작성에 대한 추가 왕복이 발생하지 않는다.

3. MPA (Multi Page Application)

새로운 페이지를 요청할 때마다 정적 리소스가 다운로드 되고, 그에 맞춰 전체 페이지를 다시 렌더링 하는 방식이다. (즉, SSR 방식으로 렌더링된다.)

인터넷 주소창에 주소를 입력하거나 링크를 클릭하는 등의 사용자가 어떠한 요청을 하게 되면, 그에 맞는 완전한 페이지를 받아오고 다시 렌더링된다.

SEO(검색 엔진 최적화) 관점에서는 유리하지만, 새로운 페이지를 이동할 때마다 완전히 새로 렌더링 되기 때문에 UI가 깜빡거리며 프론트엔드와 백엔드가 밀접하게 연결되어 개발이 복잡해질 수 있다.

4. SPA (Single Page Application)

웹 어플리케이션에 필요한 모든 정적 리소스를 최초 한번만 다운로드한다.

그 이후 새로운 페이지에 대한 요청이 있을 떄마다 페이지 갱신에 필요한 데이터만 전달 받고 그 정보를 기준으로 페이지를 갱신한다. (즉, CSR 방식으로 렌더링한다.)

SPA를 만드는데 사용되는 프레임워크로는 React, Vue, Angular 가 있다.

최초 접속 시 맨 첫 페이지 로딩 시간은 길어도 이후 페이지부터는 속도가 빠르다는 장점이 있다. 또한 로컬 데이터를 효과적으로 캐싱할 수 있다.

하지만 초기 구동 속도가 느리고 SEO에 불리하다는 단점이 있다.

---

🔵 웹 서버와 WAS의 역할 비교

웹 서버와 WAS(Seb Application Server) 서버는 웹 상에서 서비스를 제공하기 위해 사용되는 서버이다. 두 서버의 역할과 기능에는 차이가 있으며, 각각의 서버가 목적과 기능을 가지고 있다.

항목	웹 서버	WAS
정의	정적인 콘텐츠(HTML, CSS, 이미지 등)를 제공하는 서버	동적인 콘텐츠(웹 애플리케이션)을 처리하고 제공하는 서버
기능	HTTP 프로토콜을 이용해 클라이언트에게 웹 페이지 제공	웹 애플리케이션 실행 및 데이터 처리, 웹 서버와 클라이언트 간의 중계 역할
주요 소프트웨어	Apache, Nginx	Tomcat, JBoss, WebLogic

웹 서버의 역할과 예시

웹 서버는 클라이언트가 웹 브라우저를 통해 요청한 정적 콘텐츠를 제공하는 역할을 한다. 웹 서버는 주로 HTTP 프로토콜을 사용하여 작동하며, 클라이언트가 URL을 통해 요청한 웹 페이지를 찾아 전송해준다.

예시: 회사 홈페이지, 블로그, 뉴스 사이트 등

WAS 서버의 역할과 예시

WAS 서버는 웹 애플리케이션을 실행하여 동적 콘텐츠를 생성하고, 웹 서버와 클라이언트 간의 데이터 처리를 담당하는 역할을 한다.

WAS 서버는 클라이언트의 요청에 따라 데이터베이스에서 정보를 가져오거나, 웹 애플리케이션을 실행하여 동적인 웹 페이지를 생성한 후 결과를 웹 서버에 전달한다. 웹 서버는 이를 받아 클라이언트에게 전달한다.

예시: 온라인 쇼핑몰, 은행 인터넷 뱅킹, SNS 등

---

🔵 웹 서버 ↔ WAS 협업 구조 (리버스 프록시 포함)

1. 클라이언트가 HTTP 요청을 전송

• 사용자가 브라우저에서 URL을 입력하거나 링크를 클릭
• 예: GET /index.html, POST /login

2. 웹 서버(Nginx, Apache 등)가 요청을 먼저 수신

• 정적 리소스(HTML, CSS, JS, 이미지 등) 요청이면 직접 응답
• 동적 요청이면 WAS로 전달

3. 웹 서버가 리버스 프록시 역할 수행

• WAS가 외부에 직접 노출되지 않고 웹 서버가 중계 역할
• 요청 URI나 패턴 기반으로 정적/동적 요청 분기 처리

4. WAS가 동적 요청 처리

• Java, Spring, JSP, Servlet 등 동적 로직 처리
• DB 조회, 로직 실행, 응답 데이터 생성

5. WAS → 웹 서버로 처리 결과 전달

• WAS는 HTML, JSON, 텍스트 등 생성된 응답을 반환

6. 웹 서버가 클라이언트에게 응답 전달

---

🔵 웹/WAS를 왜 분리해서 쓰는가?

1. 정적 vs 동적 처리 분산

• 정적 리소스는 웹 서버가 빠르게 처리
• WAS는 계산과 DB처리 등 로직 집중

2. 트래픽 분산 및 성능 향상

• 리버스 프록시를 통한 부하 분산 가능
• 병목 구간 분리로 확장성 확보

3. 보안 강화

• 외부 요청은 웹 서버까지만 접근 허용
• 내부 WAS는 외부 노출 차단 가능

4. 운영 유연성

• 웹 서버와 WAS를 독립적으로 배포/스케일링 가능
• 설정 변경이나 유지보수가 용이