분산시스템(Distributed System)의 개요 - 2

분산시스템(Distributed System)의 개요 - 1

 

분산 시스템은 현제 필수적이면서 평범한 사람들에게는 생소한 개념이다. 이에 대해 이전 포스터에 이어서 자세하게 설명해보도록 하겠다. 

 

1. Distributed(분산형) vs. Centralized(중앙형) Systems

분산형은 중앙형보다 더 좋은 이점을 가져온다. 분산형은 인터넷, 인트라넷과 같은 기술을 현실화할 수 있다. 이러한 분산시스템은 중앙형보다 더 나은면이 있다. 하지만 단점도 충분히 존재한다. 예로 들어 보안문제가 그것이다. 그 차이점을 분산시스템의 장점과 단점을 통해 이야기해보도록 하겠다.

 

분산 시스템의 장점:

• Realiability(신뢰성): 분산 시스템은 여러 개의 독립적인 컴퓨터들이 상호 연결되어 있으므로, 하나의 시스템에 장애가 발생해도 전체 시스템에 큰 영향을 미치지 않아서 더 높은 신뢰성을 제공한다. 반면 중앙형은 하나가 망가지면 모두 사용할 수 없다.
• Sharing of sources(자원 공유): 여러 컴퓨터가 연결되어 있어 시스템 자원을 효율적으로 공유할 수 있다. 예를 들어, 저장공간이나 처리 능력 등을 여러 시스템이 함께 사용할 수 있다. 반면 중앙형은 그 안에 무언가를 내장해야 시스템을 사용할 수 있다.
• Aggregate computing power(컴퓨팅 파워 결집): 여러 시스템을 결합하여 하나의 강력한 컴퓨팅 능력을 발휘할 수 있다. 여러 대의 컴퓨터가 동시에 작업을 수행함으로써 성능을 향상시킬 수 있다. 반면 중앙형은 불가능하다.
• Openness(개방성) / Scalability(확장성): 분산 시스템은 다른 시스템과의 연결이 용이하고, 시스템을 확장하기 쉬워 새로운 컴퓨터나 장치를 추가하는 것이 가능하다. 따라서 필요에 따라 쉽게 확장이 가능하다. 이또한 중앙형은 불가능하다.

분산 시스템의 단점:

• Security(보안): 여러 컴퓨터가 연결되어 있기 때문에, 시스템 전체에 대한 보안 위협이 증가할 수 있다. 분산 시스템은 데이터를 안전하게 보호하기 위한 추가적인 보안 조치가 필요하다. 반면 중앙형은 이를 생각할 필요가 없다.
• Software(소프트웨어): 분산 시스템에서는 여러 시스템이 함께 작동해야 하므로, 이를 관리하고 유지하는 소프트웨어가 복잡해질 수 있다. 또한 다양한 운영체제나 하드웨어 간의 호환성 문제도 발생할 수 있다. 반면 중앙형은 이를 생각할 필요가 없다.
• Communication network(통신 네트워크): 분산 시스템의 성능은 통신 네트워크에 의존하기 때문에, 네트워크 속도나 안정성 문제로 인해 성능이 저하될 수 있다. 또한 네트워크의 장애나 지연이 전체 시스템에 영향을 미칠 수 있다. 반면 중앙형은 네트워크의 의존도가 상대적으로 낮다. 

2. 분산 시스템 분야에 부여된 도전사항들

