6장. 키-값 저장소 설계

키-값 저장소는 키-값 데이터베이스라고도 불리는 비관계형 데이터베이스이며, 각 값은 고유 식별자인 키를 통해 접근한다.
키는 일반 텍스트 혹은 해시 값일 수 있으며, 짧을수록 성능에 유리하다.
값은 문자열, 리스트, 객체 등 어떤 것이든 가능하며, 저장소는 값의 형태를 따로 제한하지 않는다.

대표적인 예시로는 Amazon Dynamo, Memcached, Redis 등이 있다.

 

요구사항 정리

이번 장에서는 다음 특성을 갖는 키-값 저장소를 설계해 볼 것이다.

• 키-값 쌍의 크기는 10KB 이하이다.
• 큰 데이터를 저장할 수 있어야 한다.
• 높은 가용성을 제공해야 한다. 따라서 시스템은 설사 장애가 있더라도 빨리 응답해야 한다.
• 높은 규모 확장성을 제공해야 한다. 따라서 트래픽 양에 따라 자동적으로 서버 증설/삭제가 이루어져야 한다.
• 데이터 일관성 수준은 조정이 가능해야 한다.
• 응답 지연시간(latency)이 짧아야 한다.

 

단일 서버 기반 설계

한 대 서버만 사용하는 키-값 저장소를 설계하는 것은 쉽다.
가장 직관적인 방법은 키-값 쌍 전부를 메모리에 해시 테이블로 저장하는 것이다.

 

그러나 이 접근법은 빠른 속도를 보장하지만 모든 데이터를 메모리 안에 두는 것이 불가능할 수도 있다는 한계가 있다.
이 문제를 해결하기 위한 개선책으로는 다음과 같은 것들이 있다.

• 데이터 압축(compression)
• 자주 쓰이는 데이터만 메모리에 두고 나머지는 디스크에 저장

그러나 이렇게 개선한다고 해도, 단일 서버로는 한계가 있어 결국 분산 키-값 저장소로의 확장이 필요하다.

 

분산 키-값 저장소

분산 키-값 저장소는 분산 해시 테이블이라고도 한다. 키-값 쌍을 여러 서버에 분산시키기 때문이다.
분산 시스템을 설계할 때는 `CAP 이론`을 이해하고 있어야 한다.

데이터 일관성, 가용성, 파티션 감내라는 세 가지 요구사항을 동시에 만족하는 분산 시스템을 설계하는 것은 불가능하다는 정리

 

CAP 이론 세 가지 요소

• Consistency (일관성): 모든 노드에서 같은 데이터를 조회 가능해야 함
• Availability (가용성): 일부 노드 장애에도 시스템이 응답을 제공해야 함
• Partition Tolerance (파티션 감내): 네트워크 단절이 생겨도 시스템이 계속 동작해야 함

세 가지 모두를 동시에 만족할 수는 없으며, 일반적으로 파티션 감내(P)는 반드시 필요하므로 실제 구현에서는 CP 또는 AP 시스템 중 하나를 선택한다.

 

시스템 유형 분류

• CP (일관성 + 파티션 감내): 은행 시스템 등 강한 일관성이 중요한 곳 (→ 가용성 희생)
• AP (가용성 + 파티션 감내): SNS, 캐시 등에서 사용 (→ 일관성 희생)
• CA: 이론적으로 가능하지만, 실전에서는 분산 환경에서 파티션 감내가 필요하므로 사실상 존재하지 않음

분산 시스템에서 데이터는 보통 여러 노드에 복제되어 보관된다. 세 대의 복제(replica) 노드 n1, n2, n3에 데이터를 복제하여 보관하는 상황을 가정해 보자.

 

이상적 상태

이상적 환경이라면 네트워크가 파티션 되는 상황은 절대로 일어나지 않을 것이고, n1에 기록된 데이터는 자동적으로 n2, n3에 복제되므로 일관성과 가용성도 만족한다.

 

실제 분산 시스템

분산 시스템은 파티션 문제를 피할 수 없다. 그리고 파티션 문제가 발생하면 우리는 일관성과 가용성 사이에서 하나를 선택해야 한다.

 

CP 시스템 (일관성, 파티션)

가용성 대신 일관성을 선택한다면 세 서버 사이에 생길 수 있는 데이터 불일치 문제를 피하기 위해 n1과 n2에 대해 쓰기 연산을 중단시켜야 하는데, 그렇게 하면 가용성이 깨진다.

 

