본문 바로가기

Distributed System/이론 공부

분산시스템) 시스템 아키텍쳐(3) - 미들웨어

Architectures vs Middleware

분산 시스템을 개발할 때 많은 경우 미들웨어 형태로 제공된다. 애플리케이션이 필요로하는 서비스를 미들웨어를 통해서 요청하면 된다. 코드 시스템도 일종의 미들웨어 역할을 하는 시스템이라 볼 수 있다. 애플리케이션이 요청만 하면 overlay 네트워크를 구성하고 데이터를 찾아주는 식의 P2P로 연결하는 서비스를 코드 시스템이 해준다. 노드들이 사용하는 미들웨어 아키텍쳐도 너무 정적으로 만들지 않고 다이나믹하게 adaptive하게 만드는 것이 좋다.

Middleware의 장점

애플리케이션을 개발하는 것이 수월해진다. 모든 것을 애플리케이션이 개발할 필요 없고 미들웨어에서 제공하는 서비스는 요청해서 쓰면된다. 프로그래밍할 때 라이브러리를 사용하는 것과 같다. 개발의 효율성이 향상된다.

Middleware의 단점 - CORBA

미들웨어라는 추가적인 시스템이 들어가는 것이기 때문에 performance가 떨어질 수 있다. CORBA라는 시스템이 있다. 어떤 애플리케이션간의 통신을 담당해주는 역할을 하는 object message broker이다. heterogeneous한 플랫폼 간에 서비스를 사용하는 것을 중재해주는 역할을 했지만 너무 다양한 서비스를 제공해주려고 해서 performance가 너무 느렸다. 애플리케이션 간의 인터렉션하는 것을 remote procesure call(RPC) 방식으로 제공해줬다. 원격지에 있는 object를 호출하는 방식으로 제공되었다. object를 관리하는데 overhead가 많이 들기 때문에 나중에 object 단위로 서비스를 제공받는 대신 light weight한 메세징 방법이 나왔다. CORBA는 정적으로 디자인된 시스템이기 때문에 새로운 시스템을 추가하기 어려웠다.

A better approach

미들웨어 시스템이 configure, adapt, customize하기 쉽게 동적으로 상황에 맞게 변경시킬 수 있도록 디자인하는 것이 좋다. 그래서 policy와 mechanism을 분리하는 것이 좋다.

Self-management

Automatic adaptation

시스템이 자가 진단해서 상황이 바뀐 것을 인지하고 그에 따라 behavior를 바꾸는 형태로 바꾸면 좋다.

Feedback control model

  • Monitoring
    context detection이 가능해야한다.
  • Analyzing measurements
    시스템이 돌아가면서 클라이언트가 요청한 인풋에 대한 아웃풋을 분석해야한다. 원래 나와야하는 아웃풋과 실제 나온 아웃풋을 비교하며 분석할 수 있다.
  • Mechanisms to influence the behavior
    모니터링을 통해 데이터를 수집하고 분석을 통해 변경이 필요하다면 상황에 맞춰 변경해야한다. 어떻게 바꿀지는 어플리케이션의 종류에 따라 달라진다.

self management