• 복잡성 (Complexity): 분산 시스템은 여러 독립적인 컴퓨터가 서로 협력하여 작업을 처리하는 시스템이기 때문에 구조와 동작이 복잡하다. 각 컴퓨터와 프로세스가 어떻게 상호작용할지, 어떤 방식으로 데이터를 공유할지 등 여러 요소들이 고려되어야 한다.
• 규모 (Size): 분산 시스템은 규모가 크고, 수많은 기기와 네트워크가 연결되어 있기 때문에 시스템의 관리와 조정이 어려워질 수 있다. 시스템의 규모가 커질수록 발생할 수 있는 문제도 복잡해진다.
• 기술 변화 (Changing technologies): 기술이 빠르게 발전하면서 기존 기술의 교체나 업데이트가 필요하다. 새로운 기술이나 프로토콜이 등장하면 기존 시스템에 영향을 미치고, 그에 맞는 조정과 업그레이드가 필요하다.
• 사회 의존성 (Society’s dependence): 분산 시스템은 오늘날 많은 분야에서 중요한 역할을 하고 있다. 예를 들어, 금융, 통신, 교통 등에서 중요한 시스템들이 분산 시스템에 의존하고 있기 때문에, 이러한 시스템의 실패는 사회 전반에 큰 영향을 미칠 수 있다.

위 내용에 의해 현실적으로 분산 시스템이 직면한 도전 과제는 다음과 같다. 

• 이질성 (Heterogeneity): 분산 시스템은 서로 다른 하드웨어와 소프트웨어 환경에서 실행되는 시스템들이 상호작용하므로, 다양한 기술 간의 호환성 문제나 이질성 문제가 발생할 수 있다.
• 개방성 (Openness): 분산 시스템은 외부와 연결되거나 다양한 시스템과 통신할 수 있도록 설계되므로 개방성이 중요한 요소다. 하지만 개방성은 보안 위험을 초래할 수 있으며, 시스템의 통합 및 관리가 어려울 수 있다.
• 보안성 (Security): 여러 시스템이 네트워크를 통해 연결되고, 중요한 데이터가 전송되는 만큼 보안 문제가 중요한 도전 과제가 된다. 데이터 암호화, 접근 제어, 인증 등 다양한 보안 기능이 필요하다.
• 확장성 (Scalability): 시스템의 규모가 커지거나 사용자 수가 증가함에 따라 시스템을 확장하는 능력이 요구된다. 확장성은 분산 시스템의 성능과 효율성을 유지하기 위한 중요한 고려 사항이다.
• 고장 처리 (Fault handling): 분산 시스템은 여러 독립적인 컴퓨터가 연결되어 있기 때문에, 일부 시스템이 고장 나면 전체 시스템의 동작에 영향을 미칠 수 있다. 따라서 고장 처리 및 복구 메커니즘이 중요하다.
• 동시성 (Concurrency, 병렬성): 분산 시스템에서는 여러 프로세스가 동시에 실행되기 때문에 동시성 문제를 처리해야 한다. 이는 시스템의 효율성과 성능에 큰 영향을 미칠 수 있다.
• 투명성 (Transparency): 분산 시스템에서는 여러 시스템들이 상호작용하고 있지만, 사용자는 이를 알아차리지 못해야 한다. 즉, 시스템의 복잡한 동작을 사용자에게 숨기고, 사용자가 일관된 방식으로 시스템을 이용할 수 있도록 하는 투명성 확보가 중요하다.

3. 분산시스템의 도전과제와 그 해결법

3.1. 이질성 (Heterogeneity)

도전과제:

1) S/W와 H/W의 다양화

 분산 시스템에서의 소프트웨어(S/W)와 하드웨어(H/W)의 다양화는 중요한 도전 과제다. 시스템이 다양한 운영 체제, 네트워크, 컴퓨터 하드웨어, 프로그래밍 언어 등을 기반으로 하여 실행되기 때문에, 서로 다른 개발자가 만든 구현들이 상호작용할 때 호환성 문제나 이질성 문제가 발생할 수 있다.

 

예를 들어, 다른 운영 체제나 네트워크 프로토콜을 사용하는 컴퓨터들이 함께 작업하려면 서로 다른 시스템 간의 통합과 데이터 호환이 필요하다.

 

