[대규모 시스템 설계] 5. 키-값 저장소 설계 - CAP 정리

이번 포스팅은 키-값 저장소 설계에 관한 주제이다. 자료구조 중 Map이라는 것을 활용을 해봤다면 Key-Value 구조라는 것이 무엇인지 이해가 갈것이다. 보통 키-값 저장소는 키-값 데이터베이스라고도 불리는 비 관계형 데이터베이스이며 memcached나 레디스 같은 것들이 존재한다. 

 

키-값 자료구조 상 키는 유일해야하며 키를 통해서 값에 접근할 수 있다. 키는 일반 텍스트일 수도 있고, 해시 값일 수도 있다. 아무튼 성능상의 이유로 키는 짧을수록 좋다. 

 

단일 서버 키-값 저장소 

한 대 서버만 사용하는 키-값 저장소를 설계하는 것은 쉽다. 키-값 쌍 전부를 메모리에 해시 테이블로 저장하여 들고오면 되는 것이다. 하지만, 모든 데이터를 메모리에 두는 것은 불가능하다. 자원은 유한하기때문에 이러한 문제를 해결하기 위한 개선책으로 데이터 압축이나 자주 쓰이는 데이터만 메모리에 두고 나머지는 디스크에 두는 것이다. 

 

이러한 해결법은 완전한 방법은 아니다. 임시 방편으로 사용되는 방법일 것이며, 더 많은 실사용자의 유입이 진행된다면 단일 서버의 키-값 저장소를 두는 것은 아무래도 제한이 있다는 결론이다. 

 

그렇다면 어떻게 해야할까? 분산 키-값 저장소가 해결방법이 된다. 즉, 단일 서버가 아닌 여러 서버로 나누는 것!

 

분산 키-값 저장소 

말 그대로 키-값 쌍을 여러 서버에 분산해서 저장시킨다. 여기서 중요한 이론이 있는데 분산 시스템을 설계할 때는 CAP 정리 (Consistency, Availability, Partition Tolerance theorem)를 이해하고 있어야 한다. 

 

CAP 정리 

필자는 해당 주제를 학습하면서 CAP 정리를 처음 접해보았다. 실무 경험이 없는 우물 안 개구리는 이런 이론을 모르고 아키텍처를 설계해왔다. 서버를 빌릴 수 있는 금전적 여건도 부족했을 뿐더러 프로젝트 규모 상 단일 서버로 진행하고 모든 API 시스템이 구축이 되면 스토리지 서버를 늘려나가는 것이 흐름 상 적합하였다. 여러 프로젝트를 진행해봤지만, 스토리지 계층 서버를 분산시켜서 진행할 정도로 여유는 가지진 못하였다. 대신에 웹 계층의 서버를 여러 대로 분산 시키는 것 정도는 진행하였다. 

 

하지만, 데이터 스토리지 계층에서의 서버 분산 또한 경험해보고 싶은 마음이다. 현재로썬 프로젝트는 진행하고 있지 않은 상황에서 이론이라도 확실히 해두려고 한다.

 

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

 

데이터 일관성	분산 시스템에 접속하는 모든 클라이언트는 어떤 노드에 접속했느냐에 관계없이 언제나 같은 데이터를 본다.
가용성	분산 시스템에 접속하는 클라이언트는 일부 노드에 장애가 발생하더라도 항상 응답을 받을 수 있어야 한다.
파티션 감내	파티션은 두 노드 사이에 통신 장애가 발생하였음을 의미한다. 파티션 감내는 네트워크에 파티션이 생기더라도 시스템은 계속 동작하여야 한다.

 

[CAP 정리]

어떤 두 가지를 충족하려면 나머지 하나는 반드시 희생되어야 한다.

 

 

 

 

CP 시스템	일관성과 파티션 감내를 지원하는 키-값 저장소. 가용성을 희생
AP 시스템	가용성과 파티션 감내를 지원하는 키-값 저장소. 데이터 일관성 희생
CA 시스템	일관성과 가용성을 지원하는 키-값 저장소. 파티션 감내는 지원하지 않는다. 그러나 통상 네트워크 장애는 피할 수 없는 일로 여겨지므로, 분산 시스템은 반드시 파티션 문제를 감내할 수 있도록 설계되어야 한다. 그러므로 실세계에 CA 시스템은 존재하지 않는다.

 

위의 정의로는 크게 이해가 가지 않는다. 분산 시스템에서 데이터는 보통 여러 노드에 복제되어 보관되는데 세 대의 복제 노드의 그림을 보며 이해해보자. 

 

이상적 상태

이상적 환경이라면 네트워크가 파티션되는 상황은 절대로 발생하지 않는다. n1에 기록된 데이터는 n2, n3에 복제되어 데이터 일관성과 가용성도 만족된다. 

 

 

실세계의 분산 시스템

실세계의 분산 시스템에서는 파티션 문제를 피할 수 없다. 파티션 문제가 발생한다면 일관성과 가용성 사이에서 하나를 선택해야하는데 아래의 그림은 n3에 장애가 발생하여 n1 과 n2와 통신할 수 없는 상황이다. 즉, 클라이언트가 n1 또는 n2에 기록한 데이터가 n3에 전달되지 않는다. 또한, n3에 기록되었으나 n1, n2로 전달되지 않은 데이터가 있다면 n1, n2는 최신화 되지 않은 데이터를 가지고 있을 것이다. 

 

 

 

보통 은행권 시스템은 데이터의 일관성을 유지한다. 예를 들어 온라인 뱅킹 시스템이 계좌 최신 정보를 출력하지 못한다면 큰 문제일 것이다. 즉, 은행권 시스템은 가용성 대신에 일관성을 선택하여 세 서버 사이에 생길 수 있는 데이터 불일치 문제를 피하기위해 n1과 n2에 대해 쓰기 연산을 중단시켜야한다. 결국 파티션 때문에 일관성이 깨지는 상황이 생긴다면 해결이 될 때까지 오류를 반환해야한다는 것이다. 

 

하지만 일관성 대신 가용성을 선택한 시스템(AP)은 낡은 데이터를 반환하더라도 계속 읽기 연산을 허용해야하며 n1과 n2는 계속 쓰기 연산을 허용할 것이다. 즉, n3가 파티션 문제가 발생하더라도 시스템은 계속해서 굴러가야하며 n3의 문제점이 해결되고 나면 n1, n2에 최신화된 데이터를 n3에 전송하는 것이다. 

 

즉, 분산 키-값 저장소를 만들 때는 그 요구사항에 맞도록 CAP를 정리를 적용해야한다는 것이다.