분산 시스템 이해하기 - BASE 원칙, CAP, PACELC

분산 시스템 개요

데이터 엔지니어링하면
분산 시스템은 항상 나오는 주제이다.
그만큼 많은 소프트웨어에서 분산 시스템이 필요하다는 것인데,

그렇다면 분산 시스템이 필요한 이유는 무엇일까?

그것은 하드웨어 성능의 발전 속도로부터 나온다.

'무어의 법칙'은 하드웨어 성능의 발전은 선형적이라는 것이다. 하지만 컴퓨터에서의 트래픽과 데이터는 기하 급수적으로 늘어났다.
이에 하드웨어를 scale-up이 아닌 scale-out 전략을 생각하게 된다. 

상태를 공유하지 않으면 scale out이 쉽게 가능했지만 Database가 중요해지면서 대량의 데이터가 공유 가능해야했다.

따라서 Database를 중심으로 상태와 데이터가 공유 가능하면서 scale-out하여 많은 데이터와 트래픽이 처리 가능한 소프트웨어가 필요해졌다.

분산 시스템 특징

분산 시스템이 주로 공통적으로 가지는 특징들이 있다.

1. Concurrency
   • 자원은 공유하면서 동시에 여러 작업을 수행해 처리량을 늘린다.
2. No Global Clock
   • 시스템의 각 부분이 비동기로 동작하는데 Lock이나 Bottelneck으로 지연시키면 안된다.
3. Independent Failure
   • High Availability가 중요하기에 어느 부분이 실패해도 전체에 영향을 주면 안된다.

분산 시스템 고려 요소

1. Heterogeneity
   • OS, HW에 상관없이 서로 다른 시스템에서 일관되게 동작할 수 있어야 한다.
2. Openess
   • 서로 다른 요소끼리 연결, 확장, 상호 운용이 가능해야한다. 이때 일관된 커뮤니케이션 방식을 사용해야한다.
3. Security
   • 권한 제어, 접근 제어 등이 가능해야 한다.
     • Confidentially: 권한이 없다면 공개 불가
     • Integrity: 허가되지 않은 방법으로 변경할 수 없다.
     • Availability: 권한이 있다면 접근이 가능해야한다.
4. Scalability
   • 확장 가능해야 하며 성능이나 처리량 또는 capacity가 높아져야한다.
5. Failure handling
   • 장애나 실패에 대한 대응이 자동화된 방식으로 가능해야 한다.
   • Detecting -> Masking -> Tolerating -> Recovery -> Redundancy
6. Concurrency
   • 여러 클라이언트가 공유자원에 동시에 접근하는 문제를 해결해야한다.
7. Transparency
   • 사용자로부터는 내부 정보를 감추고 여러 투명성은 달성해야한다.
   • Access transparency
   • Location transparency
   • Concurrency transparency
   • Replication transparency
   • Failure transparency
   • Mobility transparency
   • Performance transparency
   • Scaling transparency

BASE 원칙

• Basically Available
  • 부분적인 장애는 가능해도 전체가 이용불가능한 상태는 없다.
• Soft State
  • 응답하는 데이터의 상태는 항상 consistency(일관)하지 않을 수 있다.
• Eventually Consistent
  • 그렇지만 시간이 지나면 언젠가는 consistency 해진다.

BASE는 ACID와 대비되는 개념이다.

ACID는 RDBMS의 트랜잭션 처리에서 나오는 특징이다. BASE는 ACID를 보장하지 않는다.

CAP Theorem

• Consistency (일관성)
  • 동일한 요청에는 모두 응답이 같다.
  • ACID의 consistency와는 다르며, acid는 트랜잭션이 커밋 됐을때 데이터 상태에 대한 일관성을 얘기하며 여기서 일관성은 요청에 대한 응답의 일관성이다.
• Availability (가용성)
  • 어떠한 상황에서도 항상 이용가능하다.
• Partition Tolerance (분할내성)
  • 어떠한 부분에 장애가 발생해도 다른 부분들은 정상적으로 동작한다.

분산시스템은 이 3가지를 모두 지원할 수 없으며 하나는 포기해야 실제로 구현 가능하다는 딜레마이다.

CA or CP or AP

CA - Consistency & Availability

시스템이 안정적으로 운영되며 Consistency를 보장하지만 한 부분에 장애가 생기면 부분적으로는 이용이 불가하다.
전통적인 RDBMS나 MongoDB가 있지만
분산시스템에서는 네트워크 파티션(한 부분에 장애가 생긴 경우) 발생한 경우 대비하는 시스템이기에
CA는 분산 시스템과 맞지 않다.

AP - Availability & Partition Tolerance

항상 안정적으로 운영되며 데이터와 상관없이 안정적인 응답을 받을 수 있다.
그렇지만 데이터 정합성은 보장되지 않는다.
Eventual Consistency 특징을 가진다.
Cassandra, HBase 등의 모던 분산 데이터베이스나 Druid 등 OLAP 시스템이 있다.

CP - Consistency & Partition Tolerance

Consistency와 어떤 상황에서도 파티션 경우에 이용가능하다.
하지만 파티션 상황에서 완벽한 동기화는 없기에 Consistency가 불가하다.
이런 시스템은 존재할 수 없다.

CP를 따라갈수록 응답 전 동기화로 인해 latency가 늘어나고
AP를 따라갈수록 문제를 인지하지 못하고 보장되지 않는 데이터만 계속 받을 수도 있다.

이 사이에서 요구사항에 맞는 균형점을 찾아야 한다.

PACELC Theorem

CAP 이론의 단점들을 보완하기 위해 나왔다.

Partition 상황에서
Availbility vs Consistency

Else (정상 상황)
Latency vs Consistency

네트워크 파티션 발생시
운영을 중단하고 consistency를 유지하거나, consistency를 포기하고 부분적으로 운영하는 것을 선택

정상 네트워크에서는
지연시간이 짧아지는 것을 선택하거나, 길어지더라도 consistency를 만족하는 것을 선택