해결책: 이 문제를 해결하기 위해서는 표준 프로토콜과 미들웨어 개발이 필요하다. 표준 프로토콜을 사용하면 서로 다른 시스템들이 일관된 방식으로 통신할 수 있게 되며, 미들웨어는 다양한 하드웨어와 소프트웨어 환경 간의 연결을 쉽게 해준다. 미들웨어는 분산 시스템에서 서로 다른 컴퓨터나 장치가 원활하게 협력할 수 있도록 도와주는 중간 계층의 소프트웨어이다.

 

도전과제:

2) 이질성과 모바일 코드 지원

분산 시스템에서의 이질성 문제는 하드웨어와 소프트웨어가 다양한 환경에 존재하는 상황에서 발생하는 문제다. 특히 모바일 코드(mobile code)를 지원하는 환경에서는 코드가 네트워크를 통해 전송되어 다른 시스템에서 실행될 수 있다. 이 경우, 코드가 다른 시스템 환경에 맞게 실행되도록 보장해야 한다.

 

해결책: 이를 해결하기 위한 방법 중 하나는 가상머신(Virtual Machine) 접근 방식이다. 예를 들어, Java 애플릿(Java applets)은 가상머신을 사용하여 서로 다른 운영 체제나 하드웨어 환경에서 동일한 코드가 실행될 수 있도록 도와준다. 가상머신은 코드가 실행되는 하드웨어와 운영 체제의 세부 사항을 추상화하여, 코드가 다른 환경에서도 일관되게 실행될 수 있도록 지원한다.

 

3.2.  개방성 (Openness)

분산시스템의 개방성은 이미 해결되었다. 이는 다음처럼 극복하였다. 

 

1) 개방형 시스템 개발

시스템의 주요 인터페이스가 공개되어 있다는 점을 사용하여 시스템의 구성 요소들이 외부와 상호작용할 수 있도록 표준화된 방법을 제공하며, 다른 시스템과의 호환성을 보장하여 극복하였다.

이에 대해 더 나아간 개방형 분산 시스템(Open Distributed Systems)이라는 것도 있는데, 공유 자원에 접근할 수 있도록 균일한 통신 메커니즘과 공개된 인터페이스를 제공하는 시스템을 의미한다. 이런 시스템에서는 서로 다른 장치나 소프트웨어들이 쉽게 상호작용할 수 있도록 설계되어 있다.

 

* 개방형 분산 시스템 특징

1. 판매자의 제품들의 독립성: 개방형 시스템은 특정 판매자나 공급자의 제품에 의존하지 않도록 설계된다. 즉, 다양한 공급자의 제품들이 동일한 시스템 내에서 문제없이 협력할 수 있다.
2. 공개 인터페이스 제공: 개방형 시스템에서는 주요 인터페이스가 공개되어, 사용자가 이를 활용하여 시스템과 상호작용할 수 있다. 이는 다른 시스템이나 애플리케이션이 쉽게 접근하고 통합될 수 있게 한다.
3. 공개 통신 기법: 시스템 간의 통신 방식도 공개되어, 여러 시스템이 동일한 통신 프로토콜을 사용하여 서로 데이터를 교환할 수 있다. 예를 들어, Java RMI(Remote Method Invocation)는 네트워크 상의 다른 컴퓨터에서 메서드를 호출할 수 있도록 하는 공개된 통신 기법이다. 이를 통해 분산된 시스템에서 원격으로 메서드를 실행할 수 있게 된다.

그러나 이 문제는 완벽하게 해결되었다고 볼 수 없다. 보안 문제, 상호운용성, 성능부분에 아직도 해결해야하는 과제가 있다. 

 

3.3. 보안성 (Security)

도전과제:

1) 기밀성 (Confidentiality)
기밀성은 정보가 무단으로 공개되지 않도록 보호하는 것이다. 예를 들어, 의료 기록과 같은 민감한 정보는 권한이 없는 사람에게 노출되지 않도록 보호해야 한다. .

 

