[분산 시스템] Architectures

분산시스템은 software systems으로 구성되어 있음.

분산시스템을 만들 때 애플리케이션과 underlying platform(ex. os. h/w)을 분리해야 하고 분산투명성을 제공하고 adaptability(적응성)를 추가하는 것이 좋다.

---

Architectural styles 

 

- Layered architectures

- Object-based architectures

- Data-centered architectures

- Event-based architectures

---

• Layered architectures

Components들이 하나의 계층 구조로 이루어져 있음(서로 위아래 컴포넌트끼리 네트워크 하는 것)

장점 : 관리가 쉽다. 하나의 계층에서 문제가 발생해도 그 계층만 고치면 정상적으로 작동이 가능

단점 : 계층 구조이기 때문에 계층이 많아질수록 딜레이가 발생

• Object-based architectures

컴포넌트끼리의 제약이 없는 루즈한 구조, 서버와 클라이언트 구조

컴포넌트들이 서로 직접 데이터를 주고받는 구조

• Data-centered architectures

중앙에 data repository가 있는 구조로 데이터를 전송하고자 한다면 무조건 중앙을 겹쳐서 가야만 하는 구조

ex) web기반 분산시스템 (웹서버에 데이터를 저장)

• Event-based architectures

publish/subscribe 시스템으로 받을 수 있는 subscriber가 서로 연결된 상태여야 전송이 가능

publish : event bus(중개인)에게 메시지를 적고 이정보를 event bus(중개인)가 관심 있어하는 쪽에게 전달

subscribe : 내가 필요로 하는 관심사를 미리 등록하고 만약 그 정보가 있다면 받음, 서비스를 직접적으로 요청하는 것이 아닌 간접적으로 요청하는 방식

 

• Data-centered architectures + Event-based architectures

이 두 가지를 합치면 서로 실시간으로 연결된 상태가 아니더라도 data space를 통해서 필요한 데이터를 받을 수 있음

ex) SNS

 

refenence(보내는 사람과 받는 사람을 지정)와 time별로 정리해 보자면 다음과 같다.

reference\time	couple	decouple
couple	request/reply	mail
decouple	pub-sub model	data-centered

---

System architectures

 

-Centralized architectures

-Decentralized architectures

-Hybrid architectures

 

• Centralized architectures

클라이언트-서버 모델 ex) request-reply패턴 : 클라이언트가 서버에 요청을 하고 서버가 그 요청을 받아서 응답을 하는 형태이다. 모든 request들을 서버에서 처리하기 때문에 중앙집중구조

 

connectionless protocol

ex) UDP : simple해서 빠르다는 장점이 있지만 메시지가 사라질 수 있다는 단점이 있음(unreliable), 랜 환경에서 좋음

 TCP는 UDP보다 느리다는 점이 있고 통신하기 전에 사전작업이 필요하지만 reliable 하기 때문에 TCP를 더 많이 사용

 

그래서 UDP를 쓰면 idempotent 하거나 not idempotent 한 경우가 발생할 수 있다. 그래서 TCP를 자주 씀

idempotent : 클라이언트가 서버에게 같은 request를 여러 번 보내서 처리하더라도 전체적인 서비스에 영향이 없는 경우

 

main issue

클라이언트와 서버의 역할을 분리하자

1. The user-interface level
2. The processing level
3. The data level

-The user-interface level-

사용자가 필요한 경우 input(버튼, 명령어 등)을 시스템에 주고 UI를 통해서 사 옹자가 input을 주게 되면 input에 대한 처리 결과(output)를 보여줌, 즉 input과 output을 담당하는 역할을 한다.

클라이언트 쪽에 구현되는 것이 일반적임

 

-The processing level-

3가지 중에서 가장 중요한 파트임(애플리케이션의 코어파트)

주로 애플리케이션들을 포함

주로 서버 쪽에 많이 둠

user interface는 애플리케이션 종류와 상관없이 공통점이 많은 반면에 processing level은 공통점이 별로 없다.(애플리캐이션마다 내부 코어에서 진행되는 프로세싱의 내용이 다르기 때문)

ex) 주식 분석, ms offfice

 

-The data level-

애플리케이션을 운영하는데 필요한 실제 데이터를 관리하는 컴포넌트

주로 서버 쪽에 많이 둠

 

Multi-tiered architectures

위 세 가지 컴포넌트를 상황에 따라서 다르게 둘 수도 있다.

 

(a) : UI의 일부파트를 클라이언트에 두고 일부는 서버에 둔다.

클라이언트 : 사용자가 주는 input을 받아서 서버에 전달

서버 :  사용자가 요청한 서비스를 클라이언트로 보내기 전에 서버에서 먼저 클라이언트에게 어떤 식으로 보여줄지 서버에서 먼저 확인 즉, output을 서버가 담당

 

(b) : 클라이언트는 UI파트만 담당. 사용자 input을 받아서 넘겨주고 서버가 주는 output(결과)을 화면에 출력하는 역할 

 

(c) : processing level파트를 서버와 클라이언트에서 나눠서 한다. communication latency를 줄이기 위해서 서버에서 처리해야 할 일을 클라이언트에서 처리하자. ex) 워드 프로세서 단어, 문법 등을 예전엔 클라이언트에서 다했지만 서버에서 일부를 둠

 

(d) , (e) : UI, processing 파트를 클라이언트에서 모두 처리 

 

