[DS] 분산 시스템(Distributed Systems) - 2. Architectures 정리

본 글은 Distributed Systems 책의 내용을 개인 공부 목적을 위한 요약 및 정리한 내용입니다.
오타나 오류는 알려주시길 바라며, 도움이 되길 바랍니다.
2023.04.25 Update

글을 읽으면서 스스로에게 물어보기

1. 왜 만들어 졌을까?(background, def)
2. 왜 필요할까? (why?)
3. 장점과 단점은 무엇인가? (adv, disadv)

Chapter 2. ARCHITECTURES

• 분산시스템의 조직은 시스템을 구성하는 소프트웨어 요소이다.
• 이런 소프트웨어 아키텍처를 얼마나 다양한 소프트웨어 컴포넌트가 이뤄졌는지와 어떻게 협력하는지를 말할 것이다.
  • 소프트웨어 아키텍처: 컴포넌트 단위로 기능을 나눴는데 컴포넌트끼리 어떻게 협력할 건지 결정하는 것을 말한다.
• 분산 시스템의 중요한 목표는 미들웨어 계층을 제공하는 플랫폼으로부터 어플리케이션을 분리하는 것이다.
  • 이러한 계층을 쓰는 것은 중요한 아키텍처 결정이며, 분산 투명성을 제공하는 것이다.

2.1 Architectural styles

• 아키텍처 스타일은 서로 연결되고 데이터는 컴포넌트들 사이에서 교환되는 컴포넌트들로 형성되며,이런 요인들이 시스템으로 구성된다.
• 컴포넌트 (component)는 잘 정의된 필수 및 제공, 교체 가능한 인터페이스를 가진 모듈식 단위이다.
  • 요소가 특히 시스템이 실행될 때 교체될 수 있어야함은 중요하다.
• 커넥터 (connector)는 컴포넌트 간의 통신, 협력을 중재하는 매커니즘이다.
  • 커넥터는 요소들 간의 제어와 데이터의 흐름을 허용한다.
• 요소와 커넥터를 사용하여 다양한 구성을 만들 수 있으며, 이는 아키텍처 스타일을 분류하게 되었다.
  • Layered architectures
  • Object-based architectures
  • Resource-centered architectures
  • Event-based architectures

Layered architectures

• 컴포넌트들이 $L_j$에 있는 컴포넌트가 낮은 수준에 있는 컴포넌트 $L_i$에게 다운콜하고 응답을 기대하는 레이어드 방식으로 구성되어 있다.
  • 특출난 케이스가 하이레벨 컨포넌트로 업콜 할 때이다.

• (a)는 다음 하위 계층에 대해 다운콜만 수행되는 표준 구조를 보여준다.
  • 이 구조는 네트워크 통신에 주로 보인다.

Layered communication protocol

• 통신-프로토콜 스택에서 각 계층은 데이터를 목적지로 보내는 것을 허용하는 하나 또는 몇몇의 통신 서비스를 실행한다.
• 이를 위해 각 계층은 요청될 수 있는 함수를 명시할 수 있는 인터페이스를 제공한다.
• 프로토콜 (protocol)은 당사자들이 정보 교환을 위해 따라야 하는 규칙을 말한다.
• 서비스는 계층에 의해 제공되고, 인터페이스는 서비스를 이용할 수 있게 해 주고, 프로토콜은 계층이 통신을 수립하기 위해 실행한다.
• TCP(Transmission Control Protocol)는 메시지가 연결 설정 또는 해제를 위해 교환되는 것을 명시하는 것을 말한다.
  • 이는 전송된 데이터의 순서를 보존하기 위해서 필요로 하며, 전송하는 동안 잃어버렸던 데이터를 감지하고 바로잡기 위해서 사용한다.

• Two communicating parties

from socket import *

# A simple server
s = socket(AF_INET, SOCK_STREAM) # 소켓 = 연결을 위한 출입구
(conn, addr) = s.accept()  # accept : 수신 연결 요청을 대기하기 위한 blocking 호출
while True:
    data = conn.recv(1024)
    if not data: 
        break
    conn.send(str(data)+'*') # send를 통해 각 데이터를 보낸다.
conn.close()

# A client
s = socket(AF_INET, SOCK_STREAM)
s.connect((HOST, PORT)) # 지정된 상대방에 대한 연결 설정 
s.send('Hello, world')
data = s.recv(1024) # recv를 통해 각 데이터를 요청한다.
print data
s.close() # 연결 끊기

Application layering

• 애플리케이션은 대략 세가지 부분으로 구성돼 있다.
  1. 사용자나 외부 애플리케이션과의 상호작용을 처리하는 부분 (The application-interface level)
  2. 데이터베이스나 파일시스템에서 작동하는 부분 (The data level)
  3. 어플리케이션의 핵심 기능들을 포함하는 중간 지점 (The processing level)
     • 중간 부분은 processing level에 논리적으로 위치해 있다.
• 프로세싱 부분에 대한 예제1. 인터넷 검색 엔진
  • 사용자는 키워드 문자열을 치면 웹페이지의 제목 목록들이 보여질 것이다.
  • 백엔드는 프리패치되고 인덱스되는 웹 페이지의 거대한 데이터베이스에 의해 형성된다.
  • 검색 엔진의 핵심은 키워드의 유저의 키워드를 하나 혹은 다른 데이터베이스 쿼리로 전송하는 프로그램이다.
  • 그 후에 결과들이 리스트로 랭크되고, 리스트를 HTML 페이지에 전송한다.
  • 정보 회수 파트는 프로세싱 수준에 있다.

  

