［독서기록］ 가상 면접 사례로 배우는 대규모 시스템 설계 기초 6장

📖 제목 : 가상 면접 사례로 배우는 대규모 시스템 설계 기초 : 6장
🙋‍♂️ 저자 : 알렉스 쉬
6장에서는 키-값 저장소 설계에 대해 다루고 있다. 우선 키-값 저장소가 뭔지부터 알아본 후, 단일 서버 환경에서의 키값 저장소에서부터 분산 시스템으로 확장할 경우까지 대규모 시스템 설계의 핵심 개념들을 알아보기로 하자.

📌키-값 저장소란?

사실 개발자라면 다들 Map 같은 자료형에서 키-값형태를 많이 보아왔을 것이다. 키-값 저장소란 쉽게 말해 특정한 키를 알려주면, 그에 해당하는 값을 바로 찾아주는 저장소를 뜻한다. 예를 들어 핸드폰 전화번호부를 떠올려보자.

• “엄마” -> 010-1111-2222
• “아빠” -> 010-3333-4444 이런 형태의 자료 구조에서, 키인 “엄마”를 입력하면 그에 해당하는 값인 “010-1111-2222”를 바로 찾을 수 있는 게 키-값 저장소의 구조이다. 구조가 단순하고 빠르게 데이터를 찾을 수 있다는 장점 때문에 캐시 시스템, 세션 관리, 간단한 DB 역할에 많이 사용된다.

👉 대표적인 키-값 저장소로 Redis, DynamoDB 등이 있다.

📌단일 서버에서의 키-값 저장소

단일 서버에서는 아주 간단하게 사용할 수 있다.

1 2 3

Map<String, String> memoryStore = new HashMap<>(); memoryStore.put("엄마", "010-1234-5678"); System.out.println(memoryStore.get("엄마")); // 출력: 010-1234-5678

👉 다만 이렇게 사용하면 서버 메모리 안에서만 작동하고, 서버가 내려갈 때 저장된 데이터들도 다 사라진다.

단일 서버로 키-값 저장소를 구현하는 건 쉽고 빠르지만, 실제 서비스에서 운용하려고 하면 다음과 같은 문제들이 생기게 된다.

1. 메모리 한계 : 저장할 데이터가 너무 많아지면 RAM이 부족해진다.
2. 장애에 취약 : 위에서 설명한 것처럼 서버가 내려가면 저장된 데이터들도 다 사라진다.
3. 트래픽 증가에 대응하지 못함 : 동시에 수천명이 접속하면 버벅거리게 된다.

👉 그래서 서버를 여러 대로 나눠서 분산 처리하는 설계가 필요해지는 것.

📌 분산 키-값 저장소란?

여러 서버가 나눠서 키-값 데이터를 보관하는 구조다.

• 서버A : “엄마”, “아빠”
• 서버B : “친구1”, “친구2”
• 서버C : “회사동료1”, “회사동료2”

이런 식이다. 이렇게 데이터를 분산했을 때이 장점은 서버 한 대가 망가져도 전체 시스템은 계속 작동한다는 것, 더 많은 데이터를 저장할 수 있다는 점, 많은 요청이 동시에 들어와도 나눠서 처리할 수 있다는 점이다.

📌 데이터는 어떻게 나눠서 저장하면 좋을까?

지난 장에서 배웠던 안정 해시가 여기에서 등장한다. 안정 해시를 이용하여 원형 해시 링 위에 데이터를 배치하고, 새로 서버를 추가하거나 제거해도 데이터 이동이 최소화 되도록 할 수 있다. 그 밖에, 혹시 모를 장애 대비용으로 데이터를 백업해두면 서버 A가 망가져도 A-1에서 데이터를 읽을 수 있다.

👉 CAP 이론에 대해 알아보자

CAP은 Consistency(일관성), Availability(가용성), Partition Tolerance(분할 허용성)의 약자이다. 이 이론은 “적절한 응답시간 내에 세 가지 속성을 모두 만족시키는 분산 시스템을 구성할 수 없다”는 이론이다. 즉, 분산 데이터베이스 시스템은 분할이 생겼을 때 일관성과 가용성 중 하나를 희생해야 한다는 의미다. 왜 ‘분할 허용성’을 희생할 수는 없냐하면, 분산 데이터베이스 시스템은 반드시 네트워크 장애나 여러 이유들로 인해 장애가 발생할 수밖에 없으므로 분할 허용성을 가지고 있어야 한다. 그래서 나머지 일관성과 가용성 중에 한 쪽을 선택해야 하는 것이다.
참고로 MongoDB는 CP를, Cassandra는 AP를 만족하도록 설계되어 있다.

참고해서 읽으면 좋을 글 : CAP 이론 소개

👉 장애 상황을 처리하는 방법

서버가 일시적으로 다운되었다면 : 데이터를 다른 서버에 임시로 저장했다가 나중에 전달하는 힌티드 핸드오프 방법을 사용할 수 있다.
오랫동안 서버 장애가 발생한다면 : 서버 간의 데이터를 비교하고 동기화 한다. 이때 머클 트리(Merkle Tree)라는 자료구조를 사용하면 효율적이다.

📌 버전 충돌은 어떻게 해결할까?

예를 들어, 나와 다른 사람이 동시에 같은 키 “엄마”에 서로 다른 값을 저장하려 하는 문제가 생길 수 있다. 이 때는 버전 관리가 필요하다. 벡터 시계 같은 기법을 써서, “누가 먼저 수정했는지”, “충돌이 발생했는지”를 확인할 수 있다.

👉 벡터 시계란?
각각의 노드가 자기만의 시계를 가지고 있고, 데이터를 수정할 때 마다 자기 시계를 증가시킨다. 그래서 변경 이록이 기록되면 충돌이 났는지, 누가 더 최신인지를 판단 할 수 있다. 충돌하는 경우 사용자에게 “둘 중 하나를 선택” 하게 하거나, 자동 병합 로직을 적용 할 수 있다.

📌 그 밖에 알아두면 좋은 것들

• 가상 노드 : 5장에서도 한 번 다루었는데, 가상 노드 여러개를 만들어서 서버 하나가 여러 조각의 데이터를 담당하도록 하면 더 고르게 데이터가 분산되는 기법이다.
• 블룸 필터 : 어떤 키가 존재하지 않음을 빠르게 판별하는 필터링 방식으로, DB에 없는 키는 검색하지 않고 바로 ‘없음’이라고 알려주어서 성능을 향상시킬 수 있다.