레디스(Redis)가 빠른 이유: 인메모리·단일 스레드·자료구조 설계를 하나씩 뜯어보기

핵심 메시지

• 레디스의 세 가지 선택(메모리 저장, 단일 스레드, 낯선 자료구조 목록)은 따로 떼어놓고 보면 약점처럼 보이지만, 합쳐놓으면 서로의 단점을 메우는 하나의 설계가 된다.
• 속도의 근원은 디스크가 아닌 메모리에 데이터를 두는 것이다. 대신 용량 한계와 휘발성이라는 두 가지 문제가 따라오고, 레디스는 이를 뒤에서 따로 해결한다.
• 단일 스레드는 잠금(lock)을 없애 버그와 지연을 줄이고, 덤으로 모든 명령이 원자적으로 실행돼 조회수·좋아요 카운터의 경쟁 조건 문제를 그냥 사라지게 만든다.
• 해시·리스트·집합·정렬된 집합 같은 자료구조를 서버 안에서 직접 다루기 때문에, 데이터를 앱으로 끌어와 고치고 다시 쓰는 왕복이 사라진다.
• 데이터 유실 여부는 스냅숏과 변경 로그로 조절할 수 있는 다이얼이지 고정된 사실이 아니다. '레디스는 재시작하면 데이터가 날아간다'는 통념은 사실이 아니다.

쉽게 이해하기

레디스를 처음 보면 이상한 선택들이 눈에 띈다. 데이터를 전부 메모리에 두니 전원이 나가면 사라지고, 세상이 코어 수를 늘리는 동안 명령은 스레드 하나로 처리하며, 대부분의 개발자가 잘 쓰지 않는 낯선 자료구조 목록을 들고 다닌다. 하나씩 보면 약점 같지만, 이 선택들을 나란히 놓고 보면 왜 레디스가 현대 소프트웨어에서 가장 쓸모 있는 도구 중 하나가 됐는지가 드러난다.

출발점은 목표다. 데이터를 거의 즉시 읽고 쓰는 것. 일반적인 데이터베이스가 느리게 느껴지는 큰 이유는 데이터를 디스크에 두기 때문이고, 디스크까지 가는 길은 멀다. 영상은 메모리 조회를 '머릿속에서 사실을 떠올리는 것', 디스크 조회를 '도서관까지 걸어가 서가에서 책을 찾는 것'에 비유한다. 둘 다 되긴 하지만 속도는 다른 리그다. 이 하나의 선택이 속도를 만들고, 대신 용량과 휘발성이라는 청구서를 남긴다.

여러 클라이언트가 동시에 접근할 때 흔한 본능은 스레드를 여럿 두는 것이다. 그런데 두 스레드가 같은 데이터를 건드리는 순간 잠금이 필요해지고, 잠금은 느리고 까다로우며 버그의 단골 원인이다. 레디스는 반대로 갔다. 스레드 하나가 이벤트 루프로 수천 개의 연결을 돌린다. 데이터가 메모리에 있어 대부분의 명령이 마이크로초 단위로 끝나기 때문에, 한 번에 하나씩 처리해도 정체가 생기지 않는다. 영상의 표현으로는 손님을 한 명씩 끝까지 응대하는 '엄청나게 빠른 계산원' 한 명인 셈이다.

한 번에 하나씩 처리한다는 성질은 뜻밖의 선물을 준다. 모든 명령이 원자적이 되는 것이다. 좋아요 수를 하나 올리려면 보통은 값을 읽고, 1을 더하고, 다시 쓰는데, 두 요청이 동시에 그러면 서로를 덮어써 좋아요가 사라진다. 이것이 경쟁 조건이다. 레디스에서는 '증가시켜라' 한마디면 되고, 트래픽이 몰려도 모든 좋아요가 정확히 세어진다. 다만 이 안전성은 명령 하나 단위이며, 여러 명령을 한 덩어리로 묶어야 할 때는 별도의 방법을 써야 한다.

자료구조는 레디스를 단순 캐시 이상으로 끌어올리는 도약이다. 사용자 정보를 큰 JSON 덩어리로 저장하면 이메일 한 줄을 고치려고 전체를 앱으로 가져와 파싱하고 되돌려 써야 하지만, 해시를 쓰면 필드 하나만 제자리에서 바꾼다. 리스트는 순서 있는 줄이라 생산자가 한쪽에 작업을 넣고 워커가 반대쪽에서 꺼내는데, 꺼내기가 원자적이라 워커끼리 같은 작업을 두고 다투지 않는다. 집합은 중복이 애초에 들어갈 수 없어 방문자 중복 제거나 '이미 포함돼 있는가' 확인이 즉시 끝나고, 두 집합을 겹치면 공통 친구나 공통 태그가 한 번에 나온다.

주요 인사이트

• 정렬된 집합은 하나의 구조로 여러 문제를 푼다. 점수를 매기면 리더보드, 타임스탬프를 넣으면 속도 제한기나 최근 항목 피드, 우선순위를 넣으면 우선순위 큐가 된다. 백만 명 규모에서도 상위 10위나 '내 순위'가 즉시 나오고 절대 낡지 않는다.
• 영상이 강조하는 사고방식은 '명령부터 찾지 말고 데이터의 모양부터 물으라'는 것이다. 모양에 맞는 구조를 고르면 어려웠던 문제가 조용히 풀린다.
• 성능 병목은 대개 서버가 아니라 네트워크 왕복에 있다. 작은 명령 수백 개를 루프에서 하나씩 응답을 기다리며 보내는 것이 흔한 실수이고, 해법은 명령을 묶어 보내고 응답을 한꺼번에 읽는 파이프라이닝이다.
• 지속성에는 두 가지 방식이 있다. 게임의 세이브 포인트 같은 스냅숏은 가볍고 빠르게 복구되지만 저장 사이의 변경을 잃을 수 있고, 모든 변경을 기록하는 변경 로그는 마지막 기록까지 복구되지만 파일이 크고 조금 느리다. 둘을 함께 쓸 수도 있다.
• 레디스가 만능은 아니다. 모든 데이터가 메모리에 있으니 대용량은 비용이 빠르게 불어나고, 조인이 많고 복잡한 질의와 엄격한 무결성이 필요한 관계형 데이터는 여전히 전통적인 데이터베이스가 낫다. 대부분의 팀은 속도는 레디스, 진실의 원천은 데이터베이스로 나눠 함께 쓴다.

자주 묻는 질문

관련 AI 소식