• 프로세싱 부분에 대한 예제2. 부동산 중개업을 위한 의사결정 시스템
  • 3가지 구성요소
    • 유저 인터페이스를 실행하거나 프로그래밍 인터페이스를 외부 애플리케이션에 제공하는 프론트엔드
    • 금융 데이터가 있는 데이터베이스에 접근을 위한 백엔드
    • 이런 2개 사이의 분석 프로그램
• 프로세싱 부분에 대한 예제3. office 365는 통합 문서 관리를 지원하고, 유저의 홈 경로로부터의 파일들을 실행시켜주는 공통 유저 인터페이스를 통해 통합된다.

• processing level은 프로그램의 큰 집합으로 구성되어 있다.

• 데이터 수준(data level)은 애플리케이션이 작동하는 곳에서 실제 데이터를 유지하는 프로그램을 포함한다.
  • 데이터는 애플리케이션이 실행되고 있지 않더라도 지속적이여서, 데이터는 다음 유저를 위해 어느 곳에 저장될 것이다.
  • 데이터 수준은 다른 애플리케이션을 거칠 때 데이터 일관성을 지켜야 하는 책임이 있다.

Object-based and service-oriented architectures

• 각 객체는 컴포넌트라 정의한 것과 일치하며, 이런 컴포넌트들은 프로시저 호출 방식을 통해 연결되었다.
• 객체기반 아키텍처는 데이터(state 또는 field)와 데이터에 수행되는 동작(method)을 단일 엔티티로 캡슐화하는 방식을 제공한다.
  • 캡슐화 또는 인캡슐레이션(encapsulation) : 객체의 데이터와 기능을 하나로 묶고 외부에 노출되지 않도록 숨김 처리하는 것 (데이터 보호)
• 객체에 의해 제공된 인터페이스는 실행의 세부 사항들을 숨긴다.
• 인터페이스가 잘 정의되어 있고, 다른 부분은 건드리지 않는다면, 객체는 정확히 같은 인터페이스로 대체되어야 한다.
• 인터페이스와 이런 인터페이스를 실행하는 객체 간의 분리는 장치에 있는 인터페이스를 두게 허용하며, 객체 본래는 다른 장치에 있게 한다. (분산 객체(distributed object라 한다.)
• 용어 정리
  • 객체 (object) : 사물(소프트웨어 또는 시스템)을 표현하는 단위 (프로그래밍)
  • 개체 (entity) : 정보를 표현하는 단위 (이미있는 속성들이 모인 것)

• 클라이언트가 분산 객체를 묶을때, 객체의 인터페이스(=proxy)의 실행은 클라이언트의 주소 공간으로 적재된다.
• 프록시는 오직 메시지로의 마샬 메서드 호출과 메서드 호출의 결과를 클라이언트로 반환하기 위한 언마샬 응답 메시지만 받을 수 있다.
  • 프록시 (proxy) : 컴퓨터 네트워크에서 다른 서버 상의 자원을 찾는 클라이언트로부터 요청을 받아 중계하는 서버
    • proxy는 RPC 시스템의 클라이언트 스텁과 유사하다.
    • 마샬링(marshalling)은 객체의 메모리 표현을 스토리지 또는 전송에 알맞는 데이터 포맷으로 변형의 프로세스이다.
• 수신 호출 요청이 먼저 서버 스텁으로 가면, 그들을 서버의 객체의 인터페이스에 있는 메서드 호출을 만들기 위해 언마샬한다.
  • 서버 스텁(server stub)은 응답을 마샬링하고, 클라이언트측 프록스에게 응답 메시지를 보내는 일을 담당한다.
• 서버측 스텁(=skeleton)은 서버 미들웨어가 사용자 정의된 객체를 통과하기 위한 수단을 제공한다.

• 대부분의 분산 객체들의 특징은 상태(state)가 분산되어 있지 않고 단일 시스템에 상주한다는 것이다.
  • 분산 객체에서 상태 본래 물리적으로 다중 시스템으로 분산되어 있지만, 이런 분산은 또한 객체의 인터페이스 뒤에 있는 클라이언트로부터 숨겨져 있다.
• 객체기반 아키텍처는 서비스가 독립적인 단위로 캡슐화하는 토대를 형성한다.
• 독립적으로 작동하는 다양한 서비스들을 분리함으로써, 우리는 서비스 기반 아키텍처(SOAs; service-oriented architectures)로 갈 수 있게 되었다.

Resource-based architectures

• 웹 너머로 서비스의 수의 증가와 서비스 구성을 통한 분산시스템의 발달이 더 중요해짐에 따라, 연구자들은 웹기반 분산 시스템의 아키텍처를 다시 생각해보기로 했다.
• 서비스 구성의 문제점 중 하나는 다양한 컴포넌트를 연결하는 것이 통합이 엉망이 될 수 있다는 점이다.
• 대안으로 분산 시스템을 각각이 컴포턴트에 의해 관리되는 거대한 자원의 집합으로 보는 것이다.
• 리소스들은 (원격) 애플리케이션에 의해 추가되거나 제거되고, 검색 또는 수정된다.
• 이런 접근이 지금은 웹에 널리 채택되었고, REST(Representational State Transfer)로 알려졌다.
• RESTful 아키텍처의 4가지 특징이 있다.
  1. 리소스들은 단일 이름 스키마를 통해 식별된다.
     • 스키마 (scheme) : 데이터베이스에서 자료의 구조, 표현 방법, 자료 간의 관계를 형식 언어로 정의한 구조 (정형화하여 표현)
     • 명명 스키마(naming scheme) : 네임을 붙일 때 어떤 규칙을 가지고 붙임
  2. 모든 서비스는 많아 봐야 4가지 작동으로 구성된 같은 인터페이스를 제공한다.

  

  1. 서비스로부터 보낸 메시지들은 self-described이다.
  2. 서비스에서 동작을 실행한 후에, 컴포넌트는 호출자에 대해 모든 걸 잊어버린다.(=stateless execution)
• RESTful은 Amazon S3(Amazon’s Simple Storage Service)같은 클라우드 스토리지 서비스를 생각해본다.
• Amazon S3는 오직 두가지 리소스를 지원한다.
  1. object : 파일(file)
  2. bucket : 디렉토리(directory)
• BucketName에 포함된 ObjectName 객체는 URL을 통해 참조된다.
• ex) s3.amazonaws.com/BucketName/ObjectName
• bucket이나 object을 생성하기 위해서는 애플리케이션이 bucket/object의 URL과 함께 PUT 요청을 보내야 한다.
• HTTP 요청은 S3에 의해 올바르게 해석될 것이다.
  • 버킷이나 객체가 이미 존재한다면, HTTP 에러 메시지가 반환된다.