2) 무결성 (Integrity)
무결성은 정보가 허가되지 않은 방식으로 수정되거나 방해받지 않도록 보장하는 것이다. 예를 들어, 재무 데이터와 같은 중요한 정보는 변조나 손상이 일어나지 않도록 보호해야 한다. 이는 데이터가 저장되거나 전송될 때 일관성 있게 유지되도록 하기 위한 조치다.

 

해결책:

1) 식별 및 신원 확인 (Need for encryption and knowledge of identity):
데이터를 보호하려면 해당 데이터가 적절한 사람이나 시스템에서 접근하는지 확인할 필요가 있다. 암호화는 정보를 보호하는 중요한 기법이며, 식별 및 신원 확인은 적절한 사용자나 시스템만이 특정 데이터에 접근하도록 보장한다. 이를 통해 정당한 사용자만 시스템에 접근할 수 있다.

• 서비스 거부 공격 (Denial of Service attacks, DoS):
  서비스 거부 공격은 시스템을 과도한 요청으로 가득 채워서 정상적인 서비스를 방해하는 공격이다. 이는 서버나 네트워크를 마비시켜 서비스가 중단되게 만든다. 이러한 공격에 대비하여 방어 메커니즘을 구축하는 것이 중요하다.
• 모바일 코드의 보안 (Security of mobile codes):
  모바일 코드는 사용자가 서버에 보내거나 다운로드할 수 있는 실행 가능한 코드다. 하지만 모바일 코드는 악성 코드나 바이러스를 포함할 위험이 있기 때문에 이를 검증하고 보호할 필요가 있다. 모바일 코드의 보안을 강화하려면 코드의 출처를 검증하고, 실행 전에 잠재적 위험을 평가하는 것이 중요하다.

이러한 보안 요구 사항들은 분산 시스템이 안전하게 운영되기 위해 반드시 고려해야 할 부분들로, 암호화, 인증, 접근 제어와 같은 기법을 통해 보호할 수 있다.

 

3.4. 확장성 (Scalability)

도전과제:

분산 시스템의 확장성(Scalability)은 시스템이 자원의 수나 사용자의 수가 크게 증가했을 때에도 여전히 효과적으로 동작할 수 있는 능력을 의미한다. 즉, 시스템이 커지더라도 성능 저하 없이 계속 확장 가능해야 한다는 요구사항이 있다. 이것은 도전과제가 될 수 있다.

 

해결책:

이에 대한 해결책으로 확장 가능한 분산 시스템을 설계하는 방안이 있다. 그 자세한 내용은 다음과 같다.

 

1) 물리적 자원의 비용 제어 (Controlling the cost of physical resources):
사용자가 증가할 때 시스템의 자원 비용이 선형적으로 증가하지 않도록 관리해야 한다. 예를 들어, 자원 비용이 O(n), 즉 사용자의 수(n)에 비례하여 증가하는 것을 제어해야 한다. 이는 시스템 확장이 자원 비용에 미치는 영향을 최소화하려는 노력이다.

 

2) 성능 손실 제어 (Controlling the performance loss):
데이터 집합의 크기(n)가 커지면서 성능 저하를 방지하는 것이 중요하다. 성능 손실은 O(log n)로 증가해야 하며, 이는 데이터가 많아져도 성능 저하가 상대적으로 적게 발생하도록 설계해야 한다는 의미다.

 

3) 소프트웨어 자원 고갈 방지 (Preventing software resource running out):
예를 들어, IPv4(32비트) 주소 체계에서 IPv6(128비트) 주소 체계로의 전환을 통해, 더 많은 자원을 효율적으로 관리하고 고갈을 방지하는 방법이 있다. 이러한 방식으로 시스템 자원을 더욱 확장 가능하게 만들어야 한다.

 

4) 성능 병목 현상 방지 (Avoiding performance bottleneck):
성능의 병목 현상을 방지하기 위해, DNS와 같은 시스템을 활용하여 요청을 효율적으로 분산시키는 방법을 적용할 수 있다. 병목 현상이 발생하지 않도록 다양한 최적화 기법을 적용해야 한다.

 

