분산시스템) 시스템 아키텍쳐(1) - 중앙 집중식

System architectures

분산 시스템은 논리적으로 또는 물리적으로 어디에 위치해 있어야 하는지, 시스템 소프트웨어의 역할에 따라 시스템 아키텍쳐를 고려할 수 있다. 이는 크게 Centralized architectures와 Decentralized architectures 두 가지 경우로 고려해 볼 수 있다. 위의 아키텍쳐 스타일과 연관지어서 생각할 수도 있지만 별개로 생각해 볼 수 있어 다른 관점이라고 볼 수 있다.

Centralized architectures

우리가 익히 알고있는 client-server 아키텍쳐이다. 클라이언트가 서비스를 서버에 request하면 서버는 reply하는 식으로 서비스를 이용한다.(Request-reply pattern) client는 일반적으로 request하고 reply가 올 때까지 기다린다.

centralized architectures

클라이언트-서버 모델이 Centralized architectures인 이유는 모든 서비스가 서버에 집중되어있기 때문이다. 중요한 것은 서버와 클라이언트간의 커뮤니테이션이다. 클라이언트와 서버가 통신할 때 Connetion-oriented Protocol(TCP)을 사용할지 Connectionless protocol(UDP)을 사용할지는 이용하려는 서비스 특성에 따라 고려해야한다.

1) 통신방식

(1) UDP

UDP를 사용해서 통신할 때에는 TCP에 비해 빨리 보낼 수 있다는 장점이 있다. 대신 그만큼 제공해주는 서비스가 없는 것이 단점이다. 전송이 보장되지 않기 때문에 client가 request를 보내고 reply를 기다리는 동안 reply가 오지 않을 수도 있다. 이 때 client에서 보낸 request가 소실된 것인지 server가 request를 받아 처리를 마치고 reply를 보냈지만 그 reply가 소실된 것인지 알 수 없다. 단순히 read만 할 경우 서버가 요청을 반복해서 받아도 상관 없지만 write하는 요청의 경우 반복해서 받을 경우 문제가 생길 수 있다.

서버에 동일한 요청을 여러번 반복해서 해도 문제가 되지 않는 경우를 idempotent하다고 한다.

(2) TCP

UDP의 이러한 문제점 때문에 TCP를 주로 사용한다. UDP의 경우 LAN환경에서는 패킷이 잘 소시될지 않지만 WAN 환경에서는 사용하기 어렵다. TCP의 경우 패킷 전송이 보장된다는 장점이 있지만 사전작업이 필요하다는 단점이 있다. 논리적인 connection을 맺은 다음에 맺은 connection을 통해서 통신하고 통신이 끝나면 connection을 끊어야한다. 이러한 작업을 반복적으로 작업한다면 cost가 커진다.

2) 장점

관리가 쉽고 보안이 좋다는 것이다. 대신 서버가 죽지 않는다는 가정하에서 이다.

3) Main issue

clear distinction

클라이언트와 서버의 역할을 분명히 하기 위해 software component를 클라이언트와 서버 중 어디에 둘 것인지 결정해야한다. 서버로 요청하는 전체적인 횟수를 줄이기 위해 특정 컴포는트는 클라이언트에 두는 것처럼 이러한 배치에 대해 미리 고려해야한다.

(1) User-interface level

UI의 주된 역할은 사용자와 직접 상호작용하는 것이다. 사용자가 필요한 경우 시스템에 input을 주고 그 input에 처리 결과 output을 사용자에게 제공하는 역할을 한다. 따라서 이에 대한 Display management가 필요하다.

User-interface level은 주로 client에 구현되는 것이 일반적이다. 유저 인터페이스 레벨은 단순한 인풋 아웃풋 작업 외에도 프로세싱 레벨과 상호작용하면서 더 복잡한 작업도 할 수 있다.

(2) Processing level

소프트웨어에서 가장 중요한 파트이다. 사용자의 요청을 처리하려면 그에 따른 데이터를 찾고 계산을 해야한다. 유저 인터페이스과 비교했을 때 프로세싱 레벨은 공통적인 부분이 없다. UI는 애플리케이션 종류에 따라 공통적인 부분이 많지만 프로세싱 레벨은 애플리케이션에 따라 다를 수밖에 없다.

application layering

(3) Data level

애플리케이션을 운영하는데 필요로하는 영구적인 데이터를 저장하고 관리한다. 일반적으로 서버단에 둔다. 분산 시스템의 목표 중 동시성 투명성(consistency transparency)이 깨지지 않도록 유지해야 한다. 데이터 레벨의 소프트웨어 컴포넌트에서 전체적인 데이터 관리를 담당해야한다. 애플리케이션의 특성에 따라 해당 컴포넌트의 기능이 복잡해질 수 있다.

(4) Multi-tiered architectures

단순히 생각하면 UI는 클라이언트에, 나머지는 서버에 둔다고 생각할 수 있지만 상황에 따라 다양하게 생각해볼 수 있다.

multi tiered architectures

• (a): 클라이언트는 사용자의 input을 서버로 전달해주는 역할만 하고 서버에서는 사용자에게 어떻게 결과를 보여줄 지 output에 대한 기능을 일부 수행한다. 위 application layering 그림에서 html file을 생성하는 것으로 볼 수 있다.
• (b): 클라이언트는 프로세싱을 전혀 하지 않고 서버가 전해주는 데이터를 화면에 뿌려주는 것만 한다. 오늘날 주로 사용되는 방식은 아니다.
• (c): 프로세싱 레벨이 나뉘어져서 클라이언트에서 일부 프로세싱 역할을 한다. 이전 예시 처럼 서버로 요청하는 횟수를 줄이기 위해 일부 클라이언트에서 처리하는 것을 예로 들 수 있다.
• (d),(e): (d)는 모든 데이터를 서버쪽에서 관리하는 것이고 (e)는 일부 클라이언트에서 담당한다. 예를 들어 뱅킹 서비스가 있다. 뱅킹 기기에서 일부 처리하고 나머지 서버에서 처리한다. 또 다른 예로 캐싱 기능이 있다.

multi tiered architecture2

분산 시스템에서 서버는 하나가 아니라 여러 개일 수 있기 때문에 서버가 레이어로 나뉘어질 수 있다. 따라서 화살표가 여러개가 되고 멀티플 서버가 계층적으로 구성될 수 있다. 가운데 있는 애플리케이션 서버는 서버이면서 클라이언트 역할도 할 수 있다.