Skip to content

2장 분산 시스템의 속성 #1563

Description

@jongfeel

2.1 호텔 객실 예약 시스템으로 살펴보는 분산 시스템 예시

image

Figure 2.1 – Hotel room booking request flow

각 쓰기/읽기 요청은 다음과 같이 처리됩니다.

쓰기 요청 흐름

사용자(u1)가 방(r1)을 예약합니다.
이때 사용자(클라이언트)는 RoomAvailable API를 이용하여 앱 서버에 (u1, r1) 예약 요청을 보냅니다.
서버는 하나 내지 여러 레플리카(혹은 모두가 될 수도)에 데이터를 기록합니다.

읽기 요청 흐름

사용자(u2)가 방(r1)의 예약 가능 여부를 확인합니다.
사용자(클라이언트)는 RoomAvailable API를 이용하여 앱 서버에 (u2, r1) 예약 가능 여부를 요청합니다.
서버는 하나 내지 여러 레플리카(혹은 모두가 될 수도)에 데이터를 조회합니다.

데이터 쓰기 옵션

직렬 동기 쓰기(serial sync writes)

서버가 먼저 db1에 데이터를 쓰고 처리 완료 응답을 받은 후 db2에 쓰고 응답을 받으며, 마지막으로 db3에 쓰고 응답을 받습니다.
이후 최종적으로 클라이언트에 확인 응답(예약 완료)을 보냅니다.
이 경우 사용자(u1)가 객실 예약을 완료하기까지 기다려야 하는 지연 시간(latency)은 매우 길어집니다.

직렬 비동기 쓰기(serial async writes)

서버가 db1에 데이터를 쓰고 확인 응답을 받은 후 즉시 클라이언트에 응답을 보냅니다.
이후 다른 레플리카 두 개는 비동기적으로 업데이트됩니다.
이 방식에서는 쓰기 동작의 지연 시간이 낮습니다.

병렬 비동기 쓰기(parallel async writes)

서버가 데이터베이스를 모두 동시에 업데이트하지만, 모든 처리 완료 응답을 기다리지 않고 일부(하나 내지 여러 개) 응답을 받은 후 클라이언트에 확인 응답을 보냅니다.
지연 시간은 낮지만 스레드의 자원 사용량이 높습니다.

메시징 서비스(카프카(kafka) 등)에 쓰기

카프카 등 메시징 서비스에 데이터를 기록한 후 클라이언트에 바로 응답을 보냅니다.
이후 메시징 서비스에 저장된 데이터를 읽어 오는 시스템(소비자)이 이 데이터를 가져가서 앞서 설명한 방법 중 하나로 각 레플리카에 데이터를 적용합니다.
이 방식은 지연 시간이 가장 짧고, 쓰기 요청이 아주 많아도 문제없이 처리할 수 있습니다.

데이터 읽기 옵션

  • 하나의 레플리카에서만 읽기: 하나의 레플리카 데이터베이스에서만 데이터를 읽어 와 클라이언트에 반환합니다.
  • 일부 레플리카에서 읽기: 과반수에 해당하는 레플리카에서 데이터를 읽어 와 일관성을 확인한 후 클라이언트에 반환합니다.
  • 모든 레플리카에서 읽기: 모든 레플리카에서 데이터를 읽은 후 그 결과를 클라이언트에 반환합니다.

2.2 일관성

분산 시스템 설계에서 일관성이란 여러 노드에 데이터가 복제되고 분산되어 있더라도 시스템 내 모든 노드가 항상 동일한 상태나 데이터를 참조하도록 하는 개념입니다.
즉, 일관성은 모든 노드가 동일한 데이터를 저장하고, 같은 업데이트 요청에 대해 동일한 순서로 업데이트된 데이터를 반환하도록 하는 것을 의미합니다.

2.2.1 강한 일관성

분산 시스템에서 강한 일관성이란 시스템 내 모든 노드가 공유하고 있는 데이터 업데이트를 동일한 순서로 처리하도록 보장하는 특성을 의미합니다.
강한 일관성은 쓰기 작업이 수행된 이후의 모든 읽기 작업이 항상 최신 값을 반환하도록 합니다.

강한 일관성은 은행 시스템 같은 민감한 데이터를 다루는 서비스에서 사용하기 좋습니다.

2.2.2 최종 일관성

최종 일관성은 시스템 내에서 일시적이나마 데이터 불일치를 허용하지만, 시간이 지나면 모든 레플리카 데이터베이스나 노드가 결국 동일한 상태에 도달하도록 보장하는 방식입니다.

최종 일관성 문제는 충돌 해결(conflict resolution), 데이터 복제(replication), 가십 프로토콜(gossip protocol) 같은 기법을 사용해서 해결할 수 있습니다.