그러나 이에 대한 한계가 있다. 시스템 설계 및 운영에서 발생할 수 있는 문제가 있다. 예를 들어, 데이터베이스 시스템이 너무 커지거나 사용자 수가 너무 많아지면 시스템이 처리할 수 없는 상황에 직면할 수 있다. 이러한 한계를 해결하기 위해서는 분산 시스템 설계에서 효율적으로 자원을 관리하고, 성능을 최적화하는 방법을 고려해야 한다.

 

3.4.1. 확장성 기술1: 폼 유효성 검사

그 중, 서버와 클라이언트의 역할, 확장성 관점에서 비교하여  폼 유효성 검사와 관련된 차이를 설명하고자 한다. 이것은 확장성 기술과 연결되는 개념이다.

서버와 클라이언트의 개수 차이

• 서버 수 확장: 서버 수를 늘리면, 더 많은 요청을 처리할 수 있어 시스템의 확장성을 개선할 수 있다. 서버가 많아지면 트래픽 분산이 가능하고, 더 많은 사용자 요청을 동시에 처리할 수 있게 된다.
• 클라이언트 수 확장: 클라이언트가 많아지면, 그에 맞는 서버 리소스가 필요해지기 때문에 서버의 부하가 증가한다. 확장성을 유지하려면 클라이언트의 수에 맞는 서버 용량 조정이 중요하다.

이것을 폼 유용성 검사에서 보면 다음과 같다. 

폼 유효성 검사: 서버 vs 클라이언트

• 서버에서 폼을 검사하는 경우:
  서버는 폼 데이터를 수신하여 유효성 검사를 수행한다. 이 방법은 보안성과 데이터 일관성을 유지하는 데 유리하지만, 데이터가 서버로 전송되고 다시 응답을 받아오는 시간이 소요되어 사용자 경험에서 지연이 발생할 수 있다.
• 클라이언트에서 폼을 검사하는 경우:
  클라이언트 측에서 실시간으로 유효성 검사를 진행하고 오류를 즉시 표시할 수 있다. 이는 사용자 경험을 향상시킬 수 있지만, 클라이언트 측 검증은 보안에 취약할 수 있다. 클라이언트 측 검증만으로는 정보의 신뢰성이 부족하므로, 서버 측에서 다시 검증을 해야 한다.

결론

• 확장성을 고려할 때, 서버와 클라이언트의 수를 조정하는 방법은 시스템의 성능과 부하 처리에 중요한 요소다. 또한 폼 유효성 검사를 어디서 처리할지에 대한 선택은 보안과 사용자 경험 간의 균형을 고려해야 한다.
• 서버와 클라이언트의 수는 시스템의 확장성에 중요한 영향을 미친다.

 

3.4.2. 확장성 기술2: DNS 이름 공간을 구역으로 나누기

확장성 기술 중에 DNS (Domain Name System) 이름 공간을 구역(zones)으로 나누는 것이 있다. 이는 대규모 시스템에서 효율적으로 관리하고 확장할 수 있도록 돕는 방법이다. DNS는 도메인 이름을 IP 주소로 변환하는 역할을 한다. DNS 이름 공간을 여러 구역으로 나누면, 각 구역에 대한 관리와 트래픽 분배가 용이해지고, 시스템 확장성도 개선된다.

 

구역 분할(Zoning) 설명

1. DNS 이름 공간:
   DNS는 계층적인 구조를 가지고 있으며, 각 도메인 이름을 트리 형태로 관리한다. 트리의 루트는 최상위 도메인(TLD, 예: .com, .org 등)으로 시작하고, 각 도메인은 하위 도메인으로 나뉘게 된다.
