Distributed System 4

소프트웨어 아키텍처 스타일 (이어서)

Resource-based Architecture(리소스 기반 아키텍처)

리소스 기반 아키텍처는 객체 기반 아키텍처의 하위 아키텍처라고 생각하면 된다.

분산 시스템을 리소스의 모음으로 보고, 각 리소스는 컴포넌트에 의해 개별적으로 관리된다.

 

리소스 기반 아키텍처의 대표적인 예시로 RESTful 아키텍처가 있다.

아래는 RESTful 아키텍처의 특징이다.

• 리소스는 단일 명명 스킴을 통해 식별된다. 모든 리소스는 고유한 식별자를 가지고 있다. (e.g. URL)
• 모든 서비스는 동일한 인터페이스를 제공한다. RESTful 아키텍처에서는 HTTP 메서드가 인터페이스 역할을 한다.
• 서비스로부터 보내지거나 서비스로 보내지는 메시지는 완전히 자기 설명적이다(self-desribed). 각 메시지는 그 자체로 필요한 모든 정보를 포함하고 있어, 추가적인 설명 없이도 이해되고 처리될 수 있다.
• 컴포넌트는 서비스에서 작업을 수행한 후 모든 것을 잊어버린다. 즉, 특정 작업을 수행한 후 상태를 유지하지 않으며 다음 요청에 의해 새롭게 시작한다. 이를 무상태성(stateless)이라고 한다.

REST는 Representational State Transfer의 약자로, HTTP URI(Uniform Resource Identifier)를 사용하여 리소스를 식별하고 접근한다. HTTP 메서드로 CRUD 오퍼레이션을 제공한다. Create(POST), Read(GET), Update(PUT), Delete(DELETE)가 CRUD 오퍼레이션이다.

 

RESTful API의 예시를 들면,

Add a new member (newbie라는 새로운 멤버를 members에 추가)→ POSThttps://api.dankook.com/v1/members/newbie

List up all members→GEThttps://api.dankook.com/v1/members

딱히 설명하지 않아도 어떤 작업을 하는지 충분히 이해할 수 있다.

 

REST 정책을 모두 따르는걸 RESTful API라고 한다.

REST정책은 다음과 같다.

• 클라이언트-서버: 서버 측에서 리소스를 관리하고, 클라이언트 측에서 리소스를 요청한다.
• 통일된 인터페이스: 모든 서비스는 HTTP기반의 동일한 인터페이스를 제공한다. 리소스는 단일 명명 스킴을 통해 식별된다.
• 자기 설명성: 서비스로부터 보내지거나 보내지는 (JSON)메시지는 자기 설명적이다.
• 무상태 실행: 서비스에서 작업을 수행한 후에는 아무것도 유지하거나 저장하지 않는다. 컴포넌트는 호출자에 대한 모든 정보를 잊어버린다.
• 캐싱 가능: 웹 캐싱을 사용할 수 있다. 클라이언트는 서버로부터 받은 응답을 캐싱할 수 있으며, 이후 동일한 요청에 대해 캐시된 응답을 재사용할 수 있다.
• 계층화된 시스템: 클라이언트와 서버 사이에 다른 컴포넌트들을 추가할 수 있다.

 

Data-centered Architecture(데이터 중심 아키텍처)

프로세스들이 공통의 저장소를 통해 통신하는 방식이다. 즉, 시스템의 구성 요소들이 데이터 저장소를 중심으로 상호작용하는 구조이다.

• Repository Architecture Style: 수동적인(passive) 형태이다. 클라이언트가 시스템에 요청을 보내 특정 작업을 수행하고, 저장소는 클라이언트의 요청에 따라 데이터를 제공하거나 조작한다.
• Blackboard Architecture Style: 능동적인(active) 형태이다. 시스템이 저장소에서 변화가 발생할 때마다 트리거라는 알림을 데이터와 함께 전송한다. 데이터가 변경될 때마다 관련 프로세스들에게 알람을 보내는 것이다.

데이터 중심 아키텍처

 

Event-based Architeture(이벤트 기반 아키텍처)

프로세스들이 이벤트의 전파를 통해 통신하며, 이때 이벤트는 선택적으로 데이터를 포함할 수 있다.

프로세스들은 느슨하게 결합되어 있으며, 서로를 참조할 필요가 없다. 컴포넌트끼리 직접 통신을 하지 않아서(미들웨어를 거쳐 통신) 의존성이 낮은 것이다.

이벤트 기반 아키텍처

 

이벤트 기반 아키텍처에는 Publish/Subscribe System을 사용하는데, 프로세스들이 이벤트를 발행(publish)하면 미들웨어가 해당 이벤트에 구독(subscribe)한 프로세스들만 이벤트를 수신할 수 있도록 해준다.

 