최종 일관성은 가용성과 확장성을 높이고, 클라이언트에 더 빠른 응답 시간을 줄 수 있다는 이점이 있습니다.
네트워크 분할이나 일시적인 장애가 발생해도 각 노드가 계속해서 운영되며 요청을 처리할 수 있습니다.
또 작업 부하를 여러 레플리카에 분산할 수 있어 시스템 성능이 향상됩니다.

강한 일관성은 즉각적이고 엄격한 동기화가 필요한 경우에 적합하며, 최종 일관성은 일시적인 데이터 불일치를 감수하는 대신 가용성과 확장성을 높이는 선택입니다.

image

Figure 2.2 – Hotel room booking example to understand consistency

시스템 아키텍트로서 우리는 설계할 때 어떤 일관성을 적용할지 선택해야 합니다.

  • n = 레플리카의 총 개수
  • r = 데이터를 읽을 때 참조할 레플리카 수
  • w = 데이터를 쓸 때 반영할 레플리카 수

시스템은 전체 레플리카 n개를 활용하지만, 실제 읽기나 쓰기 작업에서 일관성을 평가할 때는 레플리카 r개 또는 w개만 사용합니다.
이런 구성에 따라 선택할 수 있는 방식은 다음과 같습니다.

n = the number of replicas
r = the number of replicas we consider reading from
w = the number of replicas we consider writing to
We talk to all n replicas, but consider w or r number of replicas for evaluation.

Here are our options:
a. w=1, r=3 → strong consistency, fast writes, slow reads
b. w=3, r=1 → strong consistency, slow writes, fast reads
c. w=2, r=2 → strong consistency, writes and reads are both the same pace
d. w=1, r=1 → eventual consistency, fast writes, fast reads

어떤 경우에는 시스템이 항상 이용 가능한 상태를 유지하기 위해 일관성을 약간 포기하더라도 최종 일관성을 선택하는 것이 더 유리할 수 있습니다.

2.3 가용성

분산 시스템 설계에서 가용성이란 시스템에 장애나 오류가 발생하더라도 사용자에게 서비스를 지속적으로 제공할 수 있는 능력을 의미합니다.

가용성을 보장하는 방식에는 여러 가지가 있습니다.

  • 다중화(중복성): 시스템의 일부 구성 요소에 장애가 발생해도 시스템이 계속 작동할 수 있도록 여러 구성 요소나 자원을 중복해 두는 방식입니다.
  • 복제(레플리케이션): 시스템이 다중화를 갖추려면 데이터를 여러 노드에 복제해야 합니다. 데이터를 여러 노드에 복제해 두면 일부 노드에 장애가 발생하더라도 다른 노드가 해당 기능을 이어받아 시스템을 계속 운영할 수 있습니다.
  • 로드 밸런싱: 여러 노드에 작업량을 고르게 분배함으로써 특정 노드에 과부하가 걸리지 않도록 하고 자원을 효율적으로 사용할 수 있게 하는 방식입니다.
  • 장애 감지 및 복구: 분산 시스템에서는 노드나 구성 요소의 장애를 감지하고 해결할 수 있는 메커니즘을 갖추고 있습니다.
  • 장애 전환 및 복귀: 장애 전환은 문제가 발생한 노드나 장치의 요청을 자동으로 백업 노드나 다른 노드로 돌리는 방식입니다.

2.4 파티션 허용성

2.4.1 네트워크 파티션

분산 시스템에서 네트워크 파티션이란 네트워크 장애나 문제로 일부 노드나 컴포넌트가 시스템의 다른 부분과 연결이 끊겨 서로 접근하거나 데이터를 주고받지 못하는 상태를 의미합니다.

다음 그림에는 db2 노드가 고립되어 다른 두 노드와 통신할 수 없는 상황이 나타나 있습니다.
네트워크 파티션이 발생하면 파티션 한쪽에 있는 노드는 다른 쪽 노드와 메시지를 주고받거나 정보를 교환할 수 없습니다.
그림에서 보듯이, db1이나 db3에 대한 쓰기 작업은 db2로 전달되지 않아 사용자가 db2에 읽기 요청을 보내면 최신 정보가 아닌 오래된 데이터가 반환될 수 있습니다.

image

Figure 2.3 – Network partition scenario

2.4.2 파티션 허용성

파티션 허용성(또는 네트워크 파티션 허용성)은 네트워크 장애나 파티션이 발생하더라도 시스템이 계속 정상적으로 작동할 수 있는 능력을 의미하는 분산 시스템의 특성입니다.

2.5 지연 시간

