1. Layered protocols
- 기본적인 Layered protocols로써 OSI 7계층이 있다.
-> 자세한 것은 네트워크에서 배우기에 가볍게 말하면 물리,데이터링크,네트워크,전송,세션,표현,응용 계층으로 통신 프로토콜을 계층화한 것이다.
-> 통신의 본질은 Message를 교환하는 것이고, 해당 Message를 보내고자 할 때, Client의 응용 계층부터 물리 계층 까지 Message가 내려가며 Header를 추가한다. 이후 목적지의 물리 계층부터 응용 계층까지 헤더를 확인하며 최종 Message를 수신 처리하는 것이다.
* Distributed System에서의 Layered protocols
1. Physical layer : "bit"라는 가장 기본적인 데이터 단위를 실제로 전송하는 방식에 대한 규격을 정의한다. 또한 이 과정에서 어떤 표현이 0을 가리키는지, 어떤 표현이 1을 가리키는지 등에 대한 표현의 정의도 포함한다.
2. Data link layer : bit들의 시리즈들을 프레임이라는 형태로 변환하여 전송하는 역할을 한다. 프레임은 오류를 감지하거나 수정할 수 있는 기능을 가지고 있다. 또한 흐름 제어를 통해 데이터 전송 속도 조절이 가능하다. 이 계층에서는 MAC 주소 체계를 이용해 데이터를 전송하는 장치를 관리한다. (주로 직접 연결에 대한 오류, 흐름을 관리한다.)
3. Network layer : 패킷이라는 데이터를 작은 단위로 나누어 각 패킷이 네트워크 상에서 경로를 찾아 이동하는 방법을 규정한다. 이 시점부터 통신의 단위는 WAN 이상으로 커지며 IP 주소와 같은 논리적 주소 체계를 사용한다.
또한 이 단계에서 전송 자체에 대한 처리는 끝난다.
4. Transport layer : 실제 Communication에 있어 필요한 기능들을 정의한다. (ex: 어떤 순서로 통신을 시작할 것인지, 오류가 나면 어떻게 할 것인지 등등) => 표준 통신 프로토콜로는 TCP, UDP가 있다.
TCP는 connection-oriented(3-way handshake), reliable, stream-oriented communication(ordered)이라는 특징이 있고, UDP는 connection-less, unreliable, datagram communication이라는 특징이 있다.
5. Middleware layer : 분산 시스템에서 여러 응용 프로그램에서 공통적으로 사용할 수 있는 서비스와 프로토콜을 제공하기 위한 인터페이스를 만들고자 설계된 계층이다.
a. 다양한 통신 프로토콜을 제공한다.
b. Data (Un)Marshaling을 지원한다. 이 과정은 서로 다른 데이터 표현을 통일된 표현으로 바꿔 전송하는데 있어 필수이다.
c. 같은 System 내의 entity의 리소스 공유를 위한 식별을 위해 Naming protocol을 제공한다.
d. 안전한 통신을 위해 보안 프로토콜을 제공한다.
e. Replication, cache 등을 통해 시스템 확장성을 지원한다.
=> 이러한 Layered protocol을 구상해볼 수 있다.
2. Types of communication
* Transient vs Persistent
- Transient communication : 메시지가 전달되지 않으면 통신 서버가 해당 메시지를 폐기하는 방식. 즉, 송신자가 메시지를 보냈을 때, 메시지가 수신자나 다음 서버에 도착하지 못하면 사라지게 된다. 즉시성이 중요한 경우에는 좋으나 unreliable하다.(소멸 가능)
- Persistent communication : 다음 목적지로 전송 완료가 확인될 때까지 서버에 저장해둔다. 따라서 reliable을 보장하나 서버쪽의 부담이 더해질 수 있다.
* Asynchronous vs Synchronous
- Asynchronous communication : client 쪽에서 메시지 전송이 완료되었을 시, 즉시 다음 메시지를 전송한다. 이 방법 역시 unreliable하다.
- Synchronous communication : client는 자신이 보낸 메시지가 전송 완료가 된 것을 확인하기 전까지 다음 메시지 전송을 block한다. reliable하나 latency가 증가한다.
- 동기화는 요청 제출이 확인될 때까지 block, 요청 도착후 처리될 준비가 될 때까지 block, 요청 처리 후 확인까지 할 때까지 block이 있다.
* Client/Server
- C/S computing은 일반적으로 transient synchronous communication을 가정한다.
1. Client와 Server는 communication에 있어 active time을 가진다.
2. Client는 reply를 받을 때까지 block된다. 즉, 요청 처리 후 확인 시까지 block 된다.
3. Server는 기본적으로 별 다른 프로세스를 실행하지 않고 request의 수신을 대기한다. 그리고 차례대로 request를 처리한다.
=> 이러한 특성 때문에 Client는 request 후 reply가 올 때까지 아무런 일을 할 수 없고, Client가 무한 대기를 하지 않게 하기 위해 Failure가 발생시 즉시 핸들링 되어야한다.
- 따라서 메일, 뉴스 등에 적합하지 않을 수 있다. (즉시성보단 정확성이 중요할 때)
* Messaging
- Message-oriented middleware는 high-level persistent asynchronous communication을 목표로 한다.
=> 프로세스들은 각자 자신의 message들을 보내고, 이들은 queue에 쌓인다.
=> Client는 immediate reply를 기다릴 필요가 없다.
=> Middleware는 종종 fault tolerance를 보장한다.
3. Remote Procedure Call (RPC)
* Basic RPC operation :
- 사용 이유 :
1. RPC를 활용함으로써 프로시저 호출 방식을 네트워크 환경에서도 사용할 수 있게 해준다.
2. 잘 설계된 프로시저는 고립된 상태에서 black box 처럼 동작한다. RPC는 네트워크 상의 프로시저도 동일한 방식으로 호출할 수 있게 해준다.
3. 프로시저를 별도의 머신에서 실행하는 데 제한이 없다. 즉, 로컬에서 동작하는 것으로 보이지만 실제로는 다른 컴퓨터나 서버에서 프로시저가 실행될 수 있다는 것이다. ( Distribution transparency )
- 사진으로 예시를 들면, Client가 프로시져 콜을 한다.{doit(a,b)} -> Client stub은 이 프로시져에 관한 정보를 담은 message를 구성한다. -> network를 통해 Server machine에 프로시져 콜 메시지를 전송한다. -> Server Os는 stub을 통해 메시지를 받는다. -> 메시지를 unpack한 Server stub은 해당 정보에 해당하는 프로시져를 실행한다.
- 이를 통해 사용 편의성은 올라가나, 실제 local에서 프로시져 콜을 할 때에 비해 latency, 즉 성능이 떨어진다. 또한 fault에 대한 tolerance도 필요해지며 함수 형태의 parameter는 제한되게 된다.
* RPC: parameter passing (Synchronous communication)
- 단순히 parameter를 메시지에 포함하는 것으로 생각하지만 이 부분에 많은 어려움이 존재한다.
1. Client와 Server machine 사이의 데이터 표현이 다를 수 있다.
2. Parameter를 wrapping한다는 것은 특정 value를 byte들의 나열로 변환한다는 것이다. 즉, 동일한 인코딩 방식을 사용해야한다.
3. Client와 server는 동일한 인코딩을 사용하여야하므로 basic data value들(int, floats, char)을 어떻게 표현할지, 어느 정도의 complex의 data value들을 표현할지(arrays, unions).
=> 이를 극복하고 Clinet와 server는 적절하게 message들을 번역하여 machine-dependent representation으로 이해할 필요가 있다.
4. Copy in/copy out semantics : 프로시져가 실행될 때 동안 parameter value들에 대해 어떠한 것도 가정을 내릴 수 없다.
5. Global reference data 전송을 제외하곤 모든 data들은 parameter들에 의해서만 전송된다.
* Asynchronous RPCs (One-way RPC) :
서버의 reply를 기다리지 않고 request가 승인이 되었다면, client가 계속하여 동작할 수 있게 한다.
* Sending out multiple RPCs
- Server Group들에 동시에 RPC를 전송할 수도 있다.
4. Message-oriented persistent communication
* Message-oriented Middleware (MoM)
- Asynchronous persistent communication은 middleware-level queue에 의해 구현된다. Queue들은 각 communication server들의 buffer에 해당한다.
- MoM의 opt들은 위의 사진과 같다. put은 sender 측에서 특정 큐에 message를 추가하는 것, get은 특정 queue가 non empty라면 block하고 첫번째 메시지를 제거한다. poll은 block을 하지 않고 첫번째 메시지를 제거한다. notify는 지정된 큐에 메시지가 put 될 때 실행될 핸들러를 설치하는 것이다.
* Queue managers :
- Client 측의 application이 message를 바로 Server queue에 추가하는 방식은 reliable하지 못하다. 따라서 Client(local)측의 application은 local queue에만 message를 추가할 수 있으며, 이는 local OS를 통해서만 추출이 가능하다. 즉, 직접 연결은 불가능하고 큐를 통해서만 Message를 주고 받는 것이다. Queue manager들은 해당 message를 routing 해준다.
(Source queue manager가 자신이 관리하는 Queue에 Application의 요청을 받아 message를 put하고, 소유 중인 Look up address table에서 destination node queue manager address를 찾아 자신의 queue에서 get한 message를 전송하는 구조 이다.)
- Message Queue를 통한 communication은 Persistance communiucation이므로 Sender, Receiver 작동 여부에 따라 메시지를 바로 전송할 지, 저장 해둘지가 정해진다.
- Message queueing system들은 common messaging protocol을 가정한다. 그리고 모든 system의 application은 동일한 message format을 사용해야한다. (structure, data representation)
* Message broker
=> Message queueing system에서 모든 application은 동일한 format을 사용해야한다고 했는데 이는 WAN 단위로 가면 절대 쉬운 일이 아니다. 따라서 network 전송 중에 Message broker라는 노드를 배치하여 adapter 역할을 해준다.
=> broker는 source의 format에서 targer node format으로 변환해준다. application gateway처럼 행동한다.
=> borker는 publish-subscribe model을 지원하여 subject에 따라 message를 routing할 수 있다.
5. Muilticast communication
* Application-level Multicasting (ALM)
- Basic approach
1. Initiator는 multicast identifier mid를 생성한다.
2. succ(mid)를 찾는다. 이 노드는 해당 multicast group의 root가 된다.
3. join request가 succ(mid)로 routing되어서 succ(mid)가 루트가 된다. 즉, 트리를 이루게 된다.
4. 만약 노드 P가 참여를 원하면, root에 참여 요청을 전송한다. 즉, mid에 참여하고 싶다면 succ(mid)에 요청을 전송한다.
5. 만약 join request가 Q에 도착했을 때, Q가 참여 요청을 받은 적이 없는, 즉 가지고 있는 그룹이 없는 노드였다면 Q는 forwarder 역할을 하며, P는 Q의 child가 된다. 이 때 이 요청은 상위 노드로 계속 전송되며 트리 구조가 확장된다.
6. Q가 이미 트리 구조를 알고 있다면(즉, Q가 루트로 연결된 상위 노드와 하위 노드가 이미 있다면), P는 단순히 Q의 하위 노드로 추가된다. 이 때는 트리 구조를 확장시킬 필요가 없으므로 더 이상 요청을 다른 곳으로 forwarding할 필요가 없다.
* ALM에서의 cost
1. Link stress : ALM message가 동일한 물리적 링크를 몇 번이나 통과하는지를 나타낸다.
=> 예를 들어, A에서 D로의 메시지가 전송될 때, Router Ra, Rb를 두 번 거쳐야하는 상황이 발생될 수 있다.
(A->B->E->D)로 전송하기로 판단하고, 이는 A->Ra->Rb->B->Rb->Ra->Re->E->Re->Rc->Rd->D 로 전송된다.
2. Stretch : ALM level route와 Network level route 사이의 지연 비율을 나타낸다. 즉, ALM을 통해 전달되는 경로가 실제 네트워크 경로에 비해 얼마나 비효율적인지를 평가하는 기준이다. (Ovelay network와 실제 link의 불일치 정도)
=> 예를 들어, B에서 C로 가는 메시지가 ALM 레벨에서 73의 cost를 가지고 (B->E->D->C, 39+27+7 = 73) Network level에서 47의 cost를 가진다.(B->Rb->Rd->Rc->C) 즉, Strech는 73/47 이다.
* Flooding
- Flooding은 네트워크에서 모든 이웃 노드에게 단순히 메시지를 전송하는 방식이다. 구현은 쉽지만 네트워크 부하와 성능 저하 문제가 발생 가능하다.
1. P가 메시지 m을 이웃에게 전송 : 노드 P는 자신의 인접 노드에게 전부 m을 전송한다. 이 때, 각 인접 노드는 m을 이전에 받은 적이 없으면, P를 제외한 모든 인접 노드에게 다시 메시지를 전달한다.
2. 1.은 모든 노드에 m이 도달할 때까지 계속해서 전송된다.
=> Flooding에서 노드 수가 증가함에 따라 네트워크 내에서 메시지를 전달하는 경로(number of edges)는 매우 빠르게 증가할 수 있다. 즉, 노드 수가 증가할 수록 네트워크 부하가 매우 크게 증가한다는 문제이다. (사진 참조)
=> 이 단점을 극복하기 위해 pflood라는 확률을 기반으로 메시지 전달하는 방식이 있다. 노드 Q가 인접 노드에 메시지를 전달할 확률을 pflood로 설정하는 것이다. 이 확률은 자신의 degree나 이웃의 degree에 따라 다르게 설정된다.
'개인 공부' 카테고리의 다른 글
| Distributed System - 3. Processes (0) | 2024.10.07 |
|---|---|
| Distributed System - 2. Architectures (0) | 2024.10.01 |
| Distributed System - 1. Introduction (0) | 2024.09.30 |
| CLIP : Connecting text and images. (기본 개념) (0) | 2024.06.25 |
| Q-Learning (0) | 2024.06.24 |