(d) : 모든 데이터를 서버에서 관리

 

(e) : 데이터가 쪼개져서 일부를 서버와 클라이언트 파트로 나눔 ex) cache

---

• Decentralized architectures
  1. Vertical distribution : 클라이언트와 서버의 역할을 어떻게 배분할지 수직적으로 나누어서 생각해야 됨(centralized)
  2. Horizontal distribution : 서버와 클라이언트의 구분 없이 수평적으로 생각해 보자(decentralized) ex) p2p

peer-to-peer 

centralized구조의 단점인 single point of failure(서버 하나가 마비되면 모두가 고장남)을 해결할 수 있음. 또한 특정 서버가 없기 때문에 peer들을 계속 확장시킬 수 있기 때문에 확장성이 좋음 그러나 데이터를 관리하는 측면이 복잡해진다.

즉, p2p의 핵심은 모든 peer들은 동일한 역할을 수행한다. 서버 역할을 하면서 클라이언트 역할도 함

고려해야 할 사항은 peer들 간의 overlay network(애플리케이션 프로세스들 간의 사이의 연결관계)을 어떻게 구성해야 할 것인지이다.

client/server구조는 관리가 편하고 보안이 좋다. 서버하나만 관리하면 되니까.

반면에 P2P는 관리가 어렵다. 중앙집중식 서버가 없기 때문에. 그럼 왜 쓰지? 위에 구조에서 서버가 죽으면 문제가 전체가 마비되지만 P2P는 그렇지 않음

 

-Structured P2P-

룰을 가지고 구조를 만들자.

주로 DHT(Distributed Hash Table : peer들끼리 자기가 관리해야 할 데이터들을 쪼개서 관리를 함)을 많이 사용함

DHT : 각각의 데이터들에게 키를 할당함. peer들도 키값이 존재함. 각각의 데이터를 어떤 peer들이 관리할지 룰을 정하는 방식

 

ex) Chord system : 링 형태로 overlay를 구성. 어떤 데이터 값을 k라고 할 때 k보다 크거나 같은 ID를 갖는 노드 중에 가장 작은 노드. K라는 키를 담당하는 노드가 누구인지 찾는 과정을 LOOKUP

 

4bits key space

임의의 노드가 Chord 네트워크에 참여하고 싶다고 가정해 보자.

1. hash function을 돌려서 ID값을 받자(13이라고 가정), ID가 중복될 수 있기에 bit 수를 증가시켜서 확률을 낮추자

2. 13ID를 가지고 LOOKUP서비스를 요청

3. 13을 담당하는 애(15)가 누구인지 Chord system에게 요청

4. 13이 15와 12에게 통신을 걸어서 들어간다고 요청, successor와 preseccessor를 업데이트

5. 15가 관리하고 있는 데이터를 13에게 쪼개자(관리하는 데이터를 업데이트)

 

임의의 노드가 Chord 네트워크에 빠져나간다고 가정해 보자.

1.  successor와 preseccessor에게 나간다고 요청

2. 내가 관리한 데이터도 넘겨주고 가기

 

-Unstructured P2P-

overlay를 구성하고 데이터를 관리하는 측면에서 룰이 없다. 랜덤으로 정하는 방식

그럼 내가 필요한 데이터를 어떻게 찾지? broadcast를 해서 모든 네트워크에게 다 요청, 그러면 네트워크가 혼잡해짐

그럼 Membership 관리를 어떻게 하지? 주기적으로 나와 이웃(neighbor)들한테 각자가 가지고 있는 이웃정보를 교환

 

P2P는 서버가 없어서 좋은 점 보다 단점이 더 많다. 그래서 새로운 것이 필

 

-Superpeers-

다른 peer보다 강력한 peer를 두자(즉, 서버를 두겠다는 말) 물어볼 상대를 정하자.

regular peer가 네트워크에 오고 싶으면 가까운 superpeer에게 요청을 하자.

---

• Hybrid architectures

클라이언트/서버구조와 decentralized구조를 합친구조

ex) BitTorrent

파일을 주고받는 것은 P2P 방식이지만 파일을 받을 노드들을 찾을 때는 서버의 도움을 받는다.

---

 

Architectures vs Middleware

미들웨어를 사용하면 애플리케이션 개발이 더 수월해진다. 미들웨어에서 제공하는 서비스를 이용하자.

그러나 미들웨어는 추가적인 레이어드가 들어가기 때문에 퍼포먼스가 떨어질 수 있다.

그럼 어떻게 디자인하는 게 좋을까?

쉽게 구성하고 적응하고 커스터마이즈 하도록 만들자.

즉, 시스템이 상황에 맞게 변경할 수 있도록 디자인하는 게 좋다(policy와 mechanism을 분리하자)

 

Self-management

상황에 따라 변경되는 시스템을 만들자. 스스로 자가진단해서 그에 맞게 행동을 바꾸는 것

자동으로 적응하도록 만드는 것이 좋다.

자가진단해서 분석을 하기 위해서 3가지 요소가 필요하다

1. Monitoring

클라이언트와 서버 사이에 딜레이값이 얼마큼 유지되는지 확인

2. Analyzing measurements

모니터에서 본 딜레이값을 분석을 하자. 기준값을 주고 값을 비교해서 정상적인지 확인

3. behavior 바꾸기

비정상적이라면 바꾸자.