은행권 시스템은 보통 데이터 일관성을 양보하지 않는다.
예를 들어, 온라인 뱅킹 시스템이 계좌 최신 정보를 출력할 수 있는 상황이 발생하면 이런 시스템은 상황이 해결될 때까지는 오류를 반환해야 한다.

 

AP 시스템(가용성, 파티션)

하지만 일관성 대신 가용성을 선택한 시스템은 설사 낡은 데이터를 반환할 위험이 있더라도 계속 읽기 연산을 허용해야 한다.

아울러 n1과 n2는 계속 쓰기 연산을 허용할 것이고, 파티션 문제가 해결된 뒤에 새 데이터를 n3에 전송할 것이다.

 

CA 시스템(일관성, 가용성)

앞서 말했듯이, CA 시스템은 분산 시스템에서 존재하지 않는다
분산 시스템이 아닌 단일 시스템에서는 존재할 수 있다.

 

키-값 저장소 핵심 컴포넌트 및 기술

• 데이터 파티션
• 데이터 다중화(replication)
• 일관성(consistency)
• 일관성 불일치 해소(inconsistency resolution)
• 장애 처리
• 시스템 아키텍처 다이어그램
• 쓰기 경로
• 읽기 경로

 

데이터 파티션(Partitioning)

전체 데이터를 한 서버에 담는 건 비효율적이므로 데이터를 나눠 여러 서버에 저장한다. 다음 조건을 만족해야 한다

• 데이터를 고르게 분산할 수 있을 것
• 서버 추가/삭제 시 데이터 이동 최소화

5장에서 다룬 안정 해시 설계는 이 문제를 푸는 데 적합한 기술이다.

해당 키를 같은 링 위에 배치하고, 시계 방향으로 순회하다 만나는 첫 번째 서버가 바로 해당 키-값 쌍을 저장할 서버다.

 

안정 해시를 사용하여 데이터를 파티션 하면 좋은 점

• 규모 확장 자동화(automatic scaling) : 트래픽에 따라 서버 자동 증설/축소 가능
• 다양성(heterogeneity) : 서버 성능에 따라 가상 노드 수를 다르게 설정 가능 다시 말해, 고성능서버는 더 많은 가상 노드를 갖도록 설정할 수 있다.

 

데이터 다중화(Replication)

• 높은 가용성과 안정성을 확보하기 위해 데이터를 N개의 서버에 비동기적으로 복제한다.
• 일반적으로 해시 링에서 키 위치를 기준으로 시계 방향으로 N개의 노드를 선택하여 사본을 저장한다. 지점으로부터 시계 방향으로 링을 순회하면서 만나는 첫 N개 서버에 데이터 사본을 보관하는 것이다.
  따라서 N=3으로 설정한 아래 그림에서 key0은 s1, s2, s3에 저장된다

그런데 가상 노드를 사용한다면 위와 같이 선택한 N개의 노드가 대응될 실제 물리 서버의 개수가 N보다 작아질 수 있다.

이 문제를 피하려면 노드를 선택할 때 같은 물리 서버를 중복 선택하지 않도록 해야 한다.

 

🤔 이게 무슨 말이지?

예를 들어, s0, s1, s2가 실제로는 모두 서버 A 한 대에 존재하는 가상 노드들일 수 있다.
이 경우 key0의 3개 복제본이 물리적으로 같은 서버 A에 저장된다.
즉, 논리적으로는 3개의 서로 다른 노드에 저장했지만 실제로는 1개의 물리 서버에만 저장될 수 있다는 뜻이다.

 

그렇게 되면 다음과 같은 문제가 발생한다

문제 상황	설명
서버 장애	서버 A 하나에 장애가 발생하면 key0의 모든 복제본이 함께 손실됨
복제 무효	논리적으로는 3개의 노드에 저장했지만, 실제로는 1개 서버에 몰려 있어 복제의 의미가 없어짐
고가용성 실패	정전, 네트워크 단절, 자연재해 등 물리적 장애에 대응할 수 없음

 

같은 데이터 센터에 속한 노드는 정전, 네트워크 이슈, 자연재해 등의 문제를 동시에 겪을 가능성이 있다.
따라서 안정성을 담보하기 위해 데이터의 사본은 다른 센터의 서버에 보관하고, 센터들은 고속 네트워크로 연결한다.

 

데이터 일관성(Consistency)

다중화된 데이터를 적절히 동기화하기 위해 정족수 합의(Quorum Consensus)를 사용한다.

• N: 복제본 수
• W: 쓰기 성공으로 간주되기 위한 응답 수
• R: 읽기 성공으로 간주되기 위한 응답 수

