Middleware Protocol

Middleware

애플리케이션과 OS 사이에 존재하면서 분산 시스템에서 중요한 역할을 한다. 분산시스템의 기본 목적이었던 distribution transparency와 같은 것들을 제공해 줄 수 있는 이유가 미들웨어가 가려주기 때문이다. 애플리케이션에게는 노출하고 싶은 부분만 노출하고 밑단에서 일어나는 것들은 미들웨어 레이어에서 숨겨준다는 것이다. Layered protocol 입장에서는 분산 시스템 역할을 수행하기 위해 미들웨어 레이어가 들어갈 수 도 있다. 미들웨어 프로토콜은 통신을 이용해야 하므로 애플리케이션과 전송 계층 사이에 위치해야 한다. 미들웨어를 사용하는 애플리케이션은 이제 TCP, UDP를 직접 사용하는 것이 아니고 미들웨어를 통해 통신을 하고 분산 시스템 서비스를 이용할 수 있게 된다. 미들웨어가 애플리케이션에게 다양한 분산 시스템 또는 통신과 관련된 서비스를 제공해 준다.

미들웨어를 거치지 않고 직접 하는 방법은?

직접 해도 되지만 distribution transparency를 제공하기 어렵고 TCP, UDP 만으로는 분산 시스템이 요구하는 다양한 통신과 관련된 요구사항을 만족시키기 어렵다. 그래서 미들웨어라는 부분이 필요한 경우가 많다.

미들웨어도 애플리케이션 레이어 영역이고 애플리케이션에게 서비스를 제공하기 위한 미들웨어 영역에서의 프로토콜이 존재한다. 미들웨어는 위 애플리케이션 레이어에 다양한 종류이 애플리케이션이 올 수 있다. 좋은 미들웨어라면 특정 애플리케이션이 사용하는 미들웨어 보다는 범용적으로 사용할 수 있는 것이 좋다. 애플리케이션의 종류와 상관없이 사용할 수 있는 서비스들을 제공하는 미들웨어가 디자인 되면 좋다. CM도 그런 목적의 미들웨어다.

미들웨어가 제공해 줄 수 있는 서비스의 역할

미들웨어 레이어에서는 그럼 애플리케이션에게 어떤 종류의 서비스를 제공해 줄 수 있을 것인가

미들웨어가 제공해 줄 수 있는 서비스의 역할은 크게 두 가지로 구분해 볼 수 있다. 첫 번째는 일반적인 미들웨어 서비스 위에 분산시스템 애플리케이션이 사용할 수 있는 미들웨어 서비스이다. 일반적이고 공통적인 서비스를 말하는 것이다. 또 다른 하나는 커뮤니케이션에 특화된 서비스이다. 커뮤니케이션이면 메시지를 주고 받는 것 이외에 High-level에서의 커뮤니케이션 서비스가 있을 수 있다. 여기서 하이 레벨은 트랜스포트 레이어 보다 위에 있는 레벨을 말한다. 애플리케이션은 그런 서비스를 요청만 하면 미들웨어 단에서 알아서 해주겠다는 것이다.

미들웨어도 이런 서비스를 제공해 주기 위해서 밑에 있는 transport layer를 사용해야 한다. 미들웨어에서는 결국에는 tcp, udp를 써서 통신을 하고 애플리케이션에게는 그 사실을 숨기면서 애플리케이션이 요청한 다른 일반적인 서비스나 통신 서비스 같은 것들을 제공을 해준다.

공통 서비스

Authentication Protocols

예로는 Authentication Protocols이 있다. 사용자나 다른 디바이스에 대한 인증 서비스이다. 애플리케이션 종류와 상관없이 공통으로 제공해 줄 수 있는 서비스 중에 하나다. 여기선 프로토콜이라 적혀있지만 서비스라 생각해도 된다. 이런 서비스를 제공해주기 위해 미들웨어 단에선 프로토콜이 필요하므로 프로토콜이라 이름지었다.

Authorization Protocols

그 다음으로 Authorization Protocols이 있다. 일종의 권한 관리 서비스이다. Authentication과 Authorization의 차이점은 사용자 인증과 사용자 권한으로 생각하면 쉽다. 사용자 인증은 말그대로 어디에 등록해두고 인증된 사용자라는 것을 아이디와 패스워드를 가지고 증명하는 것이다. 인증은 누구나 다 인증은 등록만 정당하게 등록만 됐으면 인증은 통과된다. 인증이 통과된 다음에 봐야 될게 이제 Authorization이다. 인증된 사용자라도 사용자 종류에 따라서 권한이 다를 수 있다. 일반 사용자, 관리자, 게스트에 따라서 애플리케이션마다 대부분 보면 이렇게 사용자의 등급에 따라 다른 권한을 준다. 그런 권한 관리와 관련된 서비스를 미들웨어의 단에서 공통된 authorization 개념을 제공해 줄 수도 있을 것이다. 미들웨어에서 크게 지금 얘기한 것처럼 세 단계로 사용자의 레벨을 구분지어 놓을 수 있다.

