분산시스템) 목표(3) - Openness

Goals - Openness

목적

개방성이 되기 위해선 분산 시스템의 서비스를 제공할 때 standard rule에 따라 제공해야한다.

모든 분산 시스템의 목적이 될 수는 없고 개방성을 따르는 시스템의 목적이 될 수 있다. 사용자는 분산 시스템에서 제공하는 서비스를 요청하고 분산 시스템은 사용자에게 서비스를 제공한다. 요청하고 제공하는 방식을 표준으로 마련해두면 사용자 입장에서 어떤 분산 시스템이건 동일한 방법으로 요청할 수 있어 사용하기 편해진다.

standard rule

In computer networks, standard rules govern the format, contents, and meaning of messages sent and received. And rules are formalized in protocols.

IDL(Interface Defenition Language)

분산 시스템도 서비스를 제공할 때 표준을 지켜서 제공하면 좋다. 그 표준 중에 IDL이란 것이 있다. 클라이언트가 분산 시스템에 서비스를 요청하는 것은 프로그래밍 레벨로 보면 서비스라고 하는 함수를 호출한 것이라 볼 수 있다. 클라이언트 C가 분산 시스템 DS로 서비스를 요청하기 전에 DS에서 어떤 서비스를 제공하는지 알아야한다. DS가 제공하는 서비스 목록 L을 포함하여, 서비스 함수를 요청하기 위해 필요한 파라미터, 리턴 값 등의 정보를 요청하고 제공 받는 것이 서비스 인터페이스이다. 분산 시스템을 개발하는 입장에서는 사용자에게 서비스 이름, 리턴 타입, 필요한 파라미터 등을 어떻게 노출시킬지에 대한 인터페이스를 정의해야한다. 이때 IDL을 사용해서 인터페이스를 정의한다.

client ds

IDL을 이용해 인터페이스를 정의하는 것은 서비스 이름, 리턴 타입 등 syntax 표준을 마련해주는 것이고 어려운 것은 인터페이스의 semantics 이다. a라는 서비스가 어떤 서비스인지 설명이 있어야한다. 어떤 라이브러리를 활용하는데 함수 이름과 syntax만 있으면 이게 어떤 기능을 하는 함수인지 알기 어렵다. 이 서비스가 어떤 종류의 서비스를 제공하는 것인지 semantics를 알아야한다. 이것을 제공하는 입장에서 사전에 클라이언트측에 충분히 제공해줘야 하고 이에 대해 스탠다드 룰을 따르면 좋다.

목표

Interoperability

상호 운용성

어떤 서비스 a가 있을 때 이 서비스를 두 회사가 따로 각각 개발하였다 가정해보자. 사용자는 a 서비스를 A 회사로부터 받을 수도 있고 B 회사로부터도 받을 수 있을 때, 해당 서비스를 어디서 받든 동일한 품질로 사용할 수 있으면 서비스 a 는 상호 운용이 가능하다고 말한다. 다른 예로 A 회사는 서비스 a를 개발하고 B 회사는 서비스 b를 개발할 때, 두 서비스 a, b가 서로 요청하고 제공하는 클라이언트-서버 관계에 있다면 상호 운용성이 제공된다고 한다. 어떤 서비스를 둘 이상의 개발팀에서 각자 개발했을 때 어떤 것을 쓰든 서로 이용이 가능하다면 상호 운용성이 제공된다고 한다.

Portability

이식성

한 분산 시스템이 어떤 서비스를 제공하도록 개발 했을 때 이 서비스를 별도의 수정작업 없이 다른 분산 시스템에서 이용 가능하다면 이식성이 제공되는 서비스라고 한다. 분산 시스템 서비스는 아니지만 Portability에 부합되는 예로 자바가 있다. 시스템 독립적이어서 자바 프로그램이 만들어지면 OS에 상관없이 돌아간다.

Flexibility

separating policy from mechanism

하나의 분산 시스템 서비스가 사용자의 요구사항에 맞춰서 적응형으로 서로 다른 방식으로 서비스가 될 수 있으면 더 좋은 서비스가 될 수 있다.

Monolithic