N = 3인 경우에 대한 그림을 살펴보자.

 

1. W = 1 일 경우

W = 1은 데이터가 한 대 서버에만 기록된다는 뜻이 아니다.

위의 그림과 같이 데이터가 서버 0, 서버 1 서버 2에 다중화되는 상황을 예를 들어 살펴보자.

W = 1의 의미는, 쓰기 연산이 성공했다고 판단하기 위해 중재자(coordinator)는 최소 한 대 서버로부터 쓰기 성공 응답을 받아야 한다는 뜻이다.

따라서 서버 1로부터 성공 응답을 받았다면 서버 0, 서버 2로부터의 응답을 기다릴 필요가 없다.

중재자는 클라이언트 노드 사이에서 프락시(proxy) 역할을 한다.

 

2. W = 1 또는 R =1인 경우

W = 1 또는 R = 1인 구성의 경우 중재자는 한 대 서버로부터의 응답만 받으면 되니 응답속도는 빠를 것이다.

W나 R의 값이 1보다 큰 경우에는 시스템이 보여주는 데이터 일관성의 수준은 향상될 테지만 중재자의 응답 속도는 가장 느린 서버로부터의 응답을 기다려야 하므로 느려질 것이다.

 

3. W + R > N

W + R > N인 경우에는 강한 일관성이 보장된다.
일관성을 보증할 최신 데이터를 가진 노드가 최소 하나는 겹칠 것 이기 때문이다.

 

🤔 그럼 어떻게 정해야 할까?

책에서는 가능한 몇 가지 구성을 제시한다.

• R = 1, W = N : 빠른 읽기 연산에 최적화된 시스템 (쓰기 응답은 복제본 수만큼 받기)
• W = 1, R = N : 빠른 쓰기 연산에 최적화된 시스템 (읽기 응답은 복제본 수 만큼 받기)
• W + R > N : 강한 일관성이 보장됨(보통 N=3, W=R=2) (읽기 응답과 쓰기 응답은 복제본 수 보다 크도록 설정)
• W + R <= N : 강한 일관성이 보장되지 않음 (읽기 응답과 쓰기 응답은 복제본 수 보다 작도록 설정)

요구되는 일관성 수준에 따라 W, R, N의 값을 조정하면 된다.

 

일관성 모델

일관성 모델은 키 값 저장소를 설계할 때 고려해야 할 또 하나의 중요한 요소다.
일관성 모델은 데이터 일관성의 수준을 결정하는데, 종류가 다양하다.

 

• 강한 일관성(strong consistency) : 모든 읽기 연산은 항상 최신 데이터를 읽음.
  다시 말해서 클라이언트는 절대로 낡은 데이터를 보지 못한다.
• 약한 일관성(weak consistency) : 읽기 연산은 최신이 아닐 수 있음.
• 최종 일관성(eventual consistency) : 약한 일관성의 한 형태로, 시간이 지나면 모든 사본이 동기화됨

강한 일관성을 달성하는 일반적인 방법은, 모든 사본에 현재 쓰기 연산의 결과가 반영될 때까지 해당 데이터에 대한 읽기/쓰기를 금지하는 것이다.
이 방법은 고가용성 시스템에는 적합하지 않다. 새로운 요청의 처리가 중단되기 때문이다.

 

다이나모 또는 카산드라 같은 저장소는 최종 일관성 모델을 택하고 있기 때문에 더 자세히 알아보자.
최종 일관성 모델을 따를 경우 쓰기 연산이 병렬적으로 발생하면 시스템에 저장된 값의 일관성이 깨어질 수 있는데, 이 문제는 클라이언트가 해결해야 한다.

 

클라이언트 측에서 데이터 버전 정보를 활용해 일관성이 깨진 데이터를 읽지 않도록 하는 기법에 대해서는 아래에서 살펴볼 것이다.

 

비 일관성 해소 기법 : 데이터 버저닝

데이터를 다중화하면 가용성은 높아지지만 사본 간 일관성이 깨질 가능성은 높아진다.
버저닝(versioning)과 벡터 시계(vector clock)는 그 문제를 해소하기 위해 등장한 기술이다.

 

버저닝은 데이터를 변경할 때마다 해당 데이터의 새로운 버전을 만드는 것을 의미한다.
따라서 각 버전의 데이터는 변경 불가능하다.

 

