서버 분배(로드밸런싱... )

서버 분배(로드밸런싱... )

Network/Server 2004/03/08 17:01

일정 규모 이상의 웹 사이트라면 여러 대의 웹서버로 Web farm을 구성하는 경우가 
많습니다. 
Windows 제품에 내장된 Windows Load Balancing Service(WLBS)를 사용하거나 
Layer 4 이상의 스위치 장비를 Web farm 앞단에 붙여서 여기저기로 분산 
시키거나 
DNS 서버로 하여금 한 도메인에 대해 여러 아이피를 돌아가며 응답하게 하는 등 
여러가기 방법을 사용할 수 있습니다. 

가능하면 비슷한 H/W 환경에 
똑 같은 S/W 환경 (특히 컴포넌트)을 구성해주고 
DB Connection String을 한 지점의 DB로 물려주기만 하면 크게 문제 없이 Web 
farm이 구성됩니다. 
하지만, 몇가지 정도 단일 서버 환경과는 달리 고려해야 할 점이 있는데요. 

1. 세션 유지의 문제 
Web farm으로 사용자가 접속한다는 것은 사용자가 A 서버 붙었다가 B 서버 
붙었다가 이리저리 서버마다 돌아 다니며 접속할 가능성이 있다는 얘기입니다. 
웹 서버단에서 단순히 In-proecss 세션 관리를 한다면 A 서버에 로그인 했는데, B 
서버 단으로 붙었을 때는 로그인 한 상태가 아닌 것이 되는 등 혼란이 야기될 수 
있습니다. 

이런 문제를 해결하기 위해 쿠키나 URL에 사용자의 Identity 정보를 유지를 
하거나 
State Server를 중립 지점에 두고 웹 서버 간에 세션 정보를 공유 하거나 
아예 DB 서버에 세션 정보를 유지하는 방법을 사용합니다. 

2. 파일 업로드의 문제 
사용자가 A 서버의 게시판에 붙어 파일을 업로드를 했다면, B 서버의 게시판에 
붙어서 파일을 다운로드 하려는 사용자는 어떻게 될까. 
저는 항상 중간 지점에 파일 서버 두는 방법을 사용했습니다. 그리고, 모든 웹 
서버에 UNC 경로로 가상 디렉토리를 잡아 동일한 지점의 저장소를 공유하도록 
했습니다.(마치 DB 처럼) 
이 과정에서 서버 간에 웹 사용자에 대한 인증을 통과시켜주는 것이 이슈가 
되므로 주의해야 합니다. 

3. View State의 문제 
이건 ASP.NET 응용프로그램에 해당하는 얘기인데, 
클라이언트가 이 서버 저 서버 돌아가며 붙을 수 있다는 얘기는 
A 서버에서 GET 으로 Web form을 받은 후 B 서버로 POST 때릴 수 있다는 
얘기입니다. 
이 때, A 서버에서 View State를 Encoding 할 때 사용했던 Key와 B 서버에서 
Decoding 할 때 사용하는 Key가 다른 문제 때문에 View State를 해독해 내지 
못하는 문제가 발생합니다. 
이럴 때는 모든 웹 서버가 같은 Key를 사용하도록 강제 설정해 주는 조치가 
필요합니다. 

4. 캐싱의 문제 
종종 웹 서버의 메모리에 DB의 Data를 Caching 해서 DB 서버와의 Round-trip 수를 
줄이고 속도 향상을 효과는 보는 경우가 많은데요. 
만약 웹 서버가 여러 대가 된다면? 
A 서버에 캐싱을 해 놓고, 캐싱된 데이터가 없는 B 서버에 다음 Request가 도착할 
수 있으므로 이런 상황을 항상 염두에 두고 개발하는 것이 필요합니다. 
아울러 웹 서버가 일정 대수 이상 많아지는 경우 웹 서버단에 동일한 내용을 
중복해서 캐싱하는 것이 오히려 효율이 떨어지게 되는 임계점이 있습니다. 이럴 
때는 미들 웨어를 중간 지점에 배치하는 등 multi-tier로 Farm을 구성하는 
전략적인 접근이 필요합니다. 

ASP 뉴스그룹에 좋은글이 있길래 가져왔습니다.

[출처] 서버 분배(로드밸런싱... )|작성자 한결아빠