[CS] 분산 시스템 간의 Communication과 RPC(Remote Procedure Call)

Communication

분산 시스템에서 공통적으로 접근하는 Shared Data에 대한 동기화(Synchronization)를 위해서 필요하다.

이를 위해서 분산 시스템 간의 의사소통이 필요하기 때문에 Communication의 방법론들이 탄생하게 되었다.

 

두 가지 Communitcation 방법

• Shared Memory : 직접 메모리 엑세스(스레드), 매핑된 메모리(프로세스)
  • 물리적으로 메모리를 공유할 수는 없음
• Message : OS의 IPC, 네트워크를 통한 통신
  • Latency(지연 시간) 발생
  • Failure 확률 상승
  • Heterogeneity로 인한 비호환성 발생 가능

 

---

 

분산시스템의 Communication 종류

1. Message-oriented Communication

2. RPC (Remote Procedure Call) ****

3. RMI (Remote Method Invocation) :본질적으로는 RPC, 분산된 객체(원격 객체)에 대해 사용되는 것

4. Stream-oriented Communication

 

 

---

 

Socket-based Communitcation

• Low-level의 커뮤니케이션 방법
• Connection oriented(연결 지향)이거나 Connection-less(연결이 없음)일 수 있음
  • TCP 소켓(Connection oriented) / UDP 소켓(Connection-less)
• 유연성은 복잡성에 대한 대가로 나옴
• Socket API Problem
  • Socket의 I/O가 분산된 환경을 숨기는 Transparency 원칙에 적합하지 않음
  • 매번 프로그래머들이 처리해야 할 게 많음..
• Socket은 투명성(Transparency)을 제공할 수 없음

 

---

Middleware 

• OS와 분산 애플리케이션 사이단에 위치한 계층
• 분산 시스템의 Complexity(복잡성)과 Heterogeneity(이질성)을 Hide(숨김)
• Low-level OS ↔ 추상화된 프로그래밍 언어 간의 Gap 사이를 매꿔줌
• 분산 애플리케이션을 위한 프로그래밍 추상화 및 인프라 제공
  • 이질성을 줄여주어, 네트워크 하드웨어 OS… 등 신경써야 할 것들을 Mask(숨겨) 개발자들의 부담을 감소시킴
  • Higher-level의 프로그래밍 추상화 제공 (Socket보다 High level)
  • 개발자들의 개발 부담을 줄이고 Transparencies라고 불림
• 운영체제 → 하드웨어를 사용 가능하게 만드는 소프트웨어
• 미들웨어 → 분산 시스템을 프로그래밍 및 관리 가능하게 만듬

---

 

RPC(Remote Procedure Call) 

 

 

1. Transparency : 분산 컴퓨팅을 중앙 집중식 컴퓨팅처럼 보이게 만들기 위한 목적으로 개발된 통신 프로토콜 및 프레임워크

2. Higher-level의 프로토콜로서 사용할 수 있음. (Socket은 TCP/IP 위에서 돌아가는거에 대비됨)

3. Middleware 중 가장 일반적으로 사용, 위치, 구현 언어에 대해, 즉 Client-Server 통신에 대한 Transparency를 제공

 

 

근본적 Idea

• 클라이언트가 프로시저나 함수처럼 사용할 수 있도록 한다. 서버는 클라이언트가 쓸 수 있는 인터페이스를 제공한다.
• 라이브러리 API와 비슷, 프로시저/함수는 메세지 교환 형태로 변환

 

 

 

Stub : Argument들을 포장(Packaging)하고 메세지를 보내는 역할

• Appernet(한 쌍의) Stub을 만들어, 이런 목적을 달성할 수 있도록 함
• Client-side Stub
  • 로컬 서버 기능 처럼 보이고(Transperency) → 그렇지만 서버 기능을 호출하는 코드 덩어리
  • Argument를 메시지로 묶어(Marshalling)
  • Server-side Stub로 보냄
  • 응답을 기다리고 결과 Bundle을 해제함
• Server-side Stub
  • 로컬 클라이언트 기능처럼 보임(Transperency) → 클라이언트가 호출했다고 생각하지만, 서버 Stub에 의해 호출
  • Client Stub의 메시지를 Socket에서 수신
  • Argument를 Unbundleing 후 서버 로컬 함수 호출
  • 응답 메시지로 Bundle이 생성됨
• Stub은 RPC가 Transparency하도록 서로에게 Message를 보냄
• Stub은 개발자들이 Application의 의미에 집중할 수 있도록 하고, Message, 서식, 균일한 표현 등을 제공함

