분산 시스템

따로 도는 여러 대의 컴퓨터가 메시지를 주고받으며 하나처럼 굴러가는 시스템입니다. 밖에서 쓰는 쪽은 그것이 몇 대인지 몰라도 됩니다. 안에서는 서로를 직접 들여다볼 수 없습니다. 보낸 말이 닿았는지조차 확실하지 않습니다.

상세

여러 방에 한 사람씩 나눠 앉아 쪽지로만 상의합니다. 얼굴을 못 보니 상대가 지금 무엇을 하는지 알 길이 없습니다. 쪽지는 늦게 닿기도 하고 아예 안 닿기도 합니다. 상대가 멈춘 것인지 아직 답을 쓰고 있는 것인지 끝까지 갈리지 않습니다.

분산 시스템은 서로 떨어진 여러 개의 처리 주체가 메시지를 주고받는 것만으로 협력해 하나의 시스템처럼 일하는 것입니다. 가르는 기준은 대수가 아니라 통신 방식입니다. 같은 메모리를 함께 들여다보며 상태를 나누는 것이 아닙니다. 보낸 것과 받은 것만으로 서로의 사정을 짐작합니다.

한 대에서 도는 프로그램과 근본이 갈리는 자리가 셋입니다.

첫째, 여럿이 동시에 돕니다. 어느 것이 먼저 일어났는지가 늘 정해지지는 않습니다. 두 사건 사이에 오간 메시지가 없으면 순서를 말할 근거 자체가 없습니다.

둘째, 모두가 같다고 믿을 시계가 없습니다. 각자의 시계는 조금씩 어긋납니다. 어긋난 폭을 정확히 알 방법도 없습니다.

셋째, 일부만 죽습니다. 한 대짜리 프로그램은 죽으면 전부 같이 죽습니다. 여기서는 절반이 살아서 계속 일하고 절반이 답을 못 하는 상태가 성립합니다. 그리고 답이 없는 쪽이 죽은 것인지 아직 처리 중인 것인지는 밖에서 구별되지 않습니다.

sequenceDiagram
    participant A as 보낸 쪽
    participant B as 받는 쪽
    A->>B: 요청
    Note over A: 기다린다
    Note over A: 시간이 지나도 답이 없다
    Note over A: 받는 쪽이 죽었나 · 아직 처리 중인가 · 답이 오다 사라졌나

그림의 세 갈래를 보낸 쪽에서 갈라낼 방법이 없습니다. 그래서 답이 없는 것을 죽음으로 볼지 더 기다릴지를 미리 정해 두는 일이 설계의 일부가 됩니다. 한 대에서 도는 프로그램에는 이 자리가 아예 없습니다.

배경

일을 한 대에 다 얹으면 두 가지가 그 한 대에 묶입니다. 그 한 대가 죽으면 서비스 전체가 같이 멈춥니다. 그리고 그 한 대가 감당하는 만큼이 처리량의 천장이 됩니다. 천장을 올리려면 더 큰 기계를 사야 하는데 기계 크기에는 끝이 있습니다.

그래서 일을 여러 대에 나눠 얹게 됩니다. 나누는 순간 잃는 것이 있습니다. 같은 메모리를 함께 들여다보던 것이 끊깁니다. 같은 시계를 보던 것도 끊깁니다. 「지금 상태」라는 것이 어디에도 하나로 존재하지 않게 됩니다. 각자는 자기가 마지막으로 들은 것까지만 압니다.

그 자리를 다루는 말이 이 이름입니다. 1978년 Leslie Lamport 의 논문은 분산 시스템을 공간적으로 떨어져 있으면서 메시지를 주고받아 서로 통신하는 별개 프로세스들의 모임이라고 적었습니다. 같은 글은 한 프로세스 안의 사건 사이 시간에 비해 메시지 전달 지연이 무시할 만하지 않으면 그 시스템은 분산되어 있다고 적습니다. 기준이 물리적 거리가 아니라 지연의 상대적 크기라는 뜻입니다. 그 논문이 세운 전제는 이렇습니다. 분산 시스템에서는 두 사건 중 어느 쪽이 먼저 일어났는지 말하는 것이 때때로 불가능합니다. 「먼저 일어났다」는 관계는 그래서 사건들의 부분 순서일 뿐입니다. 사람들이 이 사실과 그 함의를 충분히 알지 못해 문제가 자주 생긴다는 것을 알게 되었다고 같은 논문이 적습니다.

예시

성격이 다른 네 자리를 봅니다. 무엇을 여러 대에 나눠 놓았고 그래서 한 대짜리와 무엇이 달라졌는지가 각각 다릅니다.

DNS

이름 하나를 주소로 바꾸는 일을 한자리에 모아 두지 않았습니다. RFC 1034 는 도메인 네임 시스템(DNS, Domain Name System)의 설계 목표를 적으면서, 데이터베이스의 크기 자체와 갱신 빈도가 그것이 분산된 방식으로 유지되어야 함을 시사한다고 적습니다. 성능을 개선하기 위한 지역 캐싱이 함께 붙습니다. 같은 문서는 전체 데이터베이스의 일관된 사본을 모으려 시도하는 접근은 점점 더 비싸지고 어려워질 것이므로 피해야 한다고 적습니다. 이름 공간의 구조에도 같은 원칙이 적용되며, 특히 이름을 만들고 지우는 장치도 분산되어야 한다고 이어 적습니다.

한 대짜리와 갈리는 자리가 여기 있습니다. 전체를 한자리에 모은 일관된 사본이 애초에 설계 목표에서 빠져 있습니다.

PostgreSQL

