Chapter 2 - System Models [시스템 모델 (1/2)]

1. 서론 

디자인을 하기 위해선 The widest한 범위, 연산과 다양한 이슈를 고려가 필요

분산 시스템은 하부의 다양한 타입의 자산과 일반적 문제를 포함

어떻게(HOW) 디자인하는가? 

(1) Physical Model 

가장 직관적인 형태의 디자인

(2) Architectural Model

연산과 데이터 처리를 생각한 모델

(3) Fundamental Model (핵심 모델)

- interaction Model

- failure Model

- security Model

분산 시스템의 적용하기 어려운 이유.

- 넓게, 변경/변환되는 사용 Modes

: Workload의 변동성

- 넓은 범위의 시스템 환경

: 이질적인 하드웨어, OS, Network에 수용됨

- 내부의 문제

: 동기화를 위한 clocks의 부재

- 외부의 문제

: 데이터 공격, 보안 문제 

2. 내용 및 정리

(1) Physical Model

가장 하부에 존재하는 개념

- 초기 : 70s ~ early 80s 의 로컬 영역 개념의 네트워크 환경, 10~100의 LAN 환경

- 중기~ : 90s에 급격한 성장, OPEN STANDARD와 MIDDLEWARE의 발달

- 현대 :  모바일 컴퓨팅(laptops smartphone), 유비쿼터스 컴퓨팅, 클라우딩 컴퓨팅 그리고 클러스터 아키텍쳐

** ultra large-scale(ULS) distributed system

(2) Architectural Model

- 신뢰성, 관리의 편의성(Manageable), 적용성(Adaptable), Cost-effective 그리고 명료함과 각각의 추상화된 기능

- Server Process, Client Process, Peer Process

- 컴퓨터, 모바일에서 구현될 때, 추가 또는 삭제가 비가시적이어야 함. 

신뢰성, 관리 편의성, 적용성, 비용 효율성의 이유를 충족 시킬 방안

- 하위의 개체의 코어를 찾는다.

- Composite의 아키텍쳐적 패턴을 실험한다.

- MIDDLEWARE 플랫폼을 고려한다.

(2.1) Communicating entities

- 문제 해결 지향 언어 개념(객체 지향 언어), Problem-oriented abstractions

Object - DS에서 사용되는 객체 지향 언어

Components - Object가 결합되어 컴포넌트를 구성하며, 분산시스템에 인터페이스를 통해 접근  

* Web service

- Communication paradigms

Interprocess comunication : 분산처리시스템의 커뮤니케이션 프로세스에서 낮은 단계로 영향을 미친다.

* Message-passing primitives

* Direct access to the API offered by internet protocols

* Support for multicast communication

Remote invocation  : 원격 호출 

* Request invocation

   Request-reply protocols

   Remote procedure call (RPC)

   Remote method invocation (RMI)

        

Indirect communication

* Group communication : 메세지로 수혜자에게 전달되며, 일 대 다수로 진행됨

* Publish-subscribe system : 이벤트 중심으로 분배

  Message queues - 메세지 큐 방식

  Tuple spaces - 레코드 개념

  Distributed shared memory - 추상적 개념 분배

(2.2) Roles and responsibilities

- Client-Server : 일반적 서버와 클라이언트 관계

- Peer-to-peer : 서버와 클라이언트의 관계를 모호하게 만든 방식

(2.3) A service provided by multiple servers

하나의 서비스는 multiple servers에서 제공됨

(2.4) Placement

하위에 존재하는 multiple servers의 이슈 및 multiple servers의 service 

신뢰성, 실시간성, Quality를 어떻게 보장해야 할까?

배치 전략

- Mapping of service to multiple servers : 다양한 백업 서버 구현 및 파티션 활용

* Web / Sun Network Information service (NIS) 

*** SNIS의 경우 차후에 내용을 다루도록 하겠습니다.

- Caching : 다수의 코어를 활용할 경우 각 캐쉬 마다의 동기화 이슈가 발생

* Web proxy servers 활용

- 계층 구조

* two-tier solution

  Advantage : 한번의 호출을 통한 낮은 처리 시간

  Disadvantage :  어플리케이션 로직이 프로세스 범위를 가로지르면서 발생하는 파열

* Three-tier solution 

(2.4) Thin clients : 사용자 클라이언트의 경량화

* Real VNC

* Adventiq

* Apple Remote Desktop/Tight VNC/ Aqua Connect

(2.5) Other commonly occurring patterns

* Proxy

* Brokerage

* Reflection

** 남은 내용에 대해서는 추후 정리 하도록 하겠습니다.