Distributed System 7

추석도 그렇고, 국군의 날도 그렇고 뭔가 중간에 뜨문뜨문 쉬는 날들이 껴있어서 분산 처리 복습을 수월하게 처리 중이랄까...

감사합니다 공휴일님 ㅠㅅㅠ

이번에 듣는 수업 중 가장 어려운 수업.. 내용이 방대해서 그런 것 같다.

---

Application-level Multicasting

분산시스템의 첫 시작부터 강조되었던, 분산 시스템의 노드들은 오버레이 네트워크를 조직한다는 사실!

노드들은 데이터를 전파시키기 위해 이 오버레이 네트워크를 사용한다.

 

트리 구조를 통해 고유한 경로로 데이터를 전송하는 방식과,

메시 네트워크를 통해 데이터를 라우팅하여 전송하는 방식이 있다.

플러딩 기반(Flooding-based) 멀티캐스팅은 네트워크의 모든 노드에 데이터를 전송하는 방식이다. (= broadcasting)

 

Epidemic (Gossip) Protocols: 전염(소문) 프로토콜

애플리케이션 레벨의 멀티캐스팅에 사용되는 프로토콜로, 쓰기-쓰기 충돌이 없다고 가정한다. (동시에 쓰는 작업이 없음)

업데이트 작업은 하나의 서버에서 수행되며, 복제본(replica)은 업데이트 된 상태를 몇몇 이웃에게만 전송한다.

업데이트의 전파는 지연된 방식으로 이루어지며, 즉각적이지 않다.

하지만 결국, 모든 업데이트는 모든 복제본에 도달하여 최종적으로는 일관된 상태를 유지하게 된다.

 

두 가지 형태의 전염 프로토콜

• Anti-entropy: 각 레플리카는 정기적으로 랜덤한 레플리카를 선택해 상태 차이를 교환하며, 동일한 상태를 가지게 한다. P는 무작위로 선택된 노드 Q로부터 새로운 업데이트만 가져오고, P는 자신의 업데이트만 Q에게 전송한다. 이렇게 P와 Q는 서로의 업데이트를 주고 받는다.
• Rumor spreading: 갓 업데이트된 레플리카는 그 업데이트를 몇몇의 다른 복제들에게만 알린다(감염). P가 데이터 항목 X에 대해 갓 업데이트 된 경우, 임의의 다른 노드 Q에 연락하여 업데이트를 전송시키려고 한다. 만약 Q가 이미 다른 노드로부터 업데이트를 받은 상태라면, P는 더이상 업데이트를 퍼뜨리는 것에 흥미를 잃어 전파가 멈출 수 있다.

전염 프로토콜은 업데이트를 전파하는데 매우 효과적이지만, 데이터 항목의 삭제를 전파하는 것은 어렵다. 삭제된 항목에 대한 정보가 계속 유지되지 않으면 새로운 노드에 전파되지 않기 때문이다.

이 문제를 해결하기 위해, 삭제된 항목을 Death certificate으로 기록한다. 이 사망 증명서는 항목이 삭제되었음을 나타내는 특별한 형태의 업그레이드로, 삭제된 항목을 전파할 수 있게 도와준다. 하지만 궁극적인 해결책은 아니다.

---

자, 이제 분산 시스템의 아키텍처에 대해서 배우고, 분산 시스템의 통신에 대해 배우면서, 통신 방법과 통신 패턴에 대해서도 배웠다.

 

새로운 내용을 배우기에 앞서 간단한 복습이다.

클라이언트와 서버 사이의 통신은 계층형 아키텍처에서 클라이언트-서버 모델을 통해 이루어진다.

서버는 특정한 서비스를 제공하는 프로세스고, 클라이언트는 서버에 서비스를 요청하는 프로세스다. 그리고 클라이언트는 요청을 보낸 후에, 응답을 받을 때까지 잠시 대기한다.

 

그럼 서버는 클라이언트와의 수락된 연결을 어떻게 처리할 것인가?

I/O Multiplexing

I/O Multiplexing은 스레드로 여러 개의 파일 디스크립터를 동시에 처리하는 방법이다.

이는 많은 수의 클라이언트 연결을 관리해야하는 서버에서 매우 유용하다. 

 

Select는 모든 파일 디스크립터의 리스트를 반복적으로 확인한다. (= polling)

리스트를 관리하는 함수는 아래와 같다.

• FD_ZERO: 파일 디스크립터를 초기화한다.
• FD_SET: 파일 디스크립터를 목록에 추가한다.
• FD_ISSET: 파일 디스크립터가 목록에 있는지 확인한다.
• FD_CLR: 파일 디스크립터를 목록에서 제거한다.

select는 싱글 스레드로 다수의 I/O를 처리한다.

 

Epoll은 이벤트를 기반으로 변경된 파일 디스크립터의 리스트를 확인한다.

• epoll_create: 파일 디스크립터를 저장할 공간을 생성한다.
• epoll_ctl: 파일 디스크립터를 추가, 수정, 또는 삭제한다.
• epoll_wait: 하나 이상의 파일 디스크립터에 변경 사항이 생길 때까지 기다린다.

epoll은 이벤트 기반으로 동작하여, select와는 달리 이벤트가 발생한 파일 디스크립터만 처리하기 때문에 자원을 적게 사용한다.

또한 여러 개의 스레드를 사용하여 이벤트가 발생하면 하나의 스레드가 깨어나 처리하고 다시 wait하는 방식으로 운영하기 때문에 많은 연결을 효율적으로 처리할 수 있다. 스레드 안전(?)하기도 하다.

---

Network I/O in JAVA

NIO(New Input Output)

select 기반이며, 저수준의 API다.

java.nio.channels.selector()를 사용한 논블로킹 I/O를 지원한다.

 

Netty

epoll 기반이며, 고수준의 API다.

이벤트와 핸들러(콜백)를 사용한 논블로킹 I/O를 지원한다.

 

RPC vs Java RMI

원격 프로시저 호출(RPC)은 절차적 프로그래밍(e.g. C) 기반이다.

매개 변수는 일반 데이터 구조로 전달되며, 개발 비용이 높다.

보안이 없어서 개발자가 직접 구현해야 한다.

 

원격 메소드 호출(RMI)은 객체 지향 프로그래밍(e.g. JAVA) 기반이다.

매개 변수는 객체로 전달되며, 합리적인 개발 비용이 든다.

클라이언트 레벨의 보안이 제공되며, RPC의 후속 버전이다.

---

교수님께서 수업을 마치며 컴공생이면 RPC구현 정도는 해보는게 기본 예의라고 하셨다.

조만간.. 해보도록 하겠습니다 교수님. 저는 위장 컴공생이지만 해보겠습니다.

 

** 대학교 수업을 듣고 이해한 부분을 최대한 풀어서 작성한 글입니다.

틀린 정보가 존재할 수 있으며, 언제나 피드백은 환영입니다. **