2. 구역(Zones):
   이름 공간을 구역으로 나누면, 각 구역이 독립적으로 관리되고 책임을 지게 된다. 예를 들어, example.com이라는 도메인이 있을 때, example.com의 DNS 관리 책임을 한 서버가 맡고, sub.example.com이라는 서브도메인은 다른 서버가 관리할 수 있다. 이렇게 구역을 나누면 여러 서버에서 각각 관리할 수 있게 되어 효율적인 관리와 부하 분산이 가능하다.
3. 확장성 향상:
   DNS 이름 공간을 구역으로 나누면, 각 구역에 대해 별도의 서버가 책임을 지므로, 부하 분산과 확장성이 가능해진다. 예를 들어, 트래픽이 많은 도메인에 대해 별도의 서버를 추가하여, 전체 DNS 시스템의 성능 저하 없이 확장할 수 있다.

결론: 

DNS 이름 공간을 구역으로 나누는 방식은 확장성을 개선하는 기술로, 관리와 성능을 최적화하는 데 도움을 준다. 각 구역을 독립적으로 관리하면, 서버 수를 증가시키거나 트래픽을 분산시키는 등 확장성을 유지하면서 시스템 성능을 향상시킬 수 있다.

 

3.5. 고장 처리 (Fault handling)

도전과제:

고장 처리은 시스템이 고장이 발생했을 때, 작업을 계속해서 수행할 수 있도록 하는 능력을 말한다. 이러한 능력의 분산시스템에서의 도전과제는 고장을 감지하고, 이를 처리하여 시스템의 신뢰성을 유지하는 것이다. 고장 취급 기술에는 고장 감지, 고장 마스킹, 고장 허용 및 복구 등의 기법이 포함된다.

 

해결책:

이라한 고장 처리의 해결책으로는 고장 감지, 고장 미스킹, 고장 허용, 고정 복구, 중복하기가 있다. 

 

1) 고장 감지 (Detecting Failures)

시스템 내에서 오류가 발생했는지 확인하는 방법. 대표적인 고장 감지 기법으로는 체크섬(checksum)이 있다. 체크섬은 데이터가 전송되거나 저장될 때, 데이터의 무결성을 확인하기 위해 사용하는 방법이다. 이 외에도 타임아웃, heartbeat(정기적인 신호 송출) 등의 방법으로도 고장을 감지할 수 있다.

 

2) 고장 마스킹 (Masking Failures)

고장이 발생했을 때, 이를 시스템이 사용자에게 드러내지 않도록 처리하는 방법도 있다. 고장을 숨기기 위한 방법으로는 다음과 같은 기법이 있다:

• 재전송(Retransmission): 데이터가 손실되었을 때, 해당 데이터를 다시 전송하여 문제가 발생하지 않도록 처리하는 방법.
• 미러링(Mirroring): 데이터나 시스템의 복제본을 두어, 한쪽에서 고장이 발생해도 다른 복제본이 정상적으로 작동하도록 하여 고장을 숨기는 방법.

3) 고장 허용 (Tolerating Failures)

고장 허용을 하는 방법도 있다. 고장 허용은 시스템이 일부 고장에도 불구하고 계속해서 작업을 수행할 수 있는 능력안데 고장 허용 기법은 시스템이 완전한 고장 없이 지속적으로 동작할 수 있게 만들어준다. 이러한 기법은 주로 분산 시스템에서 사용되며, 일부 노드가 고장 나더라도 전체 시스템은 정상적으로 작동할 수 있도록 한다.

 

4) 고장 복구 (Recovery from Failures)

고장 복구를 하는 방법도 있다. 고장 복구는 고장이 발생한 후 시스템을 정상 상태로 복원하는 기술이다. 복구 방법으로는 다음과 같은 기술이 있다:

• 체크포인트(Checkpoint): 시스템 상태를 일정 주기마다 저장하여, 고장이 발생했을 때 저장된 지점으로 복원할 수 있도록 하는 기법.
• 롤백 복구(Rollback Recovery): 시스템이 고장을 일으킨 시점으로 돌아가서 작업을 다시 시작하는 방식. 이는 주로 트랜잭션 시스템에서 사용된다.

