분산시스템) 아키텍쳐

Architectures

분산 시스템을 구성하는 서버와 클라이언트 측의 아키텍처를 디자인 할 때 어떤 부분을 고려해야하는지 살펴보자. 아키텍쳐라는 것은 주로 하드웨어는 있다고 치고 이 분산 시스템을 구성하는 소프트웨어 컴포넌트들을 어떻게 구성해야할지에 대한 문제이다. 설계하려는 시스템의 소프트웨어가 어떤 구조를 가질지 설계하고 실제 설계한 내용을 개발해서 구체화하면 그게 시스템 아키텍쳐이다.

Goals of Distributed System and Architectures

이번 포스트에서 다루는 system architecture나 software architecture, 그냥 architecture 모두 software component들 사이의 관계를 어떻게 구성할건지에 대한 문제이다. 특히 일반 시스템이 아닌 분산 시스템을 개발할 때 소프트웨어 측면에서 목적을 살펴보면 개발하려는 애플리케이션과 underlying platforms을 분리하는 것이 중요하다. 애플리케이션을 돌리는 플랫폼은 OS를 포함한 개념이며, heterogeneous 할 수 있으므로 설계 단계부터 분리해서 생각해야한다. underlying platforms은 분산 시스템의 경우 많은 경우 미들웨어 레이어에서 숨겨준다. 애플리케이션은 미들웨어가 제공하는 서비스를 이용해서 구축될 수 있다. separation을 위해 middleware 개념이 많이 사용된다. 분산 시스템을 개발할 때 상황에 따라 가능한 한 distribution transparency를 지켜주는 것이 중요하기 때문이다.

 

그 다음 Adaptability를 제공해주면 좋다. 상황에 맞게 적응되는 시스템이면 좋다. 예를 들어 사용자의 달라진 행동 패턴에 따라 제공하는 서비스도 변화하면 좋다.

Architectural styles

1) Main topics

(1) Software architecture

이번 장에서 아키텍쳐는 소프트웨어의 아키텍쳐를 어떻게 처리할지에 대한 것이다. 분산시스템의 논리적인 구조를 소프트웨어 컴포넌트로 나타낸다.

(2) Component

분산 시스템 소프트웨어 아키텍쳐에는 여러 스타일이 있다. 구조의 스타일은 아키텍쳐를 구성하는 소프트웨어가 어떻게 구성되는지와 그 소프트웨어 컴포넌트들이 서로 어떻게 연결되는지, 데이터는 서로 어떻게 교환하는지 등에 따라 결정된다. 컴포넌트는 잘 정의된 modular unit이다. 컴포넌트로 구성하는 장점 중 하나는 replaceable하다는 것이다. 문제가 있거나 기능을 개선할 때 전체 소프트웨어를 건들지 않더라도 해당 unit만 수정할 수 있다.

(3) Connector

클래스나 프로세스나 컴포넌트 사이에서 데이터 교환을 어떻게 할지를 중재해주는 수단이 필요하다. 데이터를 전달하는 방법이 몇 가지 있다. Low layer입장에서 TCP/UDP를 사용할 수밖에 없고 컴포넌트에서 다른 컴포넌트로 전달하는 방법은 Remote Procedure Calls(RPC), message passing(socket), or streaming data(video or music) 등이 있다.

(4) Aiming at distribution transparency

사용자에게 제공하는 performance와 programming이 쉬워지는 것과 trade-offs 관계가 있다. distribution transparency를 키우면 programming이 쉬워지는 반면 사용자에게 제공하는 performance는 떨어질 수 있다.

2) Layered architectures

컴포넌트들이 레이어 관계에 있다. 위에 있는 레이어가 아래에 있는 레이어의 컴포넌트의 서비스를 이용하는 형태의 계층적 관계가 있다. 이는 지켜야될 규약이 있다는 것이다. 만약 Layer N이 바로 Layer 1의 기능을 사용한다면 레이어 계층 관계가 깨진다. Layer N이 Layer 1에서 제공되는 서비스를 사용하려면 계층적으로 인터페이스를 만들어서 연결을 해줘야한다는 단점이 있다.

대표적인 예는 네트워크 프로토콜들이 있다. 프로토콜을 하나의 뭉텅이가 아니라 레이어별로 역할을 구분지어서 제공한다. 이렇게 레이어로 아키텍쳐를 구성하면 소프트웨어를 컴포넌트로 구성했을 때의 장점이 잘 적용될 수 있다.

3) Object-based architectures

