[TIL][C++] 250517 MMO 서버 개발 38일차: 레디스를 사용하는 이유

주의사항: 해당 글은 일기와 같은 기록용으로, 다듬지 않은 날것 그대로인 글입니다. 

What is Redis

• Redis는 Remote Dictionary Server의 약자로, 메모리 기반의 NoSQL 데이터베이스
• Key-Value 형태의 저장소이며, RAM에 데이터를 저장하기 때문에 읽기/쓰기 작업에 대해 적은 부하로 빠르게 처리가 가능하다.
• 주로 캐시, 데이터 베이스, 세션 관리, 메시지 중개인 등의 용도로 활용한다.

Redis 요약 키워드

• Remote Dictionary Server
• Database, Cache, Message Broker
• In-memory Data Structure Store
• Supports rich data Structure

 

레디스를 사용하는 이유 1: 캐시

• 레디스를 활용하는 주된 이유는 바로 캐시이다. 보편적으로 MainDB는 MySQL이나 MsSQL와 같이 관계형 데이터베이스(RDB)를 기반으로 한 관리 시스템(RDBMS)을 사용하는데, 이러한 RDBMS는 복잡한 쿼리 처리, 트랜젝션 관리, 영속성 보장 등 많은 부분을 책임져야 하기 때문에 읽기/쓰기 작업이 굉장히 무겁다. 그래서 쇄도하는 작업 요청을 그대로 받아버리면 엄청난 부하를 먹으며 뻗어버릴 수 있다.
• 이렇듯 MainDB가 먹을 부하를 줄여주기 위해 캐싱한 데이터를 레디스에 저장한 다음, 나중에 같은 요청이 들어왔을 때 MainDB에 접근하지 않고도 데이터를 가져갈 수 있도록 한다.

 

레디스가 먹는 부하는 걱정하지 않아도 될까?

• 레디스를 사용한다고 했을때, 결국 RDBMS가 먹을 부하를 일부 레디스가 떠안게 되는 것이다. 그렇기 때문에 자연스레 레디스가 과연 RDBMS가 먹는 부하를 버틸 수 있는지가 의문이다.
• 이에 대해 결론만 말하자면, 걱정하지 않아도 된다. RDBMS에서 부하를 크게 먹는 건 복잡한 쿼리문이나 트랙잭션을 사용했을 때 발생하는 것인데, 레디스는 그냥 map 자료구조 하나랑 별반 다를 게 없어 같은 요청이라도 읽기/쓰기 작업에 대한 부하가 굉장히 적다.
• 결론적으로 Redis는 RDBMS 대비 10분의 1 수준의 부하를 가지며, 이는 개발 환경에 있어 시스템 성능에 거의 영향을 주지 않는다. 아래는 Redis와 MySQL의 실제 부하 차이 예시이다.

실제 부하 차이 예시

// 간단한 데이터 조회 시
Redis: 0.1ms, CPU 0.1%
MySQL: 1-10ms, CPU 1-5%

// 복잡한 쿼리 시
Redis: 해당 없음 (단순 키-값만 지원)
MySQL: 10-1000ms+, CPU 10-50%+

 

레디스를 사용하는 이유 2: 서버들의 통합 메모리

• 서비스가 잘되면 많아진 트래픽에 적절히 대응할 수 있도록 서버의 성능을 높여야 한다.
• 이때 서비스 운영에 서버가 단 하나인 모놀로 틱 아키텍처의 경우, 서버의 성능을 높이는 방법은 오로지 수직적 스케일 업(Vertical Scale-up) 방식 밖에 없다. 당연히 수직적 스케일 업은 한계가 있고, 그렇기에 일반적인 경우 분산 서버 시스템을 차용한다.
• 분산 서버 시스템을 사용하는 대표적인 예시는 MSA로, 이 경우, 서버를 증설시키는 수평적 스케일 아웃 방식을 채택할 수 있다.
• 문제는 분산 서버를 사용하는 경우, 각 서버가 물리적으로 분리되어 있어 각 서버의 메모리를 공유할 수 없다.
• 이때, 레디스를 각 서버의 통합 메모리로써 사용하면 각 서버가 다른 서버가 알 필요가 있는 데이터를 레디스에 올리기만 하면 되기 때문에, 다른 서버의 정보를 쉽게 알 수 있는 방법이 생기게 된다.

 

레디스를 사용하는 이유 3: 자료 구조

• 레디스에선 다양한 자료 구조를 지원한다. 이를 통해, 다른 서버에게 보다 쉽게 데이터를 넘겨줄 수 있다.
• 게다가 레디스의 자료 구조들은 여러 서버에서 같은 자료구조에 접근하는 경우에서도 Atomic 하게 처리되기 때문에 Race Condition이 발생하지 않는다는 장점이 있다. (애초에 레디스가 싱글 스레드로 돌아가는 게 이유가 되기도 한다.)
  • Redis 자료구조는 Atomic Critical Section에 대한 동기화 기능 제공
  • 서로 다른 트랜젝션 Read/Write를 동기화
• 결과적으로, 프로그래밍 언어에 존재하는 자료 구조(ex. HashMap)를 사용하지 않고 레디스 자료 구조를 굳이 쓰는 이유를 정리하자면 아래와 같다.
  • 단일 서버: Atomic 자료 구조 사용 또는 캐시용
  • 여러 서버: 데이터를 thread-safe 하게 공유

레디스는 왜 Single Threaded로 실행되는가?
- CPU연산보다 메모리 I/O 작업을 하는데 대부분의 시간을 보냄
- CPU적인 최적화를 했을 때 큰 의미가 없음
- 개발적 단순화