Redis -> MongoDB 전환 이유 (몽고DB 특징, 장점 etc)

요즘 이런 저런 개발 회고록을 눈팅하다보면 Redis -> MongoDB 전환기가 많이 보인다. 예컨대 올리브영, LINE 등. NoSQL은 Redis 밖에 못써봤고... 정해진대로 써야하는(?) 그런 조직에 있는 나에게는 '전환기 회고록' 등을 작성하는게 먼나라 이웃나라 이야기이지만 언젠가 참고할 일이 있길 바라며 + 우물안 개구리가 될 수는 없기에...

 

Redis -> MongoDB 전환은 왜 하는 것인지.. 그럼 뭐가 더 좋아지는지 등등 정리해본다.

 

참고한 회고록(1)

https://engineering.linecorp.com/ko/blog/LINE-integrated-notification-center-from-redis-to-mongodb

LINE 알림 센터의 메인 스토리지를 Redis에서 MongoDB로 전환하기

 

참고한 회고록(2)

https://oliveyoung.tech/blog/2023-01-04/oliveyoung-discovery-mongodb/

올리브영 전시영역 MongoDB 도입하기 | 올리브영 테크블로그

 

 

 

Redis의 한계

"늘어가는 알림 종류와 스펙, 새 계정 유입 등의 영향으로 Redis 사용률이 지속적으로 증가하면서 결국 가용량의 80% 이상을 사용하는 상황까지 도달했습니다. 이에 따라 스왑 인/아웃(swap in/out)이 발생하면서 Redis 페일오버(failover) 또한 발생하는 상황이었고요."

-> redis는 in-memory data store로 physical memory 이상을 사용하면 swap memory*를 사용하게 된다. 

(*swap memory ? 스왑 메모리는 실제 메모리 ram이 가득찬 상황에서 더 많은 메모리가 필요할 때 부족한 메모리를 대체할 수 있는 공간으로, 디스크 공간을 이용한다. 하드 디스크공간을 메모리처럼 사용하는 것으로 속도면에서 현저히 떨어진다.)

-> 보통 레디스가 갑자기 느려졌다면? swap 메모리까지 쓰고 있는 건 아닌지 확인이 필요.

-> 레디스는 싱글 쓰레드*이기 때문에 적은 메모리를 사용하는 instance를 여러개 운영하는게 낫다. 어쩔 수 없이 큰 메모리를 써야하는 경우 ElasticCache*를 쓰면 상관 없다.

(*ElasticCache ? 대용량 분산 in memory cache*를 손쉽게 생성하고 확장할 수 있는 서비스. 읽기 중심의 서비스를 제공하거나 빠르게 데이터를 분석해야 하는 경우에 적합하다. Memcached, Redis 캐시 엔진을 지원한다. 대표적으로 2가지 캐싱 전략이 있다. Lazy loading, Write-through. Lazy loadin은 데이터 요청이 있을 때만 캐싱하는 것이다. 즉, 최소 1번은 데이터를 조회해야만 캐싱이 된다. 최초 조회 시 DB에 직접 요청하기 때문에 느리다. 하지만 데이터가 갱신되었을 때 기존 캐싱 데이터를 무효화하면 된다는 간편함이 장점이다.  Write-through 방식은 데이터 갱신 시 캐시와 DB 모두에 업데이트 하는 방식이다. DB를 업데이트 하면 별도로 캐시도 업데이트 해줘야 한다. 하지만 항상 캐시에서 조회하므로 속도가 빠르다는 장점이 있다.)

(*in memory cache ? 모든 데이터를 메모리;RAM에만 올려놓고 사용하는 데이터 베이스의 일종)

(레디스는 싱글쓰레드기 때문에 O(N) 명령은 주의 해야 한다. 예컨대 keys, flushall, flushdb, delete collections, get all Collections 이런 것들)

-> 어쨌든 메모리 가용량을 다 써서 swap까지 쓰고 있다면? 해당 page 접속 시 오히려 느려질 수 있기 때문에 g g

-> 또한 레디스는 메모리 파편화가 발생할 수 있다. 

 

 

 

 

그런데 왜 redisd의 대체로 MongoDB를 채택한 곳들이 많을까? 어떤 특징이 있기에?

 

 

 

 

MongoDB의 특징

-> 몽고DB는 document database로 리턴 데이터가 아래와 같은 특징이 있다면 적합하다.

• 리턴 데이터를 부분적으로 사용하기 보다는 전체를 사용함
• 각 데이터가 상호 간 독립적임. 즉, 별도 정규화가 필요 없음
• 데이터 스펙이 변화 가능성이 큼 (데이터 추가 및 변경이 자유로워야 함 -> schema-less가 유리)

-> 또한 MongoDB는 풍부한 인덱스 기능을 제공한다. 여러개의 인덱스를 구성할 수 있고, 복합 인덱스도 지원한다. 인덱스를 자유롭게 추가할 수도 있다. 인덱스 생성에 따른 제약도 적고, 인덱스를 백그라운드로 생성할 수 있어서 서비스 중에도 부담 없이 인덱스를 추가할 수 있다.

그 외 일반적으로

-> 메모리맵을 활용하고 b-tree 구조를 통해 탐색하기 때문에 아주 빠른 읽기가 가능하다.

-> 안정적인 Replica Set 구성이 가능해서 가용성을 높일 수 있다.