처리 능력이 부족하면 복수 서버로 부하 분산한다
서버 액세스 증가 시 대처 방법들
- 서버로 통하는 회선을 빠르게 하는 방법
- 서버 머신을 고성능 기종으로 교체하는 방법(Scale-Up)
- 복수 서버를 사용하여 처리를 분담하는 방식(Scale-Out) — 분산 처리
- 같은 기능을 가진 여러 대의 서버가 아닌 다른 방법으로 부하 분산. 데이터베이스 서버와 웹 서버 같은 역할에 따라 서버를 나누는 방법으로, 캐시 서버를 사용하는 방법임 — 분산 처리 캐시 서버를 이용한 서버의 부하 분산(프록시)
라운드 로빈 방식으로 부하 분산 할 때의 단점
- DNS 서버에서 라운드 로빈 방식으로 IP를 반환하는 형태이면, 고장난 웹 서버의 IP 주소가 반환되면 문제 발생
- 복수의 페이지에 걸쳐 클라이언트와 서버가 대화할 때, 웹 서버가 도중에 변하게 되면 대화가 도중에 끊길 수 있음
부하 분산 장치(로드 밸런서)를 이용해 부하 분산
- 부하 분산 장치를 사용할 때는 부하 분산 장치의 IP를 웹 서버 IP 대신 DNS 서버에 등록 ⇒ 클라이언트는 부하 분산 장치가 웹 서버라고 생각하고 여기에 리퀘스트를 보냄
- 그 후 부하 분산 장치가 웹 서버에 리퀘스트 메시지를 전송함
요점은 어느 웹서버에 리퀘스트를 전송해야 할지 판단하는 부분임
판단 근거
1. 복수 페이지에 걸쳐 있지 않은 단순한 액세스라면 웹 서버의 부하 상태가 판단 근거가 됨
- 웹 서버와 정기적으로 정보를 교환하여 CPU나 메모리 사용률 수집, 이것을 바탕으로 어느 웹 서버의 부하가 낮은지 판단
- 혹은 시험 패킷을 웹 서버에 보내 응답 시간으로 부하를 판단하는 방법
- 그러나, 웹 서버의 부하는 단시간에 증가하거나 감소하므로 꼼꼼히 상황을 조사하지 않으면 정확한 곳 까지 파악할 수 없음. 그렇다고 너무 자세하게 조사하면 조사 동작 자체로 웹 서버 부하가 증가함
- 그래서, 미리 웹 서버의 능력을 설정한 후 비율에 따라 리퀘스트를 분배하면 좋다고 생각할 수 있음
- 대화가 복수 페이지에 걸쳐 있을 때는 웹 서버의 부하에 관계 없이 이전 리퀘스트와 같은 웹 서버에 전송
- HTTP 자체의 대화가 1회씩 전혀 다른 것으로 보이기에(stateless) 이전 리퀘스트와 이번 리퀘스트 사이의 관계 알 수 없음
- 리퀘스트 송신처 IP 주소로 동일 리퀘스트라고 판단하기 어려운 것이 프록시를 사용하게 되면 리퀘스트의 송신처 IP 주소가 프록시의 IP 주소로 변경되기에 실제 클라이언트 알 수 없음
- 주소 변환 이용시도 마찬가지임
- HTTP 헤더의 cookie 를 이용(쿠키, 세션, 등 같은 클라이언트 임을 알기 위한 방법)