컴포넌트와 컴포넌트 사이에 특정한 제약 없이 루즈하다. Object-based architectures는 소프트웨어 컴포넌트를 object라고 본다. 어떤 한 object가 다른 object와 통신하고자 할 때 주로 (remote) procedure call mechanism을 사용한다. 로컬에서 자신의 함수를 호출하는 LPC(Local procedure call)와 달리 어떤 한 컴포넌트가 리모트에 있는 한 컴포넌트를 호출하는 것이다. 호출 될 수 있는 프로시저(함수)들을 외부로 인터페이스로 노출시켜놓고 다른 컴포넌트가 호출할 수 있도록 하는 것이다. 주로 client-server 통신 구조에서 많이 사용한다. 소켓처럼 transport layer를 직접 사용하여 통신하는 것이 아니고 간접적으로 RPC라는 기술을 사용하여 원격지에 있는 함수를 호출하는 것이다. 꼭 RPC를 사용하지 않더라도 컴포넌트들로 나누고 컴포넌트들 사이에 통신 구조를 사용하여 임의의 리모트에 있는 컴포넌트에 있는 서비스를 활용하면 이 범주에 들어갈 수 있다고 본다.

Layered architectures	Object-based architectures

4) Data-centered architectures

데이터 중심 아키텍쳐에서는 소프트웨어 컴포넌트들 사이에 통신하기 위해서 직접 통신하는 것이 아니고 서로 주고받는 모든 데이터를 저장할 중앙 데이터 저장소가 있다. 특정 컴포넌트는 다른 컴포넌트에게 메세지를 전달하고자 한다면 중앙 데이터 레퍼지토리에 데이터를 다 쓰고 다른 컴포넌트가 저장소로부터 데이터를 읽어가는 방식으로 통신한다.

(1) 웹 기반 분산 시스템

웹 기반 분산 시스템이 데이터 중심 아키텍쳐이다. 웹 서버와 웹 브라우저의 관계로 생각하면 된다. 데이터 저장소를 가진 웹 서버의 역할이 있고 그것을 이용하는 브라우저 역할이 있고 그것을 관리하는 컴포넌트의 역할이 있다. 웹 페이지를 만든 사람이 웹 페이지를 사용하는 사람들에게 직접 전달하는 것이 아니고 레퍼지토리 역할을 하는 서버에 넣어두고 그것을 사용하고 싶은 웹 브라우저는 레퍼지토리에 연결해서 가져간다.

(2) 장점

데이터 중심 아키텍쳐의 가장 큰 장점은 데이터를 전달하려 할 때 데이터를 받으려고 하는 컴포넌트가 없어도 된다는 것이다. 나중에 가져갈 수 있다. 만들어둔 데이터를 사용할 사용자가 언제 어디서 사용할지 모를 때 이 아키텍쳐를 사용한다. 언제 어디서든 접근할 수 있도록 데이터 센터에 넣어둔다. 다른 아키텍쳐는 이런 중앙 데이터 센터가 없이 직접 데이터를 주고받는다. 그러므로 컴포넌트들 사이에 서로 통신하고 싶은 컴포넌트들이 실행중이어야 한다.

 

data centered architecture

5) Event-based architectures

컴포넌트와 컴포넌트들 사이에 이벤트를 통해 통신하는 것이다. 받을 대상과 직접 통신하는 것이 아니고 전달하려는 메세지를 필요로하는 사람이 있으면 지금 가져다 쓰라고 던져두는 것이 이벤트 기반 아키텍쳐이다. 한 컴포넌트가 데이터를 생성하고 누구에게 전달해야할 지 모를 때 이벤트 버스 오브젝트에 데이터를 던지다. 이벤트 버스는 모든 컴포넌트들 사이의 데이터 전달 목적지를 알고있어서 받은 데이터를 목적지 컴포넌트에 전달해준다. 미들웨어 레이어에서 이벤트 버스 역할을 할 수 있도록 한다. 이벤트 기반 아키텍쳐에서 데이터를 받고자하는 컴포넌트는 사전에 어떤 데이터를 받고자하는지를 이벤트 버스에 등록해야한다.

그림
모델명	publish/subscribe model	Shared data spaces
특징	publish는 데이터를 이벤트 버스에 올리는 것이고 subscribe는 관심사를 등록하여 해당 데이터가 들어왔을 때 이벤트 버스는 subscriber들에게 전달해준다. 이 때 publisher와 subscriber는 서로에 대해 모른다.	이벤트 기반 + 데이터 중심 아키텍쳐를 합친 형태이다. 이벤트 버스의 역할을 하면서 데이터 레퍼지토리의 역할도한다.
차이점	데이터 중심 아키텍쳐와의 차이점은 이벤트 버스는 전달의 역할을 하는것이지 저장을 하는 것이 아니기 때문에 publisher와 subscriber가 동시에 접속해 있어야 한다. 그러므로 온도 정보 처럼 해당 정보가 지금 아니면 필요없는 경우에 사용한다.	나중에 사용할 수 있도록 데이터 레퍼지토리처럼 저장하는 역할도 가능하게 한다.
활용	요새 IoT에서 센서 데이터를 전달할 때 주로 사용한다.