데이터베이스 서버를 여러 대로 묶는 자리입니다. PostgreSQL 문서의 고가용성 장은 데이터베이스 서버들이 함께 일해서 주 서버가 실패하면 두 번째 서버가 빠르게 넘겨받게 하거나, 여러 컴퓨터가 같은 데이터를 서빙하게 할 수 있다고 적습니다. 앞이 고가용성이고 뒤가 부하 분산입니다. 같은 문서는 정적 웹 페이지를 서빙하는 웹 서버라면 요청을 여러 대에 부하 분산하는 것만으로 꽤 쉽게 결합된다고 적습니다. 읽기 전용 데이터베이스 서버도 비교적 쉽게 결합된다고 덧붙입니다. 다만 대부분의 데이터베이스 서버는 읽기와 쓰기가 섞인 요청을 받고, 읽기와 쓰기를 다 받는 서버는 결합하기가 훨씬 어렵다고 적습니다. 읽기 전용 데이터는 각 서버에 한 번만 놓으면 되지만, 어느 서버에 들어온 쓰기는 모든 서버로 전파되어야 이후의 읽기 요청이 일관된 결과를 돌려주기 때문입니다.

같은 문서는 이 동기화 문제가 서버들이 함께 일할 때의 근본적인 어려움이라고 못 박습니다. 모든 사용 사례에 대해 동기화 문제의 영향을 없애는 단일 해법은 없기 때문에 여러 해법이 있다고 이어 적습니다.

etcd

결정을 여러 대가 함께 내리는 자리입니다. etcd 운영 문서는 클러스터의 과반 구성원이 실패하면 클러스터가 실패하고 더 이상 쓰기를 받지 못한다고 적습니다. 과반 실패에서 복구하려면 구성원의 과반이 다시 사용 가능해져야 합니다. 과반이 온라인으로 돌아오지 못하면 운영자가 재해 복구를 시작해야 한다고 적습니다. 과반이 동작하면 클러스터가 새 리더를 자동으로 선출하고 건강한 상태로 돌아옵니다. 새 리더는 모든 리스의 타임아웃을 자동으로 연장하며, 이 장치가 서버 쪽 사용 불가로 리스가 만료되는 일이 없게 한다고 적습니다.

같은 문서는 네트워크 분단을 따로 적습니다. 네트워크 분단은 클러스터를 두 쪽으로 가릅니다. 한쪽은 구성원 과반을 쥐고 다른 쪽은 소수를 쥡니다. 과반 쪽이 사용 가능한 클러스터가 되고 소수 쪽은 사용 불가가 됩니다. 대수를 세는 규칙 하나가 두 쪽 가운데 어느 쪽이 계속 일할지를 정합니다.

HDFS

파일을 수천 대에 흩어 두는 자리입니다. HDFS(Hadoop Distributed File System) 설계 문서는 가정과 목표를 적는 첫 항목으로 하드웨어 고장을 듭니다. 하드웨어 고장은 예외가 아니라 정상이라고 적습니다. 하나의 HDFS 인스턴스는 수백 또는 수천 대의 서버 머신으로 이루어질 수 있고 각 머신이 파일 시스템 데이터의 일부를 저장합니다. 구성요소가 엄청나게 많고 각 구성요소가 사소하지 않은 고장 확률을 가진다는 사실은 HDFS 의 어떤 구성요소는 늘 동작하지 않는 상태임을 뜻한다고 적습니다. 그래서 결함 탐지와 빠르고 자동적인 복구가 HDFS 의 핵심 아키텍처 목표라고 못 박습니다.

한 대짜리 파일 시스템에서 고장은 멈추고 고치는 사건입니다. 여기서는 고장이 상시 상태라 그것을 전제로 설계가 짜입니다.

여담

이 분야에서 널리 인용되는 정의 한 줄은 농담 형식입니다. 「분산 시스템이란 존재하는 줄도 몰랐던 컴퓨터의 고장이 내 컴퓨터를 못 쓰게 만들 수 있는 시스템이다」입니다. Leslie Lamport 는 자기 저작 목록 페이지에서 이 문장의 출처를 1987년 5월 28일 12시 23분 29초에 DEC SRC 게시판으로 보낸 이메일이라고 직접 적어 두었습니다. 같은 자리에서 그는 이 말이 꽤 널리 인용되었고 잘못 인용되기도 했다고 덧붙입니다. 농담인데도 정의로 통하는 까닭은 부분 실패가 시스템 밖으로 새어 나온다는 점을 한 문장에 담았기 때문입니다.

관련 항목

어려움의 뿌리

부분 실패 · 네트워크 분단 · 비동기 네트워크 · 시계 어긋남 · 사건 순서 · 비잔틴 장애 · FLP 불가능성(Fischer-Lynch-Paterson impossibility)

자주 나는 장애

스플릿 브레인 · 좀비 노드 · 썬더링 허드 · 재시도 폭풍 · 중복 처리

합을 맞추는 장치

합의 · Raft · Paxos · 2단계 커밋(2PC, two-phase commit) · 정족수 · 리더 선출 · 하트비트 · 리스

데이터를 두는 방식

복제 · 파티셔닝 · 샤딩 · 일관성 해싱

데이터가 고르는 일관성 수준

복제 지연 · 결과적 일관성 · 선형화 가능성

다루는 도구

멱등성 · 벡터 시계 · 논리 시계 · 아웃박스 · 백오프 · 캐싱

재고 맞바꾸는 축

CAP(Consistency, Availability, Partition tolerance) · 지연 대 처리량 · 성능

이루는 구성 요소

프로세스 · 데이터베이스

실제로 구현한 시스템

DNS · PostgreSQL · etcd · HDFS