• 유사한 방식으로, 객체가 버킷에 포함되는지를 알기 위해, 애플리케이션은 버킷의 URL과 함께 GET 요청을 보낸다.
  • S3는 일반적인 HTTP 응답으로 객체 이름의 목록을 반환해줄 것이다.
• RESTful 아키텍처는 단순함때문에 대중화되었다.

event-based coordination

Publish-subscribe architectures

• 시스템이 꾸준히 성장하고 프로세스들이 쉽게 합류하거나 떠나는 게 가능해지면서, 프로세스 간의 의존성이 느슨해지는(loose) 아키텍처를 가지는 것은 중요해졌다.
• 큰 분산 시스템 클래스는 처리(processing)와 조정(coordination) 간의 강한 분리가 있는 아키텍처를 채택했다.
• 이 생각은 시스템을 독립적으로 작동하는 프로세스들의 집합으로 보는 것이다.
  • 조정 (coordination)은 프로세스 간의 통신과 협력을 말한다.
    • coordination : 여러 노드 사이에서 벌어지는 일에 대해서 뭔가를 조정하는 것을 말한다.
    • 이것은 프로세스에 의해 수행되는 활동들이 전체로 묶여지는 결합을 형성한다.

  

• 시간 결합(Temporal coupling)은 두 개의 모듈이 서로 동시에 실행되어야 하는 경우를 의미한다.
  • 즉, 한 모듈이 실행되는 도중에 다른 모듈도 실행되어야 하는 경우이다.
  • 이러한 경우 두 모듈은 시간적으로 결합되어 있다고 볼 수 있지만 이는 시스템의 유연성을 저하시키고 유지보수를 어렵게 만들 수 있다.
• 참조 결합(Referential coupling)은 한 모듈이 다른 모듈의 내부 데이터나 메소드를 직접 참조하는 경우를 의미한다.
  • 이는 모듈 간에 강한 결합도를 만드는데, 만약 다른 모듈의 내부 구현이 변경된다면 그에 따라 참조하는 모듈도 변경해야 할 수 있다.
  • 이러한 경우 모듈의 재사용성을 저하시키고 시스템을 유연하게 변경하기 어렵게 만들 수 있다.
  • 따라서 가능하다면 모듈 간에 참조를 최소화하고 인터페이스를 이용하여 모듈 간의 통신을 할 수 있도록 설계하는 것이 좋다.

• direct coordination
  • Temporally coupled, Referentially coupled의 경우
  • 하나의 모듈이 변경되면 다른 모듈도 변경되어야 할 가능성이 높다.
  • 시스템의 유연성과 유지 보수성을 떨어뜨리는 데 기여할 수 있다.
• mailbox coordination
  • Temporally decoupled, Referentially coupled의 경우
  • 이 경우 모듈은 독립적으로 개발될 수 있지만 다른 모듈을 사용하는 방법에 대한 정보를 가져야 한다.
  • 통신 프로세스가 동시에 실행될 필요가 없다. 대신에 통신은 메시지를 메일 박스에 넣음으로써 발생한다.
  • 코드의 재사용성과 이식성을 향상시킬 수 있지만 유지 보수성과 시스템의 복잡도를 높일 수 있다.
• event-based coordination
  • Temporally coupled, Referentially decoupled의 경우
  • 참조 분리 시스템에서는 프로세스들은 명시적으로 서로 알지 못한다.
    • 프로세스가 유일하게 할 수 있는 건 이벤트의 현상을 나타내는 알림을 발행(publish)받는 것이다.
    • 모든 종류의 알림이 온다면, 프로세스는 특정 종류의 알림을 구독(subscribe)해야 한다.
• shared data space
  • Temporally decoupled, referentially decoupled의 경우
  • 프로세스들은 전부 튜플(tuple)을 통해 통신한다.
  • 튜플을 검색하기 위해, 프로세스는 튜플에 맞는 검색 패턴을 제공한다.
  • 공유 데이터 공간은 가끔 이벤트 기반 조정과 결합된다.
    • 프로세스는 검색 패턴을 제공함하여 특정 튜플을 구독한다.
  • 키의 특징으로 프로세스는 서로 명시적 참조를 가지고 있지 않다.
  • 또한 그림에서 발행자와 구독자가 매치되는 (event bus로 알려짐) 메커니즘의 추상화를 볼 수 있다.

