분산 키값 저장소

DeadWhale·2023년 12월 19일

#system-design #study

발표 기반 자료다 보니 문서상 생략된 부분이 있습니다.

개요

K : V 저장소는 현대에 와서 굉장히 많은 분야에서 사용 중인 저장 방식이다.
가장 큰 장점은 속도인데 Key를 통해 일반적인 환경에서 0(1)에 속도적 우위를 취할수 있다
일반적이지 않은 상황
1. 해시 충동
2. 리사이징
3. 분산환경
4. 디스크기반 저장

이런 환경으로 가장 대표적인 것들
아마존 다이나모
- AWS 의 완전 관리형 서비스: AWS가 인프라 관리를 완전 담당하여 서버 관리에 신경 쓸 필요가 없다.
레디스
- 영속성을 제공하는 다양한 데이터 구조를 지원하는 방식의 K:V 저장소
memcached
- 영속성과 다양한 데이터 구조를 지원 하지 않지만 그만큼 가벼우면서 편한 방식의 K:V 저장소

키값 저장소의 역할은 기본적으로 간단한 연산을 한다.
키값 저장소의 장점인 속도 측명에서 장점을 취하기 위함이다.
대표적으로

put ( key , value )
get ( key )

설계범위 확정

6장에서 일관성,가용성의 가용성을 고려해 키:값 설계를 제한한다.

키-값 합계의 크기는 10kb
큰 데이터를 저장할 수 있어야한다.
높은 가용성이 중요하다 , 장애의 경우에도 빨리 응답해야한다.
높은 확장성도 필요하다. 트래픽에따라 오토스케일링을 제공해야한다.
일관성 수준의 제약 관리가 조정이 되야한다.
Latency(응답 지연 속도) 가 빨라야한다.

단일 환경

매우 간단한 방식의 구조 put / get 의 역할을 위해 한개의 저장소에 저장만 하면 되기 때문에 매우 간단하다.
하지만 한계는 분명하다 저장소의 역할의 따라 해시 테이블의 크기가 감당이 안될 수 있다.
이를 해결하기 위한 솔루션으로는

데이터의 압축 (저번에 말한 압출 )

주기적으로 자주 엑세스되는 데이터만 남기고 나머지는 버림 처리

분산 환경

제한적 단일 환경을 벗어나기 위해 실제 분산 환경을 구축해야한다.
저장되는 해시 테이블을 분산하는 것인데 이것은 논리적 물리적 모두 해당 된다.

CAP 정리

이 주제를 알고 가야하는게 CAP 정리는 모든 분산환경에 적용되는 말인대.

일관성(consistency)

분산 시스템의 접속하는 모든 클라이언트는 어떤 노드에 접속 했는지에 상관 없이 언제나 같은 값을 봐야한다.
가용성(availability)

분산 시스템에 특정 노드가 장애여도 항상 응답을 해야한다.
파티션 감내(partition tolerance)

파티션 : 두 노드 사이에 연결의 유실,지연등을 의미
노드간 파티션이 발생해도 시스템은 계속 동작해야한다는 의미.

을 모두 만족할 수 없다는 정리다.

CA ( 일관성 + 가용성 )

시스템은 모든 노드에서 일관성과 가용성을 제공한다. 파티션 발생은 허용불가능하다
현실적으로 통신 문제를 방지 불가능 함으로 이론상으로만 존재

CP ( 일관성 + 파티션 감내 )

파티션 문제가 발생 시 해결 전까지 일관되지 않은 노드를 사용 불가능 하게 한다.
일부 노드가 네트워크에서 어떤 이유로든 분리되면 해당 분리된 노드에 대해서 엑세스가 중지된다.
예시: Google의 BigTable, HBase, MongoDB 등이 CP 모델을 따른다.

AP ( 가용성 + 파티션 감내 )

파티션 문제가 발생해도 가용성을 포기하지 않는다.
시스템은 네트워크 분할 동안 각 파티션에서 독립적으로 작동할 수 있으나, 이로 인해 데이터가 일시적으로 불일치할 수 있다.
예시: Amazon DynamoDB, Cassandra, CouchDB 등이 AP 모델을 따릅니다.

여기서 Redis의 경우 CP(일관성 + 파티션 내성)의 경우를 따른 다고 볼 수 있다.
다만 "Redis Sentinel"과 "Redis Cluster"등의 여러 기능들이 있어 AP모델로도 동작 되도록 할 수 있다.

책에서 나오는 사례로 설명해보자면.

좌측 상태가 기본적인 분산 환경이다 .
n1에 대해 데이터 변동 시 n2와 n3에 자동을 전파된다.
파티션이 발생해서 n3가 장애 상태가 발생하면. 일관성과 가용성에 대해 선택해야한다.
- 일관성을 선택 시 데이터 불일치를 막기 위해 n1 과 n2는 쓰기/수정 연산을 중지해야 한다.
- 가용성을 선택 시 낢은 데이터를 보내는 문제가 발생한다.
은행권과 같은 일관성이 매우 중요한 서비스의 경우 가용성을 포기하고 일관성을 선택한다.
가용성이 중요한 스트리밍 서비스,소셜 미디어 서비스 같은 경우 일관성을 포기한다.
서비스의 특징에 따라서 일관성과 가용성을 선택하는 것이 매우 중요하다.

