[Redundancy] 02. 다중화 작업 흐름 및 부하분산
카테고리: REDUNDANCY
태그: redundancy linux
02-1. 다중화 작업 흐름
① 장애 상정
위 그림의 시스템에서 발생할 수 있는 장애를 상정하면 “라우터 또는 서버 장애로 서비스 정지한다.” 즉, 어떤 장비에 장애가 발생하더라도 서비스가 정지해버린다.
② 예비 장비 준비
장애를 대비하여 예비 장비를 도입하면 위 그림의 시스템과 같다.(아직 예비 라우터와 서버는 네트워크에 연결되지 있지 않다.)
③ 운용체제의 정비
운영체제 정비는 1, 2단계의 어디에 어떻게 장애가 발생할지, 어떤 장비로 어떻게 구성할지에 따라 대응을 생각해야 한다. 먼저 1단계에서 상정한 라우터 장애와 웹 서버 장애를 예를 들면 다음과 같다.
▶ 라우터 장애시의 대응 (Cold Standby)
다중화된 시스템에서는 “현재 장비와 예비 장비의 구성이 같은 상태”로 해두어야 한다. 라우터와 같은 네트워크 장비라면 운용 중에 빈번히 설정이 변경할 일도 없고, 저장해두어야 할 데이터도 많지 않으므로 Cold Standby 운용은 현실적인 선택방법 중 하나다.
▶ 서버 장애시의 대응 (Hot Standby)
웹 서버의 경우, 사이트 내용의 매일 갱신, 버전업 등의 다양한 갱신작업을 중지되어 있는 예비 운용장비에 지속적으로 수행하는 것은 어렵고, 만일의 경우에도 예비 운용장비를 기동했을 때 컨텐츠의 내용이 오래됐거나 애플리케이션의 버전이 이전 버전이라면 큰 문제가 될 수 있다. 따라서, 웹 서버의 예비 장비는 항상 전원을 켜두고 네트워크에 연결하여 현재 장비의 내용을 갱신할 때에는 예비 장비에도 동일하게 갱신될 수 있도록 운용한다.
02-2. 장애극복(Failover)
현재 운용장비에 장애가 발생했을 때 자동적으로 예비 운용장비로 처리를 인계하는 것을 의미한다. 현재 장비인 WEB1에는 자신의 IP 주소와는 별개로 VIP을 할당해두고 서비스는 VIP로 제공하도록 하고 장비에 장애가 발생했을 때 예비 장비인 WEB2가 VIP를 인계한다.
02-3. 장애검출(Health Check)
| 종류 | 설명 |
|---|---|
| ICMP 감시 (Layer 3) | ICMP의 echo 요청을 보내서 응답이 돌아오는지 체크, 가장 간단하지만, 웹 서비스가 다운된 경우는 감지할 수 없다. |
| 포트 감시 (Layer 4) | TCP로 접속을 시험해서 접속할 수 있는지 여부를 체크, 웹 서비스가 다운된 것은 감지할 수 있지만, 과부하 상태로 응답할 수 없다거나 에러를 반환하는 것은 감지할 수 없다. |
| 서비스 감시 (Layer 7) | 실제 HTTP 요청 등을 보내서 정상적인 응답이 돌아오는지 체크, 대부분의 이상을 감지할 수 있지만 경우에 따라서는 서버에 부하를 유발할 수도 있다. |
02-4. 클러스터링(Clustering)
클러스터링은 여러 대의 컴퓨터를 하나의 시스템으로 묶어서 고가용성 및 장애 허용성을 높이고, 서비스의 안정성을 제공하는 기술로 클러스터링 환경에서는 물리적인 서버들이 하나의 논리적인 그룹으로 구성되어 동작하며, VIP(Virtual IP)를 통해 서비스를 제공하고 데이터를 처리합니다. 이를 통해 하나의 장비에 문제가 발생해도 전체 시스템이 영향을 받지 않고 서비스가 지속될 수 있도록 구성된다.
02-5. 부하분산(Load Balancing)
서비스 이용자가 많아 많은 트래픽이 발생할 때, 여러 대의 서버로 분산처리하여 서버의 부하량, 성능 저하 등을 해결하기 위한 기능을 말하며 서버의 부하를 클러스터링된 서버별로 균등하게 로드밸런싱을 수행하는 S/W 또는 H/W 장비를 로드밸런서라고 한다.
■ 부하분산 주요 기술
▶ NAT(Network Address Translation)
사설 IP(Private IP) 주소를 공용 IP(Public IP) 주소로 변환하는 기술로, 주로 여러 컴퓨터가 하나의 공용 IP 주소를 공유하거나, 로컬 네트워크의 IP 주소를 인터넷에서 식별할 수 있는 공용 IP 주소로 변환하는데 사용된다.
▶ 터널링(Tunneling)
인터넷 상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념으로, 데이터를 캡슐화하여 통로를 통해 전송하며, 캡슐화된 패킷은 목적지에서 해독되어 원래의 데이터로 복원된다.
▶ DSR(Direct Server Return)
DSR은 로드밸런서를 사용하는 서버에서 클라이언트로 응답 패킷이 돌아갈 때, 응답 패킷의 목적지 주소를 로드밸런서의 IP 주소가 아닌 클라이언트의 IP 주소로 설정하여, 로드밸런서를 거치지 않고 바로 클라이언트에게 도달하도록 하는 기술이다. 이를 통해 로드밸런서의 부하를 줄이고 네트워크 성능을 향상시킬 수 있으며, 클라이언트-서버 간 직접적인 통신이 이루어지므로 로드밸런서의 부하를 감소시키면서도 빠른 응답 시간을 제공할 수 있다.
■ Architecture
■ 로드밸런서 종류
| 종류 | 설명 |
|---|---|
| L2 로드 밸런서 (Data Link Layer) | L2 로드 밸런서는 MAC 주소를 기반으로 로드밸런싱을 수행, 네트워크 스위치의 스패닝 트리 프로토콜(STP)를 이용하여 서버 간 통신을 분산시키는 방식으로 L2 로드 밸런서는 주로 데이터 센터 내부에서 서버 간의 로드밸런싱을 수행하며, 스위치 레벨에서 동작하기 때문에 외부 네트워크에는 노출되지 않는다. |
| L3 로드 밸런서 (Network Layer) | L3 로드 밸런서는 IP 주소를 기반으로 로드밸런싱을 수행, 클라이언트 요청을 받은 로드밸런서가 요청을 받은 후, 목적지 IP 주소와 포트 번호를 기준으로 서버로 트래픽을 분산시키는 방식으로 L3 로드밸런서는 대부분 네트워크 라우터 기능을 갖추고 있어 외부 네트워크와의 통신에 사용됩니다. |
| L4 로드 밸런서 (Transport Layer) | L4 로드 밸런서는 전송 계층의 포트 번호를 기반으로 로드 밸런싱을 수행, 클라이언트가 요청한 포트 번호와 프로토콜을 분석하여 적절한 서버로 트래픽을 전달하는 방식으로 L4 로드밸런서는 TCP, UDP와 같은 전송 계층 프로토콜을 다루며, 대표적인 예로 IPVS (IP Virtual Server)가 있다. |
| L7 로드 밸런서 (Application Layer) | L7 로드 밸런서는 애플리케이션 레이어의 정보를 기반으로 로드 밸런싱을 수행, HTTP 헤더, URL, 쿠키 등과 같은 애플리케이션 레이어의 특성을 이용하여 트래픽을 분산시키는 방식이다. |
■ 부하분산 알고리즘
| 종류 | 설명 |
|---|---|
| 라운드 로빈(Round Robin) | 서버에 들어온 요청을 순서대로 배정하는 방식, 클라이언트의 요청을 순서대로 분배하기 때문에 여러 대의 서버가 동일한 스펙을 갖고 있고, 서버와 연결이 오래 지속되지 않을 경우에 활용하기 적합하다. |
| 가중치 라운드 로빈(Weighted RR) | 각 서버에 가중치를 매기고 가중치가 높은 서버에 요청을 우선적으로 배분하는 방식, 서버의 트래픽 처리 능력이 상이한 경우 사용되는데 예를 들어 A 서버가 5, B 서버가 2라는 가중치를 갖는다면 로드밸런서는 라운드로빈 방식으로 A 서버에 5개, B 서버에는 2개의 요청을 전달한다. |
| IP 해시(IP Hash) | 클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방식, 사용자의 IP를 해싱하여 로드를 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장한다. |
| 최소 연결(Least Connection) | 요청이 들어온 시점에 가장 적은 연결 상태의 서버에 우선적으로 트래픽을 배분하는 방식, 자주 연결이 길어지거나 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합하다. |
| 최소 리스폰 타임(Least Respones Time) | 서버의 현재 연결 상태와 응답시간을 모두 고려하여 트래픽을 배분하는 방식 |
■ 로드밸런싱의 단점
로드밸런서를 사용할 때 어려운 문제 중 하나는 세션 데이터를 관리하는 것인데, 클라어언트의 연결 정보를 저장하는 세션이 로드 밸런싱을 통해 하나의 서버에 저장되는 경우, 추후 다른 서버로 연결되면 해당 클라이언트의 세션이 유지되지 않는다.
▶ 해결책 - 세션 유지
| 종류 | 설명 |
|---|---|
| 고정 세션(Sticky Session) | 첫 요청 이후의 모든 요청을 첫 요청을 처리한 서버로 고정하는 방법, 해당 방법은 사용자는 접속해야하는 서버가 정해져 있기 때문에 트래픽 몰림 문제에서 완전히 자유로울 수 없다. 결국 서버에 장애가 발생하는 경우 해당 서버를 이용하고 있던 사용자의 세션 정보를 잃어버리게 된다.(즉, 가용성이 떨어짐) |
| 세션 클러스터링(Session Clustering) | WAS 서버가 2대 이상 설치한 환경에서 동일한 세션으로 관리하는 것으로, 한 서버가 클라이언트의 요청을 받아 세션을 생성하면 다른 서버에게 세션을 복제하는 방식으로, 세션이 복제하면 유저가 이후에 어떤 서버에 접속하더라도 세션이 복제되어 있어 정합성 이슈가 해결된다. 하지만 모든 서버가 동일한 세션을 가져야 하기 때문에 많은 메모리가 필요하며 또한 세션이 저장소에 저장될 때마다 모든 서버에 트래픽 증가로 인해 서버 수가 증가 할수록 성능 저하가 발생하게된다. 더 치명적인 것은 여러 대의 서버로 하나의 서비스를 위해 사용함으로써 데이터 불일치가 잠재적으로 발생할 수 있어 4개 이하의 서버의 소규모 클러스터일 때 적합하다. |
| 세션 저장소(Session Storage) | 세션 정보를 요청을 처리하는 서버가 아니라 별도의 스토리지 서버에 저장하는 방식, 요청을 처리하는 각 서버들은 세션 스토리지 서버를 바라봄으로써 데이터의 정합성 문제를 해결할 수 있고, 세션 정보가 요청을 처리하는 서버에 생성되지 않기 때문에 세션 생성으로 인한 메모리 사용량이 줄어든다. 단, 세션 스토리지에 장애가 발생하면 세션 정보를 찾을 수 없기 때문에 세션 저장소 또한 Backup 서버를 두어 세션 복제해 놓아 두면 기존에 있던 세션 스토리지가 다운되어도 서비스를 지속할 수 있다. |
댓글 남기기