• description이 (attribute, value)로 구성된다면 topic-based publish-subscribe systems이라 부른다.

• 구독은 알림에 대해 매치되어야 한다.
• 이벤트는 실제로 이용가능한 데이터에 해당한다.
• 매칭이 성공하면, 두가지 시나리오가 있다.
  1. 미들웨어는 관련 데이터와 함께 발행된 알림을 보내는 것을 결정한다.
  2. 미들웨어는 구독자가 읽기 동작을 실행해 관련 데이터를 검색할 수 있는 알림지점을 보낸다.
• 저장은 별도 서비스에 의해 관리되거나 구독자의 몫이다.
  • 다시 말해, 참조 분리이지만 시간 결합 시스템을 가지고 있다.

• 이벤트는 구독 처리를 쉽게 복잡하게 만든다.
• 중요한 이슈는 구독을 알림으로 매칭하는 효율적이고 확장 가능한 실행이다.
• 발행-구독 아키텍처는 강한 프로세스 분리때문에 아주 큰 규모의 분산 시스템을 쌓는데에 많은 것을 제공한다.

2.2 Middleware organization

• 미들웨어의 조직에 적용되는 디자인 패턴의 유형으로 래퍼(wrapper)와 인터셉트(interceptor)가 있다.
  • 각각은 다른 문제를 목표로 하지만 미들웨어에 개방성(open)을 얻는 목표를 보낸다.

Wrappers

• 기존 컴포넌트로 분산 시스템을 구축할 때 레거시로 제공되는 인터페이스는 모든 애플리케이션에 적용되지 않는다는 문제가 생긴다.
• wrapper나 adapter는 이것의 기능들을 컴포넌트에서 가능한 곳으로 전송하는 인터페이스를 클라이언트 애플리케이션에 접근가능하게 해주는 특별한 컴포넌트이다.
• object adapter는 객체들이 관련 데이터베이스의 테이블에서 동작하는 라이브러리의 결합으로써 실행된다 할지라도 애플리케이션이 원격 객체를 호출할 수 있는 컴포넌트이다.
• 아마존 S3 스토리지 서비스는 RESTful 아키텍처, 기존 접근을 따르는 두 타입의 가능한 인터페이스가 있다.
  • RESTful 인터페이스를 위해, 클라이언트는 HTTP 프로토콜을 사용하게 되는데, 실제 스토리지 서비스의 어댑터 역할을 하는 기존 서버와 본질적으로 통신하는, 들어오는 요청을 부분적으로 나누고 결과적으로 그들을 S3의 특수 서버 내부에 넘겨준다.
• wrapper는 기존 컴포넌트를 가지고 시스템을 확장하는데 중요한 역할을 한다.
  • 래퍼 (wrapper) : 활동범위를 설정하고 좀더 중요한 다른 프로그램의 실행을 가능하게 하는 프로그램이나 스크립트 ¹
  • 개방성을 달성하는데 중요한 확장성이 필요하면 wrapper를 추가해 보내지곤 했다.
  • 다시 말해, 애플리케이션 A가 애플리케이션 B가 필요로 했던 데이터를 관리했다면, B에 특화된 wrapper를 개발하여 A 데이터에 접근할 수 있도록 하는 것이다.
    • N 애플리케이션이 있다면 $N \times (N-1) = O(N^2)$ wrapper를 개발해야 한다.
• wrapper의 수를 줄이는 건 미들웨어를 통해 행해진다.
  • 논리적으로 다른 애플리케이션 간의 모든 액세스를 다루는 컴포넌트가 중앙 브로커(broker)를 실행한다.
  • 브로커가 각각 애플리케이션에게 단일 인터페이스를 제공하기 때문에 우리는 $O(N^2)$ 대신에 많아봐야 $2N = O(N)$가 필요할 뿐이다.

Interceptors

• 개념적으로 인터셉터(interceptor)는 제어의 일반적인 흐름을 깨고 다른 코드가 실행될 수 있도록 하는 소프트웨어 구조일 뿐이다.
• 인터셉터는 미들웨어를 애플리케이션의 특정한 필요로부터 적용하는데 주요 수단이다.
  • 따라서 인터셉터는 미들웨어를 개방(open)하는데 중요한 역할을 한다.
  • 인터셉터를 포괄적으로 만드는 것은 상당한 실행 노력이 필요할 것이며 이러한 경우 일반화가 제한된 애플리케이션과 단순함보다 좋다고 말하는 것은 확실치 않다.
  • 또한, 많은 경우 오직 제한된 인터셉터를 가지는 것은 소프트웨어 관리와 분산시스템을 향상시킬 것이다.

• 객체 A는 객체 B에 속한 메서드를 호출하지만 객체 A는 A와 다른 시스템에 있다.
• 이런 원격-객체 호출은 3단계에 걸쳐 수행된다.
  1. 객체 A는 객체 B에 의해 제공되는 것과 정확히 같은 로컬 인터페이스를 제공받는다. A는 메서드를 그 인터페이스에서 가능하게 호출한다.
  2. A에 의한 호출은 A가 상주하는 장치에 있는 미들웨어에 의해 제공되고 일반 객체 호출 인터페이스를 통해 만들어진 일반 객체 호출로 변형된다.
  3. 마지막으로, A의 로컬 운영 체제에 의해 제공되어 전송 수준 네트워크 인터페이스를 통해 보내지는 일반 객체 호출은 메시지로 변형된다.

