개요
레디스를 왜 써야 할까요?
Redis란
- In Memory Data Structure Stroe
- Memcached는 Collection을 지원하지 않지만, Redis는 지원한다.
- 개발 편의성이 높고 개발 난이도가 낮아서 생산성이 높다.
Redis를 어디에 사용해야 하는가?
- Remote Data Store
- 여러 서버에서 데이터를 공유하고 싶을 때 사용할 수 있습니다.
- 만약 한 대라면? 전역 변수 사용하면 되나요?
- Redis는 Atomic을 보장해주고 내부적으로 싱글 스레드로 동작하기 때문에 race condition에 대한 이슈가 상대적으로 작습니다. 물론 조심은 해야합니다.
- 다만 SPOF가 되는 점이 우려됩니다.
- 인증 토큰 (Collection의 Strings, hash)
- Sorted Set을 활용한 랭킹 보드
- User API Limit
Redis Collections
- Collection의 종류
- 어떤 상황을 주의해야 할까요?
- 하나의 컬렉션에는 일반적으로 10000개 이하의 숫자를 유지해야 합니다. 너무 많은 아이템이 담겨 있으면 조회 시 성능 이슈가 발생합니다.
- Expire는 모든 컬렉션 전체 아이템에만 걸립니다. 별개로 걸리지 않으니 설정 시 주의해야 합니다.
Redis 운영
레디스를 사용하는 경우 운영 환경에서 어떤 점을 주의해야 할까요?
- 메모리 관리를 잘하자
- 인메모리 데이터베이스만큼 메모리 관리가 굉장히 중요합니다. 메모리를 적게 쓴다면 우아하지만 많이 쓴다면 헬게이트가 열립니다.
- 만약 너무 많은 메모리가 필요하다면 Swap을 사용하게 되는데, 한번 스왑이 발생한 메모리 페이지는 지속해서 스왑이 발생합니다. 이는 디스크에 접근한다는 것을 의미하니 사실 일반적인 DB를 사용하는 것과 다르지 않습니다. 결국 성능 저하를 의미하죠.
- 이를 방지하기 위해 Maxmemory를 설정하면 내부적으로 해당 제한을 넘어갔을 때 키를 랜덤하게 지우거나 Expire를 지워서 메모리를 확보합니다.
- 레디스가
jmalloc을 통해 메모리를 할당/해제합니다. OS에서는 메모리를 가져오는 경우 메모리 페이지 단위(ex. 4096)로 가져오게 되는데 여기서 요청 시 얼마나 가져올지 알 수가 없습니다. (ex. 4097이 필요한데 4096 X 2를 가져오는 현상) 이는 메모리 파편화 현상을 유발합니다.
- 메모리는 필연적으로 Master-slave에서 fork를 하게 되는데 write가 헤비한 경우 memory copy때문에 메모리를 이에 2배까지 사용할 수 있습니다.
- 3.X대 버전의 경우 used memory가 2GB로 나오지만 실제 11GB의 RSS를 사용하는 경우가 자주 발생하기도 했습니다.
- 4.X대 버전에서는 jmelloc에 힌트를 주는 기능이 들어갔습니다.
- 다양한 사이즈보다는 유사한 크기의 데이터를 저장하는 것이 메모리 파편화 현상을 줄일 수 있습니다.
- 만약 메모리가 부족하다면 늘리고, 줄이고 싶다면 재부팅을 통해서 Swap을 사용하지 않도록 프로세스를 재시작하는 것이 좋습니다.