5) 중복하기 (중복성, Redundancy)

중복하기는 시스템이 고장을 허용하기 위해 사용하는 기법으로, 동일한 자원을 여러 개 배치하여 하나의 자원이 고장 나더라도 다른 자원이 이를 대신하도록 하는 방식이다. 예를 들어, 서버나 하드웨어에 중복 장치를 두어, 하나가 고장 나더라도 다른 장치가 자동으로 그 역할을 대신하는 방식이다.

정리: 고장 취급 기술은 시스템이 고장 상황에서 계속해서 정상적으로 동작하도록 돕는 다양한 방법을 포함한다. 고장 감지, 고장 마스킹, 고장 허용, 고장 복구 및 중복성 기술을 통해 시스템은 고장을 효과적으로 처리하고, 사용자가 이를 인식하지 못하게 하거나, 최소한의 중단 시간으로 복구할 수 있다.

 

3.5. 동시성 (Concurrency)

도전과제:

1) 일관성 (Consistency) 문제

여러 프로세스가 동일한 데이터를 동시에 읽거나 수정할 때, 데이터가 일관성을 잃을 위험이 있다. 예를 들어, 은행 시스템에서 하나의 계좌 데이터를 동시에 수정할 경우, 잘못된 잔액이 기록될 수 있다.

 

해결책:

• 분산 트랜잭션: 트랜잭션의 원자성(Atomicity), 일관성(Consistency), 고립성(Isolation), 지속성(Durability)을 보장하는 ACID 원칙을 적용한다.
• 분산 락 (Distributed Lock): 자원을 수정하기 전에 락을 설정하여 하나의 프로세스만 접근할 수 있도록 제한한다.
• 일관성 프로토콜: 분산 환경에서 데이터 일관성을 유지하기 위해, 예를 들어 Two-Phase Commit 프로토콜을 사용할 수 있다.

도전과제:

2) 동기화 (Synchronization) 문제

분산 시스템의 각 프로세스는 독립적으로 실행되며, 클럭(clock) 동기화가 부족할 수 있다. 이로 인해 타이밍 문제와 순서 충돌이 발생할 가능성이 높다.

 

해결책:

• 논리적 클럭(Logical Clock): 분산 환경에서 이벤트의 순서를 동기화하기 위해 Lamport 논리적 클럭을 사용한다.
• 물리적 클럭 동기화: 네트워크 타임 프로토콜(NTP)을 통해 분산 시스템 내 모든 프로세스의 클럭을 물리적으로 동기화한다.
• 세마포어와 뮤텍스: 프로세스 간 동기화 문제를 해결하기 위해 세마포어(Semaphore)와 뮤텍스(Mutex)를 활용한다.

도전과제:

3) 프로세스 간 통신 (Inter-Process Communication, IPC)

분산 시스템의 프로세스들은 서로 다른 물리적 위치에 존재하기 때문에 데이터 교환이 지연되거나 손실될 수 있다. 또한, 프로세스 간의 의존성이나 메시지 순서 문제가 발생할 수 있다.

 

해결책:

• 메시지 패싱(Message Passing): 프로세스 간의 통신을 위해 메시지를 주고받는 방식을 사용한다. 예를 들어, RabbitMQ, Kafka와 같은 메시지 큐 시스템이 있다.
• 원격 프로시저 호출(Remote Procedure Call, RPC): 한 프로세스에서 다른 프로세스의 함수를 호출하는 것처럼 동작하도록 구현한다.
• 공유 메모리 모델: 동일한 메모리 공간을 프로세스 간에 공유하여 효율적인 데이터 교환이 가능하도록 설계한다.

3.6. 투명성 (Transparency)

