전통적인 웹서비스나 RDBMS부터 Hadoop, 블록체인 등의 최신 기술까지 모두 분산 시스템 구조는 필수적으로 적용되어 있다.
이러한 시스템들을 사용하면서 어렴풋이 분산 시스템에 대한 개념이나 특징을 체득했을지는 몰라도 정확한 개념을 알고 사용하지는 않고 있다.
그 와중에 Distributed Systems라는 서적이 PDF 형태로 제공(https://www.distributed-systems.net/index.php/books/distributed-systems-3rd-edition-2017/ 페이지에서 다운로드 가능)되고 있는 것을 알게 되었고, 공부하고 있다.
이 책을 읽으며 그간 사용해왔던 시스템들이 얼마나 분산 시스템의 개념과 특징을 잘 적용했고 이를 얼마나 잘 추상화했는지 알 수 있었다.
이 글은 위 서적의 Introduction 부분을 번역 및 요약한 글이다.
컴퓨터 시스템의 변화는 압도적으로 진행되고 있다.
1945년 모던 컴퓨터 시대가 시작된 이후부터 1985년까지 컴퓨터는 매우 크고 비쌋다. 더욱이 다른 컴퓨터와 연결할 방법이 없었기 때문에 이 시대의 컴퓨터들은 다른 컴퓨터들과 독립적으로 동작했다.
1980년대 중반부터 이러한 상황을 바꾸는 2개의 기술 발전이 있었다.
- 강력한 마이크로프로세서의 개발
8bit 에서 시작한 프로세스가 이제 16,32 bit를 거쳐 64bit까지 발전했다. 또한 멀티코어 CPU가 등장하므로써 우리는 이제 병렬성을 고려하여 프로그램을 개발해야 한다.
2. 고속 네트워크의 발전
LAN(Local Area Networks)을 통해 수천 대의 컴퓨터를 연결할 수 있고, 수 마이크로초 이내에 적은 양의 정보를 전달할 수 있다. 많은 양의 정보의 경우 몇십억 bps(bits per second) 의 속도로 전달할 수 있다.
WAN(Wide Area Networks)을 통해서는 지구 상의 수십억 대의 컴퓨터를 적게는 10에서 많게는 몇백억 bps 정도의 속도로 전달할 수 있다.
이러한 기술의 발전은 대규모 네트워크 컴퓨터 시스템을 쉽게 구성할 수 있게 했다. 이러한 컴퓨터들은 대부분 지리적으로 분산되어 있기 때문에, 분산 시스템(Distributed System)이라고 불리운다.
What is a distributed system?
A distributed system is a collection of autonomous computing elements that appears to its users as a single coherent system.
분산 시스템은 사용자에게는 하나의 시스템으로 보이는 독립적인 컴퓨터들의 집합이다.
위 정의는 분산 시스템의 2가지 특징을 말하고 있다.
첫번째 특징은 분산 시스템을 구성하는 각 컴퓨팅 요소들이 독립적으로 동작할 수 있다는 것이다. 이러한 컴퓨팅 요소들을 일반적으로 노드(Node)라고 부르며, 이는 하드웨어 장치나 소프트웨어 프로세스가 될 수 있다.
두번째 특징은 사용자들이 분산 시스템을 다룰 때 단일 시스템을 다루는 것처럼 느낀다는 것이다. 이것은 각 노드들이 다른 노드들과 협업하여 동작하는 방법이 필요하다는 의미이다. 이러한 협업을 구성하는 것은 분산 시스템 개발의 핵심이다.
Characteristic 1: Collection of autonomous computing elements
현대 분산 시스템은 다양한 종류의 노드(Small Devices ~ High Performance Computers)로 구성될 수 있다. 분산 시스템을 구성하는 노드들이 다른 노드들과 독립적으로 실행될 수는 있다. 하지만 완전히 독립적으로 동작한다면, 그들을 같은 시스템 안에 넣을 필요가 없다.
실제로 노드들은 서로 메시지를 주고받으면서 동일한 목표를 달성하도록 프로그래밍된다. 노드들은 수신한 메시지에 반응하여 프로세스를 수행하고 다시 다른 노드로 메시지를 전달하는 방식으로 동작한다.
각 노드들의 이러한 일련의 처리 과정에서 중요한 점은, 각 노드들이 각자 자신의 notion of time을 가지고 있다는 것이다. 다르게 표현한다면, Global Clock이 존재하지 않는 것과 같다. 이러한 Global Clock의 부재는 분산 시스템에서의 동기화(Synchronization)와 코디네이션(Coordination)에 대한 질문으로 이어질 수 있으며, 이는 6장에서 다루게 된다.
분산 시스템이 어떤 노드들로 구성되어 구성되어 있고, 노드들이 어떤 노드와 통신할 수 있는지에 알 수 있게 하기 위하여 Group(Membership) 관리도 필요하다. Group은 Open Group과 Closed Group으로 나뉘어진다.
- Open Group: 시스템에 존재하는 어떠한 노드도 그룹 가입이 가능하다. 각 노드는 시스템에등록된 모든 노드에게 메시지를 보낼 수 있다.
- Closed Group: 그룹에 가입된 노드끼리만 통신할 수 있다. 그룹에 들어오고 나가는 매커니즘이 분리되어 있다.
이러한 그룹의 권한 관리는 매우 복잡하다.
첫번째로, 노드의 인증(Authenticate) 과정이 제대로 설계되지 않았다면 이 부분이 시스템의 병목(Bottleneck)이 될 수 있다.
두번째로, 각 노드가 다른 그룹의 멤버와 통신할 수 있는지 아닌지에 대해서도 설계해야 한다. 그렇지 않은 경우 침입자(Intruder)에 의한 시스템 혼란(Havoc)이 올 수 있다.
마지막으로, 멤버와 멤버가 아닌 노드들이 통신할 수 있는지에 대해서도 설계해야 한다. 이는 시스템 신뢰성에 대한 문제를 발생시킬 수 있다.
Overlay Network는 분산 시스템을 구성하는 예를 보여준다.
- 구조화 오버레이(Structed overlay)
- 네트워크 구성 시 토폴로지(Topology)가 반영된다.
- 노드 별로 연결 가능한 이웃 노드가 정해져 있다.
- 노드 간 연결이 구조화되어 있기 때문에 메시지 전송 시 전송 횟수가 크게 늘어나지 않는다.
- 노드 탐색이 유연하지 않다.
2. 비구조화 오버레이(Unstructured Overlay)
Characteristic 2: Single coherent system
단일 시스템 관점(Single Coherent view)을 사용자에게 제공하는 것은 도전적인 일이다.
예를들어, 최종 사용자는 자신이 실행한 작업이 어떤 노드에서 실행되고 있는지 알 수 없어야 한다. 또한 데이터가 어디에 저장되고 복제되는지에 대한 것도 사용자는 알 수 없어야 한다.
이러한 특징을 분산 시스템의 투명성(Distribution transparency)이라고 부르며, 이를 달성하는 것은 분산 시스템 설계의 매우 중요한 목표이다.
또한 분산 시스템은 네트워크 상에서 여러 개의 노드로 구성되어 있기 때문에, 일부 시스템 실패를 피할 수 없다. 하지만 분산 시스템에서 동작하는 응용 프로그램들은 이러한 일부 노드의 실패에서 정상적으로 동작할 수 있어야 한다.
Design Goals
Supporting resource sharing
사용자는 분산 시스템 상의 자원을 쉽게 공유하고 접근할 수 있어야 한다. 자원은 데이터, 파일, 서비스, 네트워크 등 어떠한 것도 될 수 있다.
Making distribution transparent
분산 시스템은 프로세스와 자원이 시스템을 구성하는 물리적인 컴퓨터에 분산되어 있다는 사실을 감추어야 한다(Offering Coherent View). 이를 프로세스와 자원의 투명성을 달성한다고 한다.
Type of distribution transparency
투명성의 개념은 분산 시스템의 여러 부분의 관점에서 생각해볼 수 있다. 각 관점에서의 투명성은 아래와 같으며, 개체(object)라는 표현은 프로세스 혹은 리소스를 의미한다.
접근 투명성(Access Transparency)은 데이터 표현의 차이와 개체 접근 방법을 숨긴다. 기본적으로 장비 설계구조를 숨기며, 더 나아가 데이터들이 이런 다른 장비 설계와 운영체제 하에서 어떻게 다르게 표현되는지를 숨긴다.
예를 들어 분산 시스템은 다른 운영체제가 설치된 노드들로 구성될 수 있고, 각기 다른 운영체제는 File Naming Convention, File Operation 등에서 차이를 가질 수 있다. 이러한 저레벨(Low Level)수준의 세부사항은 사용자와 응용 프로그램으로부터 숨기는 것이 좋다.
위치 투명성(Location Transparency)은 사용자가 자신이 사용하는 개체가 시스템 상에 물리적으로 어디에 위치해있는지 숨기는 것이다.
예를 들어 http://www.prenhall.com/index.html 이라는 URL(Uniform Resource Locator)은 해당 사이트가 동작하는 웹서버에서 index.html 파일이 실제로 어디에 위치하는지에 대한 단서를 제공하지 않는다.
재배치 투명성(Relocation Transparency)은 개체가 옮겨지는 것에 대한 정보를 사용자에게서 숨긴다.
위의 예에서 사용자는 index.html 파일이 원래 파일인지, 새로운 파일이 기존 파일을 대체한 것인지 알 수 없다. 또한 재배치 투명성은 Cloud Computing에서 매우 중요한 주제 중 하나이다.
복제 투명성(Replication Transparency)은 리소스의 복사본이 여러개 있는 것을 사용자에게서 숨기는 것이다.
리소스는 가용성을 높이거나, 리소스 사용시의 퍼포먼스를 높이기 위해서(Locality 관점에서의 접근같다) 복제가 이루어진다.
복제 투명성을 달성하기 위해서는 복제 대상 파일이 여러 위치에 같은 이름으로 존재해야 하고, 위치 투명성이 보장되어 사용자가 자신이 사용하는 파일이 복제본인지 아닌지에 대한 것을 알 수 없어야 한다.
병행 투명성(Concurrency Transparency)은 동일한 자원을 다른 사용자가 사용하고 있다는 것을 숨기는 것이다.
공유 자원에 동시 접근(Concurrent)하는 것에서 가장 중요한 문제는 자원을 일관적인 상태로 유지하는 것이다. 이러한 일관적인 상태는 시스템에서 락(Locking Mechanisms)을 제공하므로써 달성할 수 있다.
락을 제공하는 시스템에서 사용자들은 공유 자원 접근 시 순서대로 독점 접근을 할 수 있다. 더 나아가 트랜잭션(Transaction)을 사용하게 할 수도 있지만, 이러한 방법은 분산 시스템에서 구현하기 어렵고, 확장(Scalability) 이슈를 만들어낼 수도 있다.
실패 투명성(Failure Transparency)은 사용자들이 일부 시스템의 실패와 이를 복구하는 과정에 대해 숨기는 것이다.
실패 투명성에서 가장 어려운 것은 실제로 모든 자원이 사용할 수 없게 되었는지, 아니면 실패한 자원을 복구하는 과정에서 응답시간이 늦어지는지를 구분할 수 없는 것이다.
Degree of distribution transparency
모든 투명성을 만족시키는 것은 불가능하며, 가능하더라도 모든 상황을 만족시킬 수는 없다.
높은 투명성(High degree of transparency)을 만족시키는 것과 시스템 성능(Performance of a system)사이에는 Trade Off가 발생하기 때문이다.
따라서 모든 투명성을 만족시킬 필요는 없으며, 최대한 달성하려고 노력하면 되는 것이다.
Being open
개방성(Openness)은 분산 시스템의 또다른 중요한 목표 중 하나이다. 개방된 분산 시스템은 다른 시스템이 쉽게 사용 및 연동할 수 있는 시스템이다.
개방형이라는 것은 시스템 구성요소가 자신이 제공하는 구문(Syntax)과 의미(Semantics)를 설명하는 표준 규칙을 준수한다는 것이다. 즉, 구성 요소와 상호작용할 수 있는 인터페이스(Interface)를 잘 정의하는 것이다.
컴포넌트는 인터페이스를 제공하므로써 다른 임의의 프로세스와 일관된 방식으로 상호작용이 가능해진다.
상호 운용성(Interoperability)은 이러한 인터페이스를 통해 두개의 다른 시스템이나 컴포넌트가 서로에 의지하여 동작할 수 있는 특징을 의미한다.
이식성(Portability)은 A 시스템에서 동작하던 응용 프로그램이 동일한 인터페이스를 가진 B시스템에서도 수정 없이 동작할 수 있는 것을 의미한다.
확장성(Extensibility)은 시스템을 구성하는 컴포넌트를 다른 컴포넌트로 교체할 수 있어야 한다는 것을 의미한다.
Being Scalable
Scalability dimensions
시스템의 확장성은 최소 3개의 차원에서 측정할 수 있다.
- 규모 확장성(Size scalability)
- 지리적 확장성(Geographical scalability)
- 관리 확장성(Administrative scalability)
규모 확장성(Size scalability)을 가진 시스템에서는 시스템 자원을 쉽게 추가할 수 있다.
특정 서버에 의존적인 서비스들은 요청량(Request)가 늘어날 수록 병목현상(Bottleneck)이 발생하게 된다. 대부분 병목현상을 일으키는 원인은 아래 세가지이다.
- Computational capacity, limited by CPUs
- Storage capacity, including the I/O transfer rate
- The network between the user and the centralized service
이러한 병목현상들을 해결하는 방법은 아래 Scaling Techniques 에서 다루도록 한다.
지리적 확장성(Geographical scalability)을 가진 시스템에서는 사용자와 시스템이 물리적으로 멀리 떨어져있어 발생하는 통신 지연을 알아차리기 어렵다.
분산 시스템은 Local Area Network 상에서 이용하도록 설계되었기 때문에, Synchronous Communication 을 기반으로 한다. 때문에 LAN 환경에서는 수백 마이크로초에서 처리되던 요청도 WAN 환경으로 넘어간다면 수백 밀리초까지도 처리 시간이 늘어날 수 있다.
이러한 문제에 대한 대응책도 추후에 다룰 예정이다.
관리적 확장성(Administrative scalability)을 가진 시스템은 여러 시스템 관리 조직이 시스템을 관리할지라도 쉽게 관리할 수 있다.
Scaling techniques
- Scaling up & out
대부분 분산 시스템에서 발생하는 성능(Performance) 문제는 서버와 네트워크의 성능(Capacity)의 한계에서 발생한다. 이러한 문제를 해결하기 위해 Scaling up과 Scaling out이라는 기법을 사용한다.
Scaling up은 부족한 자원의 성능(Capacity)을 향상(CPU 업그레이드, 메모리 증설, 네트워크 증설 등)시키는 기법이다.
Scaling out은 장비를 추가하므로써 전체 성능을 증가시키는 방법이다.
2. Partitioning and distribution
파티셔닝(Partitioning)과 분산(Distribution) 기법은 컴포넌트를 시스템 전반에 걸쳐 작게 나누어 쪼개는 방법이다.
서적에는 DNS(Domain Name Server)와 Web 구조를 통해 설명했는데, 내가 익숙한 MongoDB의 Sharding 기반으로 이해했다.
Sharding은 Collection(RDBMS에서의 Table) 단위로 제공하는데, Sharding 기능이 적용된 Collection에 데이터를 저장할 때는 데이터를 Index 기반으로 나누어 여러 서버에 저장한다. Sharding을 통해 얻어낼 수 있는 장점은 아래와 같다.
- 데이터가 여러 서버에 나뉘어 저장되기 때문에 큰 규모의 Collection도 구성할 수 있다. Sharding을 적용하지 않으면 단일 Collection의 크기는 서버 Disk에 제한을 받게 된다.
- Read 시 Broker를 통해 데이터가 실제로 저장되어 있는 서버 목록을 전달받은 후 실제 Read Operation은 해당 서버들에 대해서 수행한다. 따라서 Read 부하 분산을 이뤄낼 수 있다.
3. Replication
복제(Replication) 또한 두 가지 장점을 가지는데 파티셔닝과 분산에서 언급한 장점과 겹치는 부분이 있다.
- 가용성(Availability)이 높아진다. Process의 Replication의 경우 SPOF(Single point of failure)를 막을 수 있고, Data의 Replication의 경우 서버 문제로 인한 데이터 유실을 막을 수 있다.
- 부하 분산(Load Balancing)을 얻어낼 수 있다. 동일한 Process 혹은 Data가 여러 서버에 걸쳐 존재하기 때문에 요청을 분산시킬 수 있다.
4. Caching
캐싱(Caching)은 복제(Replication)의 특별한 형태이다.
복제와 같이 자원을 복사하는 것은 같지만, 캐싱은 자원 소유자가 아닌 사용자에 의해 결정된다.
캐싱과 복제 모두 복사본 간에 일관성(Consistency) 문제를 일으킬 수 있다.
예를 들어, 웹 사용자들은 동일 페이지를 접근하는 경우 웹 브라우저에 저장된 캐시 데이터를 보는 경우가 존재하는데, 이미 원본이 변경되었을지라도 변경된 내용이 사용자의 페이지에 반영되지 않는다. 이는 캐시 데이터의 일관성이 보장되지 않기 때문이다.
이와 다르게 캐시 데이터의 일관성이 강력하게 보장되어야 하는 경우가 있다.
주식이나 경매 시장이 그 예인데, 이러한 경우 원본의 변경 사항을 복제본에게 전달하는 방식으로 일관성을 유지할 수 있다.
더 나아가 원본 데이터를 동시에 변경하는 요청이 발생할 경우, 복사본에도 이러한 요청이 순차적으로 반영되어야 한다.
복제(+캐싱)는 이러한 전역적 동기화(Global Synchronization) 과정을 필요로 하며, 전역적 동기화는 성능 향상이 매우 어렵거나 불가능하다. 이 부분은 추후 7 챕터에서 설명하도록 한다.