• 이제 객체 B가 복제된다고 생각해보면, 각 복제품은 실제로 호출되어야 한다.
• 이 부분은 인터셉션이 도와줄 수 있다. 이걸 request-level interceptor이 할 수 있으며, 복제품 각각에 invoke(B, &doit, val)을 호출한다.
  • 객체 A는 B의 복제품을 알지 못하고, 미들웨어에 추가된 요청 수준 인터셉터만이 B의 복제를 알 수 있다.
• 마침내, 원격 객체에서의 요청은 네트워크를 통해 보내질 것이다.
• 실제로, 로컬 운영 체제에 의해 제공된 메시지 인터페이스는 호출을 필요로 할 것이다.
  • 이 수준에선, message-level interceptor는 호출을 목표 객체로 전송하는 것을 도와준다.

Modifiable middleware

• wrapper와 interceptor를 제공하는 것은 미들웨어를 확장하고 조정하는 수단이다.
  • 조정의 필요성은 분산 애플리케이션이 변화가 연속적으로 실행되는 환경으로부터 온다.
• modifiable middleware는 미들웨어는 조정할 필요가 있을 뿐 아니라, 이것을 중단하지 않고 의도적으로 수정할 수 있어야 하는 것으로 표현했다.
  • 인터셉터는 제어의 표준 흐름을 조정하는 수단을 제공한다.
• 컴포넌트 기반 디자인은 구성을 통해 수정가능성을 지원하는 데 집중한다.

2.3 System architecture

• 이제는 어떻게 많은 분산 시스템이 소프트웨어 컴포넌트들이 어디에 배치되는지 고려하여 실제로 구성되는지 본다.
• 소프트웨어 컴포넌트, 상호협력, 그리고 배치를 결정하는 것은 시스템 아키텍처(system architecture)의 예시를 보여준다.

Centralized organizations

• 서버로부터 서비스를 요청하는 클라이언트 관점에서 생각하는 것은 분산 시스템의 복잡성을 이해하고 관리하는 데 도움이 된다.

Simple client-server architecture

• client-server 모델에서 분산시스템의 프로세스는 2개의 그룹으로 나뉘어진다.
  • server는 특정 서비스(ex. 파일 시스템 서비스나 데이터베이스 시스템)를 실행하는 프로세스이다.
  • client는 서버로부터 서비스를 요청하는 프로세스이며, 서버의 응답을 기다린다.

• 클라이언트와 서버 간의 통신은 간단한 무접속 프로토콜 수단에 의해 실행되는데, 밑에 있는 네트워크가 많은 LAN과 같이 상당히 신뢰할 때이다.
• 하지만, 프로토콜을 가끔 전송 실패에 대해 저항력있게 만드는 것은 흔하지 않다.
  • 우리가 할 수 있는 유일한 것은 응답 메시지가 안 들어온다면 클라이언트에게 요청을 재전송하는 것 뿐이다.
  • 하지만 클라이언트가 원본 요청 메시지를 잃어버리거나 응답의 전송 을 한지 안 한지 감지하지 못할 때 문제가 있다.
  • 작동이 손상없이 여러번 반복되면, 이것을 idempotent라고 말한다.
• 대안으로, 많은 클라이언트-서버 시스템은 신뢰할 수 있는 연결 지향 프로토콜을 사용한다.
  • 이 해결책이 상대적으로 낮은 성능때문에 LAN에 적절하지 않을 지라도, 통신이 본래 신뢰할 수 없는 WAN에서는 완벽히 작동한다.
  • (사실상 모든 인터넷 애플리케이션 프로토콜은 신뢰할 수 있는 TCP/IP 연결에 기반한다.)

Multitiered Architectures

• 가장 단순한 구성은 오직 두 가지의 시스템을 가지고 있는 것이다.
  1. 유저 인터페이스 수준을 실행하는 프로그램만을 포함한 클라이언트 시스템
  2. 프로세싱과 데이터 수준을 실행하는 프로그램을 포함한 서버 시스템
• 조직에서 모든 것은 서버에서 다루는 반면, 클라이언트는 본질적으로 오직 편리한 그래픽 인터페이스만 가진 터미널일 뿐이다.
  • (하지만 많은 다른 가능성들이 있다.)
  • 많은 분산 애플리케이션들은 3 계층으로 나뉘어 진다.
    • user interface layer
    • processing layer
    • data layer

• c의 예시로 워드 프로세서가 있다. 기본 편집기를 클라이언트(로컬에서 작동하거나 인메모리에서)쪽에서 실행하고, 서버쪽에서는 스펠링과 문법을 체크하는 고급 지원 기능들이 있다.
• 많은 클라이언트-서버 환경에서 d나 e는 특히 인기있다.
• 이런 조직들은 클라이언트 기계가 PC이거나 워크스테이션에서 사용된다. (네트워크를 통해 연결되어 분산 파일 시스템이나 데이터베이스로 가는)
• 본질적으로 대부분의 애플리케이션은 클라이언트 기계에서 실행되지만, 파일이나 데이터베이스 엔트리의 모든 작동은 서버로 간다.

