분산시스템의 투명성 (Transparency in Distributed System)

1. Access (접근성): 데이터 표현과 리소스 엑세스 방법의 차이를 숨겨야 한다.
- 각각의 컴퓨터마다 표현방법이 다를 수 있다. 예) 인코딩 / 프로그램 타입 등등
하지만 유저는 기기나 OS 상관 없이 액세스를 할 수 있다. 단 액세스 방법의 차이를 숨겨야 한다.

2. Location (위치): 리소스가 있는 위치를 숨겨야 한다.
- 객체가 물리적으로 어디에 위치된지 알 수 없다. 예를들어 URL/index.html 이 주어진다면 유저는 서버컴퓨터 어디에 위치한지 알 수 없어야 한다.

3. Migration (이동): 리소스가 다른 위치로 이동 하더라도 유저와는 상관이 없어야 한다.
- 분산시스템에서 리소스가 어떻게 액세스 하는지 상관없이 리소스가 옮겨지더라도 유저는 상관 없어야 한다.

4. Relocation (재위치): 사용중에 리소스가 다른 위치로 이동되더라도 유저와는 상관이 없어야 한다.
- 유저가 시스템 사용중일때 리소스의 위치를 옮겨도 유저는 알지 못하여야 한다.

5. Replication (중복성): 리소스가 복제됌을 숨겨야 한다.
- 가용성. 하나가 죽더라도 계속 사용할 수 있거나, 리소스의 유효성 혹은 성능을 늘리기 위해 리소스를 복제해서 접근하기 쉬운곳에 배치한다. 이때 여러 사본의 리소스가 있다는 것을 숨긴다.
동시에 해당 리소스가 다른 위치에 있다고 하는 LOCATION transparency도 함께 지켜져야 한다.

6. Concurrency (동시성/병렬적): 여러 경쟁 사용자가 리소스를 공유할 수 있음을 숨겨야 한다.
- 여러 사용자가 사용하더라도 혼자 사용하는 것 처럼 보여야 한다. 데이터 공유시에 다른 유저가 같은 리소스를 사용하고 있다고 인지하지 못하게 하여야 한다. 중요한 점은
동시에 공유데이터를 액세스 할 때 리소스를 일관된 상태로 남겨야 한다는 것이다. 일관성을 위해서는 LOCKING 매커니즘을 사용한다. 이를 통해 원하는 데이터를 혼자 사용할 수 있다.

7. Failure (실패): 리소스의 장애 및 복구됌을 숨겨야 한다.
- 시스템에 어떤 부분에서 문제가 발생해도 이를 알지 못하고, 시스템은 바로 리커버해야 한다. 
분산시스템에서 실패를 Failure를 숨기는 일은 매우 어렵다. 리커버가 어려운 주된 이유는 시스템상에서 프로세스가 죽은것인지 혹은 매우 느리게 반응하는지 구분하는게 사실상 불가능하기 때문이다.
웹서버를 예를 들면 유저가 매우 바쁜 웹사이트를 접속할 때 결과적으로 브라우저에서 타임아웃이 발생했다면 그 원인이 서버가 죽은 것인지 혹은 네트워크가 매우 혼잡한 이유인지 알 수 없는 것이다.

 

Transparency를 지키기 위해서는 중요한 Trade-off를 해야 한다. 앞서 설명한 Failure transparency의 경우 매우 어려우므로 자칫하면 시스템 전체가 Halt 하는 최악의 상황도 발생할 수 있다.
이는 부분적으로 숨기기 어렵다.