본문 바로가기

Distributed System/이론 공부

분산시스템) 서버 클러스터

Server clusters

서버들이 여러개가 있어서 클러스터로 구성되어 있는 것이다. 물리적으로 서버 랙같은 것이 있어서 판처럼 생긴 컴퓨터를 수평을 꽂고 초코속 로컬 랜으로 연결하여 구성해놓은 것이 서버 클러스터이다.

Server Clusters

구성

First tier

client로부터 요청을 받아들여서 전달해주는 스위치 역할을 해준다. 클라이언트의 요청을 다 받는 front역할을 한다. 클라이언트의 요청을 적절히 분배해주는 라우팅 역할을 한다.

Second tier

Second tier의 서버가 애플리케이션 서버로 클라이언트의 요청을 직접 처리하는 역할을 한다.

Third tier

데이터베이스 서버라 생각하면 된다.

Multiple services

서버 클러스터를 구성할 때 하나의 서비스보다 여러 서비스를 제공하는 경우가 많다. Second tier에 있는 서버가 제공해주는 서비스를 다를 수 있다. 따라서 스위치의 역할이 중요하다. 서버스의 종류를 구분할 수 있어야 한다.

Access transparency

client 입장에서 동일한 방법으로 request를 날려서 reply를 받을 수 있으면 좋다. single access point를 제공해주는 것이 좋다. 확장성이나 가용성 측면에서는 access point를 여러개 가지고 있는 것이 일반적이다. 하나의 access point만 제공하면 single point of failure 문제가 생길 수 있다. 따라서 여러개의 사용 가능한 access point를 두지만 사용자에게는 하나의 access point만 제공해준다. 서버쪽에서는 실제 사용하는 access point가 바뀌더라도 클라이언트 측에는 감춘다.

Accessing a server cluster

클라이언트가 server cluster에 TCP로 연결하고 client로 부터의 TCP 연결 요청을 받아주는 역할을 하는 Transport-layer switches(하드웨어 스위치)를 사용한다. 하드웨어 스위치가 hands off 역할을 하여 클라이언트와의 연결을 적절한 서버로 넘겨준다. 하지만 클라이언트에게는 single access point를 제공하는 것처럼 보이게 한다. 실제 요청을 한 곳과 응답을 받는 곳이 물리적으로 다르지만 보내는 주소를 스위치의 주소로 넣어서 보낸다. TCP handoff 작업이 되려면 OS level에서 지원되어야 한다. 그래서 하드웨어 스위치가 필요하다.

 

Server Cluster Single Connection

Load distribution

서버들 사이에 부하를 분배해줘야 하는 경우가 있다. 서버 입장에서는 서버쪽의 리소스가 효율적으로 사용되는 것이 좋다. 따라서 First tier인 스위치의 역할이 중요하다. 단순한 솔루션은 round robin이 있다. 서버의 상태와 상관없이 순서대로 넘겨주는 것이다.
조금 더 advanced하게 서버를 선택하는 방법은 스위치가 서버 상태를 모니터링 하면서 클라이언트의 request를 적절히 분배하는 것이다. 더 나아간다면 스위치가 클라이언트로부터의 request가 어떤 종류인지 뿐만아니라 request 패킷 전체를 다 뜯어볼 수 있다. 스위치가 클라이언트의 정보를 더 많이 알기 때문에 더 적절한 서버로 넘겨줄 수 있다. 이를 content-aware request distribution이라 한다. 클라이언트가 요청하는 내용을 다 파악해서 적절히 분배해준다는 의미이다. 복잡해진 만큼 분배는 더 잘 해주지만 관리는 더 힘들어진다.

single access point의 문제인 single point of failure를 해결하기 위해 여러 access points를 둘 수 있다. 대표적인 예로 DNS가 있다. DNS의 경우 호스트 네임은 하나이지만 같은 host name을 사용하는 IP 주소는 여러개를 둘 수 있다. DNS의 approach를 그대로 사용하면 client가 알게된다. 클라이언트 쪽 미들웨어에서 애플리케이션 모르게 처리하면 되긴 한다. 물론 이런 방법을 써도 되지만 static access point, 즉 permenant한 하나의 access point를 클라이언트에게 제공해주고자 하는 원래의 철학에 벗어난다.

Flexible server cluster

static = stable. Stable access point로 client에게 노출되는 access point는 하나로 만들고 싶다. 하지만 실제 서버 클러스터에서는 access point 역할을 하는 서버를 flexible하게 만들고 싶다. 이 두 문제가 계속 맞물린다. 그래서 다양한 방법들이 나오기 시작했다. flexible하다는 것은 access point 역할을 하는 서버가 죽으면 다른 서버가 access point 역할을 할 수 있다는 것이다.

Distributed servers

