무조건 RDBMS를 사용해야하는 걸까?
RDBMS는 실제 물리적 장치에 저장하기때문에 데이터를 영속적으로 관리할 수 있지만,
입출력에 다소 시간이 걸리는 단점이 존재한다. 이러한 여러가지 부분에 있어서 인증 토큰에 대해서는 Redis를 사용한다.
Redis
Remote Dictionary Server 약자로
Key-Value 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 데이터 베이스 관리 시스템 (NoSQL)
특징
- Key-Value 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 데이터 베이스 관리 시스템 (NoSql)
- 데이터베이스, 캐시, 메세지 브로커로 사용된다
- In-Memory 기반의 데이터 처리 및 저장을 제공하여 속도가 빠르지만 서버가 꺼지면 모든 데이터가 사라지기 때문에 보조 데이터베이스로 사용된다.
- 데이터를 디스크에 쓰는 구조가 아니라 메모리에서 데이터를 처리하기때문에 속도가 빠르다
- String, Lists,Sets,Sorted Sets, Hashes 자료 구조를 지원한다
- String : 가장 일반적인 key-value 구조의 형태
- Sets : String의 집합, 여러 개의 값을 하나의 value에 넣을 수 있다
- Sorted Sets : 중복된 데이터를 담지 않는 Set 구조에 정렬 Sort를 적용한 구조로 사용할 수 있다
- Lists : Array 형식의 데이터 구조, List를 사용하면 처음과 끝에 데이터를 넣고 빼는 건 빠르지만 중간에 데이터를 삽입하거나 삭제하는 것은 어렵다
- Single Threaded
- 한 번에 하나의 명렁만 처리할 수 있다 그렇기 때문에 중간에 처리 시간이 긴 명령어가 들어오면 그 뒤에 명령어들은 모두 앞에 있는 명령어가 처리될 때까지 대기가 필요하다 (하지만 get, set 명령어의 경우 초당 10만 개 이상 처리할 수 있을 만큼 빠르다)
SOCK 프로젝트에선 Redis의 특징 중 Single Threaded를 활용하여 레시피 인기도 상승에 대한 로직을 구현하였다
구현 방식에 대한 자세한 내용은 다음 포스팅에 작성하도록 하겠다
데이터 베이스가 있는데도 Redis라는 인메모리 데이터 구조 저장소를 사용하는 이유가 무엇일까
데이터베이스는 데이터를 물리 디스크에 직접 쓰기때문에 서버에 문제가 발생하여 다운되더라도 데이터가 손실되지 않는다. 하지만 매번 디스크에 접근해야 하기때문에 사용자가 많아질수록 부하가 많아져서 느려질 수 있다
일반적으로 서비스 운영 초반이거나 규모가 작은, 사용자가 많지 않은 서비스의 경우에는 WEB -WAS -DB 의 구조로도 데이터베이스에 무리가 가지 않는다.
하지만 사용자가 늘어난다면 데이터베이스가 과부하될 수 있기때문에 이때 캐시 서버를 도입하여 사용한다
그리고 이 캐시 서버로 이용할 수 있는 것이 바로 Redis이다
캐시는 한번 읽어온 데이터를 임의의 공간에 저장하여 다음에 읽을 때는 빠르게 결괏값을 받을 수 있도록 도와주는 공간이다
같은 요청이 여러번 들어오는 경우 매번 데이터 베이스를 거치는 것이 아니라 캐시 서버에서 첫 번째 요청 이후 저장된 결괏값을 바로 내려주기때문에 DB의 부하를 줄이고 서비스의 속도도 느려지지 않는 장점이다
캐시 서버는 Look aside cashe 패턴과 Write Back 패턴이 존재한다
Look aside cache
- 클라이언트가 데이터 요청
- 웹 서버는 데이터가 존재하는지 Cache 서버 먼저 확인
- Cache 서버에 데이터가 존재하면, DB에 데이터를 조회하지 않고 Cache 서버에 있는 결괏값을 클라이언트에게 반환 (Cache Hit)
- Cache 서버에 데이터가 존재하지 않다면, DB에 데이터를 조회하여 Cache 서버에 저장하고 결괏값을 클라이언트에게 반환 (Cache Miss)
Write Back
- 웹 서버는 모든 데이터를 Cache 서버에 저장
- Cache 서버에 특정 시간 동안 데이터가 저장됨
- Cache 서버에 있는 데이터를 DB에 저장
- DB에 저장된 Cache 서버의 데이터를 삭제
- insert 쿼리를 한 번씩 500번 날리는 것보다 insert 쿼리 500개를 붙여서 한 번에 날리는 것이 더 효율적이다는 원리이다
- 이 방식은 들어오는 데이터들이 저장되기 전에 메모리 공간에 머무르는데 이때 서버에 장애가 발생하여 다운된다면 데이터가 손실될 수 있다는 단점이 있다
Redis 사용에 주의할 점
- 서버에 장애가 발생했을 경우 그에 대한 운영 플랜이 꼭 필요하다
- : 인메모리 데이터 저장소의 특성상, 서버에 장애가 발생했을 경우 데이터 유실이 발생할 수 있다
- 메모리 관리가 중요하다
- 싱글 스레드의 특성상, 한 번에 하나의 명령만 처리할 수 있다. 처리하는데 시간이 오래 걸리는 요청, 명령은 피해야 한다
이 외에도 Master-Slave 형식의 데이터 이중화 구조에 대한 Redis Replication, 분산 처리를 위한 Redis cluster, 장애 복구 시스템 Redis Sentinel, Redis Topology, Redis Sharding, Redis Failover 등의 Redis를 더 효율적으로 사용하기 위한 개념들이 존재한다
📮개인 공부를 위한 공간으로 틀린 부분이 있을 수도 있습니다.📮
문제점 및 수정 사항이 있을 시, 언제든지 댓글로 피드백 주시기 바랍니다.
'TIL' 카테고리의 다른 글
Test Code ? 왜 그리고 어떻게 작성해야할까 ? (0) | 2023.07.04 |
---|---|
MSA (0) | 2023.07.03 |
FCM(Firebase Cloud Messaging) (0) | 2023.05.26 |
[GreenCherry/React, Spring boot, PWA, FCM] FCM을 활용한 백그라운드에서 알림 구현 (0) | 2023.05.25 |
[JPA] OSIV와 성능 최적화 (0) | 2023.03.22 |