Distributed Systems 2

Considerations of Distributed Systems

1. Heterogeneity(이질)

분산 시스템의 각각의 노드들이 동일한 OS나 하드웨어 등을 쓸 필요가 없다. 분산되어 있으니까!

그래서 다양한 네트워크, 하드웨어, OS, 프로그래밍 언어가 사용된다. 

 

그렇다면 이질적인 것들을 위한 서포트가 있어야하는데,

• 미들웨어: 프로그래밍 추상화를 제공하는 소프트웨어 레이어이다. DCE, CORBA, DCOM 등
• 모바일 코드: 한 컴퓨터에서 다른 컴퓨터로 이전되어 실행될 수 있는 프로그램 코드. JVM 등

2. Openness(개방성)

개방성이란 시스템의 확장성이나 재구성을 판단하는 기준이다.

기존 환경에서의 이질과 관계없이 다른 서비스의 요소와 상호작용을 허용한다.

핵심 요소는 coherence(일관성)인데, 중요 요소에 대한 퍼블릭 인터페이스나, 공유 자원에 접근하기 위한 유니폼 커뮤니케이션 메커니즘 등을 통해 이루어진다.

Uniform communication mechanism: 시스템 내에서 일관된 방식으로 다양한 구성 요소 간의 통신을 가능하게 하는 메커니즘

 

3. Scalability(확장성)

시스템이 확장 가능하다면, 사용자와 리소스 수가 크게 증가하더라도 효과를 유지할 수 있다.

또한 사용자와 리소스가 추가되더라도 성능 저하나 관리 복잡성의 증가 없이 처리가 가능하다.

 

확장성을 설계하기 위해서는 아래 항목들을 고려해야한다.

• 물리적 자원의 비용
• 성능의 손실
• 소프트웨어 자원의 부족
• 성능의 병목현상

성능의 손실, 소프트웨어 자원의 부족, 병목현상은 비슷비슷한 말이다. 관점에 따라서 말도 조금씩 바뀐거다.

사용자의 관점, 컴포넌트의 관점, 상호작용의 관점에서 보면 조금 이해가 된다.

 

   3-1. Scalability Components

• Size Scalability

간단하게 예시를 들면 '메모리가 부족할 때 메모리를 늘린다.' 라고 할 수 있다.

시스템의 성능 저하 없이 더 많은 사용자와 자원을 추가할 수 있다.

 

한정된 CPU에 따른 컴퓨터의 연산 능력이나, I/O전송 비율을 포함한 스토리지 능력이나, 사용자와 중앙집중된 서비스 사이의 네트워크 지연 때문에 병목현상이 발생한다. 이를 CPU를 더 추가한다던가, 스토리지 크기를 더 늘린다던가 등의 사이즈를 조절하여 해결하는 것이다.

• Geographical Scalability

사용자와 어플리케이션 사이의 통신 딜레이를 줄일 수 있다.

통신 딜레이가 발생하는 이유는 두가지인데,

동기식 클라이언트 서버의 통신이 긴 레이턴시를 발생시킨다. 데이터베이스에 누군가 접근하면 다른 클라이언트가 블락되어 기다려야하는 것을 예시로 들 수 있다.

또한 한정된 대역폭 역시 레이턴시를 발생시킨다. 고속 인프라가 잘 구축되어 있는 수도권은 대부분 대역폭이 넓은데, 수도권에서 외곽지역으로 가면 스트리밍 서비스가 살짝 느려지는 것이 대역폭이 좁아졌기 때문이다.

• Administrative Scalability

여러 독립적인 행정 조직에 걸쳐 있는 시스템이라도 관리할 수 있다. 사용, 관리, 보안에 있어서 정책 충돌이 발생하는 것을 관리하는 것이다.

그리드 컴퓨팅에서 신뢰할 수 없는 사용자와 자원을 어떻게 공유할 것인지, 공유 장비들을 어떻게 관리할 것인지를 예로 들 수 있다.

 

   3-2. Scaling Techniques

• 통신 레이턴시 줄이기: 비동기식 통신을 하거나, 들어오는 응답에 대해 분산된 핸들러를 사용한다.
• 데이터와 연산을 여러 개의 머신으로 분할: 연산을 클라이언트에게로 이동(e.g. 게임 프로그램은 사용자의 GPU를 사용)시키거나, 네이밍 서비스(e.g. DNS)나 정보 시스템(e.g. WWW)를 분산시킨다. 
• 복제와 캐싱: 다른 머신에서 사용 가능한 데이터를 복사하거나, 웹 사이트를 미러링하거나, 웹이나 파일을 캐싱한다. 

4. Partial Faliure(부분적인 오류)

시스템이 동작이 요구된 기능과 다르게 작동한다면, 그 시스템은 오류가 발생한 것으로 간주한다.

오류를 해결하는 기술에는,

• Fault detection(오류간파): timing failure, response failure, omission failure, crash failure 등 오류가 어디서 발생해는지를 찾는다.
• Fault masking(오류은폐): 재전송, 체크섬, 롤백 등
• Fault tolerance(오류허용): 오류를 간파한 후에, 예상대로 오류를 발생시키거나 오류를 사용자에게는 숨긴다.
• Recovery form failures(회복): 롤백
• Redundancy(고가용성): 예비용 백업 장치의 준비

등이 존재한다. 어느 부분에 오류가 발생하더라도 다른 부분은 정상적으로 작동할 수 있도록 한다.

 

5. Concurrency(동시성)

공유 자원에 동시에 접근하게 된다면, 그 자원의 불일치를 가져올 수 있다.

자원을 동시에 쓰고 읽는다고 가정했을 때, 읽는 작업이 먼저 이루어진 후에 곧바로 쓰는 작업이 이루어졌다면, 먼저 자원을 읽은 사람은 옛날 자원을 갖고 있게 되는 것이다.

이런 동시 접근으로 인한 문제들을 피하고 싶다면, 관련 트랜잭션은 직렬화되어야 한다. (one-at a-time)

 

6. Security(보안)

Authentication(입증), Authorization(권한 부여), Encryption and Decryption(암호화와 복호화)

 

7. Distribution Transparency(분산 투명도)

분산 시스템에서 분리로 인해 발생하는 특징들을 감추어, 이를 하나의 통합된 시스템 처럼 보이게 하는 추상화 개념 또는 메커니즘이다.

• 분산 투명도의 타입

Transparency	Description
Access(접근)	데이터에 대상이 어떻게 접근했는지와 데이터 표현의 차이점을 숨긴다.
Location(위치)	대상이 어디에 위치되어 있는지를 숨긴다.
Relocation(재배치)	사용중인 대상이 어디로 옮겨졌는지를 숨긴다.
Migration	저장해놓은 대상이 어디로 옮겨졌는지를 숨긴다.
Replication	복제된 오브젝트를 숨긴다.
Concurrency	독립적인 사용자들에게 대상이 공유될 수 있다는 것을 숨긴다.
Failure	오류를 숨기고 대상을 회복시킨다.

 

위 항목들을 모두 숨기는 것은 오버헤드가 너무 크기 때문에, 일부는 보여지는게 오히려 좋을 때도 있다.

 

** 대학교 수업을 듣고 이해한 부분을 최대한 풀어서 작성한 글입니다.

틀린 정보가 존재할 수 있으며, 언제나 피드백은 환영입니다. **