이제는 Flexible server 보다는 Distributed servers라는 용어를 사용한다. Distributed servers는 머신의 집합이 dynamic하게 바뀔 수 있고 access point도 상황에 따라 바뀔 수 있지만 클라이언트에게는 하나의 강력한 서버와 계속 통신하고 있다는 느낌을 주는 것이다. 이것이 분산 시스템의 기본 개념이다. 서버 클러스터의 구성을 더 flexible하게 해준 것이 Distributed servers라고 보면 된다.

클라이언트가 stable한 서버의 시스템을 이용할 수 있게 해주지만 실제 서버들은 클러스터의 형태로 구성되어 경우에 따라 다른 서버가 대신 그 역할을 해주는 flexible한 구성이다.

MIPv6

모바일 디바이스를 기반으로 한다. 모바일 디바이스는 주로 상주하는 home 영역이 있다. 이를 home network라 부른다. home network안에는 agent 역할을 하는 것이 있다. agent는 라우터나 스위치같은 하드웨어 디바이스라 생각하면 된다. home agent는 이렇듯 자신이 관장하는 네트워크 범위가 있다. 외부에서 오는 트래픽은 home agent를 거쳐서 안에 있는 노드에 전달된다. home network안에는 노드가 있고 그 노드는 home agent로 부터 할당받은 stable한 주소가 있고 이를 home address라 부른다.


노드는 모바일 디바이스이므로 한 네트워크에만 머물지 않고 다른 home network로 들어갈 수도 있다. 이전에 사용했던 home address A는 더이상 의미없다. 다른 주소를 새로 받아야한다. 새로 받은 B라는 care-of address를 이전 home network의 agent에게도 알려준다. 따라서 이전 agent가 받은 요청을 새로 옮긴 home network로 forwarding해주므로 사용자는 stable한 주소로 계속 연결을 할 수 있다.

MIPv6(2)

 

분산 시스템과 MIPv6

서버들 중 하나가 access point 역할을 수행하고 자신의 주소를 home agent에 등록한다. 모든 트래픽은 home agent를 거쳐서 access point 역할을 하는 서버로 간다. 만일 access point 역할을 하는 B 서버가 고장났을 경우 다른 서버가 다시 등록하면 된다. 서버 입장에서는 사용 가능한 access point가 여러개라 single point of failure(SPOF) 문제를 해결할 수 있고 사용자 입장에서는 single access point만 제공받아 Access transparency를 제공할 수 있다.

Bottleneck problem of MIPv6

모든 트래픽이 하나의 에이전트로 몰리는 것을 해결하기 위하여 클라이언트도 알게 할 수 있다. 클라이언트 애플리케이션이 알도록 하는 것이 아니라 클라이언트의 미들웨어가 알도록 한다. 원래의 home address를 HA라 하고 현재의 care-of address (CA)라 하면 클라이언트가 pair (HA, CA)를 알도록 한다. 이 방식으로 하면 통신은 직접적으로 되지만 client app은 HA를 사용할 수 있다.

Bottleneck problem of distributed system

이를 해결하기 위해 access point의 역할을 하나가 아니고 동시에 여러개가 하도록 한다. 이런 방식으로 클라이언트로부터 오는 request를 분산할 수 있다. 여기서 home agent는 일단 혼자 다 받을 수밖에 없다. 따라서 하드웨어인 home agent의 성능이 좋아야한다. MIPv6의 방식에서 처럼 pair (HA, CA1)를 줘서 다른 access point로 갈 수 있도록 한다.

Bottleneck

Managing server clusters

관리자가 원격지에서 각각의 서버 노드에 연결해서 컴포넌트를 설치하거나 변경하는 작업을 원격으로 하는 방법도 있다. 보통은 관리자가 사용하는 관리 전용 머신이 있어서 한 명령을 내렸을 때 모든 서버에 적용되게 할 수 있다. 서버 여러개의 그룹에 하나의 오퍼레이션을 전달해줄 수 있어서 좋다.

서버의 개수가 굉장히 많은 경우 관리하기 어렵다. 서버가 N대이고 서버 한대가 고장날 확률을 p라 할 때 전체 서버가 고장나지 않고 돌아갈 확률은 (1-p)^N이다. 예를 들어 서버가 1000개이고 서버 한대가 고장날 확률이 0.001일 때, 전체가 고장나지 않고 잘 돌아갈 확률은 36%이다. 서버 한대가 고장날 확률이 0.1%인 것에 비해 굉장히 많이 올라간다. 대규모 시스템 관리는 사람이 하기에 점점 어려워진다. 따라서 self-managing solutions이 대두되고있다.

'Distributed System > 이론 공부' 카테고리의 다른 글

분산시스템) 커뮤니케이션  (0) 2020.08.26
분산시스템) 코드 마이그레이션  (0) 2020.08.21
분산시스템) 서버  (0) 2020.08.16
분산시스템) 클라이언트  (0) 2020.08.16
분산시스템) 가상화  (0) 2020.08.15