예전 분산 시스템에서 개발된 서비스들은 많은 경우 monolithic approach로 만들어져 제공된다. Monolithic approach란 서비스가 하나의 커다란 덩어리로서 고정된 형태로 제공되는 형태를 말한다. Flexibility와 반대되는 개념이라 볼 수 있다. 쉽고 빠르게 개발하다보면 서비스가 monolithic한 방법으로 개발된다. 여러가지 사용 가능한 옵션 같은 것들을 고려하지 않고 제공하는 경우를 말한다.

Caching

분산 시스템 서비스 중 웹 브라우저 상에서 cache 서비스를 예로 들 수 있다. 캐싱의 개념은 웹브라우저에서 url을 치면 웹 서버로부터 우리가 요청하는 웹 리소스(웹 페이지 등)를 다운로드 받는다. 한 번 다운 받아서 액세스했던 웹 페이지는 내가 요청할 때마다 매번 웹 서버로부터 다운로드 받는 대신에 로컬에 저장해 놓고 이를 캐싱이라 한다. 캐싱을 사용하는 이유는 보다 빠르게 웹 페이지를 엑세스하기 위해서이다. 로컬에 있는 웹 페이지를 로드하는 것이 웹 서버로부터 웹 페이지를 다운로드 받아서 로드하는 것보다 훨씬 빠르다. 이처럼 퍼포먼스 향상을 위해서 많이 사용한다.

 

Flexible한 캐싱 서비스를 제공할 때 고려해야할 파라미터는 캐시 사이즈(로컬에 저장할 저장 공간)나 원본 데이터와의 consistency 등이 있다. 캐시된 데이터가 원본 데이터와 같은지 확인하는 작업이 필요하다. 원본 데이터와 캐시된 데이터가 다른 경우 consistency가 깨졌다고 한다. consistency를 매번 체크할 것인지 한 세션당 한 번만 체크할 것인지는 캐시된 데이터의 특성에 따라 다르게 적용할 수 있다. 매번 체크해야하는 것은 항상 최신 데이터가 필요한 경우이다. 대표적인 예로 주식시장이 있다. 현재 주식 시세는 초를 다투는 문제이기 때문에 캐시된 데이터로 옛날 데이터를 보여주면 문제가 될 수 있다. 업데이트가 잘 되지 않는 웹페이지 같은 경우나 원본과 다르더라도 크게 문제가 되지 않는 경우 빈도를 낮출 수 있다.

 

이외에도 캐시된 데이터를 얼마나 오랫동안 저장해둘지나 저장공간이 가득 찼을 때 이미 캐시된 데이터 중 어떤 것을 삭제할지 결정하는 것이 있다.

Policy & Mechanism

Policy는 어떤 방식으로 서비스할지를 의미하고 mechanism은 제공하려하는 서비스 자체를 의미한다. Policy는 'HOW'에 해당하고 mechanism은 'WHAT'에 해당한다. 분산 시스템을 설계할 때 이를 고려하지 않으면 policy와 mechanism이 분리되지 않고 monolithic하게 개발되어 flexible하게 제공하기 어렵게 된다.

 

웹 캐싱의 예를 들면 mechanism은 캐싱이라는 기능 자체가 된다. 웹 브라우저는 기본적으로 캐싱 메커니즘을 제공하여 사용자가 방문했던 페이지는 캐싱 공간에 로컬로 저장한다. policy의 경우 캐싱 메커니즘을 어떤 방식으로 서비스 할 것인가를 의미하는데, 옵션에서 캐시와 관련된 policy 파라미터를 조정할 수 있도록 해주면 더 유연한 서비스가 될 수 있다.

 

가장 이상적인 형태는 policy 자체를 사용자가 개발해서 현재 메커니즘에 플러그인 형태로 끼워넣을 수 있도록 하는 것이다. 나중에 생각치 못한 파라미터가 생길 수 있으므로 컴포넌트 형태로 policy를 현재 메커니즘에 추가할 수 있으면 좀 더 flexible한 서비스가 될 수 있을 것이다.

Another goal for an open distributed system

• 시스템을 configure하기 쉬워야 한다.
• 시스템을 확장하기 쉬워야 한다.