• 위의 그림은 three-tiered architecture이다.
• Client는 애플리케이션 서버와 통신하며, 애플리케이션 서버는 데이터베이스와 통신하여 데이터를 처리한다.
• transaction processing monitor라 불리는 분리된 프로세스는 다른 데이터 서버들을 통해 모든 트랜잭션들을 조정한다.
• 아주 다른 예시로, three-tiered architecture를 웹 사이트(Web site) 조직에서 볼 수 있다.
  • 웹 서버는 사이트의 엔트리 포인트로써 수행하며, 요청을 실제 처리가 발생하는 애플리케이션 서버로 전달한다.
  • 이 애플리케이션 서버는 차례로 데이터베이스와 상호작용한다.

Decentralized organizations: peer-to-peer systems

• 다른 층들은 직접적으로 애플리케이션의 논리적 조직으로 관계를 맺는다.
• 많은 비즈니스 환경에서, 분산 처리는 클라이언트-서버 애플리케이션을 다중 계층 구조(multitiered architecture)로 구성하는 것과 동등하다.
  • 이런 유형의 분포를 수직 분포(vertical distribution)라 부른다.
  • 수직 분포의 특징은 다른 기계들에 논리적으로 다른 컴포넌트를 배치함으로써 얻는다.
• 시스템 관리 관점에서 수직 분포를 갖는 것은 도움이 된다.
  • 기능들이 특정 그룹의 기능들로 맞춰져 있는 다수의 장치들로부터 논리적이고 물리적으로 나뉘어져 있다.
• 현대 아키텍처에선, 클라이언트와 서버의 분포를 중요시하며, 이를 수평 분포(horizontal distribution)이라 한다.
  • 이런 유형의 분포에서, 클라이언트나 서버는 논리적으로 동등한 부분으로 물리적으로 분리될 수 있지만, 각 부분은 자체적인 공유 데이터 셋에서 작동한 다음
• 이 섹션에서는 수직 분산을 지원하는 현대 시스템 아키텍처의 한 분야인 P2P systems을 살펴본다.
  • 피어 (peer) : 계층적 구조의 프로토콜을 사용하는 통신망의 동일 프로토콜 계층에서 대등한 지위로 동작하는 기능 단위 또는 장치 ²
  • cf) 노드 (node) : 데이터를 전송하는 통로에 접속되는 하나 이상의 기능 또는 단위

• 높은 계층 관점에서는, P2P 시스템을 구성하는 프로세스들은 모두 동일하다.
  • 수행이 필요한 기능들은 분산 시스템을 구성하는 모든 프로세스에 의해 수행된다.
  • 결과적으로, 프로세스 간 상호작용은 대칭적이다.
  • 각 프로세스는 클라이언트와 서버로 동시에 수행할 것이다. (servant의 역할이기도 하다.)
• peer-to-peer architecture $\rightarrow$ overlay network
  • 노드들은 프로세스에 의해 형성되고 링크들은 가능한 통신 채널을 표현하는 네트워크
  • 노드는 직접 통신하지 않고, 가능한 통신 채널을 통해 메시지를 보낸다.

Structured peer-to-peer systems

• 정형 P2P 시스템에서 노드(=process)들은 오버레이(특정한 토폴로지를 고수하는: 링형, 트리형, 그리드형 등)를 구성한다.
  • 토폴로지는 데이터를 효과적으로 찾을 때 쓰인다.
