분산 메모리

 

메모리 인터페이스를 통해 원격 컴퓨터의 메모리를 참조하는 것이 분산 메모리 시스템의 목표입니다.
분산 메모리를 다루기 위한 여러 가지 모델이 운영체제 개발자들에 의해 제시되었습니다.
그중 가장 널리 사용되는 방법은 원격 메모리와 분산 메모리입니다.

 

1. 원격 메모리

원격 메모리는 일반적인 메모리 인터페이스나 파일 인터페이스와는 다른 인터페이스를 사용하여 네트워크 메모리 내에서 다양한 접근 방법을 사용합니다.

 

프로세스는 전역 주소 공간에 매핑된 로컬 주소 공간의 이름을 통해 원격 메모리를 참조합니다. 예를 들어, 원격 메모리에 전송 계층 주소(net#, host#, port#)가 할당되면 프로세스는 해당 서버 주소상의 블록과 오프셋을 참조할 수 있습니다. 만약 서버가 1개 이상의 블록을 관리한다면 로컬 이름 공간 안에서 단순한 주소는 다음 형식의 주소에 대응됩니다.

<(net#, host#, port#), block, offset>

Linda 접근 방식은 이러한 문제를 공유된 전역 튜플 공간을 위한 연관 참조 연산을 사용하여 해결합니다. 프로그램은 메모리의 네트워크 위치에 대한 정보 없이 전역 튜플 공간에 튜플을 쓸 수 있습니다. 또 다른 방법으로는 컴파일 시간, 적재 시간, 런타임 바인딩이 일어나도록 시스템이 설계될 수 있습니다. 컴파일 시간 바인딩은 반드시 위치가 명확해야 하고 소프트웨어와 밀접하게 연관되어 있어야 합니다. 그러나 이러한 시스템은 거의 존재하지 않습니다. 적재 시간 바인딩은 외부 참조를 해결할 때 링크 에디터를 통해 네트워크 위치가 정의됩니다. 이는 프로그램이 링크되고 적재될 때 사용자가 원격 메모리의 위치를 제공한다는 것을 의미합니다. 그러나 런타임 바인딩이 훨씬 유연하기 때문에 적재 시간 바인딩은 거의 사용되지 않습니다. 런타임 바인딩을 하면 프로그램은 처음 참조될 때 원격 메모리의 위치를 바인딩하기 위해 이름 서버를 사용하기 위한 충분한 정보를 가지고 컴파일됩니다. 연속적인 참조가 발생할 경우에는 처음의 참조 바인딩을 재사용합니다. 데이터 일관성은 공유 메모리에 저장된 데이터가 일관성을 유지한다는 것을 명확하게 보장하지 않기 때문에 정의에 어긋날 수 있습니다. 그러므로 일관성은 시스템보다는 오히려 프로그래머의 책임이 됩니다. 프로그래머는 필요한 시점에 동기화 메커니즘을 추가해야 합니다.

 

2. 분산 공유 메모리

공유되는 원격 메모리는 스레드가 마치 로컬 메모리처럼 취급하므로 추상적인 측면을 가지고 있습니다. 이러한 원격 메모리를 구현하기 위해서는 가상 메모리 인터페이스를 이용합니다. 가상 메모리는 메모리 맵 메커니즘을 추가하여 자신의 명령어 중 고유 부분으로 가상 주소 공간을 구성합니다. 분산 공유 메모리에서 분산 가상주소들은 공유 가상 메모리 주소로 매핑됩니다. 이러한 분산 공유 메모리는 프로그래머의 관점에서는 매우 매력적이며 로컬 가상 메모리와 같은 방법으로 할당되고 참조될 수 있습니다.

하지만 메모리 관리자의 관점에서는 네트워크 네이밍과 투명성 문제를 다룰 필요가 있습니다. 전역 메모리 서버는 자신의 서비스를 적절한 이름 서버에 등록하여 클라이언트가 런타임에 서버에 바인딩할 수 있도록 해야 합니다. 또한, 로컬 메모리에 있는 페이지들의 다양한 복사본과 전역 페이지 서버에 있는 페이지 워 보들 간의 일관성 유지는 중요합니다. 이를 위해 많은 연구가 진행되고 있습니다.

 

3. 원격 프로시저 호출

원격 프로시저 호출(RPC)은 애플리케이션이 다른 컴퓨터에 있는 프로시저를 호출할 수 있도록 하는 클라이언트-서버 메커니즘입니다. 이를 통해 원격지의 서버 프로그램을 마치 로컬에서 실행하는 것처럼 사용할 수 있습니다.

 

4. 원격 프로시저 호출의 동작

RPC는 전통적인 프로시저 호출을 가로채어 해당 호출과 매개변수를 원격지 컴퓨터로 전달하는 클라이언트-서버 메커니즘입니다. 이 때, RPC 프로시저는 호출을 수행한 프로시저와는 다른 주소공간에서 실행됩니다. RPC를 사용하려는 클라이언트는 먼저 로컬 프로시저를 호출해야 하는데, 이러한 프로시저들을 스텁(stub) 루틴이라고 부릅니다. 스텁 루틴은 호출자가 넘겨준 인자를 메시지로 만든 후에 네트워크를 통해서 특정 서버 프로세스에 전달합니다. 그 후 클라이언트 측의 스텝 루틴은 실행을 중단한 채 차단됩니다. 서버는 전달된 메시지를 보고 적절한 프로시저를 호출한 뒤 그 결과를 다시 메시지로 만들어서 클라이언트의 스탑 루틴에 돌려주고, 이 스탑 루틴의 수행이 재개되어 RPC의 결과 메시지를 풀어서 이를 다시 호출자에게 돌려줍니다. 이러한 구조는 호출 프로세스의 관점에서 보면 마치 한 컴퓨터에서 다른 컴퓨터로의 프로시저 호출처럼 작동합니다.

 

5. 원격 프로시저 호출의 구현

RPC는 한 컴퓨터에서 실행되는 애플리케이션이 다른 컴퓨터의 프로시저를 호출할 수 있도록 해주는 클라이언트-서버 메커니즘입니다. 이를 구현하기 위해서는 몇 가지 사항을 고려해야 합니다. 첫째, RPC 구문은 이상적으로는 고급 프로그래밍 언어에서 로컬 프로시저 호출과 동일해야 합니다. 둘째, 호출 프로시저와 피 호출 프로시저는 각각의 주소공간에서 실행되기 때문에 대부분의 RPC 구현에서는 참조호출을 지원하지 않습니다. 셋째, RPC 수신자는 호출자가 생성된 곳과 유사한 환경에서 실행되어야 합니다. 프로시저가 전역변수를 참조하거나 수정하는 전통적인 프로시저 환경과 같은 의미 있는 동작을 제공하기 위해서는 클라이언트와 rpcServer 사이의 특별한 통신이 필요합니다.

RPC는 클라이언트와 서버 간의 통신으로 구성됩니다. 클라이언트 컴퓨터는 클라이언트 응용 프로그램 코드와 클라이언트 스탑, 전송 메커니즘으로 이루어져 있습니다. 서버 컴퓨터는 전송 메커니즘, 서버 스태프 메인 프로그램, 프로시저의 서버 구현을 가진 rpcServer 프로세스를 구현합니다. 클라이언트 스탑은 로컬 프로시저 호출을 RPC 프로토콜의 클라이언트 측 동작으로 변환합니다. 서버 스텝은 RPC 프로토콜의 서버 측 부분을 구현합니다. 클라이언트 스탑은 메시지 안에 인자들을 넣고 해당 메시지를 rpcServer 프로세스 내의 서버 스탑으로 전송합니다. 서버 스탑은 호출을 수행하고 결과 매개변수를 메시지 안에 넣어 클라이언트 프로세스에 반환합니다. 클라이언트 프로세스는 반환 메시지를 받고 반환 매개변수를 메시지로부터 분리하여 메인 프로그램으로 전달합니다.

RPC는 분산 처리에 유용하지만 병렬 처리에는 적합하지 않습니다. 원격 프로시저가 실행되는 동안 호출자는 일시 정지됩니다. 그러나 원격 프로시저는 분산 응용에 널리 사용되고 있으며, 전통적인 프로그래밍 모델을 구현하면서 분산 메커니즘과 정책들에 대한 적은 지식을 요구하기 때문입니다. RPC는 대부분의 클라이언트-서버 응용프로그램에서 사용되며, 원격 파일 시스템, 분산 데이터베이스 시스템, 인터넷에서의 분산 인터페이스 서비스, 분산 그래픽 시스템 등의 분산응용을 위해 사용됩니다. RPC는 서버와 클라이언트가 서로 다른 언어로 작성되어 있을 수도 있기 때문에 다양한 컴퓨터 시스템과 응용프로그램 사이의 상호운용성을 제공합니다.