투명성(Transparency)은 분산 시스템에서 사용자가 시스템의 분리된 특성을 인식하지 못하도록 숨기는 것을 의미한다. 이를 통해 사용자와 프로그래머는 시스템의 내부 구현을 알 필요 없이 서비스를 이용할 수 있다. 그러나 투명성을 제공하기 위해 다양한 도전 과제가 존재하며, 이를 해결하기 위한 전략이 필요하다.

 

도전과제:

1) 접근 투명성 (Access Transparency)
로컬 및 원격 자원에 동일한 방식으로 접근해야 하는데, 네트워크 연결 상태나 프로토콜 차이로 인해 접근 방식이 달라질 수 있다.

해결책:
표준화된 API와 프로토콜을 사용하여 로컬 및 원격 자원 접근을 통일한다. 예: RESTful API, RPC.

 

도전과제:

2) 위치 투명성 (Location Transparency)

자원의 실제 위치를 알 필요 없이 접근해야 하지만, 분산된 자원의 위치를 파악하지 못하면 요청 처리가 어렵다.

해결책:
디렉터리 서비스나 DNS와 같은 이름 해석 서비스를 활용하여 자원의 위치를 동적으로 관리한다.

 

도전과제:

3) 동시 수행 투명성 (Concurrency Transparency)
여러 프로세스가 동일한 자원을 공유할 때 충돌이나 데이터 손상이 발생할 수 있다.

해결책:
세마포어, 뮤텍스, 트랜잭션 관리와 같은 동기화 기법을 사용하여 자원 접근을 조율한다.

 

도전과제:

4) 복제 투명성 (Replication Transparency)

복제된 자원을 사용해도 사용자나 프로그래머는 이를 인식하지 못해야 하지만, 복제본 간 데이터 일관성 유지가 어렵다.

해결책:
일관성 유지 프로토콜(CAP 이론 기반)과 리더-팔로워 구조를 사용하여 복제본의 상태를 동기화한다.

 

도전과제:

5) 고장 투명성 (Failure Transparency)
하드웨어나 소프트웨어 고장 발생 시 이를 숨기고 작업을 지속해야 하지만, 시스템 복구와 데이터 손실 방지가 어려울 수 있다.

해결책:
체크포인트, 롤백 복구, 재전송 및 중복 구성 등을 사용하여 고장 발생 시 복구를 자동화한다.

 

도전과제:

6) 이동 투명성 (Mobility Transparency)

자원이나 클라이언트가 시스템 내에서 이동해도 작업에 영향을 주지 않아야 하지만, 이동 중 연결 유지 및 데이터 동기화가 어렵다.

해결책:
모바일 에이전트 기술과 동적 경로 지정 프로토콜을 사용하여 자원의 이동을 지원한다.

 

도전과제:

7) 성능 투명성 (Performance Transparency)

부하가 변할 때 성능을 유지하거나 향상시켜야 하지만, 시스템 리소스 배분 조정이 복잡할 수 있다.

 

해결책:
부하 분산 알고리즘과 동적 리소스 프로비저닝 기술을 사용한다.

 

도전과제: 규모 확장 투명성 (Scaling Transparency)

시스템 규모가 확장되어도 기존 구조나 알고리즘을 변경하지 않아야 하지만, 확장 시 성능 저하가 발생할 수 있다.

 

해결책:
마이크로서비스 아키텍처와 같은 분산 설계를 도입하고, 수평 및 수직 확장을 통해 부하를 분산한다.

 

결론:

분산 시스템에서 투명성은 사용자의 편의성을 높이고 프로그래머의 복잡성을 줄이는 핵심 요소다. 이를 위해 접근, 위치, 동시성, 복제, 고장, 이동, 성능, 규모 확장의 다양한 투명성을 구현해야 하며, 이를 달성하기 위한 기술적 해결책을 전략적으로 적용해야 한다.

 

 

출처

https://slideplayer.com/slide/13094275/

Distributed Systems, 5/E (IE) (책)