• 이 시스템은 semantic-free index를 이용하는 것에 기반을 둔다.
  • 시스템에 의해 유지되는 각 데이터 아이템은 특별하게 키와 연관되어 있고, 이 키는 결과적으로 인덱스로 쓰인다. 마지막에 가서, 해쉬 기능을 사용하는 것이 일반적이다.
  • 그래서 우리는 key(data item) = hash(data item's value)를 얻는다.
• P2P 시스템은 전반적으로 (key, value) 쌍을 담당한다.
  • 이 시스템은 분산 해쉬 테이블을 구현하고, DHT로 축약되었다.

• 시스템은 키를 기존 노드에 map하는 lookup 기능의 효과적인 구현을 제공한다.
  • existing node = lookup(key)

Unstructured peer-to-peer systems

• 비정형 P2P 시스템에서 각 노드는 이웃들의 애드혹 목록을 유지한다.
  • 결과 오버레이는 랜덤 그래프와 유사하다.
  • 애드혹 (ad hoc) : 독립 단말끼리 외부의 도움없이 자기들만으로 자율적인 임시적 망을 구성함을 뜻함 ³
• 노드가 조인할때 종종 잘 알려진 노드와 접촉하여 시스템에 있는 다른 피어들의 시작 목록을 얻으려 한다.
  • 이 목록은 피어들을 찾는데 쓰이며, 다른 것들은 무시한다.
  • 실제로, 노드의 로컬 목록은 수시로 변한다.
• 비정형 P2P 시스템에서는 데이터 검색에 의존해야 한다.

• Flooding과 Random walk는 분산 시스템에서 메시지 전달을 위해 사용되는 알고리즘 중 두 가지이다.
  • 두 알고리즘 모두 메시지 전달 시 경로를 선택하는 방법으로 사용된다.
• Flooding : 각 노드가 수신된 메시지를 모든 이웃 노드에게 전송하는 방식이다.
  • Pros : 메시지가 어떤 이유로 인해 전송이 실패해도 다른 경로를 통해 전송되기 때문에 높은 신뢰성을 가진다.
  • Cons : 메시지가 네트워크에서 계속해서 전파되면서 네트워크 대역폭을 낭비하고, 불필요한 메시지 전송으로 인해 네트워크 부하가 증가할 수 있다.
  • 알고리즘
    1. 발행 노드 u는 자료 아이템을 모든 이웃들에게 요청을 전달한다.
    2. 수신 노드 v가 이전에 본적 있다면, 수신은 무시된다. 그렇지 않으면, v는 지역적으로 요청된 자료 아이템을 찾는다.
    3. v가 필요한 자료를 가지고 있다면, 발행 노드에게 직접적으로 반응하거나 원래 전달자에게 반송한다.
    4. 만약 v가 요청 자료를 가지고 있지 않다면, 요청을 이웃들 모두에게 전달한다.

• Random walk : 노드가 무작위로 경로를 선택하여 메시지를 전송하는 방식이다.
  • Pros : 각 노드는 무작위로 경로를 선택하므로, 불필요한 메시지 전송이 줄어든다. 또한 이 알고리즘은 안정성이 높은 경로를 찾아 전송할 가능성이 높다.
  • Cons : 무작위로 선택된 경로로 메시지가 전달되는 경우, 목적지 노드에 도달하지 못하거나, 경로 선택이 길어지는 등 메시지 전달에 대한 보장이 없다.
  • 알고리즘
    1. 발행 노드 u는 랜덤하게 선택된 이웃(ex. v)에게 요청하여 자료 아이템을 찾으려 할 것이다.
    2. v가 만약 데이터를 갖고 있지 않다면, 요청을 랜덤하게 선택된 이웃에게 전달한다. 그 결과를 random walk라 한다.
    3. 랜덤 워크는 네트워크 트래픽을 덜 부과하지만, 요청 데이터가 있는 노드에 도달하는 데 시간이 더 걸릴 수 있다.
    4. 대기 시간을 줄이기 위해, 발행자는 n 랜덤 워크를 동시에 시작한다.

Hierarchically organized peer-to-peer networks

• 비정형 P2P 시스템에서, 관련 자료 항목들을 찾는 것은 네트워크가 커짐에 따라 확장성 측면에서 문제가 될 수 있다.
  • 검색 요청을 특정 자료 항목으로 보내는 결정론적 방법이 없다, 특히 노드가 의존하는 기술은 flooding이나 randomly walk 수단에 의한 요청을 위한 검색뿐이다.
• P2P 시스템의 대칭성을 버리는 게 실용적인 상황이 있다.
  • 노드들이 자원을 서로 제공하는 협력을 생각해본다.
  • CDN(; content delivery network)에서는, 노드들은 웹 클라이언트가 근처의 페이지를 접근하기 위해 웹 문서 복사본을 호스팅하기 위한 스토리지를 제공하기 때문에, 그들에게 빨리 접근할 수 있다.
    • CDN (콘텐츠 전송 네트워크) : 동영상 등 다양한 콘텐츠를 복잡한 네트워크 환경에서 사용자에게 안정적으로 전송해주는 서비스 ⁴
• 필요한 것은 문서들이 어디에 저장되어야하는지를 찾는 수단이다.
• 서로 가까이 있는 많은 수의 노드들에 대한 자료 사용량과 가용량에서 자료를 모으는 브로커를 사용하는 것은 신속하게 충분한 자원을 가진 노드를 선택할 수 있다.
• 인덱스를 유지하거나 브로커 역할을 하는 노드를 슈퍼 피어(super peer)라 한다.
  • 슈퍼 피어는 p2p 네트워크로 구성되어 계층적 구조로 이어진다.
  • 약한 피어가 네트워크를 조인할 때마다, 슈퍼 피어에 붙게 되고 네트워크를 해제할 때까지 붙어 있는다.
  • 슈퍼 피어는 높은 가용성을 가진 수명이 긴 프로세스이다.

• 보았듯이, P2P 네트워크는 노드가 네트워크를 조인하고 해제하는 데 유연한 수단을 제공한다.
• 하지만, 슈퍼피어 네트워크(super-peer network)의 문제는 슈퍼피어에 적합한 노드를 어떻게 선택하느냐 이다.
  • leader-election problem로 이어진다.

Hybrid Architectures

Edge-server systems

• 엣지-서버 시스템은 서버가 네트워크의 엣지부분에 위치한 인터넷이 배치된다.
  • 엣지(edge)는 ISP(Internet Service Provider)가 제공하는 것과 같이 기업 네트워크가 실제 인터넷 사이의 경계에 의해 형성된다.
• 마찬가지로, 집에 있는 사용자가 ISP를 통해 인터넷에 연결하면, ISP는 인터넷의 엣지에 거주할 것을 고려된다.
• 엣지 서버의 주요 목적은 필터링을 적용하고 기능을 변환한 후에 내용을 제공하는 것이다.

Collaborative distributed systems

• 비트토렌트(BitTorrent)는 P2P 파일 다운로드 시스템이다.
• 토렌트파일은(torrent file)은 특정 파일을 다운로드하는데 필요한 정보이다.
  • 특히, 이것은 요청된 파일의 덩어리를 가지고 있는 정확한 활동노드 계정을 지키는 서버 tracker로 알려진 링크를 포함한다.
    • 활동노드는 현재 파일을 다운로드하고 있는 것이다.

2.4 Example architectures

The Netwrok File System

• 많은 분산 파일 시스템은 Network File System(NFS)를 가진 클라이언트-서버 구조로 구성된다.
• NFS의 주요 개념으로 각 파일 서버는 로컬 파일 시스템의 표준 뷰를 제공하는 것이다.
  • 즉, 로컬 파일 시스템이 어떻게 구현되는지는 중요하지 않다.
• NFS는 클라이언트를 서버에 있는 파일에 접속할 수 있게 해주는 통신 프로토콜과 함께 제공된다.
  • 서버는 다른 운영체제와 기계에서 실행되어 공통의 파일 시스템을 공유한다.
• NFS 모델과 비슷한 것으로 remote file service가 있다.
  • 이 모델에서 클라이언트는 원격 서버에 의해 관리되는 파일 시스템으로 가는 데 투명 접근을 제공받는다.
  • 클라이언트는 파일의 실제 위치를 모른다. 대신에, 기존 로컬 파일 시스템에 의해 제공받는 인터페이스와 비슷한 파일 시스템으로 가는 인터페이스를 제공받는다.
  • 특히, 클라이언트는 오직 다양한 파일 작동을 포함한 인터페이스를 제공받는다. 하지만 서버는 그러한 작동을 구현하는 것을 담당한다.
  • 이러한 모델을 remote access model이라 부른다.

• 이와는 반대로, upload/download 모델에서는 클라이언트는 이것을 서버로부터 다운로드받은 후에 파일을 로컬로 접근한다.
• 클라이언트가 파일받는 걸 끝낼때, 이것은 다른 클라이언트가 쓸 수 있도록 서버에 다시 업로드된다.

• 사실상 모든 현대 유닉스 시스템에서, NFS는 위의 그림처럼 구현된다.
• 클라이언트는 로컬 운영 체제에 의해 제공되는 시스템 호출을 사용하여 파일 시스템에 접근한다.
  • 시스템 호출 (system call) : 운영체제가 제공하는 서비스에 대한 프로그래밍 인터페이스 제공 ⁵
• 하지만, 로컬 유닉스 파일 시스템 인터페이스는 인터페이스가 Virtual File System(VFS)로 가면서 대체된다.
• 사실상, 모든 현재 운영 체제는 VFS를 제공하여 개발자에게 새로운 파일시스템 구조를 적용할 때 운영 체제의 큰 부분을 재구현하는 데 덜 강요하게 되었다.
• NFS와 함께, VFS 인터페이스에서의 작동은 로컬 파일 시스템으로 전달되거나 분리된 컴포넌트(NFS 클라이언트로 알려진)로 전달된다.
  • NFS client : 접근을 원격 서버에 저장된 파일로 가는 부분을 처리하는 걸 책임을 짐
• NFS에서, 모든 클라이언트-서버 통신은 remote procedure calls(RPCs)를 통해 행해진다.
  • RPC는 시스템 A에 있는 클라이언트가 다른 시스템 B에서 구현되는 프로세스를 정상적으로 호출할 수 있도록 하는 표준 방식이다.
• NFS 클라이언트는 NFS 파일 시스템 작동을 서버로가는 원격 프로시저 호출로써 구현한다.
• NFS server는 들어오는 클라이언트 요청을 처리하는 걸 담당한다
  • 서버에 있는 RPC 컴포넌트는 들어오는 요청을 나중에 VFS 계층을 통과하는 표준 VFS 파일 작동으로 전환한다.
  • 다시 말해, VFS는 실제 파일이 저장되어 있는 로컬 파일 시스템을 구현하는 것을 담당한다
• 이 스키마의 중요한 이점은 NFS는 로컬 파일 시스템과 독립적이라는 것이다.

The Web

Simple Web-based systems

• 많은 웹기반 시스템은 상대적으로 단순한 클라이언트-서버 구조로 여전히 구성되어 있다.
• 웹사이트의 핵심은 문서들을 저장한 로컬 파일 시스템에 접근할 수 있는 프로세스에 의해 형성된다.
  • 문서를 참조하는 가장 간단한 방식은 URL(uniform resource locator)이라 불리는 참조의 방식을 쓰는 것이다.
  • 이것은 서버가 문서를 로컬 파일 시스템에서 찾을 수 있는 파일 이름과 함께 관련된 서버의 DNS 이름을 임베딩함으로써 문서를 어디에 위치할지를 지정한다.
  • 게다가, URL은 네트워크를 통해 문서를 전달하는 애플리케이션 계층 프로토콜을 지정한다.
• 클라이언트는 문서를 적절하게 보여주는 걸 담당하는 브라우저를 통해 웹서버와 상호작용한다.
• 브라우저와 웹서버 사이의 통신은 표준화되어 있다.
  • 그들은 모두 HyperText Transfer Protocol(HTTP)을 지킨다.

Multitiered architectures

• Figure 2.27과 같은 기본 아키텍처에서 첫번째 강화된 것 중 하나는 Common Gateway Interface(CGI) 수단에 의해 단순한 유저 인터랙션을 지원하는 것이다.
  • CGI는 웹 서버가 유저 데이터를 입력으로 가져오는 프로그램을 실행할 수 있는 표준방식이다.
  • 보통 유저 데이터는 HTML 형식으로 가져온다.
  • 형식이 완료되면, 프로그램의 이름과 모은 파라미터 값들은 서버로 전송된다.
  • 데이터 처리 후, 프로그램은 HTML 문서를 생성하고 그 문서를 서버로 반환한다.
  • 서버는 그후 문서를 클라이언트에게 전달한다.

References

1. [<용어> wrapper란? - peene](https://pinelover.tistory.com/187) ↩

2. 해시넷 - 피어 ↩

3. 정보통신기술용어해설 ↩

4. 해시넷 - CDN ↩

5. 2.3 시스템 호출(system call) - pwnpwnhnpwn ↩