이 하위의 내용은 개략적으로 읽는걸 추천

키값 저장소 구축을 위한 요소들은 매우 많다.
한번의 스터디에서 한번에 다루기는 불가능하다고 판단.
최대한 요약 정리

데이터 파티션(partition)

데이터 서버 노드에 고르게 분산 가능한가
데이터의 이동을 어떻게 최소화 하나
안정해시가 이 문제의 적합한 해결책이다.

데이터 다중화(replication):

장애 발생 시 데이터 손실 방지와 가용성 향상을 위해 데이터의 복사본을 여러 노드에 저장한다.
링 형태의 서버 위 시계 방향으로 N개의 서버에 데이터 서버를 보관한다.

일관성(consistency):

모든 사용자가 동일한 데이터 뷰를 보게 하여 데이터의 정확성을 유지한다.
이때 정족수 합의 프로토콜를 통해 성능과 일관성 사이의 균형을 조절 해야한다
R : 읽게 연산의 정족수 , 읽기 연산 성공 시 R개 이상에서 승낙 받아야한다.
W : 쓰기 연산의 정족수 : 쓰기 쓰기 성공 시 W개 이상에서 승낙 받아야한다.
N : 사본의 개수 (다중화된 서버를 의미)

일관성 모델(consistency model):

데이터의 일관성 수준을 결정하는 모델
강한 일관성(strong consistency)
- 모든 읽기는 가장 최근에 갱신된 결과를 반환한다.
약한 일관성(weak consistency)
- 모든 읽기가 가장 최근에 갱싱된 결과를 반환하지 못 할 수도 있다.
최종 일관성(eventual consistency)
- 약한 일관성 중 하나의 형태다
- 갱신 결과가 결국에는 모든 사본에 동기화(반영)된다.

정족수 합의는 일관성 유지를 위한 구체적인 기술적 메커니즘.
일관성 모델은 시스템이 데이터 일관성을 어떻게 다룰 지에 대한 전반적인 방침이나 철학.

강한 일관성은 현재 쓰기 요청이 접근 시 락을 걸어버리는 단순 무식하지만 강력한 방식이다.
최종 일관성을 가장 많이 채용한다.

책에서는 다이나모와 카산드라를 얘기 했는데 이것들은 레디스와 다르게
대규모 데이터 처리를 위한 확장성과 고성능을 제공하는 것에 초점을 맞춘다.
빅데이터 처리, 실시간 분석, 온라인 서비스 백엔드등에서 사용된다.
캐싱은 아님!

데이터를 다중화할 때 피할 수 없는 문제는?

가용성은 보장되지만 사본 간 일관성을 지키기가 어렵다는 점이다.
이를 해결하기 위한 것이 버저닝이다.

버저닝이란?

데이터를 변경할 때마다 해당 데이터의 새로운 버전을 만드는 것
각 버전 데이터는 불변(immutable)이다.

두 클라이언트가 동시에 같은 키 값으로 두 개의 사본 저장소에 쓰기 작업을 한다면 어떤 문제가 발생할까?

키에 대해 값이 2가지로 충돌된다.

이를 해결하기 위한 것이 벡터 시계(vector clock)이다.

벡터 시계는 어떻게 동작할까?
다음은 벡터 시계의 사용 시나리오다.

하지만 벡터시계는 어렵다 그냥 원리만 한 줄로 이해하고 가자면

벡터 클락은 분산 시스템에서 각 노드의 이벤트 순서를 추적하여
서로 다른 노드에서 발생한 이벤트 간의 인과 관계를 파악하는 메커니즘이다.

참조
https://darkstart.tistory.com/144

장애 처리:

시스템 장애 발생 시 데이터의 안전성과 서비스의 지속적인 운영을 보장하는 방법이다.
서버의 장애는 무조건 발생한다.
- 이를 감지하는 기법과 해소하는 기법이 있다.

장애전파 : 멀티 캐스트

장애전파 : 멤버쉽 목록

멀티캐스팅(multicasting)
- 각각의 서버 서로를 모두 연결한다.
- 서버가 많아질 수록 비효율적이다.
가십 프로토콜(gossip protocol)
- 멤버십 목록(membership list)를 저장한다.
- 멤버십 목록에는 각 멤버(서버)ID와 해당 멤버의 박동 카운터(heartbeat counter)를 갖는다.
- 각 노드는 주기적으로 자신의 박동 카운터를 증가한다.
- 각 노드는 무작위로 선정하여 주기적으로 자기 박동 카운터 값을 보낸다.
- 박동 카운터 값을 받은 노드는 멤버십 목록을 최신으로 갱신한다.
- 어떤 멤버의 박동 카운터 값이 지정된 시간 동안 갱신되지 않을 경우, 해당 멤버를 장애 상태로 간주한다.

장애 감지의 경우 간단한 편이다.
장애 처리도 두가지 경우로 나뉘는데.

일시적 장애
1. 일시적인 장애임으로 다른 서버에 역할을 위임 하여 처리 할 수 있다.
영구적 장애
1. 실제 데이터 손실이 발생하기 때문에. 이 데이터를 백업하는 처리가 필요하다.
2. 보통 anti-entropy 프로토콜을 구현한다.
3. 머클(해시)트리를 활용할 수 있다.(생략)

시스템 아키텍처 다이어그램: