[정글] Redis

배경

redis를 조사하고, 프로젝트 발표까지 진행했지만 대답하지 못하는 질문들이 있었고, 아직 이해가 부족하다 느껴졌다. 프로젝트를 진행하며 궁금하거나, 대답하지 못했던 질문들을 정리해보려 한다.

redis 서버를 별도로 만드는 이유

redis를 빠른 응답만 생각했지만, 실무에서 redis를 사용하는 이유가 하나가 아니였다.

• 빠르게 접근하는 데이터베이스
• 여러 서버 공유 가능
• 확장 가능
• 운영 편의 (복구 등)

코치님이 언급하신 내용이였는데, 로컬에 redis를 만든다면 해시테이블을 만드는것과 다른게 무엇이냐는 질문을 하셨다. 단지 빠르게 접근 가능하다는것 외 용도도 고려해봐야 했다.

url 파라미터를 key로 사용할 때, 어떤걸 고려해봐야하나?

일반적인 서버에서 url 파라미터는 어떤 페이지를 특정하는지 알아내기 위해 사용된다. 파라미터를 이용해 키를 만드는데, 이때 몇가지 고려해야할 사항들이 있다.

• 유효한 파라미터를 선별하고, 그 외 파라미터는 무시
• 파라미터를 정렬 (파라미터에 따라 다른 키가 나오면 안돼)
• 네이밍 규칙을 만들어 캐시 데이터에 접근/관리가 편하도록
• 캐시 무효화, TTL을 통한 관리
• 결과 전체를 저장할지, 일부만 저장할지

redis 확장 전략

사용자가 많아지고 요청이 증가하면 Redis 인스턴스에 병목이 생길 수 있다. 이를 완화하는 방법으로는 다음 선택지가 있다.

• 단일 인스턴스 성능 개선(수직 확장)
• replication
• Redis Cluster

서비스의 읽기/쓰기 비율과 데이터 특성에 따라 적절한 방식을 선택해야 한다.

작은 규모에서는 먼저 Redis 서버 자체의 성능을 높이거나 단일 인스턴스를 최적화하는 방법이 현실적일 수 있다.

읽기 요청이 대부분이고 쓰기가 적다면 replica를 늘려 읽기 요청을 분산할 수 있다. 다만 replica는 primary를 복제하는 과정에서 지연이 발생할 수 있으므로, 최신성이 매우 중요한 읽기에는 주의가 필요하다.

Redis Cluster는 키 공간을 샤딩하는 방식이다. 키는 hash slot에 매핑되고, 각 Redis 노드는 일부 slot만 담당한다. 이를 통해 읽기/쓰기 부하와 저장 용량을 여러 노드에 분산할 수 있다. 다만 여러 키가 서로 다른 slot에 있으면 multi-key 연산이 제한될 수 있어 설계가 더 복잡해진다.

어떻게 redis에 저장되는가

1. DB에서 조회할 때
2. 자주 사용된다고 기되대는걸 미리 저장

자세한 내용은 추후에 다루기로 하고, 이 정도만 알고 넘어가겠다.

redis 단점

1. 저장 비용이 비싸다

   메모리에 저장하기 때문에, DB처럼 대용량으로 저장하기에는 부담스럽다. 따라서, 자주 빠르게 접근해야하는 소량 데이터만 저장하는게 좋아보인다.

2. 영속성이 없기 때문에, 주 저장소가 될 수 없다.

   복구 수단인 RDB, AOF가 있다고 하지만, 인메모리가 갖는 휘발성이라는 단점때문에 주 저장소가 될 수 없다.

3. 데이터 일관성 문제

   redis에 있는 데이터가 항상 최신이 아닐 수 있기 때문에, 캐시 무효화, TTL 등을 통해 관리한다해도 이전 데이터를 조회할 수 있다. 캐시 무효화가 반영되기 전에 요청이 들어올 수도 있다.

   따라서 항상 최신 데이터가 전달되지 않을 수 있다는 잠재적 문제점도 존재할 것이다.

4. 로직이 복잡해진다

   기존에는 서버가 요청을 받고, DB를 이용해 응답하는 식이였다. 그런데 redis가 추가되고, redis에서 먼저 데이터를 검사하고, 없다면 DB에 접근한다. redis를 추가하면서 로직이 복잡해진다.

5. 느려질 수 있다.

   하나의 서버로도 충분한데, redis 서버를 추가할 경우 네트워크 비용때문에 더 느려질 수 있다. 또, 캐시 적중률이 낮으면 redis에다 DB까지 접근해야해 더 느려질 수 있다. redis는 비싼 작업 비용을 줄일 때 의미가 있는것이지, 항상 사용해야하는건 아니다.

6. 복잡한 조회에는 알맞지 않다.

느낀 점

Redis의 필요성, 아키텍처 설계시 고려사항은 작은 규모보단 대규모 확장을 고려했을 때 이해가 빨랐다. 예를 들면, 사용자 요청이 많아 redis에 병목이 생긴다면, 어떻게 redis를 확장할것인가라는 질문이 들었고, 주로 발생하는 요청이나 규모, 데이터의 성격을 고려해 선택할 수 있었다.

이번 프로젝트는 규모가 작아 reids를 로컬에서 다루었다. 사실 말이 redis인거지 해시테이블을 만들어 다루는것과 다를게 없다. 그래서 잘못된것이라는 생각이 들었지만, 아주 작은 규모라 하나의 서버에 둔다는 판단하라면 납득할만하지 않나라는 생각이 들었다. 요지는 선택에 근거나 이유가 있어야했다는 것이다.