지연 시간은 분산 시스템에서 들어온 요청에 대한 응답이 돌아오기까지 걸리는 시간을 의미합니다.

지연 시간을 줄이는 데 활용할 수 있는 몇 가지 기술이 있습니다.

  • 네트워크 최적화: 지연 시간을 줄이려고 네트워크 인프라를 개선하는 방법입니다. 빠른 연결을 사용하거나 네트워크 홉(network hop) 수를 줄일 수도 있고, 아니면 네트워크 혼잡도를 최소화할 수도 있습니다.
  • 캐싱
  • 데이터 지역화: 데이터 복제, 에지 컴퓨팅(edge computing), 콘텐츠 분산 전략(contents distribution strategy)을 활용하는 방식이 있습니다.
  • 비동기 통신: 메시지 큐나 이벤트 기반 아키텍처 같은 비동기 통신 패턴을 사용하면 컴포넌트 간 결합을 줄이고, 병렬 처리나 논블로킹 상호 작용으로 지연 시간의 영향을 줄일 수 있습니다.
  • 성능 튜닝

2.6 내구성

내구성이란 분산 시스템에서 장애나 오류가 발생하더라도 시스템에 저장된 데이터가 손실되지 않도록 보장하는 능력을 의미합니다.

분산 시스템에서는 내구성을 유지하기 위해 복제와 백업 같은 방법을 사용할 수 있습니다.

2.7 신뢰성

신뢰성이란 하드웨어 고장, 네트워크 문제, 애플리케이션 버그, 휴먼 에러등 다양한 오류와 장애가 발생하더라도 시스템이 원래 기능을 꾸준히 제공할 수 있는 능력을 의미합니다.

2.8 장애 허용성

장애 허용이란 일부 요소가 고장 나서 제대로 돌아가지 않거나 네트워크 문제가 발생해도 시스템이 정상적으로 작동을 계속할 수 있음을 의미합니다.

장애 허용을 구현하고자 분산 시스템에서는 다중화(중복성), 복제, 장애 감지 및 복구 메커니즘 같은 여러 기술을 사용합니다.

2.9 확장성

확장성이란 사용자 수나 데이터양이 증가해도 성능이나 신뢰성을 유지하면서 시스템이 더 많은 작업을 처리할 수 있는 능력을 일컫습니다.

분산 시스템에서 확장성은 두 가지로 나눌 수 있습니다.

  • 수직 확장성: 기존 서버나 장비의 성능을 높여 처리 능력을 향상시키는 방식입니다.
  • 수평 확장성: 서버나 장비를 여러 대 추가하여 전체 시스템의 처리 능력을 확장하는 방식입니다.

image

Figure 2.4 – Vertical scaling versus horizontal scaling

2.9.1 수직 확장성

스케일 업이라고도 하는 수직 확장성 방식은 개별 노드, 인스턴스, 노드 내 자원의 용량을 늘리는 것입니다.

수직 확장성의 장점

  • 단순성: 기존 시스템 아키텍처나 소프트웨어에 최소한의 변경만 필요합니다.
  • 소규모 작업에 대한 비용 효율성: 수직 확장은 상대적으로 적은 작업량을 처리하는 시스템의 경우 비용 면에서 더 효율적인 방법일 수 있습니다.

수직 확장성의 단점

  • 하드웨어의 한계점: 업그레이드를 계속하다 보면 비용이 지나치게 높아지는 한계점에 도달합니다.
  • 단일 장애점: 시스템이 단일 노드에 의존하기 때문에 해당 노드에 장애가 발생하면 시스템 전체가 먹통이 될 수 있습니다.

2.9.2 수평 확장성

스케일 아웃이라고도 하는 수평 확장성 방식은 분산 시스템에 더 많은 노드나 인스턴스를 추가하여 작업량이나 요구 사항이 많아지더라도 문제없이 처리할 수 있도록 하는 것입니다.

수평 확장성의 장점

  • 용량 및 성능 증가
  • 장애 허용성

수평 확장성에서 해결해야 할 과제

  • 분산 조정: 여러 노드에 작업을 분산하려면 각 노드가 적절하게 협력하고 동기화할 수 있는 메커니즘이 필요합니다.
  • 데이터 일관성: 수평 확장성에서는 데이터가 여러 노드에 걸쳐 분산되므로 단일 노드에 데이터가 위치한 수직 확장성보다 데이터 일관성을 유지하는 것이 더 어려울 수 있습니다. 이를 해결하려면 분산 트랜잭션이나 최종 일관성 같은 기법을 사용하여 여러 노드 간 데이터 일관성을 관리해야 합니다.

Metadata

Metadata

Assignees

Projects

Status
Done

Relationships

None yet

Development

No branches or pull requests

Issue actions