RPC의 문제점은 요청이 발송될 때 수신 측이 실행 중이라고 가정할 수 없는 경우와 RPC의 동기적인 성격 때문에 클라이언트가 블록되는 현상이 발생한다는 점이다.
이에 대한 대안적인 접근 방식은 메시징(messaging)이다.
1. Berkeley sockets
많은 분산 시스템은 전송 계층에서 제공하는 간단한 메시지 지향 모델(message-oriented mode)을 기반으로 구축된다.
소켓은 개념적인 통신 끝점으로, 응용 프로그램은 여기에 전송할 데이터를 작성하고 들어오는 데이터를 읽을 수 있다.
TCP 소켓 원시 함수(TCP socket primitives)를 사용하여 다음과 같은 작업을 수행할 수 있다.
첫째, 소켓을 생성한다.
이는 호출자가 새로운 통신 끝점을 생성하고 메시지를 보내고 받기 위해 로컬 운영 체제에서 자원을 예약한다는 것을 의미한다.
둘째, bind 함수를 사용하여 새로 생성된 소켓에 로컬 주소를 연결한다.
예를 들어, 서버는 자신의 IP 주소와 함께 포트 번호를 소켓에 바인딩한다.
이렇게 바인딩하면 운영 체제에게 서버가 지정된 주소와 포트에서만 메시지를 수신하려는 의도를 알린다.
클라이언트 측에서는 바인딩이 필요하지 않으며, 연결이 설정될 때 운영 체제가 동적으로 포트를 할당할 수 있다.
TCP 소켓 원시 함수
-
listen (서버 측)
- 연결 지향 통신에서만 사용된다.
- 비차단 호출로, 로컬 운영 체제가 지정된 최대 연결 수에 대해 충분한 버퍼를 예약할 수 있도록 한다.
-
accept (서버 측)
- 호출자를 블로킹시키고 연결 요청이 도착할 때까지 대기한다.
- 요청이 도착하면, 로컬 운영 체제가 새로운 소켓을 생성하고 호출자에게 반환한다.
-
connect (클라이언트 측)
- 호출자가 연결 요청을 보낼 전송 수준 주소를 지정한다.
-
send, receive
- 연결이 설정된 후에는 양쪽 모두 정보를 교환할 수 있다.
-
close
- 연결을 종료한다.
2. Message-queuing model
메시지 큐 시스템 또는 메시지 지향 미들웨어(MOM)는 지속적인 비동기 통신을 지원하기 위해 다양한 기능을 제공한다.
이들 시스템은 메시지를 중간기간 동안 저장할 수 있는 용량을 제공하며, 메시지 전송 중에 발신자나 수신자가 활동 중이어야 할 필요가 없다.
즉, 발신자와 수신자는 메시지 전송 중에 활성 상태일 필요가 없다.
애플리케이션은 특정한 큐에 메시지를 삽입함으로써 통신을 수행한다.
각 애플리케이션은 자신에게 메시지를 전송할 수 있는 개별적인 개인 큐를 가지고 있다.
큐는 개인적으로 사용되거나 공유될 수 있다.
발신자는 메시지가 최종적으로 수신자의 큐에 삽입될 것을 보장받지만, 실제로 메시지가 언제 또는 실제로 읽힐지에 대해서는 보장되지 않는다.
수신자가 메시지가 전송되는 동안 실행 중이어야 할 필요는 없다.
또한 발신자는 메시지가 수신자에 의해 가져가지는 순간에 실행 중이어야 할 필요도 없다.
한 번 메시지가 큐에 저장되면, 메시지가 제거될 때까지 그대로 유지된다.
발신자와 수신자의 실행 모드에 대해 4가지 조합이 있다.
-
실행 중인 발신자와 실행 중인 수신자
-
실행 중인 발신자와 수동적인 수신자
-
수동적인 발신자와 실행 중인 수신자
-
수동적인 발신자와 수동적인 수신자
-
Put
• 지정된 큐에 메시지를추가함(논블로킹호출)
• 발신자가 메시지를 기반 시스템에 전달하기 위해 호출됨 -
Get
• 지정된 큐가 비어 있지 않을 때까지 블로킹됨(블로킹호출)
• 큐에서 가장 긴 대기 중인 메시지를제거함
• 특정 메시지를 검색할 수도 있음 -
Poll
• 'Get' 원시 함수의논블로킹버전
• 큐가 비어 있거나 특정 메시지를 찾을 수 없는 경우, 호출 프로세스는 그대로 진행함 -
Notify
• 지정된 큐에 메시지가 추가될 때 호출될핸들러를 설치함
• 핸들러는 자동으로 호출되는콜백 함수임
2. General Architecture
메시지는 오직 같은 기계의 큐 혹은 같은 LAN에 있는 인접한 기계의 큐로만 전달될 수 있다.
이러한 큐를 소스 큐라고 부른다.
메시지는 오직 로컬 큐에서만 읽혀질 수 있다.
또한, 메시지는 목적지 큐의 명세를 포함하고 있다.
메시지 큐잉 시스템은 메시지가 정확히 이동되는 것을 보장하는 역할을 담당한다.
큐 매니저는 대기열을 관리하며 애플리케이션과 직접 상호작용한다.
라우터나 릴레이로 작동하는 특수한 큐 매니저도 있다.
이러한 릴레이는 여러 가지 이유로 편리하다.
예를 들어, 많은 메시지 큐 시스템에서는 일반적인 네이밍 서비스가 없다.
그 대신, 대기열 네트워크의 토폴로지는 정적으로 설정되어 있으며, 각 큐 매니저는 대기열과 위치 매핑의 사본이 필요하다.
이러한 접근 방식은 대규모 대기열 시스템에서 네트워크 관리 문제를 일으킬 수 있다.
릴레이 사용의 해결책은 네트워크 토폴로지에 대한 정보를 알고 있는 몇 개의 라우터를 사용하는 것이다.
예를 들어, 아래 그림과 같이 하나의 송신자 A가 목적지 B로 메시지를 보낸다고 가정해보자.
메시지는 먼저 가장 가까운 라우터인 R1로 전송된다.
이 라우터는 메시지를 처리할 방법을 알고 있으며, B의 방향으로 메시지를 전달한다.
이렇게 함으로써, 대기열이 추가되거나 제거될 때 라우터만 업데이트해주면 된다.
다른 모든 큐 매니저들은 가장 가까운 라우터가 어디에 있는지만 알면 된다.
릴레이가 사용되는 또 다른 이유는 메시지의 보조 처리를 가능하게 한다는 것이다.
예를 들어, 메시지는 보안이나 장애 허용성을 위해 로그에 기록되어야 할 수 있다.
또한, 특수한 릴레이는 메시지를 수신자가 이해할 수 있는 형식으로 변환하는 게이트웨이 역할을 수행할 수도 있다.
3. Message brokers
메시지 큐 시스템의 중요한 응용 분야는 기존 및 신규 애플리케이션을 하나의 일관된 분산 정보 시스템으로 통합하는 것이다.
이 통합은 애플리케이션이 메시지를 이해할 수 있어야 한다는 요구사항을 가지고 있다.
그러나 문제는 개별적인 메시지 형식이 필요한 시스템에 새로운 애플리케이션이 추가될 때마다 각 수신자를 조정해야 한다는 것이다.
이를 해결하기 위한 대안적인 해결책은 공통된 메시지 형식에 동의하는 것이다(전통적인 네트워크 프로토콜과 같은).
그러나 메시지 큐 시스템에서는 이 접근 방식이 일반적으로 작동하지 않는다.
왜냐하면 추상화 수준 때문에 공통된 메시지 형식은 프로세스 집합이 실제로 충분히 공통점이 있을 때 의미가 있기 때문이다.
이는 응용 프로그램 수준에서 어렵다.