퍼블리셔와 구독자 간의 상호작용은 느슨하게 결합되어 있어, 서로 직접적인 의존성이 없다. 구독자는 특정 이벤트나 이벤트 패턴에 대한 관심을 표현할 수 있고, 퍼블리셔가 생성한 이벤트 중 일치하는 것이 있으면 구독자는 알림을 받는다. 이벤트는 비동기적으로 전파되며, 그 이벤트에 구독한 모든 구독자들에게 자동으로 전달된다.

Pub/Sub System

퍼블리셔는 아이템을 전부 미들웨어에 던져 놓으면, 미들웨어가 자동으로 알맞은 구독자들에 알림 보내고 아이템을 전송시키기 때문에 퍼블리셔와 구독자 사이의 의존성이 낮은 것이다. 

 

Pub/Sub System에서는 세가지 차원의 Decoupling(서로 함께 움직이지 않는 것)이 있다.

• Space Decoupling(공간적 디커플링): 상호작용하는 당사자들이 서로를 알 필요가 없다. 
• Time Decoupling(시간적 디커플링): 상호작용하는 당사자들이 동일한 시간에 상호작용을 참여할 필요가 없다. 퍼블리셔가 이벤트를 발생시킬 때 구독자가 실행 중일 필요가 없으며, 역시나 구독자가 이벤트를 받을 때 퍼블리셔가 실행 중일 필요가 없다는 뜻이다.
• Synchronization Decoupling(동기화 디커플링): 퍼블리셔는 이벤트를 생성할 때 블로킹되지 않으며, 구독자는 비동기적으로 이벤트 알림을 받을 수 있다. 즉, 퍼블리셔는 이벤트를 생성하면서 다른 작업을 계속할 수 있고, 구독자는 자신이 수행 중인 다른 작업과 병행하여 알림을 받을 수 있다.

이러한 디커플링, 정보의 생성과 소비를 분리하는 것은 상호작용하는 당사자들 간의 명시적 의존성을 제거하여 확장성을 높인다. 이는 시스템이 더 많은 당사자들을 효율적으로 처리할 수 있게 하며, 시스템의 유연성을 강화한다. 

 

Pub/Sub System에도 종류가 있다.

• Topic-based Pub/Sub: 주제(topic) 개념 이전에는, 채널을 사용하여 퍼블리셔와 구독자 사이를 연결했다. 주제는 채널의 개념을 확장하여, 이벤트의 내용을 특성화하고 분류할 수 있는 방법이다. 이벤트는 고유한 이름이나 키워드를 통해 식별된다.

주제 기반 Pub/Sub

• Content-based Pub/Sub: 주제 기반 구독을 개선한 방식으로, 이벤트의 실제 내용에 기반한 구독 방식이다. 구독자는 특정 주제뿐만 아니라 이벤트의 속성에 따라 선택적으로 구독할 수 있다. 필터를 지정하여 관심 있는 이벤트만 구독할 수 있고, 이 필터는 (속성-값)쌍과 기본 비교 연산자의 형태로 정의되며, 이를 기반으로 이벤트를 식별한다. 예시를 들자면, (institute=="DKU", department=="CE", GPA>3.0) → DKU대학의 CE학과의 GPA가 3.0이상인 학생과 관련된 이벤트를 구독
• Type-based Pub/Sub: 주제는 일반적으로 이벤트의 내용 뿐만 아니라 구조에서도 공통점을 가지는 이벤트들을 그룹화한다. 따라서 이벤트의 이름 대신 이벤트의 타입을 기준으로 분류하고 구독하는 방식이다. 이러한 방식을 사용하면, 결과 코드에서 타입 캐스트를 사용하지 않아도 되기 때문에 타입 안전성을 보장할 수 있다. 또한, 이벤트의 캡슐화가 보장되어 안전한 구독 서비스를 구현할 수 있다.

 

Shared Data-Space Architecture(공유 데이터 공간 아키텍처)

이벤트 기반 아키텍처와 데이터 중심 아키텍처가 결합된 아키텍처이다. 프로세스들은 시간적으로 디커플링되어 있어, 통신이 이루어질 때도 서로 활동 중일 필요가 없다. 공유 저장소에 접근할 때는 SQL과 유사한 인터페이스를 사용한다.

공유 데이터 공간 아키텍처

---

수업하실 때마다 어마어마한 양의 진도를 나가시는 교수님. 제 머리가 따라가고 있지 못하지만 최대한 열심히 해보겠습니다.

 

** 대학교 수업을 듣고 이해한 부분을 최대한 풀어서 작성한 글입니다.

틀린 정보가 존재할 수 있으며, 언제나 피드백은 환영입니다. **