마이크로서비스 아키텍쳐와 레디스

 

❐ Redis의 특징

---

1. 실시간 응답 (빠른 성능)

데이터베이스는 대부분 디스크에 Block 단위로 보조 기억장치에 데이터를 저장한다.

따라서 데이터를 조회할 때 직접 디스크에서 데이터를 Block 단위로 조회해서 속도가 느리다.

 

하지만 레디스와 같은 인메모리 형태의 데이터베이스에서는 모든 데이터가 컴퓨터의 메모리에서 관리된다.

디스크에 접근하는 과정이 필요 없기 때문에 데이터의 처리 성능이 굉장히 빠르다는 장점을 갖는다.

 

 

2. 단순성

레디스는 키-값 형태로 데이터를 관리할 수 있는 데이터 저장소다. String 뿐만 아니라 hash, hashSet 등

더욱 복잡하고 다양한 데이터 구조를 저장할 수 있도록 지원하며, 이런 데이터 타입은 프로그래밍의

기본 자료 구조와 밀접한 관련이 있어 추가적인 데이터의 가공 없이 애플리케이션에서 쉽게 사용할 수 있다.

 

+) 레디스는 내장된 다양한 자료 구조를 통해 [임피던스 불일치]를 해소하고 개발을 편리하게 할 수 있도록 지원한다.

💭 임피던스 불일치란?
기존 관계형 데이터베이스의 테이블과 프로그래밍 언어 간 데이터 구조, 기능의 차이로 인해 발생하는 충돌

💭 Redis에서 임피던스 불일치를 해소하는 방법은?
1. 다양한 데이터 구조 지원 
2. 직력화/역직렬화 지원
3. 스키마리스 구조(정해진 형식이 없음)

 

레디스가 단순하다는 또 다른 이유는 레디스는 싱글 스레드로 동작하기 때문이다. 

엄밀히 말하면 4개의 쓰레드를 사용한다. (메인 1개 + 보조 3개)

따라서 클라이언트의 커맨드를 처리하는 부분은 이벤트 루프를 이용한 싱글 스레드로 동작한다.

이러한 동작 메커니즘 때문에 배포도 쉽고, CPU가 적은 서버에서도 좋은 성능을 낼 수 있다.

 

 

3. 고가용성

레디스는 자체적으로 HA(High Avalablity)기능을 제공한다. 복제를 통해 데이터를 여러 서버에 분산시킬 수

있으며, [Sentinel]은 장애 상황을 탐지해 자동으로 [Fail-over]를 시켜준다.

 

애플리케이션이 센티널을 이용해 레디스에 연결하는 구조에서는 master에 장애가 발생하더라도 레디스로의

엔드포인트를 변경할 필요 없이 fail-over가 완료돼 정상화된 master 노드를 사용할 수 있다.

💭 Sentinel이란?
장애 발생시 운영 서비스에 영향 없도록 "마스터 모니터링" 및 "자동 장애 극복 조치" 해주는 서비스

 

 

4. 확장성

레디스에서 [클러스터 모드]를 사용한다면 쉽게 수평적 확장이 가능하다. 데이터는 레디스 클러스터 내에서

자동으로 샤딩된 후 저장되며, 여러 개의 복제본이 생성될 수 있다. 이때 어떤 샤드로 저장됐는지 신경쓰지 않아도

된다. 내부적으로 Cluster Bus라는 프로토콜에 의해 관리돼기 때문이다.

 

 

5. 클라우드 네이티브 - 멀티 클라우드

멀티 클라우드를 사용하면 데이터가 특정 지역이나 국가 내에 물리적으로 위치하도록 조절할 수 있어,

더 가까운 저장소에서 데이터를 처리하게 되므로 대기 시간을 줄이고 장애 상황에 더욱 강건하게 대응할 수 있다.

 

레디스는 멀티 클라우드 전략에서 그 중요성을 발휘해, 여러 클라우드 환경에 걸쳐 일관된 성능과 기능을

제공함으로써 서비스의 연속성과 데이터의 일관성을 보장한다.

 

 

 

 

 

❐ 마이크로 서비스 아키텍쳐에서 Redis의 역할

---

1. 데이터 저장소

레디스는 다음의 이유로 데이터 저장소 역할을 잘 수행할 수 있다.

• 간편한 설치와 간단한 사용법
• 적은 리소스로도 감당할 수 있는 막대한 처리량
• 다양한 자료 구조 제공
• 자체적으로 HA를 보장하기 때문에 별도의 설정(로드벨런서, 프록시)이 필요 없음.

 

물론 데이터가 영구 저장되지 않아 데이터의 영속성을 고민할 수 있지만,

AOF(Append Only Flie), RDB(Redis DataBase) 형식으로 디스크에 주기적으로 저장할 수 있다.

백업과 고가용성을 위한 방법은 책 뒤쪽에서 학습할 것 같음.

 

 

2. 메시지 브로커

🔘 레디스는 서비스 간 "메시지를 전달"할 때 매우 유용하게 사용할 수 있다.

pub/sub에서 모든 데이터는 전달된 뒤 삭제되는 일회성으로, 모든 메시징 상황에 적합하진 않지만
fire-and-forget 패턴이 필요한 "간단한 알림(notfication) 서비스"에서는 유용하게 사용할 수 있다.

 

 

🔘 레디스의 list 자료 구조는 "메시징 큐"로 사용하기 알맞다.

list에서 데이터는 빠르게 push/pop을 할 수 있으며, 애플리케이션은 list에 데이터가 있는지 매번 확인할
필요 없이 대기하다가 list에 새로운 데이터가 들어오면 읽어 갈 수 있는 "블로킹 기능"을 사용할 수도 있다.

Redis에서는 `BLPOP`과 `BRPOP` 명령어를 통해 리스트의 앞쪽(Left) 또는 뒤쪽(Right)에서 데이터를
꺼내되, 대기(block) 상태에서 동작할 수 있다.

 

 

🔘 레디스의 stream 자료 구조를 이용하면 "완벽한 스트림 플랫폼"으로 사용할 수 있다.

stream은 아파치 카프카 시스템에서 영감을 받아 만들어진 자료 구조로, 데이터는 계속해서 추가되는
방식으로 저장된다(append-only). Kafka 처럼 저장되는 데이터를 읽을 수 있는 소비자와 소비자 그룹이
존재해 데이터의"분산 처리"도 가능하며, 저장된 데이터를 "시간대별로 검색"하는 것도 가능하다.

 

 

 

 

 

---