버저닝에 대해 알아보기 전에 우선 데이터 일관성이 어떻게 깨지는지 예제를 통해 알아보자.
아래의 그림과 같이 어떤 데이터의 사본이 노드 n1과 n2에 보관되어 있다고 해보자.

이 데이터를 가져오려는 서버 1과 서버 2는 get(“name”) 연산의 결과로 같은 값을 얻는다.

이제 위 그림과 같이 서버 1은 “name”에 매달린 값을 “johnSanFrancisco”로 바꾸고, 서버 2는 “johnNewYork”으로 바꾼다고 하자.

 

그리고 이 두 연산은 동시에 이뤄진다고 하자. 이제 우리는 충돌하는 두 값을 갖게 되었다.
그 각각을 버전 v1, v2라고 하자.

이 변경이 이루어진 이후에, 원래 값은 무시할 수 있다. 변경이 끝난 옛날 값이기 때문이다.
하지만 마지막 두 버전 v1과 v2 사이의 충돌은 해소하기 어려워 보인다.

벡터 시계는 이 문제를 푸는데 보편적으로 사용되는 기술이다.
동작 원리를 살펴보자.

 

벡터 시계(vector clock)

• 각 데이터에 [서버, 버전] 쌍을 매단다
• 쓰기 시 해당 서버의 버전 카운터 증가
• 이를 통해 어떤 버전이 선행/후행인지 판단 가능