Commit Protocols

DB 오퍼레이션을 생각을 해볼 수 있다. 클라이언트가 서버에게 10개의 DB 쿼리를 날렸을 때 정상적인 경우에는 쿼리가 다 수행이 돼서 최종 결과값이 반환 된다. 분산된 환경에서는 문제가 있을 수가 있다. 중간에 커뮤니케이션이 끊길 수도 있고 서버에 문제가 생길 수도 있다. DB 쿼리를 여러 개를 날리는 경우 끊기는 시점에 따라서 결과가 달라질 수 있다. 애초에 처음부터 문제가 있었다면 처음 날린 쿼리 부터 결과가 안 나올 것이다. 근데 네 다섯 번째 쿼리를 날리는데 그때 문제가 생겼다면 어떻게 될까? 열 개의 쿼리 전부를 다 한 결과를 알고 싶었던 건데 중간 단계까지만 성공한 결과는 사실 의미가 없다. 클라이언트에게는 그런 경우가 있을 수 있다. 애플리케이션이 이런 여러 가지 상황에 대비를 해야 한다. 10개의 쿼리를 보냈을 때 10개에 대한 결과가 다 제대로 왔는지 확인 해야 하고, 만약 중간에 문제가 생겼다면 롤백 같은 것을 하여 중간에 받았던 중간결과 값들은 안 받은 걸로 다 취소 시켜야 한다. 이런 과정을 미들웨어에서 해주는 것을 커밋 서비스라고 한다. atomistic한 오퍼레이션 서비스를 제공해 준다. 열개가 다 성공하면 결과값을 리턴하고 만약 중간에 하나라도 수행되지 못하면 롤백을 하고 애플리케이션에게는 모두 실패했다고 한다. 그냥 마치 요청을 하지도 않았던 것처럼 그 상태로 되돌리는 것이다. 원래는 애플리케이션이 다 처리했어야 되는 것을 미들웨어가 이런 서비스를 제공해 준다면 애플리케이션을 요청만 하면 된다.

Distributed locking protocols

Concurrency 서비스 같은 것들을 제공해 줄 수 있다. OS에서도 Locking mechanism을 제공한다. 프로세스들 끼리 공유하는 리소스를 동시에 액세스하고자 할 때 공유 리소스라서 여러 프로세스나 여러 스레드가 동시에 액세스하면 충돌 문제가 발생할 수 있다. OS가 메카니즘을 제공해줘서 프로세스들이 동시에 리소스를 요청하고자 할 때 이 매카니즘을 이용해서 락을 먼저 요청해서 락을 가진 프로세스만 리소스를 이용하도록 한다. 이것이 동기화 메카니즘 이다. 이러한 것은 OS 단에서 얘기였고 지금 설명하는 것은 Distributed lock이다. lock도 분산이 되어있다는 것은 어떤 리소스가 있는데 리소스를 사용하고자 하는 프로세스가 한 컴퓨터 안에서 돌아가는 프로세스가 아니고 네트워크로 연결되어 여러 컴퓨터에서 돌고 있는 프로세스들이 사용하고자 하는 리소스가 있을 수 있다. 이때도 똑같은 문제가 발생한다. 여러 컴퓨터에서 돌아가고 있는 프로세스들이 동시에 같은 리소스를 이용하고자 할 때 그냥 액세스하면 안 된다. 동시성 제어를 위한 메카니즘이 필요하다. 한 프로세스만 lock을 가지고 lock을 가진 프로세스만 리소스를 사용할 수 있는 절차를 원래는 애플리케이션이 다 관리해야 한다. 동시성 제어를 위한 locking 메카니즘은 미들웨어에서 제공해 줄 수 있는 공통적인 서비스가 될 수 있다는 것이다. 미들웨어 단에서 락 기능을 제공해 주고 애플리케이션은 필요할 때 락을 요청만 하면 된다. 같은 미들웨어를 사용하는 애플리케이션들은 똑같은 방식으로 하면 된다. 예를 들어 특정 ID를 갖는 것을 사용하고 싶어서 락을 걸어달라고 미들웨어에게 요청 한다. 요청한 ID를 이미 누가 쓰고 있다면 거절한다.

위의 예시 말고도 애플리케이션들이 공통으로 사용할 수 있는 서비스는 더 있을 수 있다.

Middleware protocols for communication protocols