Marshalling : Argument를 포장(Packaging)하는 것을 지칭하는 용어 → 패키징 매개변수 호출 → Argument를 Message Packet으로 압축 (↔ Unmarshaling )

IDL(인터페이스 정의 언어) : IDL을 정의하고, Stub Complier로 컴파일 하면 Stub이 자동으로 생성되고 작업을 진행함. → 프로그래머가 할 일이 줄음

 

 

---

 

RPC의 특징과 이슈가 되는 사항 

 

 

Representation of Data (데이터의 표현)

1. 원격 프로시저 호출의 경우 다른 언어로 작성된 프로세스, 다양한 크기의 데이터 유형 표현, 부동 소수점 숫자를 다르게 표현하는 등의 상이함이 있음
2. IDL에 인터페이스 설명을 작성(프로시저 호출을 위한 이름, 매개변수 반환 유형 등 API 정의)
3. IDL 인터페이스 정의 → IDL 컴파일러 실행 → (Client-side-stub) → Marshalling → 서버 → Unmarshalling → (Server-side-stub) → Server 함수 호출

 

 

Parameter Passing (파라미터의 전달)

1. Call-by Value
   • Client Stub에 복사본을 전달하면 됨
2. Call-by Reference
   • 포인터는 다른 프로세스에서 해석 불가능 (동일 머신에서도)
   • 잘 정의된 데이터 구조를 포인터가 가리키는 경우, 복사본을 전달하고 Server stub이 로컬 복사본에 대한 포인터를 서버 함수에 전달함.
     • Call by value로 전환하는 거임. 데이터가 크면 오버헤드 발생
   • “포인터를 포함하는 데이터 구조”의 경우 금지하거나, 네트워크를 통해 포인터를 추적해야 함(Client의 주소 추적)
   • 전역 변수는 RPC에서 허용되지 않음

 

 

RPC Binding (서버에 바인딩하는 방법)

1. 클라이언트가 서버를 찾기 위해 바인딩이 필요함
2. 서버는 초기화 시 서버 인터페이스(이름, 주소 등..)을 Binder로 내보냄
3. 클라이언트는 First RPC가 서버 인터페이스를 가져오기 위해 Binder에 메세지를 보냄
4. Binder의 특징
   1. 내보내기 및 가져오기에는 Overhead 발생
   2. Binder은 Bottleneck 일으킬 수 있음
      1. Multiple 바인더 사용으로 해결
   3. Binder은 로드 밸런싱을 수행할 수 있음

 

 

Failure Semantics (실패 의미론) 

• 서버 내의 Failure에는 매우 다양함 → 클라이언트의 Crash, 패킷의 손실, 서버의 Crash 및 재부팅, 네트워크가 매우 느림
  • 클라이언트에서는 동일하게 보일 수 있음
• Local Procedure은 정확히 한 번 호출됨
• 문제 발생 시 Remote Procedure은 호출 횟수에 따라 의미가 다름
  • 0 Times : 서버 코드를 실행하기 전에 서버가 Crashed
  • 1 Times : 정상 작동
  • 1 or More : 대기 시간 초과 또는, 응답 패킷 손실
  • Transparency가 깨지는 원인. RPC 실패 처리를 위해 애플리케이션을 준비해야 함
• RPC 시스템은 다음 중 하나를 제공
  • At least once semantics
    • 서버 장애가 발생하더라도, 서버에서 RPC가 한 번 이상 수행되도록 보장함.
    • Idempotent Operation이 필요 → RPC가 여러 번 수행될 수 있음 → 실패한 것은 반영되지 않고 성공한 것이 작동되도록
  • At-most once semantics
    • 서버 장애가 발생하더라도 서버에서 RPC가 최대 한 번 수행되도록 보장
    • 클라이언트가 RPC 요청에 포함해야 하는 Epoch Number를 유지하여 수행됨
    • 서버는 재부팅할 때, Epoch number를 증가시키고, 이전 Epoch number의 RPC를 거부함.
  • Exactly Once Semantics : 바람직하지만 달성하기 어려움
• 멱등성 (Idempotent vs non-idempotent)
  • Idempotent functions(멱등성 기능) : 여러 번 수행해도 동일한 효과를 가지는 기능
  • non-idempotent functions(비멱등성 기능) : 여러번 수행하면 효과가 달라지는 기능

 

 

---

Content / Image Reference (CC License)

 

Tannenbaum and Van Steen :: Distributed Systems: Principles and Paradigms (PDF)