벡터 시계는 D([S1, v1], [S2, v2], …, [Sn, vn]와 같이 표현한다고 가정하자.
여기서 D는 데이터이고, vi는 버전 카운터, Si는 서버 번호이다.
만일 데이터 D를 서버 Si에 기록하면, 시스템은 아래 작업 가운데 하나를 수행하여야 한다.

• `[Si, vi]`가 있으면 vi를 증가시킨다.
• 그렇지 않으면 새 항목 `[Si, 1]`를 만든다.

이 추상적 로직이 실제로 어떻게 수행되는지를 아래의 그림으로 살펴보자.

1. 클라이언트가 데이터 D1을 시스템에 기록한다. 이 쓰기 연산을 처리한 서버는 Sx이다. 따라서 벡터 시계는 `D1([Sx, 1])`으로 변한다.
2. 다른 클라이언트가 데이터 D1을 읽고 D2로 업데이트한 다음 기록한다. D2는 D1에 대한 변경이므로 D1을 덮어쓴다. 이때 쓰기 연산은 같은 서버 Sx가 처리한다고 가정하자. 벡터 시계는 `D2([Sx, 2])`로 바뀔 것이다.
3. 다른 클라이언트가 D2를 읽어 D3로 갱신한 다음 기록한다. 이 쓰기 연산은 Sy가 처리한다고 가정하자. 벡터 시계 상태는 `D3([Sx, 2], [Sy 1])`로 바뀐다.
4. 또 다른 클라이언트가 D2를 읽고 D4로 갱신한 다음 기록한다 (3번과 병렬처리) 이때 쓰기 연산은 서버 Sz가 처리한다고 가정하자. 벡터 시계는 `D4([Sx, 2], [Sz, 1])`일 것이다.
5. 어떤 클라이언트가 D3과 D4를 읽으면 데이터 간 충돌이 있다는 것을 알게 된다. D2를 Sy와 Sz가 각기 다른 값으로 바꾸었기 때문이다. 이 충돌은 클라이언트가 해소한 후에 서버에 기록한다. 이 쓰기 연산을 처리한 서버는 Sx였다고 하자. 벡터 시계는 `D5([Sx, 3], [Sy, 1], [Sz, 1])`로 바뀐다. 충돌이 일어났다는 것을 어떻게 감지하는지는 잠시 후에 더 자세히 살펴볼 것이다.

벡터 시계를 사용하면 어떤 버전 X가 버전 Y의 이전 버전인지(따라서 충돌이 없는지) 쉽게 판단할 수 있다.

버전 Y에 포함된 모든 구성요소의 값이 X에 포함된 모든 구성요소 값보다 같거나 큰지만 보면 된다.
예를 들어 벡터 시계 `D([s0, 1], [s1, 1])`은 `D([s0, 1], [s1, 2])`의 이전 버전이다. 따라서 두 데이터 사이에 충돌은 없다.

 

어떤 버전 X와 Y 사이에 충돌이 있는지 보려면 (다시 말해 그 두 버전이 같은 이전 버전에서 파생된 다른 버전들인지 보려면) Y의 벡터 시계 구성요소 가운데 X의 벡터 시계 동일 서버 구성요소보다 작은 값을 갖는 것이 있는지 보면 된다.
예를 들어, `D([s0, 1], [s1, 2])와 D([s0, 2], [s1, 1])`는 서로 충돌한다.

 

그러나 벡터 시계를 사용해 충돌을 감지하고 해소하는 방법에는 두 가지 분명한 단점이 있다.

 

첫 번째로는 충돌 감지 및 해소 로직이 클라이언트에 들어가야 하므로, 클라이언트 구현이 복잡해진다.
두 번째는 [서버: 버전]의 순서쌍 개수가 굉장히 빨리 늘어난다는 것이다.

이 문제를 해결하려면 그 길이에 어떤 임계치(threshold)를 설정하고, 임계치 이상으로 길이가 길어지면 오래된 순서쌍을 벡터 시계에서 제거하도록 해야 한다.

그러나 이렇게 하면 버전 간 선후 관계가 정확하게 결정될 수 없기 때문에 충돌 해소 과정의 효율성이 낮아지게 된다.

하지만 다이나모 데이터베이스에 관계된 문헌에 따르면 아마존은 실제 서비스에서 그런 문제가 벌어지는 것을 발견한 적이 없다고 한다.

 

장애 감지 기법

분산 환경에서는 단일 노드의 판단만으로 장애 여부를 결정하지 않는다.
보통 두 대 이상의 서버가 똑같이 서버 A의 장애를 보고해야 해당 서버에 실제로 장애가 발생했다고 간주하게 된다.
다음의 그림과 같이 모든 노드 사이에 멀티캐스팅 채널을 구축하는 것이 서버 장애를 감지하는 가장 손쉬운 방법이다.

하지만 이 방법은 서버가 많을 때는 분명 비효율적이다.

 

가십 프로토콜(gossip protocol)

가십 프로토콜 같은 분산형 장애 감지 솔루션(decentralized failure detection) 솔루션을 채택하는 편이 보다 효율 적이다.

가십 프로토콜의 동작 원리는 다음과 같다.

• 각 노드는 멤버십 목록을 유지한다. 멤버십 목록은 각 멤버 ID와 그 박동 카운터 쌍의 목록이다.
• 각 노드는 주기적으로 자신의 박동 카운터를 증가시킨다.
• 각 노드는 무작위로 선정된 노드들에게 주기적으로 자기 박동 카운터 목록을 보낸다.
• 박동 카운터 목록을 받은 노드는 멤버십 목록을 최신 값으로 갱신한다.
• 어떤 멤버의 박동 카운터 값이 지정된 시간 동안 갱신되지 않으면 해당 멤버는 장애 상태인 것으로 간주한다.

• 노드 서버 0은 그림 좌측의 테이블과 같은 멤버십 목록을 가진 상태다.
• 노드 서버 0은 노드 서버2(멤버 ID=2)의 박동 카운터가 오랫동안 증가되지 않았다는 걸 발견한다.
• 노드 서버0은 노드 서버 2를 포함하는 박동 카운터 목록을 무작위로 선택된 다른 노드에게 전달한다.
• 노드 서버 2의 박동 카운터가 오랫동안 증가되지 않았음을 발견한 모든 노드는 해당 노드를 장애 노드로 표시한다.

 

장애 처리

1. 일시적 장애 처리

가십 프로토콜을 통해 장애를 감지한 시스템은 가용성을 유지하기 위해 다양한 조치를 취해야 한다.

• 엄격한 정족수(strict quorum) 방식에서는 일관성을 보장하기 위해 읽기/쓰기 연산을 중단해야 한다.
• 느슨한 정족수(sloppy quorum) 방식은 가용성을 우선시하여, 장애가 발생한 서버를 제외하고 W개의 건강한 서버와 R개의 건강한 서버를 해시 링에서 선택하여 연산을 수행한다.

🤔 정족수(定足數)란?
: 회의나 의결을 진행하기 위해 필요한 최소한의 참석 인원수를 의미한다.
여기서는 분산 시스템에서 어떤 연산(읽기 또는 쓰기)을 "성공"으로 간주하기 위해 필요한 최소한의 응답 수를 의미한다고 이해했다.

이때 장애 상태의 서버 대신 요청을 처리한 서버는 hinted handoff(단서 후 임시 위탁) 기법을 통해 데이터를 보관하고, 장애 서버가 복구되면 변경사항을 넘겨준다.

예시: 서버 2가 장애인 동안, 서버 3이 대신 읽기/쓰기 요청을 처리하고 복구 시 데이터를 전달

위 그림을 보면, 장애 상태인 노드 서버 2에 대한 읽기 및 쓰기 연산은 일시적으로 노드 서버 3이 처리한다.
서버 2가 복구되면, 서버 3은 갱신된 데이터를 서버 2로 인계할 것이다.

 

2. 영구 장애 처리

일시적 장애와 달리 영구적인 서버 장애를 처리하기 위해서는 반-엔트로피(anti-entropy) 프로토콜을 사용한다.

• 반-엔트로피는 복제된 사본들 간의 데이터를 비교하여 최신 상태로 동기화한다.
• 이 과정에서 머클 트리(Merkle Tree)를 활용하여 일관성 체크 및 데이터 전송량을 최소화한다.

 

3. 데이터 센터 장애 처리

정전, 네트워크 장애, 자연재해 등으로 인한 데이터 센터 단위 장애를 대비하기 위해,

• 데이터는 여러 데이터 센터에 다중화되어야 한다.
• 하나의 센터가 완전히 중단되더라도 다른 센터에서 데이터 접근이 가능하도록 구성한다.

 

시스템 아키텍처

이제 아키텍처 다이어그램을 그려보자.

• 클라이언트는 API(get, put)를 통해 시스템에 접근
• 중재자(Coordinator)는 클라이언트와 노드 사이에서 프록시 역할 수행
• 노드들은 안정 해시 링(Consistent Hashing Ring) 위에 배치되어 있음
• 데이터는 여러 노드에 다중화되어 저장
• 시스템은 자동 확장/축소가 가능하도록 설계되어 있으며,
• 단일 장애점(SPOF) 없는 완전한 분산 아키텍처로 구성됨

 

쓰기 경로에서 발생하는 일

1. 쓰기 요청이 커밋 로그(commit log)에 먼저 기록됨
2. 이후 메모리 캐시(MemTable)에 저장됨
3. 캐시가 가득 차거나 설정한 임계치에 도달하면, 디스크의 SSTable로 영속 저장됨

💡 SStable이란?
: Sorted-String Table의 약어로 키-값의 순서쌍을 정렬된 리스트 형태로 관리하는 테이블

 

읽기 경로에서 발생하는 일

1. 먼저 메모리 캐시에서 데이터를 조회
2. 없을 경우, 블룸 필터(Bloom Filter)를 통해 존재 여부를 확인
3. 블룸 필터를 통해 어떤 SSTable에 키가 보관되어 있는지 판단
4. SSTable에서 실제 데이터를 조회
5. 클라이언트에 응답 반환

💡 Bloom Filter란?
: 키가 존재할 가능성을 빠르게 판단하는 확률적 자료구조로, 존재하지 않는 경우에는 100% 정확하지만, 존재할 경우 오탐(False Positive)이 가능함

 

요약

분산 키-값 저장소의 각 컴포넌트는 서로 긴밀하게 연결되어 작동하며, 전체 시스템의 성능, 확장성, 신뢰성을 보장한다.

 

안정 해시, 데이터 다중화, 일관성 모델, 버저닝, 장애 처리 등의 기술을 적절히 조합함으로써, 대규모 데이터를 효율적으로 관리하고 높은 가용성을 제공하는 강력한 분산 시스템을 구축할 수 있다.

 

분산 키-값 저장소 설계에 사용되는 주요 기술과 그 목적을 정리하면 다음과 같다.

 

대규모 데이터 저장	안정 해시를 사용하여 서버에 부하 분산
읽기 연산에 대한 가용성 보장	데이터를 여러 데이터센터에 다중화
쓰기 연산에 대한 가용성 보장	버저닝 및 벡터 시계를 사용하여 충돌 해소
데이터 파티션	안정 해시
점진적 규모 확장성	안정 해시
다양성(heterogeneity)	안정 해시
조절 가능한 데이터 일관성	정족수 합의(quorum consensus)
일시적 장애 처리	느슨한 정족수 프로토콜 및 단서 후 임시 위탁
영구적 장애 처리	머클 트리
데이터 센터 장애 대응	여러 데이터센터에 다중화

 

 

 

 

 

 

출처
https://blog.naver.com/wavescats/222751548888?viewType=pc
https://donghyeon.dev/%EC%9D%B8%ED%94%84%EB%9D%BC/2022/03/26/%ED%82%A4-%EA%B0%92-%EC%A0%80%EC%9E%A5%EC%86%8C-%EC%84%A4%EA%B3%84/
https://dewble.tistory.com/entry/system-design-distributed-key-value-store