미들웨어에서 제공해 줄 수 있는 서비스로 커뮤니케이션의 특화된 서비스가 있다. 애플리케이션이 다른 머신에 있는 애플리케이션에게 메시지를 주고 받는 기능을 많이 사용을 하게 된다. 그냥 tcp, udp와 같이 transport layer의 소켓을 이용하기에는 부족한 부분들이 있다. 애플리케이션과 트랜스포트 레이어 사이에 미들웨어가 하이레벨 커뮤니케이션 서비스를 애플리케이션에게 제공 해주면 애플리케이션은 tcp udp 사용하는 것 보다는 사용편의성이 더 좋게 커뮤니케이션을 할 수 있는 수단을 제공해 줄 수 있다.

RPC(Remote Procedure Call)

그 중에 하나로 RPC라는 개념이 있다. Remote Procedure Call 또는 Remote Object invocation 이라 한다. Procedure는 함수라고 생각하면 된다. 서버에 어떤 서비스를 요청하고 싶다면 서비스를 요청하는 메시지를 만들어야 한다. 만든 메세지를 서버에게 보내고 서버가 보내주는 응답 메세지를 통해 요청했던 데이타를 받아서 사용하는 것이 tcp, udp를 사용할때의 일반적인 절차이다.

이는 분산시스템에서 추구했던 궁극적인 Distribution Transparency를 제공하는 철학에 맞지 않다. 서버에게 요청을 했다는 것 자체가 클라이언트는 서버의 존재를 안다는 것이다. Distribution Transparency에서 가장 이상적인 케이스는 서버의 존재도 모르는 것이다. 클라이언트는 뭔가 필요한 서비스가 있으면 그 서비스를 그냥 호출해서 이용할 수 있어야 한다. 마치 로컬 함수를 부르듯이 서비스를 사용할 수 있어야 한다. 이런 개념으로 메시지를 직접적으로 보내지 말고 클라이언트가 원하는 서비스가 있으면 그 서비스를 마치 그냥 함수를 호출 하듯이 제공해준다. 미들웨어는 애플리케이션에 함수 이름이랑 파라미터 같은 것을 주고 요청한 서비스의 결과를 리턴값으로 준다.

Synchronizing

Real-time 데이터 같이 동기화가 필요한 데이터를 주고 받을 때는 동기화 절차를 애플리케이션이 해야한다. 대표적으로 멀티미디어 스트림 데이터가 있다. 동영상이나 사운드 데이터 같은 것들이다. 인코딩, 디코딩과 같이 복잡한 작업들을 미들웨어에서 공통적으로 제공해준다면 더 편하게 이용할 수 있다.

Multicast

tcp나 udp는 목적지 대상이 하나이다. 그래서 tcp, udp를 사용해서 하는 통신은 일 대 일 통신이라 한다. 멀티캐스트는 일 대 다 통신을 할 수 있도록 transport layer에서 제공해 주는 것이 멀티캐스트 기술이다. TCP나 UDP를 가지고 하는 통신은 유니캐스트라 한다. 멀티캐스트 서비스는 IP를 그대로 이용한다. UDP 서비스의 특성을 그대로 가지고 있어 비신뢰적이다. IP multicast라 하는 것도 미들웨어가 제공해 줄 수 있다. 한 단계 더 나아가 reliable multicast를 제공해줄 수 있다. 애플리케이션이 멀티캐스트로 메세지를 보내면 미들웨어에서는 tcp에서의 역할과 유사하게 신뢰성을 보장해준다. 이는 대표적인 하이레벨 커뮤니케이션 서비스 개념이 될 수 있다. 프로토콜 레이어로 치면 트랜스포트 레이어에 속하는 영역이 될 수도 있지만 실질적으로 트랜스포트는 아니고 미들웨어에서 제공해주는 하이레벨 커뮤니케이션 서비스는 애플리케이션 레이어 안에서 제공해주는 서비스이다.

트랜스포트 레이어를 직접 수정을 하고 싶으면 어떻게 해야 될까. 나만의 TCP를 사용하고 싶다면 OS를 수정해야 한다. 미들웨어는 OS를 직접 건드리는 것은 아니고 OS를 이용하는 것이다. OS 위에 위치해 있기 때문에 그리고 네트워크 프로토콜로 보면 트랜스포트를 위에 있기 때문에 밑에 있는 TCP나 UDP를 그대로 이용한다. 이용해서 윗 레벨인 애플리케이션에게 뭔가 다른 서비스를 제공해 준다는 것이다.

Middleware Protocol Layer

OSI 7 layer 그림과 유사한데 애플리케이션 밑에 있었던 세션 레이어와 프리젠테이션 레이어는 애플리케이션에 포함시키고 애플리케이션과 트랜스포트를 레이어 사이에 미들웨어의 역할을 하는 프로토콜이 있다. 미들웨어를 이용을 해서 우리가 지금까지 봤었던 분산시스템 서비스를 제공해 줄 수 있다는 의미이다.